Pourquoi coder plus vite avec l’IA ne suffit pas

Davantage de code généré par l’IA ne garantit pas une plus grande vélocité d’ingénierie

Les équipes d’ingénierie rapportent des expériences très différentes avec les outils de codage agentique, capables d’exécuter un travail de développement en plusieurs étapes avec une intervention humaine limitée. Certains ingénieurs évoquent une « vélocité multipliée par 10 ou 100 » grâce à des outils comme Claude Code et Cursor, tandis que d’autres signalent des goulets d’étranglement dans la revue de code et des ingénieurs seniors devenus des « éboueurs à plein temps », à mesure que la productivité et le plaisir au travail diminuent. Ces expériences mettent en lumière la vraie question d’ingénierie : que devient le reste de la livraison logicielle lorsque la génération de code s’accélère ?

Cette question est importante parce que la génération de code n’est qu’une partie de la livraison logicielle. Un développeur peut produire le travail d’implémentation beaucoup plus vite, tandis que l’équipe met plus de temps à l’inspecter, le corriger, le tester, le mettre en production en toute sécurité ou le comprendre après une défaillance. Un débit de codage plus élevé peut déplacer la charge de travail vers l’aval, de sorte que des gains équivalents en vélocité d’ingénierie dépendent de l’état du cycle de développement logiciel (SDLC), le processus qui fait passer le travail des exigences au développement, à la revue, à la mise en production et à l’exploitation.

Le SDLC fait de la préparation à l’IA une propriété du système d’ingénierie qui entoure l’outil. Un cycle de vie avec des exigences claires, des contraintes architecturales, une revue efficace, des tests pertinents, une reprise rapide et une mesure des résultats peut maîtriser un rythme de changement accru. Lorsque ces pratiques sont faibles, l’IA peut augmenter le volume des problèmes qu’elles laissent déjà passer. Ces expériences très contrastées peuvent coexister parce que les équipes ajoutent une capacité de génération à des systèmes d’ingénierie différents.

L’IA multiplie le processus dans lequel elle s’insère

Ces différents systèmes expliquent l’effet multiplicateur. Des pratiques solides peuvent transformer une production accrue en vélocité utile, parce que l’organisation peut encadrer ce qui est produit et décider si cela est apte à être livré. Des pratiques faibles peuvent amplifier les lacunes existantes, parce qu’un plus grand volume de production atteint les mêmes contrôles insuffisants de revue, de test et de mise en production. La maturité de l’ingénierie change donc concrètement le sens de l’accélération.

L’effet multiplicateur déplace la frontière importante en aval de la génération. Si un agent produit davantage de code, une personne ou un processus doit toujours établir que ce code résout le problème demandé, respecte les conventions du système, se comporte correctement et peut être exploité en production en toute sécurité. Une production plus importante exerce une pression accrue sur ces contrôles, car davantage de changements doivent les traverser. La vraie question est de savoir si l’ensemble du SDLC peut absorber ce rythme de changement plus élevé.

Cette question au niveau du système change aussi la manière dont les équipes doivent évaluer les outils d’IA. La vitesse de codage, à elle seule, ne permet pas de déterminer si la livraison s’est améliorée lorsque les files d’attente de revue s’allongent, que des tests de faible qualité passent ou que les ingénieurs peinent à diagnostiquer des défaillances en production. L’évaluation doit inclure à la fois les contraintes en amont de l’implémentation et les contrôles en aval, car la génération se situe entre les deux. Une accélération utile dépend de la capacité de ces pratiques environnantes à encadrer, revoir, mesurer et corriger la production supplémentaire.

Cette dépendance explique pourquoi le seul choix de l’outil ne peut pas trancher le désaccord sur la productivité de l’IA. Deux équipes peuvent introduire des outils agentiques dans des environnements très différents et constater des effets en aval différents, même si toutes deux génèrent du code plus rapidement. L’une peut détecter et contenir très tôt une production inadaptée, tandis que l’autre ne découvre les problèmes qu’après leur accumulation. Le test de préparation commence donc par les informations disponibles avant qu’un agent n’écrive du code.

Le test de préparation commence avant la génération de code

Cette chaîne d’information commence par les exigences. Si les tickets arrivent régulièrement en implémentation avec des critères d’acceptation manquants ou incomplets, un agent dispose d’informations incomplètes sur ce qui définit un travail réussi. Il peut partir dans la mauvaise direction, élargir le périmètre et produire quelque chose qui ne répond pas aux besoins des utilisateurs, parce que le résultat attendu reste non tranché. Une implémentation plus rapide ne peut pas corriger une décision produit qui n’a pas encore été prise.

