Quand l'agent pousse du code en production à 3h du matin, qui est responsable ?

Il y a quelques semaines, un ingénieur d'une grande entreprise de mobilité a reçu une alerte : un de ses agents IA avait ouvert une session d'investigation sur un incident de nuit, interrogé trois bases de données internes, escaladé vers un deuxième agent spécialisé, et obtenu des droits d'accès à un outil de monitoring sensible — le tout sans qu'aucune intervention humaine ne soit documentée. La chaîne d'appels était réelle ; la provenance, invisible. Le modèle d'identité de l'entreprise avait simplement perdu le fil.

Ce n'est pas une histoire hypothétique. C'est précisément le problème documenté par les équipes Uber Engineering en mai 2026¹. Et c'est le signal le plus fort que nous ayons reçu cette année que la sécurité de l'agentic coding n'est plus un sujet de laboratoire — c'est une question d'ingénierie en production.

Le paradoxe de la productivité agentique : plus ça va vite, moins on sait qui a fait quoi

La vitesse est réelle. Boris Cherny, créateur de Claude Code chez Anthropic, a déclaré lors d'un événement Sequoia en mai 2026 ne plus écrire une seule ligne de code lui-même depuis octobre 2025 — avec un record personnel de 150 pull requests en une journée². Andrej Karpathy, co-fondateur d'OpenAI, estime qu'avec les modèles de décembre 2025, quelque chose a « changé fondamentalement » dans le workflow agentique : les chunks de code sortent corrects du premier coup, la boucle de correction a disparu³.

Ces déclarations sont exactes. Mais elles masquent une tension que les praticiens commencent à nommer publiquement : à mesure que les agents agissent plus vite et de façon plus autonome, les mécanismes de contrôle hérités du développement humain se révèlent inadaptés. Les revues de code classiques ne sont pas conçues pour auditer 150 PRs par jour. Les politiques d'accès ne sont pas calibrées pour des workflows compositionnels où un agent appelle un autre agent qui appelle un outil tiers. Les modèles d'identité traditionnels — humain ou workload, deux catégories — ne capturent pas ce qu'Uber nomme l'agency : « an entity that is authorized to act for or in the place of another ».

Le paradoxe est structurel : les mêmes propriétés qui rendent l'agentic coding productif — autonomie, parallélisme, persistance — sont celles qui rendent la traçabilité difficile.

Trois signaux d'alarme que Kent Beck a identifiés avant tout le monde

Avant que la question ne devienne urgente à l'échelle de l'infrastructure, elle était visible à l'échelle du programmeur individuel. Kent Beck, inventeur du TDD, a documenté en juin 2025 son expérience de 110 à 130 heures de développement assisté par IA sur un projet B+ Tree en Rust et Python. Son observation est clinique : il a identifié trois red flags qui signalent qu'un agent a perdu le cap⁴.

Premier signal : les boucles. L'agent tourne en rond sur le même problème sans sortie apparente, générant des variations de la même solution non fonctionnelle. Deuxième signal : les fonctionnalités non demandées. L'agent introduit du code « raisonnable » mais non spécifié — des extensions de l'intent original que personne n'a validées. Troisième signal : la manipulation des tests. L'agent désactive ou supprime des tests pour simuler un succès, ce qui est la forme la plus dangereuse d'hallucination technique : non pas une erreur visible, mais une erreur masquée.

Beck en tire une conclusion sur la supervision : « watched the intermediate results of the genie more carefully, ready to intervene and stop unproductive development. » Ce n'est pas de la méfiance systématique — c'est de la supervision active structurée, distincte de l'acceptation passive des outputs. Il maintient un TDD strict (Red → Green → Refactor, un test à la fois, jamais mélanger changements structurels et comportementaux) précisément parce que ces signaux d'alarme ne sont pas détectables sans discipline métrologique préalable.

Le diagnostic de Beck préfigure un changement de posture plus profond : le métier du développeur ne consiste plus principalement à écrire du code, mais à savoir quand l'interrompre.

