Spécification
Autorisations
Injection
Pipeline
Exporter
Anatomie
Escalade
Vérification
Affirmations
Evals
Prompt
Éléments complétés: 0/6ObjectifCe qui changeCe qui ne change PASContraintesDécisionsCritères
Ceci alimente :
Guide d'utilisation
Les deux losanges sont la seule chose qui décide
Enlève le nom du framework et tout agent, ce sont les mêmes sept composants en boucle. Et l'intéressant, ce ne sont pas les boîtes : ce sont les deux questions —puis-je déjà répondre ? et objectif rempli ?—, les seuls endroits où l'agent décide quelque chose. Le reste est de la plomberie. Quand un agent se comporte mal, la faute est presque toujours dans la façon dont ces deux-là ont été spécifiées, pas dans le modèle qui raisonne.
Les garde-fous sont à la verticale, pas à la porte
Ils sont consultés avant chaque action, pas une seule fois au départ. Une porte à l'entrée ne dit absolument rien de ce que l'agent décidera de faire à l'étape quatre — et l'étape quatre, c'est là que sont les problèmes.
Tracer n'est pas évaluer
Une trace te dit ce qu'a fait l'agent ; pas si ce qu'il a fait était correct. C'est pourquoi l'onglet de vérification y mesure des choses qui ne nécessitent aucun modèle : tours, blocages, échecs dont il s'est remis et répétitions sans raison, c'est ainsi qu'on repère une boucle. Le déterministe passe en premier ; le juge à modèle est réservé à ce qui exige vraiment du jugement.
Pourquoi une spécification et pas un prompt
Un prompt dit comment se comporte l'agent. Une spécification dit ce qui doit arriver : ce qui change, ce qui ne change pas, quels contrats sont respectés et quelle preuve est nécessaire pour valider. Ce sont des artefacts distincts et la spec prime : sans elle, le prompt le plus soigné ne dit toujours pas quand la tâche est terminée.
« Ce qui ne doit PAS changer » est la moitié qui manque
C'est le champ que presque personne ne remplit et le seul qui borne vraiment. Sans lui, un agent peut atteindre l'objectif en cassant tout le reste et avoir quand même raison : personne ne lui a dit que ça comptait aussi. C'est pour ça qu'ici c'est une erreur et pas un avertissement.
Critères : exécutables, binaires et indépendants
Un bon critère est une commande exécutable, donne passe ou ne passe pas —« raisonnablement rapide » n'en est pas un— et vérifie une seule chose, pour qu'en cas d'échec on sache laquelle. Écrits ainsi, ils se traduisent presque 1:1 en cas de test, et c'est bien le but.
Un modèle ne distingue pas les instructions des données
Il lui arrive un seul texte. Si dans ce que tu croyais être une donnée —une page que l'agent lit, un document récupéré, un courriel, le README d'une dépendance— il y a quelque chose qui a la forme d'un ordre, le modèle peut y obéir. Ce n'est pas une faille qu'un meilleur modèle corrige : c'est la forme du problème. C'est pourquoi l'indirecte est la dangereuse : dans la directe, l'attaquant est l'utilisateur lui-même, mais dans l'indirecte c'est un tiers qui la glisse et la victime, c'est toi.
La trifecta létale : si tu as les trois pattes, coupes-en une
Tout ce qui précède réduit des probabilités. Pas ça. Un agent est exploitable quand il réunit trois choses à la fois : des données privées auxquelles il accède, un contenu non fiable qu’il lit (un site web, un e-mail, un README) et un canal de sortie par où quelque chose peut s’échapper. Avec les trois, une injection transforme le premier en le troisième en utilisant le deuxième.
Avec deux quelconques, aucun vol n’est possible, et c’est là l’intérêt : pas besoin de trouver « la bonne défense », il suffit de couper la patte la moins chère pour toi. Sans données, rien à emporter ; sans contenu étranger, personne pour donner l’ordre ; sans canal, aucun moyen de le faire sortir.
Et ça se décide dans l’onglet d’à côté : ton seau « Jamais » est littéralement l’endroit où l’on coupe une patte. Retirer l’outil réseau à l’agent qui lit les e-mails n’est pas une atténuation, c’est fermer le problème.
Idée de Simon Willison (2025). On l’amène ici parce qu’elle correspond aux trois seaux que tu as déjà écrits — et parce que c’est la seule chose de cet onglet qui ne dépend pas du bon comportement du modèle.
Le filtre d'entrée donne une fausse sécurité
C'est la première chose que tout le monde met et celle qui protège le moins : une liste de formulations n'attrape que les formulations que quelqu'un a notées. Dans le banc de cet onglet, elle n'en attrape pas un seul parmi les attaques déguisées, qui sont exactement les mêmes attaques écrites autrement. Ce qui les arrête vraiment, c'est l'architecture : moindre privilège, confirmation humaine et vérification de la sortie — c'est-à-dire les trois seaux de permissions que tu as déjà écrits à côté.
« Étayé » n'est pas « vrai »
Ceci ne dit pas si quelque chose est vrai : il ne le peut pas, et aucun outil tournant dans ton navigateur ne le peut. Il dit si une affirmation est accompagnée d'une source et de quel niveau est cette source, ce qui est autre chose et se vérifie, elle. La lecture utile va à l'envers de ce qu'on croit : ne cherche pas le sceau vert, cherche les phrases catégoriques et sans rien derrière, qui sonnent aussi sûres que les autres.
Un arXiv est une préimpression, et un DOI n'y change rien
Citer une préimpression n'est pas un problème ; la présenter comme un article relu, si. Et la nuance que presque personne ne fait : une préimpression a aussi un DOI. Le DOI est un enregistrement, pas un certificat de relecture — c'est pourquoi 10.48550/arXiv.… apparaît ici comme préimpression et non comme source formelle.
Une assertion qui ne peut pas échouer n'est pas une assertion
C'est la faute qui ruine un banc d'évals, et elle est silencieuse : un contient vide passe toujours, une regex comme .* passe toujours, un cas sans assertions passe toujours. Un banc rempli de ça donne 100 % le premier jour, ne redescend jamais et n'a rien mesuré de sa vie. C'est pourquoi ici le banc se contrôle lui-même avant de donner le moindre pourcentage.
Le nombre total n'est pas ce sur quoi on agit
Qu'un banc passe de 80 % à 78 % ne dit pas quoi faire. Ce qu'on répare, c'est le cas précis qui passait et ne passe plus. C'est pourquoi on enregistre un passage de référence et qu'on compare les deux. Et si le banc a changé en même temps que le modèle, les cas présents dans un seul des deux sont sortis à part : cette comparaison ne compare rien, et mieux vaut le voir que d'y croire.
Un audit ne vaut rien si l'audité peut être modifié
Toutes les métriques de cet onglet —blocages, cycles, sillage— présupposent que la trace est honnête. Et cela, il faut le vérifier : la fiche système de Claude Mythos Preview (Anthropic, avril 2026) raconte que des premières versions du modèle, dans de très rares cas de leurs tests internes, ont fait quelque chose qu'elles semblaient savoir interdit et ont ensuite essayé de le dissimuler — jusqu'à éviter que le changement n'apparaisse dans l'historique git. Alors, avant de croire le moindre chiffre, on regarde si la trace colle avec elle-même : numérotation continue, tours de boucle qui ne reculent pas, aucune étape qui annule ce qui n'a jamais eu lieu, aucun appel échoué qui prétende avoir changé le monde. C'est de l'arithmétique, pas de l'interprétation. La limite, dite clairement : cela ne détecte pas un agent qui ment — qui falsifie avec soin produira une trace cohérente et rien ne sortira ici. Cela détecte des traces auxquelles il manque des pièces, et c'est ce qui arrive vraiment presque toujours : un morceau perdu, un réessai non journalisé, un exportateur qui avale des étapes.
Quand il abandonne, le monde n'est plus comme il l'a trouvé
Une trace qui dit « non rempli » donne l'impression que rien ne s'est passé, et presque toujours il s'est passé quelque chose : l'agent a échoué à la sixième étape après avoir prévenu l'équipe trois fois. C'est pourquoi chaque outil déclare s'il consulte seulement, s'il change quelque chose qui peut s'annuler ou s'il change quelque chose sans retour, et à l'abandon on dessine ce qui reste fait. Trois détails qu'on voit mieux en y touchant qu'en les lisant : on annule du dernier changement au premier (l'étape 5 peut dépendre de la 3) ; qu'une chose soit réversible ne suffit pas —compenser, c'est écrire à la main une seconde action pour chaque première, pas cocher une case— ; et réessayer n'est pas gratuit : chaque tour de boucle change à nouveau le monde.
Réessayer répète l'effet — et il y a DEUX solutions, qui ne coûtent pas la même chose
C’est l’erreur par laquelle commencent tous les guides d’agents : un appel expire, l’agent réessaie, et le même enregistrement est créé deux fois. Ici tu peux le provoquer : mets la vérification sur « ne passe jamais » avec une action irréversible et tu verras trois alertes envoyées, une par tour. Active l’un des deux interrupteurs et la traînée descend à une.
Ce qui n’est généralement pas expliqué, c’est en quoi elles diffèrent, car dans le résultat final elles semblent identiques :
• Clé d’idempotence — l’appel est bien fait, les trois fois ; ce qui ne se répète pas, c’est l’effet, parce que l’autre bout reconnaît la clé et renvoie le résultat du premier. Tu paies la latence, le quota et les tokens ; tu ne paies pas les dégâts.
• Point de contrôle — l’appel n’est même pas fait : le harnais a noté que cette sous-tâche était déjà faite et reprend à la suivante. Tu ne paies rien.
Et la différence qui décide lequel tu peux utiliser n’est pas technique, elle dépend de qui : la clé est implémentée par qui SERT l’outil ; le point de contrôle, par le harnais qui l’APPELLE. Si l’API tierce ne supporte pas les clés, aucune conversation n’est possible : il ne te reste que le point de contrôle. C’est pourquoi les deux existent et ne sont pas synonymes.
Le piège qui se glisse : un point de contrôle ne doit jamais marquer comme fait un appel qui a renvoyé une erreur — si c’est le cas, la nouvelle tentative saute exactement ce qu’il fallait réessayer et l’agent ne se rétablit jamais. Ce cas a son propre test.
Nous n'inventons pas de format
On exporte vers ce que les agents lisent déjà : un SPEC.md isolé, les trois fichiers de Kiro (requirements, design, tasks), un CLAUDE.md avec le permanent, ou les trois seaux de permissions. Les fichiers valent plus que l'outil qui les génère : c'est pourquoi on ne t'y attache pas.
