Posséder la boucle externe

• Même si les agents prennent en charge la boucle d’exécution interne, où ils alternent recherche, implémentation et validation, l’ingénieur doit posséder la boucle externe, qui décide du déploiement et assume la responsabilité du résultat
• Les systèmes agentiques fonctionnent sur la base de la qualité (Quality), c’est-à-dire les contrôles préalables, du verdict (Verdict), qui décide de la mise en production, et de l’explicabilité responsable (Answerability), qui permet d’expliquer les raisons d’une décision
• Dans l’enquête 2026 de Sonar, 42 % du code commité s’est révélé généré par l’IA ou fortement assisté par l’IA ; à mesure que la vitesse de génération dépasse la vitesse de contrôle, la revue, la vérification, la compréhension et la maintenance deviennent des ressources rares
• L’usage de l’IA s’accompagne d’une reddition cognitive, qui consiste à accepter telles quelles des réponses erronées, d’une dette cognitive qui affaiblit la compréhension du code, et d’un coût d’orchestration lié à la gestion de plusieurs agents avec une attention humaine limitée
• Une fabrique logicielle scalable n’est possible qu’en donnant aux agents non pas une autonomie maximale, mais une autonomie interruptible, ajustable et vérifiable, tandis que les humains assument les contraintes, les revues par échantillonnage, les audits, la propriété et le résultat final

---

La boucle externe de l’ingénierie agentique

• Le débat sur l’ingénierie agentique se déplace vers les harnais d’agents, les boucles, les flottes et les fabriques logicielles
• À mesure que des modèles puissants comme Fable et GPT-5.6 apparaissent, les ingénieurs doivent posséder directement la boucle externe, c’est-à-dire la responsabilité du système
• Le levier élevé des agents crée des obligations équivalentes
  • Être capable d’expliquer précisément ce qui a changé
  • Expliquer pourquoi ce changement était sûr
  • Savoir ce qui se passera si le jugement était erroné
• Si ces conditions ne sont pas remplies, il est impossible de justifier les actions de l’agent, et l’organisation aura aussi du mal à utiliser un tel système

Qualité, verdict et explicabilité responsable

• La qualité (Quality) désigne tous les contrôles mis en place avant de lâcher le système ; les preuves obtenues servent de base au verdict
• Le verdict (Verdict) est la décision finale de production prise par un humain avant qu’un travail n’entre dans les systèmes dépendants
  • Même si le modèle écrit le code, la personne qui déploie le travail sous son nom porte la responsabilité du verdict
  • Elle décide entre déployer, bloquer, changer de chemin, réduire le périmètre de réponse, ajouter des garde-fous ou refuser entièrement
• L’explicabilité responsable (Answerability) garantit que l’on peut expliquer ce jugement si quelqu’un en demande les raisons
• Un modèle peut écrire une ligne de code, mais il ne prend pas à la place de l’humain la responsabilité de décider s’il faut la transmettre à un système dépendant

Modèles, harnais, boucles et fabriques

• Un agent ne se limite pas à un modèle : il inclut aussi le harnais qui combine fichiers, outils, mémoire, compétences, sandbox, permissions, observabilité et mécanismes de récupération
• Si le modèle est le moteur, le harnais est la voiture construite autour du moteur pour que le travail réel soit effectué en sécurité
  • Les outils et la mémoire fournissent la capacité d’action
  • Les permissions et le sandbox limitent le périmètre d’exécution
  • Les tests et l’observabilité permettent de vérifier le résultat du travail
• La boucle d’exécution d’un agent se compose de recherche → implémentation → vérification → itération
  • Un cycle répétable transforme une réussite ponctuelle en processus à nouveau fiable
  • L’achèvement d’une tâche doit être déterminé par des contrôles indépendants, non par le propre jugement du modèle
• L’exploitation simultanée de plusieurs boucles devient une fabrique logicielle
  • À l’intérieur, les agents produisent le travail
  • À la frontière, les humains possèdent les décisions de production

La frontière entre l’intérieur et l’extérieur du système

