Comment les outils gagnent la confiance des développeurs

Le codage par IA peut faire apparaître les logiciels plus vite que les organisations d’ingénierie ne peuvent décider s’il est sûr de les mettre en production. Une Developer Survey a révélé un écart net entre l’usage de l’IA et la confiance :

Ces chiffres de la Developer Survey montrent que l’adoption et la confiance peuvent évoluer dans des directions opposées. Les agents de codage peuvent résoudre des problèmes plus rapidement et produire des applications entières en une fraction du temps nécessaire auparavant, mais la vitesse de génération ne mesure qu’une partie de la productivité de l’ingénierie.

Cet écart est important parce que les outils de codage agentique, c’est-à-dire les agents d’IA capables d’effectuer un travail de codage en plusieurs étapes, couvrent une plus grande partie du cycle de vie du développement logiciel (SDLC) que ne le faisaient habituellement les outils de développement classiques. À mesure que la génération devient moins coûteuse, les efforts d’ingénierie rares se déplacent vers la définition de ce qui doit être construit, la fourniture du bon contexte, la validation de sorties volumineuses, la coordination avec d’autres personnes, la réutilisation de travaux éprouvés et l’acceptation de la responsabilité du comportement en production. Le codage par IA crée une valeur durable lorsque les équipes repensent ces processus générateurs de confiance autour de sa rapidité.

L’adoption de l’IA progresse alors même que la confiance recule

L’écart entre usage et confiance change la manière dont les responsables de l’ingénierie doivent interpréter l’adoption rapide de l’IA. Un outil peut se diffuser parce qu’il donne aux développeurs individuels une puissante capacité générative, alors que l’ensemble du parcours allant de l’exigence au logiciel de production fiable reste difficile à juger digne de confiance. Produire rapidement une application prouve que la génération s’est accélérée. La revue, le déploiement, l’exploitation et la maintenance conservent leurs propres contraintes.

Ces contraintes du cycle de vie comptent davantage à mesure que les agents prennent en charge du travail tout au long du SDLC. Un outil classique a généralement un rôle délimité que les développeurs apprennent à maîtriser par l’usage répété, tandis qu’un agent accepte des instructions en langage naturel, génère des volumes importants de code et peut traiter des tâches dans plusieurs domaines qui impliquaient auparavant plusieurs outils et plusieurs personnes. Les équipes doivent donc mesurer la vitesse à laquelle le travail généré devient un logiciel qu’elles sont prêtes à assumer.

La confiance des développeurs vient de workflows prévisibles

La volonté d’assumer un logiciel dépend en partie d’outils et de processus prévisibles, et les équipes d’ingénierie ont traditionnellement construit cette prévisibilité par la répétition. Les développeurs utilisent un outil, deviennent compétents avec celui-ci, l’adaptent à leur travail, en apprennent les limites et observent si la même opération produit des résultats cohérents dans le temps. Le test utile est banal : l’expérience acquise le lundi doit rester pertinente le mardi. La répétition transforme le savoir explicite en mémoire procédurale et rend le comportement de l’outil plus facile à anticiper avant qu’un développeur n’agisse.

Une controverse entre Vim et Emacs il y a environ six ans a montré à quel point cette expérience accumulée peut être précieuse. Un article provocateur sur des IDE de plus en plus puissants demandait pourquoi qui que ce soit utiliserait encore Vim ou Emacs et décrivait leurs utilisateurs comme travaillant comme des « hommes des cavernes ». Les commentaires sont devenus hostiles et défensifs des deux côtés, avec notamment des critiques affirmant que l’argument ne comprenait pas les développeurs et des prises de position de la part d’utilisateurs convaincus d’Emacs. Derrière ce conflit se trouvait une explication de la raison pour laquelle des outils apparemment anciens pouvaient rester extrêmement productifs.

