Aller au contenu

ADR — Cadre AI Coding N1/N2/N3 (V1)

Statut : superseded par l’ADR du 20 juillet 2026 sur le modèle à deux voies. Cette page conserve les principes historiques utiles, sans le suivi opérationnel nominatif de l’époque.

Contexte

L’usage croissant des agents de code augmentait la vitesse de livraison, mais aussi le risque de multiplier des systèmes difficiles à reprendre. La grille abstraite Bas / Moyen / Haut ne donnait pas de processus concret pour classer un projet, répartir l’ownership ou choisir le niveau de review.

Le besoin était double :

  1. préserver l’autonomie sur les changements à faible rayon d’impact ;
  2. garantir un pilotage technique sur les systèmes critiques ou difficiles à inverser.

Options envisagées

A — Process technique uniforme

Tous les changements destinés à la production suivent le même niveau de review. Cette option maximise la cohérence, mais impose un coût disproportionné aux changements simples.

B — Aucun cadre commun

Chaque contributeur choisit son niveau de garde-fou. Cette option préserve la vitesse locale, mais ne permet pas le passage à l’échelle ni une reprise fiable par l’équipe technique.

C — Cadre à trois niveaux

Le processus dépend du risque : probabilité d’erreur × rayon d’impact × irréversibilité. Les standards communs s’appliquent à tous les niveaux.

Décision historique

La V1 retient l’option C.

Niveau Nature Mode de travail
N1 Faible impact, changement local et réversible Build autonome avec standards communs
N2 Impact significatif mais borné Build produit avec Tech Buddy et review adaptée
N3 Paiement, contrats, sécurité, données sensibles ou système difficile à inverser Ownership technique explicite, review du plan et review finale

Principes associés

  1. Le scope d’impact détermine le niveau, pas l’ancienneté du projet ni la personne qui le porte.
  2. Les standards sont mutualisés dès N1 : conventions, tests, règles d’agent et CI limitent le coût de reprise.
  3. Un Tech Buddy est attaché au projet N2, avec un temps de revue ciblé plutôt qu’une rotation sans contexte.
  4. Un nouveau sujet N3 ne démarre pas en build produit solo. Produit et technique le cadrent ensemble.
  5. Une exception N3 reste explicite et assumée, avec des garde-fous proportionnés.
  6. La classification est réévaluée lorsque le scope change.

Rationale

  • Un changement local et réversible ne justifie pas le même coût qu’un système de paiement ou de signature.
  • Les standards communs réduisent le risque qu’un projet simple devienne impossible à maintenir lorsqu’il grandit.
  • Le Tech Buddy apporte du contexte et du discernement sans transférer tout le build à la technique.
  • Les systèmes critiques demandent une responsabilité technique de bout en bout.

Conséquences

  • Les projets existants construits hors cadre passent par une transition proportionnée, sans rétro-blocage automatique.
  • La conformité minimale du repo commence avant le pairing ; elle n’a pas besoin d’être parfaite pour ouvrir la discussion.
  • La capacité de review technique doit être suivie pour éviter de créer un nouveau goulot.
  • Les fiches de rôle et l’onboarding doivent expliquer la frontière entre autonomie produit et ownership engineering.

Pourquoi cette décision a été remplacée

La matrice N1/N2/N3 était précise, mais lourde à appliquer et facile à interpréter différemment. Le modèle V2 réduit le choix à deux voies :

  • Vibe pour les sujets bornés, réversibles et à faible risque ;
  • Engineer dès qu’un sujet exige une responsabilité technique forte.

La V2 conserve les principes utiles de cette ADR : standards mutualisés, classification par risque, review proportionnée et ownership technique des sujets critiques.

Sources