• Au cœur d’une fabrique logicielle se trouve une frontière qui sépare l’intérieur et l’extérieur du système
• Le système interne collecte en entrée l’intention de l’équipe produit, les connaissances sur les déploiements passés, les incidents récents et les retours utilisateurs concrets
• Les boucles d’agents étudient le travail, implémentent le plan, puis vérifient les résultats
• Lorsque les preuves produites par la vérification franchissent la frontière du système, l’humain propriétaire du système dépendant décide s’il faut continuer
• Par le passé, les agents n’exécutaient qu’une partie du processus ; désormais, ils peuvent prendre en charge toute la boucle d’exécution interne, tandis que l’ingénieur s’occupe de la boucle externe
• Ce que les agents à l’intérieur de la frontière fournissent, c’est une capacité (capability)
  • Étudier une tâche
  • Implémenter un plan
  • Tester le résultat
  • Rapporter le résultat
• Ce que les humains à l’extérieur de la frontière exercent, c’est la capacité d’agir (agency)
  • Décider
  • Vérifier
  • Approuver
  • Posséder

L’écart de confiance et de vérification créé par le code IA

• La part du code IA n’est plus marginale
• Selon le rapport State of Code 2026 de Sonar, 42 % du code commité est généré par l’IA ou fortement assisté par l’IA, et les répondants s’attendent à ce que cette part continue de croître au lieu de se stabiliser
• À mesure que le coût de génération du code baisse, la revue, la vérification, la compréhension et la maintenance deviennent des ressources plus rares
• Comme la vitesse de génération augmente plus vite que la vitesse de contrôle, un écart de confiance et de vérification apparaît
  • Beaucoup expriment de la méfiance envers le code IA
  • Moins nombreux sont ceux qui traduisent cette méfiance en procédures de vérification cohérentes
• Il faut des moyens moins coûteux et plus clairs de confirmer la fiabilité du code IA

Les limites de la gouvernance a posteriori

• Selon l’étude de GitLab de juin 2026 sur la responsabilité de l’IA, le goulot d’étranglement actuel de l’usage de l’IA est la revue et la vérification
• La gouvernance s’applique surtout après la création du code
  • À ce stade, l’organisation a déjà accepté le risque
  • Le contrôle de la propriété du travail s’est aussi déjà affaibli
• La gouvernance de l’IA doit aller au-delà du simple contrôle du système et déterminer les points suivants
  • Quelles contraintes imposer au système
  • Avec quelles preuves inspecter le travail
  • Comment demander des comptes aux équipes
  • Qui possède chaque partie du cycle de vie de l’IA

La contre-pression qui produit la qualité

• La qualité peut être comprise comme une contre-pression (back pressure) exercée sur le système
• L’objectif n’est pas de donner aux agents le maximum d’autonomie possible
• Il faut leur donner juste assez d’autonomie pour pouvoir les interrompre, les ajuster, inspecter leur travail et préserver le rôle humain
• L’ingénierie existante dispose déjà de signaux indiquant si le travail va dans la bonne direction
  • Vérification de types
  • Tests
  • Hooks
  • Limites de sandbox
  • Journaux d’audit
  • Moniteurs
• Si les agents émettent les mêmes signaux, les cadres d’ingénierie existants peuvent fournir une contre-pression appropriée

Les quatre boucles où l’humain doit intervenir

• Faire confiance à un système ne signifie pas retirer l’humain de la boucle
• Les humains doivent se trouver non pas dans la boucle d’exécution interne, mais dans les quatre boucles de contrôle externes suivantes
  • Boucle des contraintes : décider quels inputs, architectures, consignes et invariants définir
  • Boucle de revue par échantillonnage : déterminer quelle part des sorties extraire et examiner
  • Boucle d’audit : décider quelles preuves conserver et comment garantir la validité des journaux d’audit
  • Boucle de propriété : clarifier qui possède quelle partie de la frontière de production
• Les agents peuvent produire plus de travail que les humains ne peuvent en examiner
• La ressource rare est donc le jugement humain essentiel, exercé à partir de signaux de qualité comme les logs et les tests
• Dans l’environnement expérimental étudié par OpenAI sur les agents et l’avenir du travail, la délégation agentique à l’échelle de plusieurs heures a déjà atteint un stade possible
• Il faut établir les frontières de propriété avant que le système ne produise plus de travail qu’il n’est possible d’en examiner

