ADR : Grille de criticité + process de review différencié par feature¶

Contexte¶

Le mode "build solo sans review tech" a permis à Romain et Alban d'aller vite sur les outils internes. Limites identifiées au meeting 2026-04-30 :

Risque de désalignement avec l'archi (cf cassage des services à chaque refacto schéma)
Pas de garde-fou tech sur des sujets pourtant critiques (calcul pénalités, votes, génération contrats, paiements indirects via Yousign)
Ne tient pas à l'échelle si on recrute d'autres builders (Romain : "ça va aggraver les problèmes")

À l'inverse, mettre tout sous le process tech complet (review code ligne par ligne, PR, etc.) tuerait la vélocité sur du back-office non-critique.

Options envisagées¶

Option A : Process tech uniforme pour tout ce qui va en prod¶

Avantages : sécurité maximale, cohérence.
Inconvénients : tue la vélocité produit, charge mentale insoutenable côté tech, ne reflète pas la réalité des trade-offs (cf refonte Retool faite en 1 semaine sans review code ligne par ligne).
Coût : élevé en vélocité.

Option B : Pas de review tech (statu quo)¶

Avantages : vélocité.
Inconvénients : déjà identifié comme insoutenable. Ne passe pas l'échelle.

Option C : Grille de criticité + review différencié¶

Description : classer chaque tool / feature par niveau de criticité. Niveau bas → pas de review. Niveau moyen → review du plan en langage naturel avant code. Niveau haut → review tech complet (plan + code, PR, garde-fous, tests).
Avantages : alignement charge tech / risque réel. Conserve la vélocité où c'est possible. Capture les sujets critiques.
Inconvénients : nécessite de tenir une grille à jour, demande discipline.

Décision¶

Option retenue : C — Grille de criticité + review différencié

Justification : "selon les sujets, il y a besoin ou non des process tech" (Romain). C'est la nature de la feature qui détermine le niveau de review, pas le profil de la personne qui code (build solo ≠ inacceptable par défaut).

Première itération de la grille à construire par Denis + Romain (réunion lundi 11h).

Conséquences¶

Positives attendues¶

Vélocité préservée sur les sujets non-critiques.
Sujets critiques (paiements, échéancier, votes, contrats, calcul pénalités) sécurisés.
Review prioritaire = review du plan, pas du code. C'est moins coûteux pour la tech (charge mentale) et capture la majorité des erreurs en amont.
Mutualisation du tooling (stack, rules Cursor, flags TS) → rend les paires reviewables cross-équipes (cf Tooling Days).
Permet d'absorber les futurs recrutements en build (profils tech ou non-tech) avec un cadre.

Négatives acceptées¶

La grille devra être maintenue dans le temps (qui owne ? probablement Denis avec input Romain/Alban).
Risque de "déjouer la grille" en sous-estimant la criticité d'une feature → besoin d'un retour de relecture si nécessaire.

Reversibilité¶

Coût d'annulation : bas. Si la grille ne marche pas, on peut revenir au statu quo ou durcir.

Plan d'implémentation¶

[x] Décision prise au meeting 2026-04-30
[ ] Denis + Romain (lundi 11h) : draft initial de la grille de criticité (critères + exemples par tool)
[ ] Tous : test du modèle entre les 4 (Romain, Alban, Denis, Vincent) avant d'élargir
[ ] Vincent : commencer à intégrer la pratique "review des plans en langage naturel" dans son interaction avec Alban
[ ] Romain + Alban : adopter le pattern "plan d'abord, code ensuite" pour les features moyennes/hautes criticité
[ ] Phase 2 : mutualisation stack / rules dans les Tooling Days

Métriques de succès¶

Grille rédigée et partagée d'ici fin mai 2026
Aucun incident critique sur des features classées "bas" (sinon = mauvaise classification)
Tous les contributeurs build (Romain, Alban + futurs recrutements) connaissent la grille
Charge mentale tech sur les reviews reste acceptable (à mesurer subjectivement avec Denis/Vincent à 3 mois)

Sources¶

Révisions¶

2026-04-30 : créée et acceptée (status: accepted)