Pour un novice, Vim et Emacs peuvent être des applications terminal peu intuitives dont les commandes et raccourcis exigent une mémorisation importante. Les utilisateurs experts peuvent atteindre un point où les utiliser revient presque à penser, parce que des années d’usage répété ont supprimé l’effort conscient des actions courantes. Une personnalisation poussée permet aussi à chacun d’adapter étroitement l’éditeur à son propre workflow. David Thomas et Andrew Hunt, co-auteurs de The Pragmatic Programmer, expliquent que les développeurs ont besoin d’« outils affûtés » ; l’expertise rend un outil de plus en plus adapté à la manière de travailler déjà établie du développeur.

Cette compétence accumulée explique pourquoi passer à un outil plus performant peut d’abord ralentir un développeur expérimenté. Tricia Gee, défenseure de la productivité des développeurs, a déclaré : « L’une de mes réticences à adopter certaines formes de programmation par IA, c’est que je vais plus vite avec mon IDE parce que je sais comment il fonctionne. » Passer d’un workflow en terminal à un IDE, ou d’un IDE à un agent, signifie modifier un processus qui produit déjà des résultats utiles. Une simple formation aux fonctionnalités ne peut pas préserver des années de pratiques acquises.

Gee a observé la même résistance chez des utilisateurs experts de Vim et Emacs à qui l’on présentait les fonctions de refactorisation d’IntelliJ IDEA. « J’ai vu la même chose quand j’ai travaillé avec des personnes qui connaissent très bien Vim et Emacs. Vous pourriez utiliser les outils de refactorisation dans IntelliJ IDEA. Ils répondent : oui, mais cela demande une courbe d’apprentissage. J’ai passé tellement de temps à utiliser tel ou tel outil. Mes doigts savent quoi faire. Très bien comprendre un outil, quel qu’il soit, devient une grande part de compétence inconsciente. » La migration d’outil peut détruire une partie de la vitesse accumulée avant que ses nouvelles capacités ne créent de la valeur.

L’IA rend une prévisibilité comparable plus difficile à construire parce que les capacités des agents évoluent rapidement et que leurs sorties sont moins prévisibles. Les développeurs peuvent généralement apprendre le rôle délimité et les limites d’un IDE, d’un outil de conteneurisation ou d’un analyseur statique. Les linters, les tests unitaires automatisés et les systèmes de continuous integration and continuous delivery (CI/CD) remplissent eux aussi des fonctions comprises au sein d’un workflow plus large. Les agents probabilistes entrent dans davantage de parties de ce workflow tout en modifiant ce qu’ils peuvent faire, de sorte que les développeurs disposent d’une expérience moins stable pour en déduire leur comportement futur.

Même les outils matures tirent leur valeur d’ingénierie du processus qui les entoure. De meilleurs IDE peuvent améliorer le travail d’implémentation, les systèmes CI/CD peuvent améliorer la livraison, et les outils de suivi des tickets avec story points peuvent soutenir l’estimation, tandis que la culture, les habitudes, les décisions et la coordination déterminent dans quelle mesure ces capacités se traduisent en résultats. Des organisations d’ingénierie de grande taille peuvent rejeter des outils pourtant performants lorsqu’ils entrent en conflit avec la manière dont les gens travaillent réellement. La capacité technique crée de la valeur une fois qu’elle s’intègre au processus environnant, ou qu’elle le transforme avec succès.

Quand la génération devient bon marché, la revue et la validation deviennent coûteuses

Ce processus environnant subit une pression immédiate lorsque la production des agents croît plus vite que la capacité à la valider. Une vieille blague disait que modifier 100 lignes était le moyen d’obtenir rapidement l’approbation d’une pull request. Un agent de codage peut désormais modifier des centaines de lignes presque instantanément et placer le diff résultant devant un évaluateur humain. La génération est devenue bien moins coûteuse alors que l’évaluateur dispose toujours d’un temps et d’une attention limités.

Une capacité de revue finie peut faire de la revue de code le nouveau goulot d’étranglement, même lorsque l’écriture du code devient nettement plus rapide. Les grands diffs exigent des évaluateurs qu’ils comprennent le comportement, les interactions avec la base de code existante, les cas limites et les effets potentiels en production. Lorsque le volume généré dépasse la capacité de revue, les équipes subissent une pression pour accepter des changements de plus en plus importants avec une inspection de plus en plus superficielle. Le rubberstamping rétablit le débit sur le papier tout en affaiblissant le mécanisme d’approbation lui-même.