Agents longue durée et explicabilité responsable

• Tous les choix effectués par des agents longue durée qui s’exécutent pendant des heures sont des décisions
• Toutes les décisions ne sont pas enregistrées, et chacune ne peut pas non plus être retracée jusqu’aux tokens d’entrée
• Si l’on se contente de croire que le résultat est le bon choix pour le problème, reconstruire la chaîne de décisions qui y a mené peut nécessiter des centaines ou des milliers d’heures de travail humain
• Comme cette chaîne de décisions est, en pratique, difficile à reconstruire, l’explicabilité responsable doit être placée au centre de la conception du système

Les trois coûts cachés de la délégation à l’IA

• Reddition cognitive

  • La reddition cognitive (cognitive surrender) est le phénomène qui consiste à accepter aveuglément les résultats fournis par l’IA
  • Même si une tâche est confiée à un agent, le livrable reste lié au travail, à la réputation et à la responsabilité de l’utilisateur
  • Les défauts restent dans le logiciel de l’utilisateur
  • Ce qui doit être modifié pour s’adapter à la sortie est aussi le logiciel de l’utilisateur
  • La réponse de l’agent devient finalement la réponse de l’utilisateur, et la responsabilité l’accompagne
  • Dans une étude de Wharton, même lorsque l’IA se trompait, près des trois quarts des participants acceptaient sa réponse et affichaient une confiance plus élevée que lorsqu’ils jugeaient sans IA

• Dette cognitive

  • La dette cognitive (cognitive debt) désigne l’affaiblissement de la compréhension et de la mémoire de la façon de résoudre un problème
  • Lorsque l’on délègue une tâche à un agent, le processus de réflexion est lui aussi externalisé
  • Le temps et l’énergie nécessaires pour comprendre soi-même une grande codebase peuvent être difficiles à dégager dans le processus d’apprentissage
  • Résultat : les livrables produits par l’agent peuvent atteindre un niveau difficile à atteindre avec les compétences actuelles de l’utilisateur
  • Plus le temps de planification de l’agent est long, plus l’écart entre le code généré et la compréhension humaine s’élargit
  • Cet écart s’accumule, et le coût pour remonter la courbe d’apprentissage augmente presque de façon exponentielle
  • Dans un essai contrôlé randomisé d’Anthropic, les ingénieurs ayant écrit du code avec l’IA ont obtenu 50 % aux quiz de compréhension, soit 17 points de pourcentage de moins que les 67 % du groupe ayant écrit le code directement

• Coût d’orchestration

  • Le coût d’orchestration (orchestration tax) vient du fait que même si de nombreux agents peuvent s’exécuter simultanément, la bande passante cognitive humaine ne se parallélise pas de la même manière
  • Les humains doivent effectuer directement les tâches suivantes
    • Ajuster les agents pour qu’ils évitent les pires comportements
    • Sélectionner, parmi les livrables, ceux qui nécessitent de l’attention
    • Indiquer quelles tâches importantes traiter en premier
    • Vérifier les contraintes critiques et les hypothèses dangereuses avant l’exécution
  • Ce travail ne peut pas être automatisé et ne peut pas remplacer le jugement humain

Protéger l’attention dans le brownfield

• Les systèmes brownfield sont particulièrement risqués, car les comportements à auditer ne résident pas seulement dans le code, mais aussi dans les cicatrices et l’histoire accumulées
• Les décisions d’architecture doivent donner la priorité à l’attention humaine
• L’utilisation de worktrees, de périmètres et de preuves permet de réduire le couplage entre le plan initial et les tâches nouvellement révélées pendant l’exécution
• Les tentatives de résolution d’étapes non exécutables doivent être limitées dans le temps
• Les droits de modification logicielle doivent être accordés selon un modèle strictement opt-in

Alpha, decay, taste

