Aller au contenu

Criticité des features

Définition

Cadre qui classe chaque feature / tool selon le rayon d'explosion d'un échec, et qui détermine la voie (méthode + validation) avant mise en prod. Canon opérationnel V2 : modèle binaire Vibe / Engineer dans ai-coding-vibe-coding. Cette page conserve l'historique V0/V1 (Bas-Moyen-Haut → N1/N2/N3).

Pourquoi on en parle

Le mode "build solo sans review tech" qui a permis à Romain et Alban d'aller vite est en train d'atteindre ses limites : - Multiplie le risque de désalignement avec l'archi - Ne tient pas à l'échelle si on recrute d'autres profils builders - Crée des sujets critiques (paiements, échéancier, contrats) sans garde-fou

D'un autre côté, mettre tous les sujets sous le même process tech (review code ligne par ligne, PR, etc.) tuerait la vélocité sur des sujets non-critiques (UX back-office, exploration produit).

État actuel (auto)

Dernière mise à jour : 2026-07-20

V2 (2026-07-20) — canon courant · accepted

Modèle 2 voies (ADR 2026-07-20, concept) :

  • Une question : si ça tombe ou produit un résultat faux — quelles conséquences, qui les subi ?
  • Vibe : échec interne / faible conséquence → vibe coding + PR + review IA ; Tech Buddy si pas d'owner tech.
  • Engineer : échec subi par un tiers (ou doute) → engineers only, peer review humaine, tests critiques, audit DORA.
  • Tech Buddy = filet transversal (déclenché par absence d'owner tech), pas un 3ᵉ niveau de criticité.
  • Mapping historique : N1 ≈ Vibe · N2 ≈ Vibe + Tech Buddy (désormais découplé) · N3 ≈ Engineer.

Tech Buddy démarré : premier point outil d'analyse 20/07.

V1 (21/05) — superseded (archive)

Matrice N1/N2/N3 — ADR 2026-05-21, synchro 21/05 PM. Validée sur le fond, jamais passée accepted ; remplacée par V2.

V0 (30/04) — superseded

Bas / Moyen / Haut — ADR 2026-04-30, meeting.

Décisions liées

Projets et areas impactés

Sources