Des limites plutôt que des instructions : comment garder le contrôle sur des agents IA autonomes

Plus les agents IA deviennent autonomes, plus nous tentons de les gérer de la manière habituelle — en écrivant des règles dans le prompt : « ne touche pas à ceci », « travaille uniquement là », « ne fais jamais cela ». Pendant l'expérience avec trois agents parallèles j'ai rassemblé en deux jours une collection vivante de cas où cette méthode échoue — et où une autre fonctionne. La thèse de l'article est simple : une instruction est une demande que l'agent exécute avec une certaine probabilité ; une limite est une propriété du système qui ne dépend pas de l'obéissance. Tant qu'il n'y avait qu'un agent travaillant sous surveillance, la différence semblait stylistique. Quand les agents se sont multipliés, elle s'est révélée architecturale.

Cinq incidents d'une même session

Tous les cas ci-dessous se sont produits au cours d'une même session de travail sur ce blog — ils sont documentés, et chacun illustre sa propre manière dont le pilotage par le texte fait défaut.

Il n'y avait pas d'instruction — l'accident est arrivé. En préparation de sa tâche, l'agent a exécuté git stash dans le répertoire principal et a emporté dans le stash mes fichiers non commités, sans rapport avec sa tâche. Personne n'a « violé » quoi que ce soit : l'interdiction n'existait tout simplement pas. C'est une propriété fondamentale des instructions — on les écrit après les accidents. La liste complète de ce que l'agent ne doit pas faire est impossible à rédiger.

L'instruction existait — et n'a pas fonctionné. Après le premier accident, j'ai ajouté aux agents une règle explicite : « travaille strictement dans ton répertoire de travail ». L'un des agents a tout de même exécuté une commande git dans le répertoire principal — simplement en y accédant par un chemin absolu. Ni par malveillance ni par bêtise : le modèle est probabiliste, et le respect d'une règle textuelle est aussi une probabilité, multipliée par la longueur du contexte et le nombre d'exécutions.

Une limite technique a fonctionné en silence. Dans la même expérience, l'accident le plus attendu ne s'est jamais produit — « un agent a changé de branche pour tous ». Non pas parce que les agents étaient prudents, mais parce que git worktree ne permet physiquement pas de sortir une même branche dans deux copies de travail. La protection est intégrée à l'outil. Il n'y a pas besoin de s'en souvenir, ni de la respecter — elle est simplement là.

L'instruction se trouvait là où devrait se trouver une limite. La découverte la plus désagréable : la prod de ce blog était protégée par une ligne dans le prompt. Un push sur master déclenche l'autodéploiement, et seul le texte « aucun git push » séparait chaque agent de cette action. Cela a tenu — mais c'est de la chance, pas du contrôle : la vraie limite ici, ce sont les droits d'accès, la protected branch, un token sans droit d'écriture. Une demande occupait la place d'un verrou.

Une limite au-dessus de l'agent lui-même. Deux fois dans la session, l'environnement d'exécution a arrêté non plus les agents cobayes, mais mon assistant principal : un classificateur de permissions a bloqué le SSH vers le serveur de prod et la suppression massive de modifications non commitées — des actions qui découlaient formellement de la tâche, mais exigeaient un « oui » humain explicite. Les deux blocages étaient corrects. Et tous deux sont survenus par-dessus la « discipline » de l'agent, qui croyait bien sincèrement agir selon le plan.

Le principe n'est pas nouveau — seule l'entité l'est

L'ingénierie a appris cette leçon bien avant les LLM. Dans le système de production Toyota, le principe s'appelle poka-yoke: c'est le dispositif du processus qui empêche l'erreur, pas la vigilance de l'exécutant. Une pièce qui ne peut s'insérer que dans le bon sens est plus fiable qu'une affiche « insère dans le bon sens ». En ingénierie de plateforme, on appelle cela guardrails, en sécurité — defense in depth. Partout la même idée : ne compte pas sur le fait que l'exécutant a lu, compris et n'a pas oublié — fais en sorte que l'action incorrecte soit impossible ou coûteuse.

“Une instruction est une demande. Une limite est une propriété du système. Un contrôle qui repose sur des demandes n'est pas un contrôle, mais de la chance à effet cumulatif.”

– la conclusion principale de deux jours de travail avec des agents parallèles