• Les trois motifs clés qui façonnent les carrières et les performances dans plusieurs domaines sont alpha, decay et taste
• Alpha est la zone de tête occupée par les personnes les plus performantes dans la compétition, et l’état consistant à jouer les coups les plus précieux
• Decay désigne les schémas établis que tout le monde a appris par répétition et observation, et que l’on peut voir comme une forme de plateau
• Taste est le jugement qui détecte l’avance de l’alpha ou le changement du decay avant que les preuves n’apparaissent
• La discussion de Paul Graham explique que lorsque n’importe qui peut créer n’importe quoi, le choix de ce qu’il faut créer devient plus important
• Dans la définition de Mitchell Hashimoto, le taste est un jugement qualitatif de haute qualité porté lorsqu’il n’existe pas encore de métrique objective
• Les déplacements de l’alpha se produisent par des changements de taste, et le decay disparaît lorsque les gens commencent à préférer autre chose

Faire du taste une capacité opérationnelle

• Pour transformer le taste, jusque-là intuitif, en capacité consciente, il faut d’abord lui donner un nom
• Il faut exercer ce jugement au moyen de critiques et d’exemples concrets
• Les raisons du jugement doivent également être formulées explicitement
• Pour accroître un avantage concurrentiel durable, il faut continuer à déplacer vers le haut les frontières du rôle
  • Effectuer directement le travail
  • Enseigner le travail à d’autres personnes ou systèmes
  • Systématiser le travail
  • Décider quand il doit être effectué
  • Posséder le résultat

La différence entre développeur et ingénieur

• Tout le monde peut devenir développeur, mais tout le monde n’est pas ingénieur
• Un développeur devient ingénieur lorsqu’il accepte une discipline de travail plus stricte
  • Raisonnement rigoureux et logiquement valide
  • Prise en compte des contraintes et des compromis
  • Conscience des risques et de l’exposition
  • Responsabilité réelle
• À mesure que l’ingénierie devient plus exigeante, les personnes sortent des tâches de gestion et dissocient les rôles autrefois liés à l’artisanat afin de clarifier la fonction de chacun
  • Les personnes qui prototypent
  • Les personnes qui construisent
  • Les personnes qui mettent en ordre
  • Les personnes qui font croître
  • Les personnes qui maintiennent

La frontière du système que seuls les humains peuvent garder

• Les humains jouent aussi un rôle d’élévation de l’alpha à l’autre frontière du système
  • Choisir ce qui vaut la peine d’être fait
  • Définir sous quelles contraintes l’exécuter
  • Juger si les preuves sont suffisantes pour avancer
  • Prendre soin du résultat
• Qu’il y ait une équipe ou cent, cette frontière ne peut être possédée que par des humains
• Attention, taste et responsabilité sont les éléments clés qui font fonctionner une fabrique logicielle
• Sans responsabilité, il n’y a pas non plus de règles, de réponses aux questions, de compromis, de risques ni de filets de sécurité
• S’il n’y a personne pour posséder les conséquences des décisions, une forte capacité d’agir mène au chaos

Une signature qui dure plus longtemps que la technologie

• La demi-vie d’un avantage technique peut être d’une release, mais celle de la signature laissée dans le travail s’étend sur toute une carrière
• Une signature signifie pouvoir mettre son nom sur le résultat déployé et le défendre
• La technologie crée du levier, et la responsabilité transforme ce levier en confiance
• Seules les personnes choisissent et héritent des conséquences
• Les agents peuvent choisir, router, fusionner et escalader dans le cadre d’une politique, mais ils ne peuvent pas hériter des conséquences

Le contrat de responsabilité de la codebase

• Chaque codebase peut avoir besoin d’un contrat de responsabilité qui explicite les conditions d’acceptation des changements
  • Une checklist confirmant ce qui a été compris au moment de l’approbation
  • Les preuves utilisées pour le jugement
  • La personne responsable du changement
  • L’état du système après le blocage du changement
• Le contrat doit traiter explicitement les liens entre attention et taste, preuves, verdict et propriété, ainsi qu’alpha, decay et taste

L’échelle de la forte capacité d’agir

• Dans les workflows agentiques, une forte capacité d’agir est la capacité de savoir quand déléguer, inspecter, interrompre et posséder le résultat
• L’échelle de la capacité d’agir va des niveaux bas vers les niveaux élevés
  1. Signaler un problème potentiel
  2. Étudier le problème
  3. Exécuter une action de réponse
  4. Diagnostiquer la cause
  5. Proposer une solution
  6. Recommander une correction
  7. Résoudre le problème
