RFC NNNN —

Auteur : <nom + repo d'origine>
Date : YYYY-MM-DD
Statut : Draft | Under Review | Accepted | Rejected | Superseded by #MMMM
Apps consommatrices concernées : <liste des apps qui bénéficient directement>

Summary

Motivation

Quel problème concret cette RFC résout-elle ?
Qui est impacté aujourd'hui (apps consommatrices, cas d'usage) ?
Quelles sont les conséquences si on ne fait rien ?
Y a-t-il un délai/urgence (incident sécurité, deadline upstream) ?

Non-goals

API proposée

Code Rust complet des nouvelles signatures publiques. Exemple d'utilisation côté consommateur.

// Signature complète
pub fn new_api(...) -> ... { ... }

// Exemple d'usage
async fn handler(...) -> Response {
    let result = new_api(...)?;
    // ...
}

Analyse de compatibilité

Checklist :

API existante non modifiée → non-breaking (patch/minor possible).
API existante étendue avec défaut → non-breaking (minor).
API existante modifiée ou supprimée → breaking (major requis + guide migration).
Nouveau comportement par défaut → évaluer l'impact sur les consommateurs, feature-flagger si risque.
Changement de schéma DB → prévoir une migration réversible.
Changement de format sérialisé → prévoir un migrateur de données persistantes existantes.

Alternatives considérées

Minimum 3 alternatives avec analyse pros/cons, y compris "ne rien faire". Sans ça la RFC est incomplète : on ne peut pas juger une proposition sans son coût relatif.

Alternative A (recommandée) :

Pros : …

Cons : …

Alternative B :

Pros : …

Cons : …

Alternative C (ne rien faire / garder le workaround) :

Pros : zéro coût, zéro risque.

Cons : dette accumulée dans les apps consommatrices, risque de divergence.

Testing plan

Tests unitaires obligatoires :

Happy path (au moins 1).
3 cas d'erreur minimum (input invalide, contrainte violée, timeout/panic path).

Tests d'intégration si la RFC touche :

Un service : test avec DB in-memory ou MockDatabase SeaORM.
Un middleware : test avec client axum fake.
Une migration : test up/down avec vérification des données existantes.

Tests de non-régression :

Code consommateur pré-RFC doit encore compiler sans warning.

Doctests :

Au moins 1 exemple copie/collable par item public, exécuté comme doctest.

Benchs (si sensitive-perf) :

Comparaison avant/après.
Régression > 10 % bloque le merge sans justification écrite.

Migration guide

Section à copier telle quelle dans le CHANGELOG.md au moment du merge.

### API changes

**Before (vX.Y.Z)** :
\`\`\`rust
old_api(foo, bar);
\`\`\`

**After (vX'.Y'.Z')** :
\`\`\`rust
new_api(foo, bar, NewConfig::default());
\`\`\`

### Migration steps

1. Bump `Cargo.toml` à vX'.Y'.Z'.
2. `cargo fix --edition-idioms` handles most of it.
3. Manuel : pour chaque appel à `old_api`, décider si `NewConfig::default()` convient.

Open questions

Liste des points en suspens. La RFC ne peut pas être acceptée tant qu'ils ne sont pas résolus :

Question 1
Question 2

Tracking issue

Lien vers l'issue GitHub où la RFC est discutée.

Score d'évaluation (rempli par les reviewers)

Critère	Note (1-5)	Commentaire
Généralité
Stabilité API
Performance
Sécurité
Complexité d'implémentation
Charge de maintenance
Documentation
Total	/35	(≥ 25 pour Accepted)

eric / rustwarden