Les Métriques et l'Amélioration Continue
Définition
Section intitulée « Définition »Les métriques AIAD informent les décisions — elles ne les dictent pas. La distinction est fondamentale. Dans une approche data-driven, les chiffres décident. Dans l’approche data-informed d’AIAD, les chiffres éclairent. On optimise la valeur, pas la métrique. On comprend les tendances, on ne réagit pas aux fluctuations.
Quatre caractéristiques définissent une bonne métrique : actionnable (pointe vers une amélioration concrète), compréhensible (l’équipe sait ce qu’elle mesure et pourquoi), comparable (permet de voir l’évolution dans le temps), et honnête (difficile à manipuler sans amélioration réelle).
L’important n’est pas de mesurer beaucoup — c’est de mesurer ce qui compte.
Pourquoi les métriques sont structurées en catégories
Section intitulée « Pourquoi les métriques sont structurées en catégories »Cinq catégories couvrent les dimensions essentielles de la performance d’une équipe AIAD. Sans cette structure, les équipes tendent à soit tout mesurer (paralysie par l’analyse), soit mesurer uniquement ce qui flatte (vanity metrics). Les cinq catégories forment un tableau de bord équilibré : productivité, qualité, efficacité IA, outcomes, et équipe.
Catégorie 1 : Productivité
Section intitulée « Catégorie 1 : Productivité »La productivité mesure la capacité de l’équipe à livrer de la valeur rapidement. Sans visibilité sur le flux de livraison, impossible de détecter les goulots d’étranglement.
| Métrique | Cible | Fréquence |
|---|---|---|
| Cycle Time (PLANIFIER → INTÉGRER) | < 3 jours | Hebdomadaire |
| Lead Time (Idée → Production) | < 2 semaines | Hebdomadaire |
| Throughput (fonctionnalités livrées) | Stable ou en hausse | Hebdomadaire |
| Release Frequency | Quotidien (idéal) | Hebdomadaire |
| Deployment Success Rate | > 95 % | Hebdomadaire |
Les signaux d’alerte : un Cycle Time en hausse indique des fonctionnalités trop complexes ou des problèmes avec les agents ; un Lead Time stagnant pointe vers des goulots dans les boucles itératives ; un Throughput en baisse interroge la qualité des SPECs ou la motivation de l’équipe.
Catégorie 2 : Qualité
Section intitulée « Catégorie 2 : Qualité »La qualité mesure la robustesse du code et la fiabilité du produit. La vélocité sans qualité est une illusion — les bugs en production détruisent la confiance des utilisateurs.
| Métrique | Cible | Fréquence |
|---|---|---|
| Couverture de Tests | > 80 % backend, > 70 % frontend | Hebdomadaire |
| Bugs en Production | Tendance en baisse (−20 %/trimestre) | Hebdomadaire |
| Mean Time To Detect (MTTD) | < 24 h | Mensuel |
| Mean Time To Repair (MTTR) | < 4 h | Mensuel |
| Dette Technique | Stable ou en baisse | Mensuel |
| First-Time Success Rate | > 70 % | Hebdomadaire |
Les signaux d’alerte : une couverture inférieure à 80 % interroge la configuration de l’Agent Quality ; des bugs en hausse questionnent le respect de la DoOD ou la suffisance de la validation QA ; un MTTR élevé révèle un monitoring insuffisant ou une architecture trop couplée.
Catégorie 3 : Efficacité IA
Section intitulée « Catégorie 3 : Efficacité IA »L’efficacité IA mesure la performance de l’écosystème d’agents. Les agents sont au cœur d’AIAD — si l’écosystème sous-performe, toute la méthode en souffre.
| Métrique | Cible | Fréquence |
|---|---|---|
| Taux d’Adoption Agents | > 90 % | Hebdomadaire |
| First-Time Success Rate (Agents) | > 70 % | Hebdomadaire |
| Ratio Code Généré / Manuel | > 80/20 | Hebdomadaire |
| Itérations Moyennes par Feature | < 3 | Hebdomadaire |
| Taux de Faux Positifs (Agents) | < 20 % | Mensuel |
| Temps Résolution Problèmes Agents | < 2 h | Mensuel |
| Satisfaction PE sur Écosystème | > 8/10 | Mensuel |
Les signaux d’alerte : une adoption inférieure à 90 % révèle soit des agents peu performants, soit une résistance culturelle ; un First-Time Success inférieur à 70 % pointe vers un AGENT-GUIDE obsolète ou des SPECs mal rédigées ; des faux positifs supérieurs à 20 % signalent un besoin de tuning des agents.
Catégorie 4 : Outcomes
Section intitulée « Catégorie 4 : Outcomes »Les outcomes mesurent la valeur réelle livrée aux utilisateurs et stakeholders. Livrer du code ne suffit pas — ces métriques vérifient que ce qui est livré résout réellement les problèmes des utilisateurs.
| Métrique | Cible | Fréquence |
|---|---|---|
| Atteinte Outcome Criteria | > 70 % | Mensuel |
| Satisfaction Utilisateur (NPS, CSAT) | > 8/10 | Mensuel |
| Adoption Fonctionnalité | > 60 % en 1 mois | Par feature |
| Time to Value | < 5 min (selon produit) | Mensuel |
| Retention Rate | > 80 % (selon produit) | Mensuel |
| Business Impact | Variable selon contexte | Mensuel |
Les signaux d’alerte : une atteinte des outcomes inférieure à 70 % interroge la qualité de la discovery ou la validité des hypothèses ; une satisfaction inférieure à 8 indique que les fonctionnalités ne résolvent pas le vrai problème ; une faible adoption questionne le go-to-market ou l’utilité réelle.
Catégorie 5 : Équipe
Section intitulée « Catégorie 5 : Équipe »L’équipe mesure le bien-être et l’engagement. Une équipe épuisée ou démotivée ne peut pas performer durablement — ces métriques sont des indicateurs avancés de problèmes à venir.
| Métrique | Cible | Fréquence |
|---|---|---|
| Satisfaction Équipe | > 7/10 | Hebdomadaire (pulse) |
| Psychological Safety | > 8/10 | Mensuel |
| Temps en Flow | > 4 h/jour | Hebdomadaire |
| Turnover | < 10 % /an | Annuel |
| Sick Days | Baseline stable | Mensuel |
Les signaux d’alerte : une satisfaction inférieure à 7 révèle des problèmes de management, de surcharge ou de manque d’autonomie ; un temps en flow inférieur à quatre heures signale trop d’interruptions ou trop de synchronisations ; un turnover élevé alerte sur du burnout ou un manque de perspectives.
Les deux dashboards
Section intitulée « Les deux dashboards »Dashboard hebdomadaire
Section intitulée « Dashboard hebdomadaire »Le dashboard hebdomadaire donne à l’équipe une vision claire de sa performance opérationnelle. Il couvre :
- Flux : Cycle Time, Throughput, WIP
- Qualité AIAD : qualité des specs, taux de premier passage à l’Execution Gate, drifts détectés
- DORA : Deployment Frequency, Change Failure Rate
- Efficacité IA : adoption des agents, First-Time Success
Trois signaux déclenchent une action immédiate : un Cycle Time qui double, un score qualité des specs inférieur à 3,5/5, ou un Change Failure Rate supérieur à 15 %.
Dashboard mensuel
Section intitulée « Dashboard mensuel »Le dashboard mensuel donne aux stakeholders une vision de la valeur livrée et des tendances. Il couvre :
- DORA : Deployment Frequency, Lead Time, Change Failure Rate, MTTR
- Flow Metrics : Cycle Time P85, Lead Time, Throughput, WIP, Flow Efficiency
- Outcomes : atteinte des criteria, NPS, adoption, impact business
- Santé technique : dette technique, ADRs pris, composants en attention
- Top 3 des améliorations nécessaires
Ce dashboard ne doit jamais devenir un outil de micro-management, une liste de vanity metrics, ou un rapport sans actions associées.
DORA Metrics et Flow Metrics
Section intitulée « DORA Metrics et Flow Metrics »AIAD intègre nativement les DORA Metrics (DevOps Research and Assessment) et les Flow Metrics comme indicateurs de performance de livraison. Contrairement aux frameworks qui les imposent comme overhead de saisie, AIAD les génère organiquement depuis le cycle de travail : chaque boucle itérative produit des données dans .aiad/metrics/, et les commandes d’agrégation les calculent automatiquement.
DORA Metrics
Section intitulée « DORA Metrics »| Indicateur | Description |
|---|---|
| Deployment Frequency | Fréquence de mise en production |
| Lead Time for Changes | Délai intention → production |
| Change Failure Rate | Pourcentage de déploiements causant un incident |
| MTTR | Temps moyen de rétablissement |
Flow Metrics
Section intitulée « Flow Metrics »| Indicateur | Description |
|---|---|
| Cycle Time | Durée exécution → déploiement |
| Lead Time | Durée intention → déploiement |
| Throughput | Fonctionnalités livrées par période |
| WIP | Fonctionnalités en cours simultanément |
| Flow Efficiency | Temps actif / temps total (calculé depuis Lead Time vs Cycle Time) |
Le processus d’amélioration continue
Section intitulée « Le processus d’amélioration continue »L’amélioration continue suit le cycle PDCA adapté :
PLAN : identifier un problème via les métriques, analyser la cause racine, définir une hypothèse d’amélioration.
DO : implémenter le changement à petite échelle, documenter, mesurer.
CHECK : analyser avant/après, vérifier si l’hypothèse est validée, identifier les effets de bord.
ACT : si succès, standardiser ; si échec, apprendre et réessayer autrement.
La technique des 5 Pourquoi
Section intitulée « La technique des 5 Pourquoi »La technique des 5 Pourquoi structure l’analyse de cause racine. Exemple : le Cycle Time a augmenté — pourquoi ? Les agents font plus d’erreurs. Pourquoi ? Les SPECs sont moins claires. Pourquoi ? Un nouveau PM n’est pas encore formé à la rédaction de SPECs. Pourquoi ? Il n’y a pas de processus d’onboarding. Action : créer un guide d’onboarding pour la rédaction de SPECs.
La cadence d’amélioration :
- Quotidienne : surveillance automatique (système)
- Hebdomadaire : review des métriques équipe (Rétrospective)
- Mensuelle : review des métriques outcomes (Synchronisation Alignement Stratégique)
- Trimestrielle : review du framework AIAD lui-même (équipe et Supporters)
L’amélioration du framework lui-même
Section intitulée « L’amélioration du framework lui-même »AIAD n’est pas gravé dans le marbre. Il doit évoluer avec l’équipe, les outils, et les apprentissages. Une équipe qui applique AIAD sans jamais l’adapter finit par suivre un processus obsolète.
La revue trimestrielle pose six questions :
- Les boucles itératives sont-elles fluides — y a-t-il des frictions ou des goulots, faut-il modifier des étapes ?
- Les synchronisations sont-elles utiles — apportent-elles de la valeur, faut-il adapter la fréquence ou le format ?
- Les artefacts sont-ils vivants et utiles — PRD, ARCHITECTURE, AGENT-GUIDE sont-ils à jour et utilisés quotidiennement ?
- L’écosystème d’agents est-il optimal — les agents apportent-ils 80 %+ de la valeur, y a-t-il de nouveaux agents à explorer ?
- Les métriques sont-elles actionnables — informent-elles vraiment les décisions, y a-t-il des vanity metrics à retirer ?
- L’équipe est-elle épanouie — satisfaction supérieure à 7/10, turnover acceptable, équilibre vie pro/perso respecté ?
Anti-patterns des métriques
Section intitulée « Anti-patterns des métriques »“On mesure tout ce qu’on peut mesurer.” Paralysie par l’analyse. Commencer avec cinq à sept métriques essentielles. Ajouter uniquement si un besoin réel émerge.
“Les métriques sont bonnes, donc tout va bien.” Les métriques peuvent être optimisées sans amélioration réelle — c’est la Goodhart’s Law : “Quand une mesure devient un objectif, elle cesse d’être une bonne mesure.” Croiser les métriques quantitatives avec le feedback qualitatif.
“On n’a pas le temps de faire de l’amélioration continue.” L’équipe court après les deadlines sans jamais s’arrêter pour s’améliorer. Les mêmes problèmes se répètent. L’amélioration continue n’est pas un luxe — c’est un investissement. Une heure de rétrospective bien faite économise des jours de travail inefficace.