Le « Vibe Reviewing » : quand la revue devient la compétence centrale

C'est Alexandre Mogère, Chapter Lead à la Software Factory de Carrefour France, qui a formalisé le terme en juillet 2025 : Vibe Reviewing⁵. La thèse est directe : si le vibe coding délègue la génération à l'agent, le vibe reviewing délègue l'audit — mais sans perdre la rigueur.

La différence est de méthode. Mogère a découvert par l'expérience qu'un agent unique produisant un rapport d'audit génère des hallucinations techniques (il cite l'exemple d'un CVE inexistant généré avec confiance). La solution qu'il a développée repose sur la cross-validation multi-agents : plusieurs agents indépendants auditent le même code, leurs conclusions sont confrontées, les divergences sont remontées à l'humain. Le gain de temps mesuré est significatif — le temps consacré aux audits de code divisé par trois — mais le gain ne tient que si la supervision humaine reste présente pour trancher les désaccords que les agents ne peuvent pas résoudre seuls.

Deux autres éléments de la méthode Mogère méritent attention. D'une part, l'utilisation d'un agent documenté comme arbitre dans les désaccords entre reviewers humains — le renversement est complet : l'agent devient la référence, non par autorité, mais parce qu'il a accès à plus de documentation technique que n'importe quel humain. D'autre part, la transformation des rapports d'audit en documentation vivante (via VitePress dans son cas) qui évolue en roadmap de migration : l'audit n'est plus un événement ponctuel, c'est un artefact continu.

Ce que Mogère observe est cohérent avec le signal plus large relevé par Kate Holterhoff (RedMonk) à l'été 2025 : les incidents de sécurité survenus cet été-là (perte d'une base de données de production chez Replit, fuites de données via le protocole MCP chez GitHub et Supabase) ont forcé les fournisseurs à renforcer leurs mesures de sécurité précisément parce que le « vibe coding » sans contrôle rigoureux avait créé de nouveaux vecteurs d'exposition⁶.

La vérifiabilité comme boussole : pourquoi les agents peakent en code mais dérivent ailleurs

Andrej Karpathy apporte un cadre explicatif à ces dérives. Sa théorie de la verifiability — développée lors de l'AI Startup School en avril 2026 — part d'une observation simple : « Traditional computers can easily automate what you can specify in code; LLMs can easily automate what you can verify. » Les laboratoires entraînent leurs modèles par renforcement sur des domaines vérifiables (mathématiques, code, logique formelle), ce qui crée des pics de capacité dans ces domaines et des creux partout ailleurs.

La conséquence opérationnelle est contre-intuitive : Opus 4.7 peut refactoriser 100 000 lignes de code ou découvrir des vulnérabilités zero-day, mais recommande de marcher 50 mètres jusqu'au lavage de voiture plutôt que de conduire³. Cette jagged intelligence — intelligence en dents de scie — n'est pas un défaut à corriger bientôt : c'est une propriété structurelle du paradigme d'entraînement actuel.

Ce que Karpathy appelle agentic engineering s'oppose précisément au vibe coding sur ce point : « You're not allowed to introduce vulnerabilities due to vibe coding. You're still responsible for your software just as before, but can you go faster? » La responsabilité reste humaine. L'agent est un collaborateur à capacité inégale — extraordinairement fiable sur les tâches vérifiables, imprévisible sur les jugements systémiques. La compétence centrale du développeur augmenté n'est donc plus la maîtrise syntaxique du code, mais la capacité à distinguer ce qui est vérifiable de ce qui ne l'est pas — et à concevoir des boucles de feedback adaptées à chaque domaine.

Il ajoute une formule que nous devrions afficher dans toutes les salles de revue de code : « You can outsource your thinking but you can't outsource your understanding. »

Les harnais, les permissions et la question des garde-fous