Cette contrainte de revue a encouragé la revue de code automatisée et les systèmes LLM-as-a-judge, dans lesquels un grand modèle de langage évalue la sortie d’un autre système. Ces systèmes peuvent faire monter en charge certaines parties de la validation, mais s’appuyer sur une revue par IA d’un code écrit par IA crée sa propre décision de confiance. La couche de revue a besoin de contrôles, d’évaluation et de responsabilité adaptés aux décisions qu’elle prend. L’automatisation peut déplacer le travail de validation, mais une validation digne de confiance reste nécessaire.

L’outillage croissant autour du développement agentique reflète le fait que de nombreuses contraintes du cycle de vie ont évolué en même temps. Des SRE IA sont introduits dans les opérations, des évaluateurs automatisés dans les pull requests, des gestionnaires de mémoire et de contexte dans les interactions avec les agents, ainsi que de meilleurs control planes et harnesses dans les systèmes qui encadrent le comportement des agents. Ces ajouts peuvent renforcer une organisation d’ingénierie activée par l’IA. Leur prolifération montre aussi qu’une génération plus rapide modifie simultanément plusieurs parties du SDLC.

Ces effets sur le cycle de vie deviennent concrets une fois que le logiciel atteint la production. Les applications cloud-native consomment du calcul, de la mémoire et du trafic réseau, tandis que les dépendances hébergées et les API créent des coûts continus. Les défaillances ajoutent des coûts plus difficiles à budgéter via les temps d’arrêt, les failles de sécurité et les opportunités manquées. Un agent peut rendre le code peu coûteux à créer alors que ces conséquences opérationnelles demeurent, de sorte que la productivité de l’ingénierie doit inclure le cycle de vie qui suit la génération.

Parce que les conséquences en production persistent, les contrôles d’ingénierie existants restent importants même si les workflows des agents les modifient. Les linters, les tests et le CI/CD ont encodé des parties de processus d’ingénierie antérieurs, et les workflows agentiques peuvent devoir adapter ces contrôles à la quantité, à l’origine et à la portée du travail généré. Améliorer les outils individuels aide lorsque les pratiques organisationnelles évoluent avec eux. Le même sujet devient encore plus important lorsque les agents commencent à franchir des frontières organisationnelles aussi bien que techniques.

Les agents peuvent contourner la collaboration qui contenait auparavant le risque

Ces frontières organisationnelles répartissaient traditionnellement la connaissance et l’autorité entre différents rôles. Les product managers élaboraient les exigences de fonctionnalités et de fonctions à partir de la recherche, des échanges avec les clients et de leur connaissance des concurrents. Les architectes appliquaient leur expérience et leur compréhension de la stack technologique existante, les ingénieurs implémentaient et relisaient le code, et la QA essayait de casser ce qui avait été construit. Après le déploiement, les équipes DevOps et SRE surveillaient les performances en production et la consommation de ressources.

Cette séquence rendait visibles différents types d’expertise à différentes étapes, même lorsque le processus lui-même était imparfait. Les contrôles d’accès, les pistes d’audit, les diffs et les vérifications CI/CD limitaient aussi ce qu’une seule personne ou un seul outil pouvait modifier sans examen. Ces mécanismes réduisaient le blast radius, c’est-à-dire l’ampleur des dommages qu’une seule erreur pouvait causer, en répartissant l’autorité et en enregistrant les actions importantes. La confiance venait en partie du fait de savoir qui avait pris une décision et quels contrôles elle avait franchis.

