Vos systèmes ont déjà des angles morts. L’IA ne fait que les aggraver.

En 2022, avant que les outils de codage génératif ne fassent partie de notre travail quotidien d’ingénierie, j’ai écrit à propos de ma philosophie sur le choix des outils. Cela a tenu mieux que je ne l’avais prévu. À l’époque, je soutenais qu’il faut commencer par les problèmes que vous résolvez réellement, connaître vos faiblesses, et prioriser la façon dont vous utilisez les outils plutôt que de vous lancer sur n’importe quel outil qui semble le meilleur en espérant que cela fonctionne. Connaissez-vous vous-même, ainsi que vos objectifs, afin de pouvoir fixer des attentes appropriées pour vos outils.

À l’époque, je pensais à la prolifération des SaaS, pas au code généré par l’IA. Mais aujourd’hui, ma philosophie est encore plus urgente et plus importante à défendre.

Beaucoup d’entre nous ont lu le rapport 2025 DORA, qui a constaté que, contrairement à l’année précédente, l’adoption de l’IA corrèle désormais positivement avec le débit de livraison. La découverte sous-jacente était que l’instabilité de la livraison continuait d’augmenter, et ils ont testé si les gains de vitesse compensaient cela. Ce n’est pas le cas. Cela correspond à notre expérience. Notre équipe a adopté le développement logiciel agentique et a constaté une augmentation de 48 % du débit sur deux trimestres, suivie d’une hausse de 16 % des problèmes de stabilité. Dix personnes constituent un petit échantillon, mais c’est aussi un échantillon qui me permet de voir l’ensemble du tableau, et le schéma s’est maintenu.

L’adoption de l’IA n’est plus vraiment une question. Vous êtes soit en train de commencer, soit déjà bien engagés. Ce qui change maintenant, c’est que les dirigeants techniques sont censés adopter l’IA et aussi prouver qu’elle rapporte. Le PDG, le conseil d’administration et les finances veulent tous savoir comment optimiser leur investissement en IA. Ils se demandent si les outils que vous avez choisis résolvent efficacement de vrais problèmes.

L’écart était toujours présent. L’IA ne l’a fait que s’élargir.

En tant que CTO, je consacre une bonne partie de mon temps à discuter avec d’autres dirigeants techniques, y compris des clients, des prospects et des pairs, pour comparer les réussites et les plaintes concernant ce que nous vivons avec l’IA. Après un nombre suffisant de ces conversations, j’ai commencé à voir des schémas dans l’adoption de l’IA et ses résultats.

L’observation principale n’est pas la mienne. DORA la met en avant depuis deux ans maintenant : l’IA amplifie tout ce qui se passe déjà dans l’organisation, tant les forces que les faiblesses. Une équipe avec une architecture propre et des habitudes de revue saines devient plus rapide. Une équipe qui a maîtrisé juste assez une boule de dette technique pour livrer du code constate maintenant que cette dette devient un obstacle majeur. Ce que ce cadrage ne saisit pas, c’est pourquoi cela prend tant d’équipes au dépourvu. L’IA n’a pas dissimulé ces faiblesses ; les systèmes sur lesquels nous comptions ne les ont jamais révélées.

La pile de tickets et de rapports sur laquelle la plupart des organisations d’ingénierie s’appuient a été conçue pour répondre aux questions que les humains se posent, à la vitesse humaine, par des personnes qui comprenaient approximativement ce que « terminé » signifiait pour une tâche donnée. Ce n’était jamais un enregistrement parfait. C’était toujours une approximation, remplie par quelqu’un qui résumait quelque chose de plus désordonné en dessous. Aujourd’hui, l’IA ajoute du volume et de nouvelles entrées qui génèrent de nouvelles activités. Aucun des systèmes (ou outils) utilisés pour les méthodes de développement traditionnelles, non IA, n’a jamais été conçu pour cela.

Quoi qu’il en soit, nous restons responsables des mêmes objectifs. Vous êtes toujours responsable de la vélocité, de la qualité, des dépenses et de la performance réelle de votre équipe. Vous ne pouvez plus simplement prendre les tableaux de bord de l’année dernière pour argent comptant.

Il y a une objection légitime ici. rapport ROI 2026 de DORA décrit une courbe en J : une baisse de productivité immédiatement après l’adoption, due à la courbe d’apprentissage, au coût de vérification du code généré par l’IA et aux processus en aval qui n’ont pas encore rattrapé. Ils l’appellent le « coût de formation » de la transformation, et ils avertissent les dirigeants de ne pas le confondre avec un échec. C’est raisonnable. Mais le coût de formation et un vrai problème semblent identiques sur un tableau de bord construit à partir de tickets. Si vous ne pouvez pas dire dans lequel vous vous trouvez, vous ne faites pas preuve de patience. Vous devinez.

Nous devons revenir aux bases. Connaissez-vous vous-même. Connaissez votre équipe. Connaissez les problèmes que vous résolvez.

Comment « Connais‑toi » avec l’IA ?

D’après mes conversations, j’ai identifié cinq domaines principaux où les systèmes conventionnels, conçus pour le travail généré et rapporté par les humains, sont aveugles. Les ignorer, c’est risquer d’amplifier vos faiblesses en continuant d’adopter l’IA.

Angle mort 1 : Théâtre de la vélocité

Plus de commits et plus de PR peuvent donner l’impression de progrès, et souvent c’est le cas. L’IA augmente automatiquement les deux décomptes. Un Stanford étude de cas a montré que l’adoption de l’IA a augmenté le nombre de PR de 14 %. Mais ce qui manque, c’est de savoir quelle part de cette activité correspond à du travail fonctionnel livré versus de la maintenance, du retravail ou du turnover provenant d’un refactor qui n’a pas tenu.