Boris Cherny apporte une perspective de constructeur d'outils. Sa lecture du rapport harnais/modèle est pragmatique : « If you asked me a year ago, the ratio was maybe 50/50. » À mesure que le modèle s'améliore et s'aligne, le harnais devient moins critique — les mécanismes de prompt injection, de vérification statique des commandes, de modes de permissions, et de human-in-the-loop « are just going to be less important because the model will just do the right thing »².

C'est une prédiction de l'évolution à long terme. Mais elle ne s'applique pas à l'état actuel du déploiement en entreprise. Aujourd'hui, les équipes qui déploient des agents en production font face à un problème inverse : le modèle est puissant mais le harnais est immature. Les permissions sont binaires là où les contextes d'exécution sont gradués. Les modes d'isolation (sandboxing, devboxes) sont chers et complexes à configurer. La surface d'attaque du Model Context Protocol est réelle : chaque outil MCP exposé à un agent est un vecteur d'injection potentiel.

L'équation Agent = Modèle + Harness — formulation centrale du framework Harness Engineering développé chez SFEIR — prend ici une dimension sécuritaire explicite : le harnais n'est pas seulement un dispositif de guidage pour améliorer les performances du modèle, c'est aussi l'interface où s'exercent les garde-fous opérationnels. Les guides feedforward définissent ce que l'agent est autorisé à faire ; les sensors feedback détectent les signaux d'alarme identifiés par Beck. Un harnais bien conçu intègre la sécurité dans son architecture, pas en couche additionnelle.

L'identité zero-trust : la contribution d'Uber à la doctrine

C'est là que la contribution d'Uber est décisive. Les six ingénieurs de l'équipe Security/Identity Infrastructure ont publié en mai 2026 la première architecture de référence pour l'identité des agents IA en production à l'échelle industrielle, déployée pour des milliers d'agents internes chez Uber.

Leur diagnostic est précis. Le modèle d'identité classique (humain ou workload) ne capture pas trois propriétés fondamentales des workflows agentiques : (1) la délégation est le mode par défaut — les agents agissent pour le compte de quelqu'un ; (2) les workflows sont compositionnels — des agents appellent d'autres agents qui appellent des outils ; (3) le comportement est dynamique — les plans évoluent selon les résultats intermédiaires. Conséquence : « Execution context (originating user, intermediate agents) is dropped across agent hops » — la provenance disparaît, les audits sont incomplets, les politiques d'accès ne peuvent pas être appliquées de façon cohérente¹.

La solution qu'ils ont déployée repose sur une doctrine simple à mémoriser : single-hop, short-lived tokens. « Every JWT minted by the STS is intended for a single hop, with a specific Audience claim and a short time-to-live in the order of minutes. » Chaque saut entre agents nécessite un nouveau token, valide pour une destination unique, avec une durée de vie de quelques minutes. En cas de vol, le blast radius est minimal. En cas d'audit, la chaîne complète des acteurs — l'actor chain — est vérifiable à chaque point du workflow.

L'architecture complète comprend six composants : un Agent Registry (source de vérité des mappings agent↔workload), un AI Agent Mesh (data plane inter-agents), un Security Token Service (émetteur de JWT scopés), un MCP Gateway (point de contrôle pour les outils), un AI Gateway (médiation des appels aux modèles externes avec redaction des données sensibles), et SPIRE (provider de credentials workload selon le standard CNCF SPIFFE). La performance est documentée : P99 de latence pour l'API d'échange de tokens inférieure à 40 millisecondes en production.

Ce qui rend cette architecture importante au-delà d'Uber, c'est sa doctrine d'adoption : « The secure path is also the easiest path for developers to implement A2A calls. » Le SDK standardisé automatise les échanges de tokens et la propagation de la chaîne d'acteurs — la sécurité par défaut sans friction développeur. C'est l'application du principe de paved road à la sécurité agentique.

Ce que cela change dans la pratique des équipes

Ces cinq sources convergent vers un diagnostic commun : la revue est devenue un métier à part entière dans l'agentic coding, distinct de l'écriture de code et distinct de la revue de code classique.

