Le tableau de bord qui brille et signifie moins
Un VP engineering que j'ai rencontré était ravi : depuis le déploiement des assistants de code IA, la fréquence de déploiement avait nettement bondi et le délai de mise en production avait chuté. Sur le tableau de bord DORA, l'équipe semblait avoir changé de dimension du jour au lendemain. Puis le taux d'incidents a grimpé, les seniors se sont plaints de la charge de revue, et une fonctionnalité livrée vite a demandé trois semaines de pompiers pour se stabiliser. Les métriques disaient que c'était mieux. Les ingénieurs savaient que c'était différent.
Les métriques DORA — fréquence de déploiement, délai de mise en production, taux d'échec des changements et temps de rétablissement — sont le standard du secteur pour mesurer la livraison logicielle depuis dix ans, et à juste titre. Le programme de recherche DORA(lien externe, nouvel onglet) les a bâties sur des preuves solides reliant la performance de livraison aux résultats de l'organisation. Mais elles ont été conçues pour un monde où les humains écrivaient l'essentiel du code, et l'IA casse discrètement l'un de leurs postulats cachés.
Ce que les métriques supposaient en silence
Les métriques DORA fonctionnent comme des indicateurs indirects parce qu'elles supposent que l'effort pour produire du code est à peu près proportionnel à sa valeur. Sous une écriture humaine, livrer plus et plus vite signifiait généralement qu'une équipe était réellement plus efficace, parce qu'écrire du code était l'étape coûteuse et limitante. La vitesse était durement gagnée, donc la vitesse était un signal. C'est exactement ce lien que l'IA tranche. Quand un assistant génère une pull request en quelques minutes, un débit élevé ne prouve plus que l'équipe s'est améliorée — il prouve que le modèle est rapide.
J'ai posé le cœur de cet argument dans l'IA écrit plus de code mais livre moins de logiciel : la production n'est plus la contrainte, donc mesurer la production dit de moins en moins. Une équipe peut afficher une fréquence de déploiement spectaculaire tout en livrant un logiciel médiocre, parce que la métrique compte le mouvement et que l'IA a rendu le mouvement bon marché.
Le détournement que personne ne cherche
Le danger n'est pas la triche délibérée ; c'est que l'IA fausse ces métriques par défaut, sans que personne ne le décide. Le délai chute parce que la génération est instantanée, pas parce que l'équipe a supprimé de la friction. La fréquence de déploiement monte parce qu'il y a plus de code à déployer, pas parce que la valeur circule plus vite. Même le taux d'échec des changements peut sembler stable jusqu'au moment où la complexité accumulée d'un code généré par IA que personne ne comprend pleinement ressurgit en grappe d'incidents — la facture différée que je décrivais dans le mirage de la productivité.
C'est ainsi que les bonnes métriques pourrissent. Dès qu'un indicateur indirect devient une cible qui ne suit plus ce qu'il représentait, l'optimiser détériore le vrai résultat. Les équipes qui courent après les chiffres DORA dans un monde d'IA peuvent accélérer droit vers une base de code plus grosse, plus rapide à changer et discrètement plus difficile à faire confiance.
Ce qui mesure encore quelque chose de réel
Les métriques qui survivent à l'ère de l'IA mesurent la confiance et les résultats, pas le volume et la vitesse. Le taux d'échec des changements et le temps de rétablissement tiennent mieux que la fréquence de déploiement et le délai, parce qu'ils mesurent si ce que vous avez livré fonctionne vraiment, et l'IA ne rend pas les pannes moins coûteuses à réparer. Même celles-ci doivent être couplées à des signaux de qualité que l'IA ne peut pas gonfler : combien de reprise un changement déclenche, combien de temps la revue prend réellement, quelle part de la base de code l'équipe comprend vraiment.
C'est là que le framework SPACE(lien externe, nouvel onglet) prend sa place. Ses auteurs soutenaient il y a des années que la productivité des développeurs est multidimensionnelle — satisfaction, performance, activité, communication et efficacité — et ne peut se réduire à un seul chiffre de débit. Cet avertissement était prémonitoire. Dans un monde d'IA, les dimensions que SPACE couvre et que DORA ignore, surtout la satisfaction et le coût humain de la revue, sont précisément là où se cache désormais la vérité. Et cela rejoint directement pourquoi le ROI de l'IA est si difficile à prouver : les métriques faciles à compter ont bougé, mais la valeur n'a pas bougé avec elles.
Comment ajuster sans tout jeter
On n'abandonne pas DORA — on le réancre aux résultats et on ajoute ce que l'IA a rendu invisible. Quelques ajustements gardent le tableau de bord honnête :
- Pondérer les métriques de stabilité (taux d'échec, temps de rétablissement) au-dessus des métriques de vitesse, puisque la vitesse est désormais en partie une propriété du modèle, pas de l'équipe.
- Suivre le taux de reprise : à quelle fréquence le code livré doit être annulé, corrigé ou réécrit peu après la mise en production.
- Mesurer explicitement la charge de revue, parce que l'IA déplace l'effort de l'écriture vers la relecture, et un relecteur surchargé est un goulot caché qu'aucune métrique de débit ne montre.
- Demander directement à l'équipe à quel point elle a confiance dans le code qu'elle livre — le signal à la SPACE qu'aucune métrique automatique ne capture.
Le Takeaway
Si vos métriques DORA se sont améliorées juste après l'adoption de l'IA, résistez à l'envie de célébrer — vérifiez d'abord votre taux d'échec des changements, la reprise et la charge des relecteurs. La vitesse est devenue bon marché. La confiance, non. Mesurez ce que l'IA ne peut pas truquer, sinon votre plus beau tableau de bord décrira votre incendie le plus lent.