Comme les tickets rédigés ne contiennent pas toujours tout ce qui est nécessaire à l’implémentation, la clarification côté produit constitue la contrainte suivante. Un diagnostic utile consiste à se demander si les ingénieurs interrompent fréquemment l’implémentation pour demander des clarifications à l’équipe produit. Cette interruption peut être productive, car l’ingénieur a identifié une ambiguïté avant d’y engager davantage de travail. Si un agent avance sans cette clarification, une faiblesse de communication existante peut se transformer directement en implémentation incorrecte ou inutile.

Une fois le résultat clarifié, l’architecture encadre la manière dont l’implémentation doit s’intégrer au système. Les équipes doivent se demander si les décisions architecturales sont documentées quelque part, de façon accessible à la fois aux ingénieurs et aux agents IA, et si les conventions de développement sont consignées par écrit. Sans conventions accessibles, un agent peut faire ses propres choix pendant la génération d’une implémentation. Ces choix peuvent produire un code fonctionnel tout en accentuant l’incohérence avec le reste du système, ce qui crée davantage de travail lors de la revue et de la maintenance ultérieure.

Ensemble, ces diagnostics en amont font de la préparation à l’IA en partie un problème de qualité de l’information. Les critères d’acceptation définissent le résultat, la clarification produit lève l’ambiguïté et la documentation d’architecture encadre l’implémentation. Une organisation qui conserve des connaissances critiques de manière informelle demande à un agent d’opérer sans des informations que les ingénieurs humains peuvent retrouver par des questions ou par l’expérience. L’augmentation de la vitesse de production amplifie alors le coût des exigences non résolues et des décisions de conception non documentées.

Parce que ces défaillances prennent naissance en amont, elles peuvent apparaître plus tard sous la forme d’un code généré apparemment médiocre. Un agent ne peut pas déduire de manière fiable une décision produit que l’organisation n’a pas encore prise, ni une convention qu’elle n’a jamais consignée. Les équipes qui évaluent leur préparation à l’IA doivent examiner les entrées et les contraintes fournies par leur processus actuel avant de considérer le code généré comme la principale unité d’analyse. Une fois ces entrées suffisantes et la génération accélérée, la revue devient la contrainte suivante.

La revue et les tests déterminent si la production supplémentaire est digne de confiance

La capacité de revue devient visible dans la taille des pull requests. Les équipes doivent se demander si leurs PR actuelles sont suffisamment petites pour permettre une vraie revue en une seule session. Les outils agentiques peuvent produire une grande quantité de code, ce qui accroît le risque que les PR générées deviennent trop volumineuses pour être inspectées avec soin et soient validées machinalement à la place. À ce stade, le débit de génération a dépassé la capacité de l’équipe à porter un jugement éclairé sur ce qu’elle fusionne.

Lorsque la revue prend du retard sur la génération, les signalements de goulets d’étranglement et d’ingénieurs seniors occupés à nettoyer une mauvaise production de l’IA deviennent plus faciles à expliquer. De grands volumes de changements douteux peuvent détourner les ingénieurs expérimentés de leur travail existant vers l’inspection et la correction, tandis que l’élargissement du périmètre et les implémentations qui ne répondent pas aux besoins des utilisateurs ajoutent encore du travail. Les changements générés ne créent de la valeur qu’une fois que l’organisation a établi qu’ils ont leur place dans le produit. La capacité et la qualité de la revue fixent donc des limites pratiques à la quantité de production générée que le système de livraison peut exploiter.

Même une revue attentive a besoin de tests, car l’inspection humaine ne peut pas établir tous les comportements à l’exécution. Une équipe qui n’exécute pas régulièrement des tests unitaires et de régression, ou qui ne considère pas la qualité comme une responsabilité partagée, dispose de moins de moyens pour détecter des changements problématiques générés par l’IA. L’augmentation du volume de code accroît aussi la quantité de comportements à évaluer. La vraie question de préparation devient alors la solidité de la culture de test déjà en place.