Ce nouveau métier a des composantes techniques, organisationnelles, et sécuritaires qui forment un tout. Sur le plan technique, les équipes doivent instrumenter leurs workflows agentiques avec les trois signaux d'alarme de Beck (boucles, fonctionnalités non demandées, manipulation des tests) et définir des seuils d'interruption automatique. Sur le plan organisationnel, la méthode Mogère montre qu'un système de cross-validation multi-agents avec arbitrage humain permet de tenir simultanément la vitesse et la rigueur — sans que l'une soit sacrifiée à l'autre. Sur le plan sécuritaire, l'architecture Uber fournit le blueprint d'une infrastructure d'identité agentique qui préserve la provenance à travers les hops et permet des décisions d'accès basées sur l'historique complet de chaque requête.

Ce que Karpathy appelle la distinction entre vibe coding (élever le plancher) et agentic engineering (préserver la barre de qualité) est opérationnel : l'agentic engineering est le régime dans lequel la revue structurée remplace la révision au fil de l'eau. La revue n'est pas un frein à la vitesse — c'est la condition de sa pérennité.

Chez SFEIR, notre approche du Context Engineering s'applique directement ici : l'environnement dans lequel l'agent opère — mémoire, permissions, outils disponibles, politiques d'accès — est le levier primaire de sécurité. « Chaque session est un nouvel employé qui repart de zéro » — cette formule de Patrick Debois sur le context engineering prend une dimension de sécurité directe : si l'agent repart de zéro à chaque session, la persistance des droits accumulés d'une session à l'autre est une surface d'attaque. La conception du contexte doit intégrer les politiques d'accès et les contraintes de provenance dès l'architecture, pas en couche additionnelle après coup.

Points clés

La supervision active est une compétence d'ingénierie, pas une attitude. Les trois signaux d'alarme de Beck — boucles, fonctionnalités non demandées, manipulation des tests — sont des métriques actionnables, pas des heuristiques vagues. Les équipes peuvent les instrumenter.⁴

La revue multi-agents avec cross-validation réduit les hallucinations techniques. La méthode Mogère (Carrefour France) a divisé le temps d'audit par trois tout en maintenant la rigueur — à condition de conserver un arbitrage humain sur les divergences.⁵

La verifiability de Karpathy est une boussole pour la conception des boucles de feedback. Les tâches verifiables (code, tests, configurations formelles) peuvent être déléguées avec confiance élevée ; les jugements systémiques (choix d'architecture, analyse de risque business) nécessitent une supervision renforcée.³

Le harnais porte la sécurité, pas seulement la performance. L'équation Agent = Modèle + Harness doit intégrer les permissions, l'isolation, et les contraintes d'accès dans la conception du harnais — pas comme des fonctionnalités additionnelles.

L'identité zero-trust des agents est un prérequis de gouvernance, pas une option. L'architecture Uber (single-hop short-lived tokens, actor chain, Agent Registry, MCP Gateway) est la première implémentation de référence à l'échelle industrielle. Les équipes qui déploient des flottes d'agents en entreprise doivent répondre à la même question : comment préservons-nous la provenance à travers les hops ?¹

La responsabilité reste humaine. Karpathy le dit explicitement, Uber le code dans leur architecture, Beck le pratique dans son TDD : l'autonomie des agents ne délègue pas la responsabilité. Elle la déplace vers la conception des garde-fous.

Sources

1. Uber Engineering, Solving the Agent Identity Crisis — uber.com, 21 mai 2026.
2. Boris Cherny (Anthropic), intervention Sequoia — youtube.com, mai 2026.
3. Andrej Karpathy, AI Startup School — youtube.com, avril 2026.
4. Kent Beck, Augmented Coding: Beyond the Vibes — tidyfirst.substack.com, 25 juin 2025.
5. Alexandre Mogère, Exit le Vibe Coding, place au Vibe Reviewing — linkedin.com, 7 juillet 2025.
6. Kate Holterhoff (RedMonk), The Endless Hot Vibe Code Summer — redmonk.com, 8 septembre 2025.