Blog · Guide · 28 octobre 2026
Liste de traçabilité pour agents d'IA en production : quoi journaliser, quoi signer, quoi montrer à la personne qui relit
Transparence : 100monkeys.ai développe AEGIS, un orchestrateur d'agents open source, et maintient la liste awesome-agent-traceability citée plus bas. Cette liste de contrôle est neutre : chaque point peut être rempli avec des outils ouverts, et aucun n'exige nos produits. Elle a été rédigée par l'un de nos agents d'IA et relue par l'entreprise ; cette version française est une traduction de l'original en anglais.
Quand un agent d'IA agit sur un système réel, quelqu'un demandera plus tard ce qu'il a fait et pourquoi. Cette liste est le travail à faire avant que la question n'arrive : quoi journaliser à chaque exécution, quoi signer pour que le journal soit digne de confiance, et quoi mettre devant la personne qui le relit. Chaque point cite un standard ouvert ou un outil de la liste awesome-agent-traceability.
Le cadre vient de notre article Red levers: traceable, deterministic agents in production (en anglais), qui définit un système d'agents comme sûr en production quand une personne peut voir chaque décision qu'il a prise, pourquoi il l'a prise, et l'arrêter. La journalisation sert le premier point, la raison consignée le deuxième, et l'étape de relecture le troisième.
Partie 1. Quoi journaliser
Étape 1. Donner une identité à chaque exécution
Attribuez un identifiant à chaque exécution dès le départ et propagez-le dans chaque appel de modèle, chaque appel d'outil et chaque effet de bord. Sans lui, un journal est un tas d'événements que personne ne peut regrouper. Utilisez les identifiants de trace et de span des conventions sémantiques OpenTelemetry pour l'IA générative, qui donnent des noms communs aux appels de modèle, aux étapes d'agent et aux invocations d'outils, afin que les traces de frameworks différents se lisent de la même façon. Les conventions pour les spans d'agent couvrent la création et l'invocation d'agents.
Étape 2. Consigner la demande et l'intention, en mots
Journalisez ce qui a été demandé à l'agent, par qui, et la raison donnée. Puis, à chaque acte qui compte, journalisez la phrase de l'agent lui-même expliquant pourquoi. Une raison écrite au moment de l'acte est une preuve ; une raison reconstruite après coup est un récit.
Étape 3. Consigner le modèle et ses réglages
Pour chaque appel de modèle : le fournisseur, le nom et la version du modèle, les paramètres qui changent la sortie (température, nombre maximal de tokens, outils proposés) et le nombre de tokens. Un comportement que vous ne pouvez pas rattacher à une version de modèle ne peut plus être reproduit une fois que le fournisseur l'a mise à jour.
Étape 4. Consigner chaque appel d'outil avec ses entrées et sorties
Nommez l'outil, les arguments, le résultat et l'heure. Masquez les données personnelles avant le stockage, pas après ; Presidio est une option ouverte. Un appel d'outil qui a écrit quelque part doit aussi consigner ce qu'il a changé : le diff, l'identifiant de l'enregistrement, l'identifiant du message.
Étape 5. Consigner chaque décision de politique
Si un moteur de politiques a autorisé ou refusé un appel, journalisez la décision et la règle qui l'a prise. Open Policy Agent tient des journaux de décision précisément pour cela. Un refus est aussi important à garder qu'une autorisation : il montre que la limite a tenu.
Étape 6. Consigner l'identité et la portée
Journalisez quel identifiant ou quel jeton l'exécution a utilisé et ce qu'il pouvait atteindre, pas sa valeur secrète. La question de la personne qui relit est souvent « aurait-il pu faire pire », et la réponse est la portée qu'il détenait.
Étape 7. Rendre l'exécution rejouable
Stockez de quoi relancer le travail : les entrées, l'état à chaque étape et l'ordre des événements. Les moteurs d'exécution durable comme Temporal conservent un historique d'événements par workflow qui permet de le rejouer de façon déterministe.
Partie 2. Quoi signer
Étape 8. Rendre le journal en ajout seul et chaîné
Un enregistrement qu'on peut réécrire après coup ne prouve rien. Écrivez les événements dans un stockage en ajout seul et chaînez chaque entrée à la précédente par un hachage, de sorte qu'une entrée supprimée ou modifiée casse la chaîne. Le groupe de travail SCITT de l'IETF définit des déclarations signées enregistrées dans des services de transparence en ajout seul, une forme toute prête pour cela.
Étape 9. Signer ce que l'agent a produit
Quand une exécution produit un artefact (un build, un rapport, un fichier publié), joignez une déclaration signée de la façon dont il a été fait. Le in-toto Attestation Framework transporte ces déclarations, et SLSA définit des niveaux de provenance de build. Pour les médias, la spécification C2PA joint des manifestes de provenance signés, y compris pour des contenus produits ou modifiés par IA.
Étape 10. Signer l'approbation
Si une personne a approuvé un acte, consignez qui l'a approuvé, quand, et exactement ce qu'elle a vu. Liez l'approbation au contenu : si l'acte change après l'approbation, l'approbation ne compte plus.
Partie 3. Quoi montrer à la personne qui relit
Étape 11. Montrer l'acte, pas un résumé
La personne qui relit doit voir l'e-mail, le diff ou la commande qui va s'exécuter, rendus à partir de la sortie même de l'exécution. Un résumé écrit par le modèle qui demande l'approbation n'est pas une surface de relecture.
Étape 12. Montrer la raison à côté de l'acte
Placez l'intention consignée de l'agent à côté du changement qu'il a fait. « Pourquoi cette ligne est-elle là » doit trouver sa réponse dans la phrase écrite quand la ligne a été intégrée.
Étape 13. Montrer les limites sous lesquelles il a tourné
Montrez la politique et la portée des identifiants à côté de l'exécution. Quelqu'un qui voit que l'agent ne pouvait écrire que sur une branche lit l'exécution autrement que quelqu'un qui doit supposer qu'il pouvait tout atteindre.
Étape 14. Donner un arrêt à la personne qui relit
Chaque écran de relecture a besoin d'un moyen de refuser, et le refus doit tenir. L'article 14 du règlement européen sur l'IA, tel que cité dans Red levers, demande que les personnes qui supervisent des systèmes à haut risque puissent "intervene in the operation of the high-risk AI system or interrupt the system" (intervenir dans le fonctionnement du système d'IA à haut risque ou l'interrompre). Le citer ici concerne la forme du contrôle, pas une revendication de conformité.
Vous vérifier
Prenez une exécution de la semaine dernière et essayez de répondre, à partir des seuls enregistrements : qui a demandé, ce que l'agent a appelé, ce qu'il a changé, sous quelle politique, qui a approuvé, et si l'enregistrement a pu être modifié depuis. Chaque question sans réponse correspond à une étape ci-dessus.
Comment nous l'appliquons
Nous construisons des outils pour certaines parties de cette liste. AEGIS by 100monkeys.ai, in beta, est un orchestrateur auto-hébergé qui exécute des agents dans des environnements isolés, soumis à des politiques, avec un état durable ; How to give an orchestrator an approval step (en anglais) montre son étape d'approbation comme exemple détaillé, et ce guide d'installation le fait tourner sur un serveur. Carbon Forge garde le code et le texte dans un seul registre où le blame montre l'intention écrite au moment de l'intégration.