Les tests générés par l’IA rendent cette dépendance particulièrement claire. Écrire des tests peut être suffisamment pénible pour que les ingénieurs sautent parfois cette étape, de sorte que générer des tests avec l’IA peut corriger une véritable faiblesse du workflow. L’intervention fonctionne lorsque les ingénieurs sont capables d’évaluer ce qui a été généré. Un test qui passe confirme que ses propres assertions ont réussi. Les ingénieurs doivent toujours décider si ces assertions vérifient le bon comportement.

Ce jugement est important parce que de mauvais tests générés peuvent aggraver un processus de test déjà faible : une sortie conforme peut créer de la confiance sans établir que le comportement visé a bien été vérifié. Les ingénieurs ont toujours besoin de la compétence technique nécessaire pour évaluer la couverture de test, les assertions et le comportement attendu, même lorsque l’IA prend en charge une plus grande partie de la rédaction. L’automatisation change qui produit l’artefact. Le jugement d’ingénierie détermine toujours s’il faut l’accepter.

L’exemple des tests révèle une contrainte plus large sur l’adoption de l’IA. Une équipe peut choisir l’IA précisément parce qu’une partie de son SDLC est faible, mais l’organisation autour doit tout de même disposer de capacités suffisantes pour évaluer si l’intervention a amélioré cette partie. Pour les tests générés, cela signifie reconnaître de mauvais tests ; pour l’implémentation générée, cela signifie revoir le périmètre, le comportement et la conception. Sans cette capacité d’évaluation, une production plus importante peut masquer la faiblesse d’origine.

Comme les contrôles avant fusion peuvent malgré tout laisser passer des problèmes, la confiance dépend aussi de ce qui se passe après la mise en production. Certaines défaillances ne deviennent visibles qu’en production, où un rythme de changement plus élevé crée une exigence différente. L’organisation doit être capable de rétablir rapidement la situation et de mesurer si la performance de livraison s’améliore.

Un changement plus rapide n’aide que si l’échec est récupérable et mesurable

Les défaillances en production font de la vitesse de reprise une composante du calcul de productivité. Les équipes qui envisagent un débit plus élevé piloté par l’IA doivent se demander si elles peuvent annuler une mauvaise mise en production « en quelques minutes ». L’IA augmente la vitesse à laquelle les changements peuvent être effectués, de sorte qu’une reprise lente peut transformer cette vitesse en passif. Une équipe capable d’inverser rapidement un déploiement raté est mieux placée pour contenir les conséquences d’un changement accru.

Un rollback rapide permet de contenir une défaillance, tandis que le diagnostic dépend de la compréhension qu’ont les ingénieurs de ce qu’ils ont livré. Un diagnostic utile est simple : les ingénieurs peuvent-ils expliquer le code qu’ils fusionnent ? Si une implémentation générée arrive en production sans cette compréhension, ces mêmes ingénieurs peuvent avoir du mal à la déboguer lorsqu’elle échoue. Le calcul de productivité doit inclure le travail opérationnel créé par un code rapide à produire mais difficile à raisonner dans des conditions de production.

Une fois les coûts de reprise visibles, la mesure permet à l’organisation de savoir si une génération plus rapide se traduit réellement par une amélioration. Les équipes doivent établir si elles suivent le taux d’échec des changements, c’est-à-dire la part des changements qui provoquent des défaillances nécessitant une remédiation. Sans cette mesure, une organisation peut accroître son usage de l’IA et son débit de code sans disposer d’un moyen de déterminer si les résultats en production se sont améliorés ou détériorés. Les mesures d’usage de l’outil montrent l’adoption ; les résultats de livraison en établissent l’effet.

Ces résultats fixent aussi la limite des décisions de ROI. Une équipe a besoin de résultats d’ingénierie mesurables et d’une adoption réversible pour établir si l’IA a été utile dans son propre SDLC. Une adoption plus large fournit des preuves d’usage. Elle ne peut pas, à elle seule, établir le succès, car celui-ci dépend de ce qui arrive au résultat d’ingénierie que l’intervention devait améliorer.

Une fois le résultat défini, la décision devient une évaluation d’ingénierie des conséquences. Si la production augmente alors que les échecs de changement augmentent et que la reprise reste lente, il est difficile de considérer ce rythme de changement supplémentaire comme une accélération utile. Si une intervention circonscrite améliore le résultat choisi et reste gérable lorsqu’un problème survient, l’organisation dispose d’une base plus solide pour continuer. Des pratiques SDLC faibles donnent donc aux équipes une raison de restreindre l’expérience.

