Au cours de l'année écoulée, le discours autour de l'ingénierie agentique s'est déplacé vers les harnais et les boucles, les flottes et les usines logicielles. Mon avis est que les ingénieurs doivent posséder la boucle externe - la responsabilité de ces systèmes. Cela devient d'autant plus vrai à mesure que des modèles puissants comme Fable et GPT-5.6 deviennent disponibles.
Les agents ont un effet de levier, et cet effet de levier crée des obligations. Quelqu'un doit être capable d'expliquer exactement ce qui a changé, pourquoi c'était sûr, et ce qui se passera en cas d'erreur. Sinon, leurs actions ne peuvent être justifiées. Ce qui rend peu probable que leur organisation les sollicite en premier lieu.
Je souhaite donc aborder trois termes. Le premier, la Qualité, désigne tous les contrôles que nous installons avant de laisser le système opérer. Ces contrôles produisent des preuves, et à partir de ces preuves, nous dérivons un Verdict.
Le second, le Verdict, désigne la décision finale que nous prenons avant que le travail n'entre dans notre système dépendant : je suis le producteur de ligne de ce contenu. Je dirige l'équipe dont le travail est publié sous mon nom. Le modèle peut écrire la ligne, mais le Verdict m'appartient. Le travail de mon équipe n'entrera pas dans nos systèmes dépendants sans ma décision. Un Verdict est la décision de production : devons-nous livrer, bloquer, rediriger, restreindre la réponse, ajouter une barrière de sécurité, ou rejeter purement et simplement ?
Le troisième, la Responsabilité de rendre compte, désigne la garantie que si quelqu'un demande, je peux expliquer pourquoi.
Pour le dire autrement : notre agent (que je définis comme un modèle plus un harnais de fichiers, d'outils, de mémoire, de compétences, de bacs à sable, de permissions, d'observabilité et de récupération) est ce qui exécute notre boucle (que je définis comme investigation, implémentation, vérification et répétition). Et c'est ce qui crée notre usine logicielle.
Le modèle n'est que le moteur. Le harnais - outils, mémoire, permissions, bacs à sable, tests - est la voiture que vous construisez autour de lui pour qu'il puisse effectuer un travail réel en toute sécurité.
Enveloppez ce harnais dans un cycle reproductible : investiguer, implémenter, vérifier, répéter. La boucle est la façon dont une bonne exécution devient un processus fiable que vous pouvez relancer. Enveloppez ce harnais dans un cycle reproductible - investiguer, implémenter, vérifier, répéter - où un contrôle indépendant, et non la propre affirmation du modèle, décide quand le travail est terminé.
Maintenant, exécutez plusieurs boucles à la fois. Une usine, ce sont des boucles à l'échelle - les agents livrent le travail à l'intérieur, tandis que les humains possèdent les décisions à la frontière.
Et au cœur de cette usine se trouve une frontière soigneusement définie entre ce qui est à l'intérieur du système et ce qui est à l'extérieur. À l'intérieur du système : nous collectons les entrées (provenant de l'intention de l'équipe produit, de la connaissance des travaux déjà livrés, des incidents récents, ou des retours spécifiques des utilisateurs). La boucle agentique investigate la tâche, implémente un plan et vérifie le résultat. Ensuite, les preuves franchissent cette frontière. Un humain, qui possède le système dépendant, voit les preuves et décide de la suite à donner.
Et c'est là, mes amis, le changement que nous essayons d'opérer. Avant, nos agents exécutaient la boucle interne de la boucle d'exécution. Maintenant, ils exécutent la boucle d'exécution interne. Les ingénieurs possèdent la boucle externe.
À l'intérieur du système, nos agents ne font vraiment qu'une seule chose : de la capacité. La capacité d'investiguer des tâches, d'implémenter des plans, de tester leurs résultats et de faire un rapport. C'est la capacité d'un modèle. Et comme nous l'avons dit, cet avenir est déjà là.
À l'extérieur du système, il n'y a qu'une seule chose : l'agencéité. L'agencéité de décider, vérifier, approuver et posséder.
Nous parlons toujours de code, voyez-vous. Il a juste besoin de vivre dans un endroit et d'être exécuté par des personnes qui savent ce qu'elles font.
Le potentiel du code IA n'est plus marginal. Dans une enquête Sonar 2026, nous avons demandé aux équipes quelle part de leurs commits était assistée par l'IA. C'était faible mais non négligeable. Et plusieurs répondants ont déclaré s'attendre à ce que cette part augmente considérablement. Le Rapport 2026 de Sonar sur l'état du code a révélé que 42 % du code commité était généré ou significativement assisté par l'IA, avec des attentes de croissance continue plutôt que de stagnation.
La création, en d'autres termes, devient moins chère. Les ressources plus rares sont la revue, la validation, la compréhension et la maintenance.
Nous avons accéléré la vitesse de génération plus rapidement que la vitesse de contrôle. Nous avons donc un fossé de confiance-vérification. Beaucoup de personnes avec qui nous parlons expriment encore une certaine méfiance envers le code IA. Pourtant, moins d'entre elles semblent intégrer systématiquement cette méfiance dans leurs processus de vérification.
Et c'est une position dangereuse. Nous allons avoir besoin de moyens moins chers et plus clairs pour vérifier la fiabilité du code IA.
Si vous regardez le rapport GitLab de juin 2026, vous verrez que les questions de gouvernance ont évolué. La recherche de GitLab sur la responsabilité IA de juin 2026 montre que la revue et la validation sont les goulots d'étranglement actuels lors de l'utilisation de l'IA et, plus inquiétant encore, que la gouvernance a généralement lieu après la création du code, après avoir accepté le risque et perdu le contrôle de la propriété. Aujourd'hui, il ne s'agit pas seulement de contrôle. Il s'agit des contraintes que nous imposons au système. Il s'agit de la façon dont nous vérifierons le travail avec des preuves, et dont nous tiendrons les équipes responsables. Il s'agit de savoir qui possédera quelle partie du cycle de vie de l'IA.
Ainsi, la dernière distinction de cette série est entre processus et qualité. La qualité est le concept de contre-pression. Nous le prenons au sens littéral. Nous ne voulons pas accorder à nos agents autant d'autonomie qu'ils peuvent en exercer. Nous voulons leur accorder juste assez d'autonomie pour avoir suffisamment de contre-pression pour les arrêter, les réguler, vérifier leur travail et garantir notre humanité.
L'ingénierie ordinaire produit de nombreux signaux indiquant que le travail effectué fait ce qu'il faut. Vérifications de type, tests, hooks, limites de bac à sable, journaux d'audit, moniteurs. Nos systèmes d'ingénierie sont pleins de ce genre de signaux, et ils sont conçus pour fournir une contre-pression suffisante afin de maintenir le système honnête.
Et donc, tant que nos agents émettent ces mêmes signaux, nous pouvons faire confiance à notre ingénierie ordinaire pour fournir une contre-pression appropriée.
Faire confiance à nos systèmes ne signifie pas que nous ne voulons pas d'humain dans la boucle. Cela signifie simplement que l'humain n'a pas besoin d'être dans la boucle interne. Nous le voulons dans la boucle de contraintes (quelles entrées, architectures, instructions ou invariants devrions-nous définir ?), la boucle d'échantillonnage (quelle quantité de production devrions-nous échantillonner et revoir ?), la boucle d'audit (quelles preuves devrions-nous conserver et comment garantir l'efficacité de notre journal d'audit ?), et la boucle de propriété (quelle partie de la frontière de production devrions-nous posséder).
Mais l'humain n'a pas besoin d'être dans la boucle interne.
L'agent peut livrer plus que ce que vous pouvez revoir.
Et la ressource rare est votre propre jugement humain fondamental, éclairé par des signaux de qualité comme les journaux ou les tests.
Le rapport AI de juin 2026 montre que, dans le cadre expérimental, la délégation agentique sur des horizons temporels de l'ordre de l'heure est essentiellement une réalité. Le travail d'OpenAI cette année sur les agents et l'avenir du travail a été une excellente source pour ces idées. Nous devons donc commencer à réfléchir à la manière d'établir cette frontière de propriété, alors que nos systèmes commencent à livrer plus que ce que nous pouvons revoir.
Et c'est là que la responsabilité de rendre compte entre en jeu.
Parce qu'avec les agents à long horizon, les décisions prises sur des échelles de temps horaires sont précisément cela - des décisions. Et toutes les décisions ne seront pas enregistrées. Vous ne pouvez pas toutes les retracer jusqu'aux jetons d'entrée. Si tout ce que vous faites, c'est faire confiance au fait que la sortie que vous obtenez est le choix correct pour le problème en question, les centaines, voire les milliers d'heures de travail humain nécessaires pour reconstruire la chaîne de décisions qui y a mené deviennent impossibles. Et donc, encore une fois, la responsabilité de rendre compte devient quelque chose qui doit être au cœur de la conception de notre système.
Trois coûts cachés
Et il y a trois coûts cachés :
La capitulation cognitive ~ accepter aveuglément ce que l'IA vous donne. Lorsque vous déléguez du travail à un agent, le travail lui-même peut sembler être le travail de l'agent. Mais c'est en réalité votre travail. C'est votre réputation. C'est votre responsabilité. Et c'est votre logiciel qui a subi les défauts de la sortie. Et c'est votre logiciel qui doit être modifié pour refléter cette sortie. Ainsi, la sortie de l'agent devient votre réponse. Et avec elle vient toute la responsabilité. L'étude de Wharton qui a rassemblé cela est rassurante quand l'IA a raison. Mais quand elle a tort, les nouvelles ne sont pas bonnes. Lorsque l'IA avait tort, près des trois quarts des gens l'ont quand même acceptée et se sont sentis plus confiants qu'ils ne l'auraient été sans l'IA.
La dette cognitive ~ l'érosion de votre compréhension et de votre mémoire sur la façon de résoudre les problèmes. Lorsque vous déléguez du travail à un agent, vous externalisez tout le travail de réflexion à l'agent. Et bien que penser par vous-même prenne du temps et de l'énergie, le faire sur une base de code massive prend des ressources qui ne sont pas disponibles lorsque vous essayez de gravir la courbe d'apprentissage. Ainsi, la sortie que vous obtenez est souvent inaccessible pour vous. Et plus l'horizon temporel de la planification agentique est long, plus l'écart entre le code que l'agent produit et votre compréhension de celui-ci se creuse. L'écart se cumule. La dette s'accumule. Et le coût de la remontée de la courbe d'apprentissage croît presque de manière exponentielle. Il existe un essai contrôlé randomisé d'Anthropic examinant si les ingénieurs qui s'appuient sur l'IA pour écrire du code le comprennent aussi bien que ceux qui l'écrivent eux-mêmes. La conclusion était sombre : lors d'un quiz de compréhension, les ingénieurs qui ont travaillé avec l'IA ont obtenu un score inférieur de dix-sept points de pourcentage à ceux qui ne l'ont pas fait, 50 % contre 67 %.
Et puis il y a la taxe d'orchestration ~ il est facile de lancer beaucoup d'agents maintenant, mais votre bande passante cognitive ne se parallélise pas de la même manière. Orienter votre agent loin des pires comportements, trier le travail que l'agent produit pour identifier ceux qui nécessitent votre attention, le diriger pour qu'il se concentre d'abord sur le travail qui vous tient à cœur, vérifier vos contraintes les plus importantes et vos hypothèses les plus dangereuses avant de le laisser fonctionner…
Tout cela demande du travail, et cela ne peut pas être automatisé.
Il n'y a pas de substitut au jugement humain.
Les systèmes brownfield sont particulièrement dangereux ici, car le comportement du système que vous devez auditer ne réside pas dans le code. Il réside dans les cicatrices.
Des solutions ? Faites de l'attention la priorité dans vos décisions architecturales. Utilisez des worktrees, des périmètres et des preuves pour réduire le couplage entre votre plan initial et le travail qui en découle. Limitez dans le temps l'effort pour résoudre les étapes non actionnables. Et faites du changement dans votre logiciel une permission strictement opt-in.
Alpha, décroissance et goût : ce sont les trois schémas fondamentaux qui façonnent les carrières et les performances dans tous les domaines.
L'alpha est la part de leader prise par le plus performant dans la compétition, lorsque vous jouez votre coup de jeu de la plus haute valeur. Les décroissances sont des schémas établis que tout le monde apprend par la répétition et en observant les autres (des plateaux, si vous préférez). Le goût est la capacité la plus précoce à sentir le leadership dans un alpha ou un changement dans une décroissance. C'est notre jugement sur ce qui va arriver avant d'avoir la moindre preuve que quoi que ce soit se produit. Le point de Paul Graham est que lorsque tout le monde peut fabriquer n'importe quoi, choisir quoi fabriquer importe davantage, et la définition de Mitchell Hashimoto est la définition opérationnelle : porter des jugements qualitatifs de haute qualité là où aucune métrique objective n'existe encore. Désormais, le goût pilote tout : les changements d'alpha sont des changements de goût. Et les décroissances s'estompent parce que nous commençons à goûter quelque chose de différent.
Prochaine étape ? Opérationnalisez votre goût. Comment ? Donnez-lui un nom qui reflète ce que vous essayez de faire passer du limbique au conscient. Pratiquez-le dans la critique et les exemples. Rendez sa raison d'être explicite.
Et continuez à faire le mouvement qui offre l'avantage concurrentiel le plus durable dans votre industrie. Qu'est-ce que c'est ? Continuez à déplacer la frontière de la simple exécution de la tâche vers son enseignement, sa systématisation, la décision du moment où elle doit être faite, et la possession du résultat.
Tout le monde est un développeur, mais tout le monde n'est pas un ingénieur. L'ingénierie est ce en quoi un développeur se transforme lorsqu'il adopte une discipline de travail plus stricte : un raisonnement approfondi et logiquement solide, la prise en compte des contraintes et des compromis, la reconnaissance des risques et des expositions, et une responsabilité pratique.
À l'avenir, les gens laisseront le travail administratif de l'ingénierie et embrasseront de nouveaux rôles qui émergeront à mesure que l'ingénierie deviendra plus exigeante. Des rôles qui sont désolidarisés de l'esprit du métier mais qui clarifient ce que chaque personne fait. Il y aura ceux qui prototypent. Ceux qui construisent. Ceux qui nettoient. Ceux qui font croître. Ceux qui maintiennent.
Les humains tiennent également la frontière du système dans l'autre direction. Augmenter l'alpha dans l'autre direction : choisir ce qui vaut la peine d'être fait, définir les contraintes dans lesquelles cela doit être fait, décider si les preuves sont suffisantes pour procéder, et prendre soin du résultat. Que ce soit une seule équipe ou une centaine d'équipes, c'est la frontière que seuls les humains peuvent tenir.
La responsabilité mettra l'usine à l'échelle. Comme l'attention et le goût, la responsabilité est aussi l'une des trois dualités qui font fonctionner les choses. Sans responsabilité, il n'y a pas de règles. Pas de débat avec les questionneurs. Pas de compromis. Pas de risques. Pas de filets de sécurité. Si personne ne possède la conséquence d'une décision, alors une agencéité élevée ne peut qu'apporter le chaos.
La demi-vie d'une frontière est une release, mais la demi-vie d'une signature est une carrière. Une signature, c'est votre nom sur le travail, de sorte que vous sentez que vous pouvez défendre ce qui a été livré. Les compétences vous donnent un effet de levier ; la responsabilité transforme cet effet de levier en confiance.
Seules les personnes peuvent choisir. Seules les personnes héritent des conséquences. On peut demander aux agents de choisir, d'acheminer, de fusionner et d'escalader en toute sécurité dans le cadre d'une politique, mais ils ne peuvent pas hériter des conséquences.
Chaque base de code devrait peut-être être accompagnée d'une sorte de contrat de responsabilité qui énonce explicitement la liste de contrôle qui a été comprise lorsque le changement a été accepté, les preuves qui ont étayé la décision, qui était responsable du changement, et l'état du système après que le changement a été bloqué. Tout comme :
- Votre attention et votre goût
- Vos preuves, votre verdict et votre propriété
- Votre alpha, votre décroissance et votre goût
Haute agencéité
Dans un flux de travail agentique typique, la haute agencéité est l'art de savoir quand déléguer, quand inspecter, quand s'arrêter et quand posséder le résultat d'un processus. L'échelle de l'agencéité va de basse à haute : signaler un problème potentiel, l'investiguer, agir en conséquence, le diagnostiquer, proposer des solutions, recommander des correctifs et résoudre le problème. Un échelon élevé sur l'échelle de l'agencéité est le discernement : trouvé, ça ne vaut pas la peine d'être corrigé, on passe à autre chose.
Les douze piliers qui soutiennent l'usine logicielle
Le brownfield est la frontière pour les usines qui espèrent passer à l'échelle. Toutes ces petites innovations astucieuses ne semblent peut-être pas encore grand-chose, mais l'environnement de production est conséquent. Lors de la construction d'un système entièrement nouveau, il est beaucoup plus facile de planifier et d'implémenter des mécanismes de contre-pression suffisants car vous avez un contrôle total. Cependant, lorsque vous ajoutez des agents intelligents à un système existant, c'est une tout autre affaire.
Les systèmes existants incluent la totalité du comportement de production, les attentes futures des clients, les historiques de migration, les durées des cycles de release et de budget, les hypothèses non dites, les cas limites, les bizarreries des données, les procédures opérationnelles, et toutes les cicatrices accumulées sans la volonté de prendre soin du système.
Être un intendant du brownfield nécessite une forme d'ingénierie durable. Un travail doit être fait pour transformer la connaissance implicite en contraintes explicites, la maintenir cohérente entre les équipes et à travers les générations, formaliser cette connaissance en procédures de test et spécifications fonctionnelles, et lier cette connaissance à des preuves objectives. Le tout en transformant les échecs en apprentissage. Parce que si le système ne reçoit pas les soins qu'il a toujours reçus, tout s'effondrera.
Le nouveau travail est un vrai travail
Le travail deviendra plus intéressant à mesure que vous passerez à l'échelle. Parce que quand tout le reste est construit, les gens voudront construire de nouvelles choses. Ils voudront utiliser l'alpha et le goût qu'ils ont développés à travers leur métier pour concevoir de nouvelles boucles qui pourront être greffées sur l'usine logicielle. Ou ils voudront construire des systèmes greenfield qui emploient toute la connaissance de l'usine logicielle dans un effort élégant, bien intentionné et fondé sur des principes. Ils voudront concevoir et implémenter de nouvelles formes de preuves qui s'élèveront au niveau de vérification pour les nouveaux systèmes. Ils voudront prendre soin des systèmes brownfield qui sont maintenant si complexes qu'ils nécessitent une attention dédiée. Ils voudront concevoir et gérer de nouveaux mécanismes de contre-pression. Ils voudront concevoir de nouveaux agents. Et ils voudront construire de l'agencéité.
Et, ce faisant, ils finiront par voir que tout cela est un vrai travail. C'est une bonne chose.
L'automatisation crée des goulots d'étranglement. Des goulots d'étranglement dans la production qui valent la peine d'être possédés. Parce que l'automatisation nous donne le contrôle à l'échelle industrielle. Mais il y a aussi de nouveaux goulots d'étranglement qui découlent de l'échelle industrielle. Le goulot d'étranglement passe de « pouvons-nous construire cela ? » à « cela devrait-il exister, pouvons-nous en répondre ? »
Ce que je suggère, c'est un modèle opérationnel pratique pour passer à l'échelle l'ingénierie agentique. Il y a des boucles internes et externes. La boucle interne est l'endroit où le travail est effectué. Les boucles sont conçues pour être aussi indépendantes que possible. Mettez toutes les assurances qualité et la vérification à l'intérieur de la boucle. Une fois que vous avez conçu et validé la boucle elle-même, la seule chose qu'il vous reste à faire est d'accorder l'autonomie en mettant en place un mécanisme de contre-pression qui agit pour contrôler le taux d'exécution de la boucle et son périmètre d'opération. Et placez les humains à leur juste place, sur les bonnes décisions. Ne traitez pas la compréhension comme un transfert ou une porte de release, mais plutôt comme un point de décision où les humains sont préparés à fournir leur perspicacité. Et ensuite, pour chaque artefact qui existe et est réinjecté dans la production et dans les nouvelles équipes et ingénieurs, laissez derrière vous de meilleurs artefacts.
Construisez l'usine ; maintenez les lumières allumées ; rendez le travail lisible, vérifiable, possédé.
Un agent peut l'écrire. Mais avant qu'il n'atteigne les utilisateurs, quelqu'un doit expliquer pourquoi il devrait exister, pourquoi il est suffisamment sûr pour faire partie de la production, et ce qu'il fera quand il aura tort.
C'est cela, l'ingénierie agentique à la boucle externe - c'est cela, le travail maintenant.
Pangram a noté cet article comme étant écrit à 100 % par un humain : https://www.pangram.com/history/ae6caccc-b70f-4336-a019-5c3411516871