Pour y remédier, surveillez la répartition entre le travail fonctionnel et la maintenance, ainsi que la fréquence des déploiements et le délai de mise en production par rapport à votre propre référence historique, et non à une moyenne sectorielle. Sans cette distinction, vous signalez un progrès que vous ne pouvez pas réellement justifier.

Angle mort 2 : Dette de revue

La capacité de révision ne s’ajuste pas automatiquement avec la production. La taxe de vérification n’est pas une phase que l’on traverse ; elle fait partie du coût permanent du développement agentique. A une récente enquête auprès des dirigeants techniques a révélé que 80 % des équipes consacrent au moins 10 % de leur temps à la révision, et qu’environ une équipe sur dix consacre plus de 40 %. Sous cette charge, les équipes oscillent entre un arriéré croissant et la validation mécanique, et aucune de ces solutions n’est réellement satisfaisante.

La contrainte sur la mise en production n’est plus la vitesse à laquelle le code est écrit. C’est à quelle vitesse un humain peut réellement être sûr qu’un changement est correct, à quelle vitesse et avec quelle précision les défauts peuvent être détectés et corrigés. Surveillez comment la charge de révision est réellement répartie au sein de votre équipe ; sinon vous risquez de surcharger vos ingénieurs seniors, de retarder vos livraisons, ou de provoquer d’importants problèmes de production.

Point aveugle 3 : Travail caché

Les refactorisations et les changements d’architecture ont tendance à se cacher dans d’autres tickets, si tant est qu’ils apparaissent dans le système de tickets. L’IA génère davantage ce type de travail, pas moins. Un agent n’hésite pas à toucher douze fichiers pour corriger un bug, alors qu’un humain peut s’arrêter et réfléchir. Un travail qui contourne le système d’enregistrement contourne également la planification, ce qui signifie que votre modèle de capacité est erroné, et que chaque prévision construite dessus l’est aussi.

Pour comprendre combien de travail est réellement effectué, vous devez observer ce qui change réellement dans le code et dans l’historique des pull requests. Sans cela, votre plan de capacité repose sur ce que les gens se souviennent d’avoir enregistré, et non sur ce qu’ils ont réellement fait.

Point aveugle 4 : Dérive de qualité

La même enquête a révélé que près de la moitié des dirigeants techniques peinent à détecter les problèmes de sécurité d’une semaine à l’autre. La complexité, la duplication et les dépendances qui ne sont pas tout à fait appropriées s’accumulent à travers de nombreux petits changements, chacun raisonnable pris isolément. Aucun d’eux ne paraît alarmant pris séparément. Dans la même étude de cas de Stanford, la qualité du code a chuté de 9 % et sa variance a plus que triplé. Alors que la moyenne a peu varié, l’écart (la partie que vous remarquez) a beaucoup bougé. À un volume d’IA, ils se cumulent plus rapidement que la plupart des processus de révision ne peuvent les rattraper. La dérive se manifeste souvent sous la forme d’une alerte d’astreinte liée à une dépendance dont personne ne se souvient avoir revu. Au moment où cela se produit, il y a de fortes chances qu’un client l’ait déjà remarqué.

Surveillez les courbes de tendance des découvertes de sécurité, des dépendances, ainsi que des échecs et récupérations — pas le commit individuel. La complexité et la duplication qui s’accumulent sur plusieurs semaines comptent davantage que tout changement isolé signalé lors de la révision. Sans cela, vous ne détectez la dérive que comme la plupart des équipes le font encore : après qu’elle a déjà provoqué un incident.

Point aveugle 5 : Dépenses non prouvées

Lorsque l’adoption de l’IA ne fait plus l’objet d’un débat, les dépenses d’IA et le ROI deviennent la question centrale. La finance veut savoir ce qui est capitalisable versus opérationnel. La direction veut savoir quels résultats l’investissement a générés. La plupart des équipes prennent encore des décisions concernant les outils, les licences et les effectifs sur la base de l’intuition, et non sur la preuve du lien entre l’argent dépensé et le travail livré.

Surveillez où l’effort d’ingénierie circule réellement dans le code même, trimestre après trimestre — pas là où la feuille de route indique qu’il devrait circuler. Sans ce lien, vous défendez le budget de l’an prochain avec des anecdotes, et les anecdotes ne résistent pas à une discussion difficile avec le directeur financier.

Commencez par ce que vous ne voyez pas

La question de la finance concernant les dépenses capitalisées et une alerte d’astreinte à 2 h du matin semblent sans lien, mais ne le sont pas. Les deux peuvent être « estimées à l’aveugle » à partir de l’activité. Mais les deux sont réellement répondables, avec des preuves, à partir du code même.

La réponse de DORA à tout cela est le système d’ingénierie lui‑même : qualité de la plateforme, clarté du flux de travail, alignement des équipes. C’est exact, mais ce n’est pas non plus la première étape. Vous ne pouvez pas corriger un système que vous ne voyez pas. Chacune de ces cinq zones doit être observable avant de pouvoir plaider en faveur d’un investissement.

La première étape utile n’est pas un nouvel outil ou un nouveau processus. C’est se connaître soi‑même, honnêtement, et déterminer quelles sont les zones aveugles parmi ces cinq domaines où vous manquez de preuves concrètes. La plupart des dirigeants peuvent immédiatement identifier (et surveillent) les problèmes dans l’un de ces domaines. Cependant, ce sont les domaines où vous disposez du moins d’informations qui sont les plus susceptibles de surgir et de vous poser problème à mesure que vous continuez à adopter l’IA.