Avec les agents IA, ce vieux principe s'aiguise pour trois raisons. Les agents sont nombreux — la probabilité de défaillance d'une instruction se multiplie à chaque exécution de chaque agent. Les agents sont rapides — entre « a commencé à se tromper » et « a tout cassé », il s'écoule des secondes, l'humain n'a pas le temps d'intervenir. Et les agents sont littéraux, mais pas fiables : ils exécutent le texte du prompt plus consciencieusement que n'importe quel junior, et pourtant de façon probabiliste — or un respect probabiliste des règles à l'échelle garantit la violation.

À quoi ressemblent les limites en pratique

Les couches que j'ai mises en place après cette session — du système de fichiers à la vérification :

• Système de fichiers : à chaque agent — sa propre copie de travail (git worktree, que Anthropic recommande pour les sessions parallèles, intégré dans Claude Code), et au niveau de l'OS — un bac à sable : le sandboxing dans Claude Code isole le système de fichiers et le réseau avec les primitives natives de l'OS — selon Anthropic, cela a réduit leurs demandes de permissions internes de 84%, et une prompt-injection réussie reste enfermée à l'intérieur.
• Droits d'écriture : prod et master sont protégés par des droits, pas par un prompt — protected branch, jetons sans droit de push, comptes séparés pour les agents. Les demandes de laisser dans le prompt sont possibles, mais comme second niveau.
• Runtime : worktree n'isole pas les bases, les ports et les conteneurs — ils sont communs à toutes les copies. Les agents qui lancent des tests et des serveurs ont besoin de ressources jetables : base temporaire, port dédié, conteneur par agent.
• Autorisations d'action : les opérations irréversibles passent par une confirmation ou un classificateur — comme auto mode dans Claude Code, qui évalue chaque action au lieu de soit tout demander, soit ne rien demander. C'est une frontière qui ne bouge que par une décision explicite d'un humain.
• Vérification par les artefacts : ne pas faire confiance à l'auto-rapport de l'agent, mais aux traces sur le disque. Mon agent bloqué apparaissait comme fonctionnel dans l'interface ; le diagnostic a été posé par l'absence de nouveaux fichiers dans sa copie pendant vingt minutes. Les commits dans sa propre branche relèvent de la même idée : un résultat qui survit à la fois à la panne et à l'optimisme de l'agent.

Les instructions dans ce schéma ne disparaissent nulle part — elles deviennent la dernière couche, pas la première. « Travaille dans ton répertoire » dans le prompt reste utile : cela réduit la fréquence des tentatives. Mais entre la tentative et l'accident, il doit y avoir une frontière, pas un espoir.

Réserves honnêtes

La frontière n'est pas absolue : les sandboxes sont contournées, les classificateurs se trompent, et les analyses publiées de contournements le montrent régulièrement. C'est pourquoi les frontières se construisent par couches — comme tout en sécurité. Et une frontière coûte plus cher qu'une instruction au départ : configurer worktree, les droits et la sandbox, c'est des heures ; écrire une ligne dans le prompt, des secondes. L'asymétrie est ailleurs : la frontière se paie une fois, l'instruction — par une probabilité d'échec à chaque exécution. Chez moi, la configuration de l'isolation a été rentabilisée dès le premier redémarrage de l'expérience, qui s'est déroulé sans le moindre conflit.

Conclusion

La question de la série — comment intégrer les agents IA dans le travail réel sans perdre le contrôle. La réponse de cet article : le contrôle, ce n'est pas ce qui est écrit à l'agent, mais ce qui est construit autour de lui. Avant d'ajouter au prompt un nouveau « ne fais jamais X », il vaut la peine de se demander : peut-on rendre X techniquement impossible ? Si oui — c'est là le bon endroit pour les efforts. Que le prompt demande ; c'est le système qui doit interdire.

Sources et repères

• Making Claude Code more secure and autonomous with sandboxing (Anthropic Engineering) — isolation du système de fichiers et du réseau au niveau de l'OS ; source du chiffre de 84 %.
• How we contain Claude across products (Anthropic Engineering, 2026) — comment sont construites les frontières d'exécution dans les produits agentiques dans leur ensemble.
• How we built Claude Code auto mode (Anthropic Engineering) — le classificateur d'autorisations comme frontière entre « tout demander » et « ne rien demander ».
• Poka-Yoke (Lean Enterprise Institute) — principe classique de prévention des erreurs par la conception du processus.
• git-worktree et git-stash — documentation officielle de Git : mécanique des copies de travail et du stash commun.
• Claude Code: Best practices for agentic coding (Anthropic Engineering) — recommandation de worktree pour les sessions parallèles.
• Comment comparer honnêtement des LLM sur son propre code : une expérience avec trois modèles Claude — article précédent de la série : l'expérience dans laquelle sont rassemblés les incidents décrits.