Cette responsabilité reste entre les mains des personnes lorsque l’IA entre dans le workflow. Charity Majors, CTO de l’entreprise d’observabilité Honeycomb, a un intérêt commercial dans les pratiques d’ingénierie qui améliorent l’exploitation et le diagnostic des systèmes de production, et elle rejette les formulations qui donnent l’impression que l’implication humaine est secondaire : « Human-in-the-loop sounds like a pity invite. I made the loop, I own the loop, I’m the only reason that loop exists. It is MY f***ing loop! » En pratique, le développeur qui pousse un commit en reste responsable, et les personnes qui approuvent une pull request restent responsables de cette approbation. Lorsqu’un déploiement du vendredi cassait la production avant l’IA, la responsabilité restait du côté des personnes et du processus autour du déploiement ; un agent ne peut pas assumer cette responsabilité.

La responsabilité devient plus difficile à exercer lorsqu’un agent permet à un développeur de franchir des frontières qui déclenchaient auparavant une consultation. Jaime DeLanghe, chief product officer de l’entreprise de collaboration au travail Slack, bénéficie commercialement du fait que les équipes considèrent la communication partagée comme importante pour le travail logiciel. Elle a décrit le risque : « You don’t have to, say, check in with your designer about the design because you just got an agent to build the design, and you don’t have to work with another engineer in a specific domain to understand their code base because you just ask the agent the question. You could go way down this path and create a massive PR. » L’individu gagne en vitesse tandis que l’organisation peut perdre des interactions qui faisaient émerger des hypothèses et des connaissances spécialisées.

La perte de ces interactions crée la possibilité d’un « silo of one ». Un développeur travaillant via un agent peut avancer à travers les exigences, la conception, l’implémentation, du code peu familier et le déploiement avec davantage d’autonomie, ce qui signifie que moins de personnes voient nécessairement le raisonnement avant que le travail ne devienne un grand diff. Le risque qui en résulte est une perte de contexte partagé et une prise de décision moins visible. Une pull request massive à la fin ne peut pas recréer une consultation qui aurait modifié une décision plus tôt.

Parce que l’information manquante est collaborative, certaines équipes déplacent les interactions avec les agents dans des workflows partagés. Une proposition consiste à solliciter l’agent dans un espace partagé où les collègues peuvent commenter et modifier l’approche en cours d’élaboration ; une autre consiste à joindre les transcriptions de prompts aux pull requests. Dane Knecht, CTO de l’entreprise d’infrastructure internet Cloudflare, a un intérêt commercial dans les outils et l’infrastructure utilisés pour construire, déployer et exploiter des logiciels, et voit de la valeur dans cette visibilité : « It’s so cool to be able to open up a PR and actually see how the developer was thinking and how they were problem solving. » Une transcription peut exposer le raisonnement et les instructions que le diff final, à lui seul, ne peut pas montrer.

La confiance doit être conçue avant la génération

Les transcriptions partagées améliorent la visibilité une fois le travail commencé, mais le même raisonnement pointe vers un contrôle plus en amont : l’information fournie avant même que le code n’existe. Les équipes doivent énoncer le comportement attendu, fournir un contexte organisationnel vérifié et réduire l’ambiguïté avant de demander à un modèle de générer. La revue humaine peut alors évaluer une sortie produite dans des conditions plus claires. Les évaluateurs consacrent moins d’efforts à reconstituer des exigences qui auraient dû orienter l’implémentation dès le départ.

Le langage naturel rend cette préparation difficile parce que la facilité conversationnelle diffère de la précision d’une spécification. Bjarne Stoustrup, créateur du C++, a formulé la distinction de manière directe : « Code is a precise statement of a solution », tandis que « English is a lousy language for expressing things that have to be unambiguous. » Un agent de codage reçoit des instructions dans un médium où une exigence peut être incomplète ou sujette à interprétation. Une génération rapide augmente le coût d’une ambiguïté non résolue parce qu’un modèle peut la transformer en une implémentation substantielle avant que quiconque ne s’en aperçoive.