• Les niveaux supérieurs incluent aussi le discernement consistant à découvrir un problème, puis à juger qu’il ne vaut pas la peine d’être corrigé et à passer à autre chose

Pourquoi le brownfield est la ligne de front des fabriques logicielles

• Le brownfield est la ligne de front que les fabriques logicielles souhaitant passer à l’échelle rencontreront
• Les systèmes greenfield permettent de contrôler l’ensemble, ce qui rend relativement plus facile de planifier et d’implémenter suffisamment de mécanismes de contre-pression
• Lorsqu’on ajoute des agents intelligents à des systèmes legacy, il faut aussi traiter la complexité située en dehors du code
  • Comportement global en production
  • Attentes futures des clients
  • Historique des migrations
  • Cycles de release et de budget
  • Hypothèses implicites
  • Cas d’exception
  • Particularités des données
  • Procédures de runbook
  • Cicatrices accumulées sans gestion
• Prendre soin du brownfield exige une ingénierie durable
  • Transformer le savoir tacite en contraintes explicites
  • Maintenir la cohérence des connaissances entre équipes et générations
  • Formaliser les connaissances en procédures de test et en spécifications fonctionnelles
  • Relier ces connaissances à des preuves objectives
  • Accumuler les échecs comme apprentissages supplémentaires
• Si le niveau de gestion dont il bénéficiait jusque-là disparaît, l’ensemble du système peut s’effondrer

Le nouveau travail qui apparaît avec l’échelle

• Lorsque les composants existants sont automatisés, les humains utilisent l’alpha et le taste issus de leur expérience artisanale pour concevoir de nouveaux travaux
  • Concevoir de nouvelles boucles à greffer sur la fabrique logicielle
  • Utiliser les connaissances obtenues de la fabrique pour construire des systèmes greenfield plus principiels
  • Créer de nouvelles formes de preuves permettant de vérifier de nouveaux systèmes
  • Prendre soin de systèmes brownfield devenus assez complexes pour nécessiter une gestion dédiée
  • Concevoir et gérer de nouveaux mécanismes de contre-pression
  • Concevoir de nouveaux agents
  • Construire de nouveaux régimes de capacité d’agir
• Toutes ces activités sont aussi du véritable travail d’ingénierie et deviennent des problèmes plus intéressants à mesure que l’échelle augmente

L’automatisation déplace les goulots d’étranglement

• L’automatisation donne un contrôle à l’échelle industrielle tout en créant de nouveaux goulots d’étranglement
• Si le goulot d’étranglement d’hier était « peut-on construire ceci ? », celui de demain devient « ceci doit-il exister, et peut-on en expliquer et en assumer les conséquences ? »
• Le nouveau goulot d’étranglement en production mérite d’être possédé directement par des humains

Le modèle opérationnel de l’ingénierie agentique

• Les boucles internes sont l’endroit où le travail réel s’effectue, et chaque boucle doit être conçue aussi indépendamment que possible
• Toute l’assurance qualité et la vérification doivent être intégrées dans les boucles internes
• Une fois les boucles elles-mêmes conçues et vérifiées, on leur accorde de l’autonomie en installant des mécanismes de contre-pression qui contrôlent la vitesse d’exécution et le périmètre du travail
• Les humains doivent être placés aux bons points de décision plutôt que dans toutes les étapes internes
• Il ne faut pas traiter la compréhension comme une simple passation ou un gate de release, mais comme un point de décision où l’humain est prêt à fournir de l’insight
• Chaque fois que les livrables sont réinjectés dans la production et vers de nouvelles équipes ou de nouveaux ingénieurs, ils doivent laisser de meilleurs livrables et de meilleures preuves qu’auparavant
• Il faut construire et exploiter en continu la fabrique logicielle, tout en maintenant le travail dans un état lisible, vérifiable et doté d’un propriétaire
• Même si l’agent écrit le code, un humain doit répondre aux questions suivantes avant qu’il n’atteigne les utilisateurs
  • Pourquoi ce code doit-il exister ?
  • Pourquoi est-il suffisamment sûr pour être inclus en production ?
  • Que fera-t-on s’il est erroné ?
• Exercer ce jugement et cette responsabilité constitue la boucle externe de l’ingénierie agentique