Accélérer la production de code sans modifier le reste du processus n'accélère pas la livraison ; cela accélère l'apparition des problèmes en production. La rapidité d'une équipe de développement ne se mesure pas à sa vitesse d'écriture de code, mais à sa capacité à apporter rapidement des modifications en toute sécurité, et ces deux aspects sont devenus de plus en plus dissociés ces deux dernières années.
Il s'agit d'un phénomène mesuré, et non d'une suspicion.
Le rapport DORA 2024 de Google Cloud, qui a interrogé quelque 39 000 professionnels, a révélé qu'une augmentation de 251 % de l'adoption de l'IA était corrélée à une baisse de 1,51 TP3T en débit de livraison et de 7.2% en stabilité. L'explication fournie par les auteurs eux-mêmes n'est pas que le code est pire, mais que la taille des lots de modifications augmente : davantage de modifications sont envoyées en même temps, elles sont examinées moins minutieusement et elles sont déployées avec plus de risques.
L'étude METR de juillet 2025 a apporté un éclairage supplémentaire. Lors d'un essai contrôlé mené auprès de 16 développeurs expérimentés sur 246 tâches concrètes, les participants ont mis 191 TP3T de plus avec l'assistance de l'IA, alors qu'ils s'attendaient à être 241 TP3T plus rapides et qu'après le test, ils pensaient toujours avoir été 201 TP3T plus rapides. Il est important de noter que METR a lui-même réexaminé ce protocole en 2026 afin de déceler un éventuel biais de sélection, et une cohorte plus importante a révélé une différence bien moindre : le résultat exact fait encore débat.
Ce qui est incontesté, c'est la conclusion secondaire, et c'est elle qui est importante pour toute orientation : La perception de la vitesse et la vitesse réelle sont deux choses distinctes.. Une équipe peut avoir l'impression d'avancer beaucoup plus vite, même si le système met plus de temps à être mis en production.
L'ampleur de la modification est la variable cachée derrière la plupart des problèmes de déploiement. Une petite modification est minutieusement examinée, testée en profondeur, déployée rapidement et, en cas d'échec, la cause peut être identifiée en quelques minutes. Une modification importante ne permet rien de tout cela.
Variable | Petite monnaie | Grand changement |
|---|---|---|
Qualité de l'avis | Cela est parfaitement compris | « Cela semble raisonnable » |
Couverture des tests | Vérifiable | Partiel dans la pratique |
Temps de diagnostic en cas de panne | Minutes | Heures ou jours |
Coût de l'inversion | Faible | Stop : ça entraîne d'autres choses dans sa chute. |
Risque de déploiement | Limité | Accumulé |
Jusqu'à récemment, l'effort de développement limitait naturellement la taille des lots. Désormais, cette limite n'existe plus : la taille des lots augmente à moins qu'une restriction explicite ne soit décidée. Cette décision – limiter la taille des modifications – est probablement l'intervention la plus rentable dont dispose une équipe de développement aujourd'hui.
Mesurer le nombre de lignes de code, les tâches accomplies ou la « productivité par développeur » ne fait qu'aggraver la situation, car cela récompense précisément le comportement à l'origine du problème. Les quatre indicateurs DORA restent la norme raisonnable :
Fréquence de déploiement. À quelle fréquence un élément est-il mis en production ? Une fréquence élevée implique de petits lots.
Délai de livraison pour la monnaie. De la rédaction à la mise en production, ce système mesure l'ensemble du processus, et pas seulement l'écriture elle-même.
Modifier le taux d'échec. Quel pourcentage des déploiements aboutit à un incident ? C’est le contrepoids à la rapidité.
Délai de rétablissement du service. Combien de temps faut-il pour se rétablir ? Cela mesure la capacité opérationnelle réelle.
Les deux premiers indicateurs mesurent la vitesse, les deux derniers la stabilité, et ils doivent être considérés conjointement. Une équipe qui améliore les deux premiers mais détériore les deux derniers ne progresse pas : elle ne fait que reporter le travail sur l’avenir et l’équipe de soutien.
Limitez l'ampleur des modifications. La mesure la plus simple et la plus efficace. Elle oblige à décomposer le travail en unités compréhensibles et rétablit la qualité de la révision.
Investissez dans les tests avant la vitesse. À mesure que le code se développe, la sécurité devient primordiale. Sans tests fiables, la limitation de débit est un pari risqué et répété.
Automatisez le déploiement et la restauration. Si le déploiement est coûteux, l'équipe accumulera les modifications jusqu'à ce que cela en vaille la peine, et le gros lot sera réintégré.
Mesurer la stabilité avec la même visibilité que la vitesse. Si le tableau de bord du comité n'affiche que les livraisons, l'équipe optimisera ces dernières.
Ne récompensez pas la vitesse isolée. Les incitations influencent les comportements. Si l'on célèbre ce qui est offert plutôt que ce qui est subi, on offre davantage et on subit moins.
Au sein de nombreux comités, on s'attend à ce que l'aide apportée par l'IA se traduise par un doublement des résultats dans les mêmes délais. C'est cette attente qui engendre les pressions susceptibles de fragiliser la stabilité.
Cette discussion franche comporte deux volets. Premièrement : la génération de code s’est effectivement accélérée de manière réelle et mesurable. Deuxièmement : la livraison est un processus plus vaste – compréhension, revue, tests, intégration, déploiement et exploitation – et elle ne s’accélère que lorsque l’ensemble du processus est pris en compte.
Traduit en une phrase utilisable dans un conseil municipal : Nous avons réduit le coût d'une partie du processus, et non celui de l'ensemble du processus.. Pour tirer profit de cette amélioration, il faut investir dans le reste, et non exiger le double de la même chose.
C’est la même conclusion à laquelle on parvient du point de vue architectural, et c’est pourquoi le débat porte désormais à nouveau sur la conception plutôt que sur l’exécution, comme nous l’avons évoqué dans Le goulot d'étranglement est une fois de plus l'architecture
Elle accélère la génération de code, mais pas nécessairement son déploiement. Le rapport DORA 2024 a constaté qu'une augmentation de 251 TP3T de l'adoption de l'IA était corrélée à une baisse de 1,51 TP3T du débit et de 7,21 TP3T de la stabilité, attribuées à l'augmentation de la taille des lots de modifications.
Car cela détermine la qualité de l'analyse, la couverture réelle des tests, le temps nécessaire au diagnostic en cas de défaillance et le coût de la restauration. L'effort de développement limitait naturellement la taille du code ; cette limite ayant disparu, il est désormais impératif de la restreindre explicitement.
Les quatre indicateurs DORA sont : la fréquence de déploiement, le délai de livraison des modifications, le taux d’échec des modifications et le temps de rétablissement du service. Les deux premiers mesurent la rapidité, et les deux derniers la stabilité ; ils doivent être interprétés conjointement.
Une étude METR menée en 2025 a mesuré un retard de 19% chez des développeurs expérimentés qui prévoyaient une accélération d'ici 24%. METR a par la suite revu la méthodologie afin d'identifier d'éventuels biais, et une cohorte plus importante a révélé une différence moindre. Le constat demeure : la vitesse perçue et la vitesse réelle divergent.
Des tests automatisés fiables, un déploiement et une restauration automatisés, ainsi qu'une limite explicite quant à la taille des modifications sont essentiels. À mesure que le volume des modifications augmente, la sécurité et la possibilité de restauration deviennent primordiales.
Car elles récompensent le comportement à l'origine du problème : produire davantage sans garantir une production fiable. L'incitation détermine le comportement, et mesurer la production plutôt que les résultats déplace le coût vers le support et les besoins futurs.
Votre équipe livre-t-elle plus vite ou produit-elle simplement plus ? Nous analysons l'intégralité du processus de livraison (examen, tests, déploiement et exploitation) et vous indiquons où se situe le véritable goulot d'étranglement. Parlons-en →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