Les spécifications deviennent donc un contrôle d’ingénierie actif. Les équipes peuvent utiliser des prompts ou des fichiers spec.md pour énoncer le comportement requis avant la génération, y compris des contraintes qu’un développeur aurait auparavant gérées implicitement en écrivant le code. Scott Hanselman, vice-président de la Developer Community chez Microsoft, dont l’employeur vend des plateformes pour développeurs et des outils de développement assisté par IA et bénéficie commercialement de workflows de développement IA efficaces, résume le risque ainsi : « If you leave anything up to chance, it will be left up to chance. » L’exigence pratique consiste à rendre explicites les hypothèses qu’un agent ne peut pas déduire de manière fiable.

L’application de ring light de Hanselman montre à quel point ces hypothèses omises peuvent être minimes. Il travaillait sur x64 mais voulait que l’application prenne en charge ARM, il a donc dû dire à l’agent : « Make me an ARM version. » Sans cette instruction, la version ARM n’aurait pas vu le jour. Le changement d’ingénierie est qu’une exigence présente dans la tête d’un développeur doit devenir une entrée explicite avant que l’agent puisse agir de manière fiable.

Même des exigences explicites ne peuvent pas contenir tout le savoir organisationnel dont dépend le travail logiciel. Les développeurs seniors accumulent au fil du temps des conventions, des décisions antérieures, des contraintes locales, des modes de défaillance connus et des relations entre systèmes. Répéter tout ce matériau pour chaque tâche serait coûteux, et les personnes omettraient malgré tout des détails pertinents. Le système de contexte autour d’un agent devient donc une partie du système d’ingénierie.

Les systèmes d’agents peuvent traiter ce problème grâce à des « mémoires à long terme et à court terme », c’est-à-dire des connaissances stockées et conservées d’un travail à l’autre, ainsi que des informations spécifiques à la tâche disponibles pour l’interaction en cours. Une mémoire utile exige une séquence contrôlée : une organisation capture les connaissances détenues par les développeurs seniors et par l’entreprise, les vérifie, les stocke là où les systèmes peuvent les récupérer, puis fournit les éléments pertinents lorsqu’une tâche en a besoin. Stack Internal est un exemple visant à capturer, vérifier et servir cette connaissance organisationnelle. Son rôle est de fournir le contexte de confiance approprié à la tâche.

Une fois que la génération démarre à partir d’exigences explicites et d’un contexte vérifié, la revue par les pairs reste une partie du processus. Le passage de la revue et l’arrivée en production créent ensuite une autre occasion de conserver ce que l’organisation a appris. Une fonctionnalité éprouvée peut devenir repérable et réutilisable pour des travaux ultérieurs. Régénérer un composant déjà couronné de succès introduit de la variation et fait perdre une partie de la confiance acquise grâce à la revue et à l’usage en production.

Laly Bar-Ilan, Chief Scientist de l’entreprise de plateforme de composants Bit, a un intérêt commercial dans la réutilisation logicielle et le partage de composants, et formule cette tension à travers une pratique logicielle bien établie : « The DRY (don’t repeat yourself) principle is our main principle », suivi de « AI today is inherently WET (write everything twice). » Ici, WET signifie « write everything twice », un schéma dans lequel une génération peu coûteuse peut rendre une nouvelle implémentation plus simple que la recherche et l’intégration d’une implémentation existante. Cette commodité locale peut créer de la duplication à l’échelle de l’organisation.

Bar-Ilan donne le cas concret des composants d’interface utilisateur. Un développeur demande à un agent de générer un bouton, puis un développeur d’une autre équipe fait la même demande et obtient un autre bouton dans la base de code. Les deux interactions peuvent sembler individuellement productives tout en créant de la duplication au niveau organisationnel. Un workflow d’agent qui favorise la réutilisation doit avoir accès aux composants existants et au savoir organisationnel qui lui indique quand la réutilisation est la voie établie.

La réutilisation rend le processus cumulatif parce que les demandes ultérieures peuvent bénéficier des revues antérieures et de l’expérience de production. Les humains responsables conservent la responsabilité des décisions, les contributions de l’IA restent visibles, et les équipes peuvent partager et réviser leurs pratiques de travail à mesure qu’elles apprennent. Les spécifications et le contexte vérifié orientent la génération ; les pairs examinent ensuite le résultat, l’usage en production fournit un retour d’expérience, et les composants réussis deviennent disponibles pour des tâches ultérieures. Chaque étape préserve des informations qui seraient autrement perdues avant la demande suivante.

