La plupart des équipes qui adoptent la programmation agentique déplacent le goulot d’étranglement de la génération vers la revue; sans corriger la boucle, le gain net de vélocité est presque nul.
Dans les environnements d’IC à grande échelle — des millions de tests nocturnes et des centaines d’ingénieurs —, la tâche la plus utile pour un agent est l’acheminement vers les responsables et le triage, et non la génération de code.
Le résultat utile d’un agent résiste à l’examen et explique les liens de causalité, plutôt que de simplement repérer des motifs.
La conception de la couche de collecte des preuves et d’assemblage du contexte importe davantage que celle de la couche de génération.
La plupart des discussions sur la programmation agentique partent encore d’une promesse simple : écrire plus de code, plus rapidement.
Cette promesse s’élargit parfois en une vision plus ambitieuse où des agents planifient le travail, ouvrent des demandes de fusion et livrent des changements avec une intervention humaine minimale. Toutefois, pour la plupart des équipes d’ingénierie, la valeur la plus évidente à court terme est plus ciblée. Il s’agit de réduire le coût des itérations.
La livraison de logiciels ne se résume pas à la génération de code. L’écriture du code n’est qu’une étape d’une longue boucle qui comprend la revue, les tests, le déploiement et l’investigation lorsque les choses tournent mal. La plupart des équipes qui adoptent la programmation agentique sans repenser la boucle de revue ne font que déplacer leur goulot d’étranglement vers l’aval.
Accélérer uniquement la génération ne rend pas automatiquement une équipe plus rapide. Cela peut simplement transférer davantage d’efforts vers la revue, la vérification et l’établissement de la confiance.
Dans de nombreux environnements d’ingénierie, l’étape coûteuse n’est pas la production d’une première version, mais l’atteinte d’un degré de confiance suffisant.
Le changement a-t-il réellement corrigé le problème ou amélioré le système? A-t-il causé une régression ailleurs? La défaillance vient-elle du code, de l’environnement, des tests ou d’une dépendance? Le correctif proposé s’attaque-t-il à la cause ou seulement au symptôme visible?
Les agents peuvent aider ici, non pas parce qu’ils remplacent les ingénieurs, mais parce qu’ils peuvent effectuer une première analyse structurée de preuves disparates : examiner les journaux, comparer les changements récents, résumer les signaux pertinents, retracer les causes probables, exécuter des vérifications et produire un résultat qu’une personne peut approfondir.
Dans de nombreuses équipes, l’utilisation d’un agent ayant le plus fort effet de levier n’est pas de générer du code à partir de zéro. Elle consiste à réduire l’espace de recherche autour d’un problème avant qu’une personne y consacre des heures manuellement.
Cela est particulièrement évident dans les processus de débogage à grande échelle. Imaginez une IC nocturne exécutant des millions de tests dans des bases de code modifiées par des centaines d’ingénieurs — une réalité pour l’un de nos clients. Lorsqu’une défaillance survient, il est difficile de l’acheminer vers les bons responsables. Le problème peut se trouver dans le code de l’application, une dépendance, le harnais de test ou ailleurs dans la pile. Les journaux peuvent atteindre plusieurs gigaoctets, et la première équipe à constater le problème n’en est pas toujours responsable.
Ce type de processus ne se prête pas naturellement à ce qu’un seul agent écrive le correctif. Il convient plutôt à un système qui permet de cerner rapidement le problème.
Une chaîne de traitement utile pourrait récupérer les journaux, sélectionner les preuves pertinentes, résumer l’essentiel, examiner le code dans un bac à sable et produire une analyse structurée des causes fondamentales comprenant un score de confiance, une traçabilité et les prochaines étapes suggérées. Pour produire un score de confiance, un spécialiste du domaine évalue le résultat initial de l’agent. Cette évaluation est ensuite transmise à un LLM agissant comme juge afin d’automatiser l’attribution des scores futurs tout en maintenant leur concordance avec le jugement humain.
L’objectif n’est pas d’éliminer le jugement des ingénieurs, mais de donner aux réviseurs un meilleur point de départ. Le triage des régressions, la revue des demandes de tirage, la réparation des tests, la validation des versions et l’investigation après déploiement suivent tous le même modèle. Ils exigent beaucoup de preuves et de revues, tout en comportant de nombreuses ambiguïtés. Ils ne demandent pas à un agent de remplacer le processus d’ingénierie, mais simplement de contribuer à le faire avancer.
C’est aussi pourquoi les équipes doivent évaluer ces systèmes avec prudence.
La mauvaise question consiste à demander si un agent peut produire quelque chose d’impressionnant de façon isolée. La meilleure question est de savoir s’il améliore un véritable flux de travail sans créer de ralentissement ailleurs.
Il faut donc vérifier si le résultat est assez précis pour être validé, s’il explique les liens de causalité plutôt que de simplement repérer des motifs et s’il facilite la revue au lieu de la compliquer. Une réponse plausible n’est pas nécessairement utile. En pratique, les équipes font confiance au résultat d’un agent lorsqu’il résiste à l’examen et leur fournit des éléments concrets à vérifier.
La leçon fondamentale est que les systèmes agentiques utiles reposent sur bien plus que la génération. Ils dépendent de la manière dont les preuves sont recueillies, le contexte est assemblé, les résultats sont vérifiés et l’incertitude est présentée à la personne chargée de la revue.
C’est pourquoi l’avenir à court terme de l’ingénierie agentique ne prendra probablement pas la forme d’un bond unique vers l’autonomie complète. Il prendra plus probablement la forme d’un ensemble de boucles soigneusement conçues où les agents aident les équipes à examiner, réviser, vérifier et peaufiner leur travail en réduisant les efforts gaspillés entre les étapes.
Cela est peut-être moins spectaculaire que la vision générale de l’autonomie, mais correspond beaucoup mieux à la façon dont les systèmes utiles sont réellement adoptés.