Empirisme sans concession
Métriques — mesurer la valeur, pas l'activité
Les métriques AIAD informent les décisions — elles ne les dictent pas. Générées organiquement par le cycle SDD lui-même et persistées dans .aiad/metrics/, elles mesurent des outcomes, jamais de la vélocité.
Philosophie : outcome, pas output
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, et on lit des tendances plutôt que de réagir aux fluctuations. C'est la cinquième valeur du framework — l'empirisme sans concession — appliquée à la mesure elle-même.
Conséquence directe : on ne mesure pas la vélocité. Compter des points de story ou des lignes de code, c'est mesurer de l'activité. SDD Mode mesure ce qui compte : la fonctionnalité livrée résout-elle le problème, reflète-t-elle l'intention, et le flux qui l'a produite est-il sain ? Une bonne métrique est actionnable, compréhensible, comparable et honnête — difficile à manipuler sans amélioration réelle (loi de Goodhart).
Le SQS — Spec Quality Score
Le SQS est la métrique d'entrée du cycle : il conditionne l'ouverture de l'Execution Gate. Cinq critères scorables — atomicité, précision, testabilité, non-ambiguïté, scope défini — complétés par un sixième critère non scorable, le Test de l'Étranger : une personne extérieure au projet comprendrait-elle la SPEC sans contexte oral ?
- SQS ≥ 4/5 → Gate ouverte, l'agent peut démarrer ;
- SQS < 4/5 → retour en révision, avec plan de remédiation critère par critère ;
- SQS partiellement non scorable → score
?/5et Gate INCONNUE — verdict JNSP, décision humaine requise. Jamais d'auto-blanchiment.
Une SPEC au format EARS dont le lint strict (règles R1-R7) ne relève aucune violation gagne +1 garanti sur le critère Testabilité ; une seule violation force ce critère à 0.
Les métriques SDD
Propres au cycle, elles mesurent la santé du processus spec-anchored. Elles sont calculées par /aiad retro et agrégées par les dashboards :
| Métrique | Ce qu'elle mesure | Cible |
|---|---|---|
| SQS moyen | Qualité des SPECs livrées sur la période. | ≥ 4/5 — alerte sous 3,5/5 |
| Taux de drift | SPECs désynchronisées du code, détectées par /sdd drift-check. | Tendance en baisse |
| First-time success rate | Sessions agent réussies du premier coup, sans itération corrective. | > 70 % |
| Taux d'alignement intention/livraison | Intent Statements dont le CRITÈRE DE DRIFT est respecté — vérifié à l'Atelier d'Intention. | > 80 % |
| Ratio code généré / manuel | Part du code produite par les agents vs écrite à la main. | > 80/20 |
Un first-time success sous 70 % pointe vers un AGENT-GUIDE obsolète ou des SPECs mal rédigées ; un taux d'alignement sous 80 % interroge la qualité des Intent Statements eux-mêmes.
DORA Metrics
Les quatre indicateurs du programme DORA (Google) mesurent la performance de livraison. AIAD les génère organiquement depuis .aiad/metrics/deployments/ — aucune saisie supplémentaire. La commande : /aiad dora.
| Métrique | Ce qu'elle mesure | Niveau Elite |
|---|---|---|
| Deployment Frequency | Fréquence des mises en production. | ≥ 1/jour |
| Lead Time for Changes | Délai commit → production (AIAD mesure aussi le Lead Time étendu intention → production). | < 1 heure |
| Change Failure Rate | Pourcentage de déploiements causant un incident. | < 5 % |
| MTTR | Temps moyen de rétablissement après incident. | < 1 heure |
Le rapport positionne chaque métrique sur l'échelle Elite / High / Medium / Low, puis remonte aux causes AIAD vérifiables : SPECs non atomiques, Gate fermée à répétition, SQS bas, gouvernance sautée. Ne visez pas Elite immédiatement — une progression d'un niveau par trimestre est réaliste, et un Change Failure Rate honnête vaut mieux qu'un hotfix non tracé.
Flow Metrics
Là où DORA évalue la livraison, les Flow Metrics évaluent la santé du flux de valeur, de l'idée au déploiement. La commande : /aiad flow.
| Métrique | Ce qu'elle mesure | Repère |
|---|---|---|
| Cycle Time | Durée exécution → déploiement (percentile 85, robuste aux valeurs aberrantes). | < 3 jours |
| Lead Time | Durée Intent créé → déploiement, avec décomposition par étape. | < 2 semaines |
| Throughput | SPECs livrées par semaine. | Stable ou en hausse |
| WIP | SPECs en cours simultanément. | Limite explicite par PE |
| Flow Efficiency | Temps actif / temps total. | 15-40 % (normal) |
L'analyse la plus précieuse est la décomposition du Lead Time, qui localise les goulots d'étranglement : un Lead Time de 15 jours avec un Cycle Time de 2 jours révèle 13 jours d'attente cachée — souvent entre l'Intent et la SPEC, ou dans les itérations de Gate. La loi de Little (Lead Time = WIP / Throughput) sert de levier : pour accélérer, réduire le WIP ou augmenter le Throughput.
Les dashboards
| Commande | Format | Usage |
|---|---|---|
/aiad dashboard | ASCII, dans le chat | Rituel d'équipe — hebdomadaire (opérationnel, 15-20 min) ou mensuel (stratégique, 30-45 min, avec stakeholders). |
/aiad dashboard-html | HTML statique multi-pages dans dashboard/ | Pilotage continu — intents, SPECs, traçabilité, métriques, gouvernance, drifts, changelog. Régénéré à la demande, publiable (GitHub Pages). |
Les deux puisent dans la même persistance .aiad/metrics/ (deployments, specs, standup, drift, retro…). Trois signaux du dashboard hebdomadaire déclenchent une action immédiate : un Cycle Time qui double, un SQS moyen sous 3,5/5, un Change Failure Rate au-dessus de 15 %.
Un déploiement non tracé n'est pas un trou à combler par une estimation — c'est un signal que le processus fuit. Les commandes métriques alertent explicitement plutôt que de moyenner sur un échantillon incomplet.
Indicateurs de succès par responsabilité
| Responsabilité | Indicateurs de référence |
|---|---|
| Product Manager | Atteinte des Outcome Criteria > 70 %, satisfaction utilisateur > 8/10, adoption fonctionnalité > 60 % en 1 mois. |
| Product Engineer | SQS moyen ≥ 4/5, taux d'alignement intention/livraison > 80 %, Cycle Time < 3 jours, drift en baisse. |
| Agents Engineer | First-time success > 70 %, adoption agents > 90 %, ratio généré/manuel > 80/20, faux positifs < 20 %. |
| QA Engineer | Couverture > 80 % backend / > 70 % frontend, bugs production en baisse (−20 %/trimestre), MTTD < 24 h. |
| Tech Lead | DORA en progression, MTTR < 4 h, dette technique stable ou en baisse. |
Une revue plus rapide n'est pas une revue meilleure : sur 1,02 million de pull requests étudiées en 2026, la revue impliquant des agents gagne du temps sans gagner en qualité. Les indicateurs de vitesse (Cycle Time, Lead Time, Throughput) se lisent donc toujours avec des indicateurs de qualité et d'intention (Change Failure Rate, drift, alignement intention/livraison). L'écart entre le gain de productivité à l'écriture du code et le gain, bien plus faible, à la livraison d'un logiciel fiable porte un nom — la Verification Tax — et c'est ce que l'investissement amont en SPEC et en Gate cherche à réduire. Voir le rôle du QA Engineer et la vérification dans la boucle Valider.
La boucle d'amélioration continue
Les métriques n'ont de sens que branchées sur une boucle PDCA : identifier un problème via les métriques, formuler une hypothèse, changer à petite échelle, mesurer avant/après, standardiser ou réessayer. Deux commandes l'outillent :
/aiad retro— la rétrospective collecte Lessons Learned et Human Learnings, calcule les métriques d'itération et engage 1 à 3 actions maximum, vérifiées à la rétrospective suivante ;/sdd context— la boucle de feedback post-session compare le Context Engineering Budget estimé au réel (tokens, dégradation, durée) et recommande les optimisations de la prochaine session.
Cadence : surveillance automatique quotidienne, review équipe hebdomadaire (rétrospective), review outcomes mensuelle (sync stratégique), review du framework lui-même trimestrielle. Commencez avec cinq à sept métriques essentielles — mesurer tout, c'est ne piloter rien.