Encoder ces pratiques dans l’outillage suit une approche que les équipes d’ingénierie utilisent déjà. Les linters encodent des règles que les développeurs vérifieraient autrement manuellement, les tests automatisés encodent le comportement attendu, et les systèmes CI/CD encodent les vérifications et séquences de déploiement. Les workflows d’agents ont besoin de mécanismes adaptés à un périmètre d’action plus large et à une sortie probabiliste. Le mouvement organisationnel reste familier : identifier une pratique qui crée de la confiance, la rendre explicite et faire en sorte que le workflow normal l’exécute de manière cohérente.

Le bon workflow IA sait aussi quand éviter l’IA

Encoder un workflow d’agent laisse néanmoins une question préalable : la tâche bénéficie-t-elle de l’IA tout court ? Les grands modèles de langage produisent des sorties probabilistes, ou non déterministes, ce qui signifie que des demandes répétées peuvent produire des résultats différents au lieu du comportement fixe attendu d’un code déterministe. Cette variabilité est utile pour un travail qui bénéficie de la génération et de la flexibilité. Les tâches déjà résolues de manière fiable par des implémentations déterministes gagnent moins à l’introduire.

Anil Dash identifie directement cette erreur de sélection d’outil : « We are trying to apply non-deterministic systems to a lot of scenarios where you should have deterministic code. » Son contre-exemple pratique est tout aussi direct : « The humble bash script that has been running for six years is fine. » Six années de comportement fiable peuvent avoir plus de valeur pour cette tâche que la flexibilité générative.

Cet exemple fait de la sélection d’outil une question portant sur le travail et sur son coût complet. Les équipes peuvent utiliser la génération probabiliste là où elle apporte des gains significatifs, par exemple pour produire rapidement une nouvelle implémentation substantielle, tout en conservant du code déterministe pour les tâches qu’il traite déjà de manière fiable. L’expérience évoquée plus tôt avec Vim et Emacs renvoie à la même décision au niveau individuel : un développeur expérimenté peut rester plus rapide avec un workflow IDE, Vim ou Emacs profondément maîtrisé lorsque le changement consomme plus de temps qu’il n’en restitue. Le codage agentique mérite sa place là où ses gains résistent aux coûts de spécification, de validation, d’exploitation et de changement de processus.

Points clés

• Traitez la confiance comme une contrainte d’adoption : l’usage du codage par IA peut augmenter alors que la confiance des développeurs recule. Les organisations d’ingénierie ont besoin de workflows prévisibles qui clarifient le comportement des agents, leurs limites et la responsabilité associée.
• Protégez la capacité de validation : une génération plus rapide peut faire de la revue de code le goulot d’étranglement. Les responsables de l’ingénierie peuvent contrôler la taille des changements générés, renforcer les vérifications automatisées et aligner le volume de sortie sur la capacité de l’organisation à le valider.
• Préservez la collaboration autour du travail des agents : les agents de codage permettent aux développeurs de franchir les frontières entre exigences, conception, implémentation et opérations avec moins de consultations. Les interactions partagées avec les agents, les transcriptions de prompts et les contrôles d’approbation existants maintiennent visibles les connaissances spécialisées et les décisions.
• Concevez la confiance avant la génération : les équipes produit et d’ingénierie peuvent rendre les exigences explicites et fournir aux agents un contexte organisationnel vérifié avant que le code ne soit produit. La revue par les pairs, le retour d’expérience de la production et la réutilisation de composants éprouvés rendent ensuite chaque implémentation réussie plus précieuse au fil du temps.
• Choisissez l’IA en fonction de la tâche : la génération probabiliste crée de la valeur là où la flexibilité et la rapidité d’implémentation l’emportent sur les coûts de spécification et de validation. Les équipes plateforme et d’ingénierie peuvent conserver le code déterministe et les outils établis là où ils fournissent déjà des résultats fiables et efficaces.