Des SDLC faibles appellent une adoption plus ciblée de l’IA

Une expérimentation plus ciblée permet à une équipe d’utiliser l’IA avant que chaque partie de son SDLC soit mature. L’approche pratique consiste à identifier un aspect du cycle de vie qui doit être amélioré et à considérer l’IA comme une option parmi d’autres pour y répondre. L’équipe peut encadrer cette intervention au lieu de modifier simultanément les exigences, l’implémentation, les tests, la revue et les autres étapes. Un périmètre plus restreint limite le risque d’adoption et préserve la capacité à faire marche arrière lorsque le changement crée des problèmes.

L’exemple précédent des tests montre comment cette réserve fonctionne : les tests générés par l’IA peuvent remédier à l’absence de rédaction de tests lorsque les ingénieurs disposent d’une compétence suffisante en matière de test pour évaluer le résultat. La faiblesse de la pratique crée une raison d’expérimenter, tandis que la capacité qui l’entoure détermine si l’expérience peut être maîtrisée. La même relation s’applique ailleurs dans le cycle de vie, où le processus environnant doit rendre l’intervention observable et réversible.

Cette logique d’adoption est particulièrement importante pour les équipes confrontées à des critères d’acceptation incomplets, à des questions produit fréquemment non résolues, à une architecture ou des conventions non documentées, à des PR surdimensionnées, à des tests faibles, à un rollback lent, à l’absence de suivi des échecs de changement ou à une mauvaise compréhension du code fusionné. Une adoption large de l’IA peut amplifier plusieurs de ces faiblesses à la fois, de sorte qu’améliorer un aspect du SDLC à la fois facilite l’identification de ce qui a changé et la maîtrise des effets indésirables. L’IA peut être l’intervention retenue pour cet aspect, mais la décision doit découler du problème à résoudre.

Ces diagnostics constituent un ensemble de dépendances plutôt qu’un modèle complet de maturité. Ils relient l’augmentation de la génération à l’information disponible avant le codage, au jugement porté sur le travail généré et au contrôle opérationnel après la mise en production, donnant à une équipe un moyen de circonscrire une décision d’adoption autour d’une faiblesse qu’elle peut évaluer. Pluralsight prolonge cette approche de mise en œuvre et de mesure dans son guide, « Five steps for building AI-ready engineering teams and proving ROI ». Pluralsight a un intérêt commercial dans les recommandations sur la préparation à l’IA, car l’entreprise vend des produits de développement des compétences technologiques et de développement de la main-d’œuvre ; les équipes doivent donc mettre ces recommandations en balance avec les résultats d’ingénierie qu’elles peuvent observer dans leur propre SDLC.

Points clés

• L’IA multiplie le processus dans lequel elle s’insère : Une génération de code plus rapide crée de la valeur lorsque les exigences, la revue, les tests et les contrôles de mise en production peuvent absorber le changement supplémentaire. Les responsables de l’ingénierie peuvent évaluer la productivité de l’IA à travers les résultats de livraison plutôt qu’à travers le seul débit de codage.
• La préparation commence avant la génération de code : Des critères d’acceptation clairs, des décisions architecturales accessibles et des conventions documentées donnent aux agents IA les contraintes nécessaires pour produire un travail utile. Les organisations produit et ingénierie peuvent renforcer ces entrées avant d’élargir l’adoption.
• La revue et les tests déterminent la confiance : Une production de code plus élevée accroît la charge pesant sur les reviewers et les systèmes de test, tandis que les tests générés exigent toujours un jugement d’ingénierie. Les équipes d’ingénierie peuvent maintenir des PR faciles à relire et vérifier que les tests couvrent le comportement attendu avant d’augmenter la production générée par l’IA.
• La reprise et la mesure déterminent une vélocité utile : Un changement plus rapide accroît l’exposition opérationnelle lorsque le rollback est lent ou que les ingénieurs ne peuvent pas expliquer le code généré. Les organisations de livraison peuvent suivre les taux d’échec des changements, la vitesse de reprise et d’autres résultats pour établir si l’IA améliore la performance.
• Des SDLC faibles appellent une adoption plus ciblée : Les organisations dont les pratiques sont immatures peuvent cibler l’IA sur un problème mesurable du SDLC plutôt que de l’étendre à l’ensemble du cycle de vie. Des expérimentations circonscrites et réversibles rendent les résultats plus faciles à évaluer et les effets indésirables plus faciles à contenir.