Les journaux d’audit des agents IA nécessitent 12 champs : ce que LangChain, CrewAI et quatre autres enregistrent.

Une trace ressemble à une preuve, mais ce n’en est pas une

Imaginez un agent qui utilise un outil : un virement de fonds, la suppression d’une ligne dans une base de données, ou l’envoi d’un message. Par la suite, il faut répondre à une question : les actions de l’agent peuvent-elles être prouvées ? La trace est consultée, et on y voit une période définie par un nom, une heure de début, des entrées et des sorties. Cela ressemble à une preuve, mais il s’agit en réalité d’un outil d’analyse qui porte l’apparence d’une preuve.

Afin de mesurer l’écart, six frameworks d’agents open source ainsi que leurs spécifications d’instrumentation ont été clonés à leurs derniers commits du 4 septembre 2026 : OpenAI Agents SDK, LangChain, CrewAI, LlamaIndex, smolagents et OpenInference. Les champs présents dans le registre des appels d’outil de chaque projet ont été extraits et comparés aux douze champs obligatoires du format le plus récent de trace d’audit des agents. Résultat : le framework typique couvre cinq des douze champs nécessaires à un registre d’audit, et aucun des six ne dispose de champ unique permettant de détecter des modifications.

Les frameworks qui couvrent certains champs sont utiles pour le débogage. Les registres d’audit ont une autre fonction, et l’écart entre les deux peut être quantifié.

Cinq constats issus de ce comptage

• Sur les cinq frameworks, la couverture médiane est de 5 sur 12 champs obligatoires : smolagents en compte 1, LlamaIndex 3, OpenAI Agents SDK 5, CrewAI 5 et LangChain 6.
• La chaîne de caractères trust_level n’apparaît dans aucun fichier parmi les six bases de code. Une recherche dans tous les fichiers Python et TypeScript de chaque répertoire ne révèle rien.
• prev_hash, previous_hash et hash_chain ne renvoient également aucun fichier. Aucun framework ne relie un enregistrement à l’autre, ce qui permet d’éditer un registre de traçage ultérieurement sans laisser de trace.
• OpenInference, la spécification d’instrumentation la plus complète de l’écosystème avec 119 attributs de balisage, ne couvre que 8 des 12 champs possibles et ne comprend pas de champ d’empreinte de modification.
• Seul un champ, timestamp, est enregistré par les cinq frameworks. agent_id, session_id et record_phase apparaissent chacun dans un des cinq cas, tandis que agent_version, outcome et trust_level ne figurent dans aucun cas.

Les frameworks disposent d’une instrumentation solide pour le débogage et d’une instrumentation limitée pour fournir des preuves. Ces deux types d’outils se ressemblent suffisamment pour que le remplacement reste invisible tant que personne ne demande de preuve. Les champs absents ne sont pas inhabituels ; ils permettent de déterminer qui a agi, sous quelle autorité, et si le registre a été modifié par la suite, des questions auxquelles une trace de débogage n’a jamais eu à répondre.

Comment le comptage a été effectué

Les corrections ont été apportées pour chaque projet : OpenAI Agents SDK (openai-agents-python) à 89c02c8, LangChain à 0d50cbd, CrewAI à 92eb5f9, LlamaIndex à d2ac544, smolagents à 30bb116, et OpenInference à 479d168. La liste des champs pour chacun provient de la classe qui enregistre une seule appel à outil, c’est-à-dire l’enveloppe du segment ainsi que son chargement spécifique à l’outil, et elle a été extraite des définitions de classe et non des documents. Par la suite, ces champs ont été comparés aux douze champs obligatoires du projet de journal d’audit actuel.

Lorsqu’un champ ne répond qu’en partie à une exigence, il a été noté comme partiel avec une raison indiquée. Par exemple, le champ error de LangChain indique qu’une opération a échoué, mais ne distingue pas entre échec, délai d’attente, refus ou escalade.

La capture montre l’exécution elle-même : six dépôts en tête, chaque champ de appel d’outil étant extrait et évalué par rapport aux douze champs. trust_level et prev_hash donnent zéro partout.

Les douze champs

Le critère de référence est la trace d’audit des agents Internet-Draft, révision 02, publiée par Raza Sharif de CyberSecAI le 3 septembre 2026. Il s’agit d’une proposition individuelle et non d’une norme IETF officiellement adoptée, ce qui en fait une proposition soigneusement argumentée et non une loi établie. Néanmoins, c’est la réponse la plus concrète publiée à ce jour, et ses douze champs obligatoires sont difficiles à contester :

• record_id est un identifiant unique pour l’enregistrement.
• timestamp indique l’heure de l’événement au format RFC 3339.
• agent_id indique l’instance d’agent qui a agi, et agent_version indique la version de son logiciel.
• session_id relie l’action à une session.
• action_type utilise un vocabulaire contrôlé plutôt que du texte libre, et action_detail contient les données spécifiques au type d’action.
• outcome peut être succès, échec, délai d’expiration, refus ou escalade.
• trust_level indique le niveau d’autorisation sous lequel l’agent a opéré, allant de L0 à L4.
• parent_record_id fait référence au enregistrement précédent dans la chaîne, et prev_hash contient son hash SHA-256.
• record_phase indique si l’enregistrement a été créé avant, pendant ou après l’exécution.

Placez cette liste à côté d’un objet span et l’aperçu du problème apparaît. Les huit premiers champs sont ceux que un débogueur pourrait raisonnablement vouloir, tandis que les quatre derniers ne concernent que l’auditeur, et ce sont précisément ces quatre qui manquent.

Comptages par framework

Comptage des champs dans le registre d’appel de l’outil, avec le niveau de couverture par rapport aux douze frameworks suivants :

• CrewAI (ToolUsageFinishedEvent plus BaseEvent) : 25 champs, dont 5 complets, 3 partiels et 4 absents.
• LangChain et LangSmith (RunTree 0.12.1) : 20 champs, dont 6 complets, 1 partiel et 5 absents.
• OpenAI Agents SDK 0.22.0 (SpanImpl plus FunctionSpanData) : 13 champs, dont 5 complets, 2 partiels et 5 absents.
• LlamaIndex (SimpleSpan plus BaseEvent) : 10 champs, dont 3 complets, 1 partiel et 8 absents.
• smolagents 1.26.0 (Timing plus TokenUsage) : 6 champs, dont 1 complet, aucun partiel et 11 absents.
• OpenInference semantic conventions définissent 119 attributs de type span dans des espaces de noms (des constantes distinctes de nom d’attribut avec point à la version 479d168, sans compter 43 autres qui sont des valeurs d’enum), et indiquent 8 champs complets, 1 partiel et 3 absents.

Le nombre brut de champs ne permet pas de prédire le niveau d’auditableté. CrewAI enregistre le plus grand nombre de champs, mais couvre moins de exigences que LangChain, car la majeure partie de ses vingt-cinq champs concerne le contexte de l’équipe, tels que agent_role, from_task, plan_step_number et delegations. Ceux-ci sont utiles, mais ne répondent à aucune question d’audit. La richesse de l’instrumentation et la pertinence des preuves ne présentent quasiment aucune corrélation.

Le graphique le montre clairement : CrewAI dispose de plus de champs que n’importe quel autre framework, mais satisfait moins d’exigences que LangChain, car la plupart de ses éléments supplémentaires concernent le contexte de l’équipe et non des preuves.

Un élément distingue CrewAI : il émet ToolUsageStartedEvent et ToolUsageFinishedEvent en tant que classes distinctes, ce qui lui permet d’avoir un véritable record_phase, c’est-à-dire un enregistrement existant avant l’exécution de l’outil. Cela est plus important qu’il n’y paraît, car un journal généré uniquement a posteriori peut indiquer qu’un événement s’est produit, mais il ne peut pas montrer qu’il avait été approuvé au préalable.

Ce que aucun framework ne enregistre

Quatre des douze champs manquent dans les cinq frameworks, et deux d’entre eux restent absents même en tenant compte des spécifications d’instrumentation.

• trust_level n’apparaît dans aucun fichier des six dépôts. Sans lui, rien ne permet de consigner l’autorité sous laquelle un agent a agi, ce qui empêche de distinguer une action autorisée d’une action interdite.
• prev_hash n’apparaît dans aucun fichier, tout comme previous_hash et hash_chain. Rien ne relie les enregistrements entre eux, et un stockage de traces n’est qu’une base de données ordinaire dont les lignes peuvent être modifiées.
• agent_version fait défaut dans les cinq frameworks. Il n’existe que dans OpenInference en tant que version reflétée de gen_ai.agent.version d’OpenTelemetry ; il peut être défini, mais, d’après cette analyse, les frameworks eux-mêmes ne le définissent pratiquement jamais.
• outcome en tant que catégorie de classification ne reçoit aucune note complète de la part de aucun framework. Tous disposent d’un champ d’erreur, mais aucun ne distingue les cas de refus des cas d’échec, distinction que les auditeurs considèrent comme la plus importante.

Les recherches concernant non_repudiation et pre_execution renvoient également zéro fichier.

Pourquoi ces champs manquent-ils

Ces outils ont été conçus pour une autre question. Un journal d’activité aide un ingénieur à découvrir pourquoi quelque chose s’est exécuté lentement ou de manière incorrecte, et input, output, duration ainsi qu’un pointeur parent suffisent en grande partie à cet effet. Les preuves doivent résister à un adversaire, y compris celui qui contrôle les journaux, or aucun de ces systèmes n’a été conçu en tenant compte de cette menace. Ces lacunes ne sont pas le résultat d’une négligence. Personne ne s’attendait à ce que les journaux d’activité servent également de preuves jusqu’à cette année.

Le contre-argument le plus solide

OpenTelemetry pourrait-il combler ce manque ? Partiellement. OpenInference couvre 8 des 12 cas, le meilleur résultat du lot, et les conventions GenAI d’OpenTelemetry définissent gen_ai.agent.id et gen_ai.agent.version, ce qui, en théorie, résout le problème d’identification. Si leur application est cohérente, l’adoption seule permettrait de résoudre quatre des douze cas sans aucun travail supplémentaire.

Cependant, les deux exigences les plus difficiles restent non résolues. La preuve d’altération ne peut pas être ajoutée à un élément en tant qu’attribut, car elle appartient au stockage et non à l’enregistrement. Une chaîne de hachage n’a de sens que si elle est écrite à un endroit où l’auteur ne peut pas la réécrire. De plus, record_phase nécessite qu’un enregistrement soit généré avant l’exécution de l’action, ce qui relève d’un choix architectural concernant le timing et non d’un champ ajouté ultérieurement. Aucune de ces solutions ne correspond aux conventions sémantiques.

Limites de la mesure

Un nombre n’est utile que si ses limites sont fiables, c’est pourquoi ces réserves sont importantes :

• Il s’agit d’une analyse statique et non d’une capture en temps réel. Seuls les champs définis par les classes ont été comptés. Six agents n’ont pas été exécutés avec leurs charges utiles respectives pour comparaison, et un framework pourrait remplir un champ via un mécanisme d’extension qui n’a pas été suivi.
• metadata, tags et extra constituent des solutions de secours et ont été considérés comme absents. La plupart de ces frameworks acceptent des clés arbitraires, ce qui permet à une équipe déterminée de stocker une chaîne de hachage dans extra. Ce comptage prend en compte les valeurs par défaut et non des plafonds.
• La chose la plus proche d’une signature n’en est pas une. OpenInference définit message_content.signature, mais sa documentation décrit une valeur opaque émise par le fournisseur et stockée telle quelle, à l’instar de thoughtSignature chez Gemini. Elle atteste du contenu du raisonnement du modèle et non de l’intégrité du enregistrement, et seul le fournisseur peut la vérifier. Le fait de la considérer comme absente en tant que preuve d’authenticité a été fait intentionnellement.
• La référence à douze champs correspond à un brouillon d’un seul auteur pour la révision 02, elle n’est donc pas officiellement approuvée, et les gens discuteront à juste titre du trust_level. Si la liste des exigences change, les chiffres de couverture changent également.
• Six projets ne représentent pas l’ensemble de l’écosystème. Pydantic AI, Semantic Kernel, AutoGen ainsi que les plateformes commerciales n’ont pas été pris en compte.
• La simple présence d’un élément ne dit pas grand-chose sur sa qualité. Le timestamp est considéré comme satisfait dans les cinq cas, mais un simple datetime.now() sans zone horaire ou sans référence de point de référence est bien moins fiable qu’un timestamp conforme à RFC 3161.

Cela ne permet pas de déterminer si l’un de ces éléments est pertinent pour un système donné. Un agent qui lit des documents et rédige du texte bénéficie grandement d’un suivi de débogage, tandis que des enregistrements de niveau audit serait excessif. Le problème apparaît uniquement lorsque les actions de l’agent ont des conséquences que quelqu’un pourrait contester par la suite.

Trois modifications selon l’ordre d’impact

1. Écrire un enregistrement avant l’exécution. Cela signifie avant l’appel et non après, en notant l’ID de l’enregistrement, la date et l’heure, l’ID de l’agent et la version, l’action qui va être exécutée ainsi que l’autorisation qui la sous-tend. La séparation entre démarrage et fin fournie par CrewAI sert de modèle, tandis que d’autres systèmes doivent la créer manuellement.
2. Chaîner les enregistrements dans un stockage uniquement en appendice. Le hachage de l’enregistrement précédent avec SHA-256 est presque gratuit. Ce qui compte, c’est l’endroit où il est enregistré, et non le hachage lui-même.
3. Donner un vocabulaire à outcome. Avec cinq valeurs (succès, échec, délai d’attente, refus, escalade), la différence entre une erreur du outil et un refus devient consultable et n’est plus cachée dans une chaîne de caractères.

Aucun nouveau cadre n’est nécessaire, seulement une centaine de lignes supplémentaires par rapport au système existant. Il reflète le phénomène des pannes silencieuses des agents que les tableaux de bord ne détectent pas, où l’absence de signe apparent est interprétée comme un état normal car rien n’a été enregistré.

Réponses rapides

En quoi un suivi d’agent diffère-t-il d’un journal d’audit ? Les traces sont conçues pour les ingénieurs qui souhaitent expliquer un comportement ultérieurement, en partant du principe que leur auteur est honnête. Les journaux d’audit, quant à eux, sont destinés aux parties en désaccord et doivent prouver l’identité, l’autorité et l’intégrité de l’auteur, c’est-à-dire qui a agi, avec quelle autorisation et si l’entrée a été modifiée depuis. En comparaison, les cadres en question comportent entre 6 et 25 champs de suivi chacun, mais ne répondent qu’à une moyenne de 5 exigences d’audit.

Les traces de LangChain peuvent-elles être prêtes pour un audit ? Seulement en partie, et en s’appuyant sur le framework plutôt qu’en le configurant. RunTree de LangSmith fournit 6 des 12 éléments nécessaires directement, dont session_id et parent_run_id. Il reste encore à ajouter l’identité de l’agent et la version utilisée, un ensemble fixe de valeurs de résultat, un niveau de confiance, un enregistrement créé avant l’exécution, ainsi qu’une chaîne de hachages stockée dans un espace de stockage en écriture seule. Des données personnalisées peuvent être incluses dans le champ extra, mais rien ne le remplit automatiquement.

OpenTelemetry résout-il ce problème ? Il couvre la partie liée à l’identité. Les preuves d’altération et l’enregistrement avant exécution restent un défi, car ils dépendent du moment et du lieu où les enregistrements sont créés, et non des attributs contenus dans un span.

Quel framework est le plus adapté aux audits aujourd’hui ? LangChain via LangSmith couvre le plus grand nombre de critères, soit 6 sur 12, tandis que CrewAI offre de manière unique un enregistrement réel avant exécution ainsi qu’un agent_id de première qualité. Aucun des deux n’est prêt pour les audits. Si la traçabilité est indispensable, il convient de créer séparément la couche de preuves et de traiter les traces fournies par le framework comme des données brutes.

Une chaîne de hachages est-elle excessive pour un outil interne ? Généralement oui. Le critère décisif est de déterminer si quelqu’un en dehors de l’équipe pourrait un jour compter sur ces journaux, comme un client, un partenaire commercial, une compagnie d’assurance ou lors d’une analyse d’incident ayant des conséquences réelles. Dans le cas contraire, une trace suffisante est suffisante. Sinon, ajouter cette chaîne maintenant coûte bien moins cher que de devoir la reconstruire plus tard.

Les débats concernant la supervision des agents durent depuis des mois. Le comptage permet de résoudre en partie cette question, car un nom de champ se trouve soit dans la classe, soit non.

Lectures complémentaires

• Lorsque le tableau de bord est vert mais que l’agent se trompe : le suivi de l’état : comment les échecs des agents se cachent dans l’état transmis entre les étapes fonctionnelles, et quels éléments de suivi, de contraintes en temps de exécution, d’enregistrements de routage et d’évaluations sont nécessaires pour les capturer.
• Notes pratiques : codage d’un agent – Comment résoudre les boucles d’agent : guide pas à pas des Notes pratiques : codage d’un agent – Comment résoudre les boucles d’agent, incluant des contrats, des vérifications et des blocs de code prêts à l’emploi pour les équipes qui utilisent ce modèle.

Une plateforme d’expérimentation minimale pour les agents IA : tests A/B et exécutions en ombre : Comment décider si la version B de l’agent doit remplacer A, en utilisant des définitions de pipelines, des affectations locales, des événements d’exposition, des traces, des évaluations en environnement isolé, des exécutions en ombre et des mécanismes de contrôle.

Notes pratiques : L’agent n’a jamais appelé l’outil de remboursement. Deux sur les trois : Guide pas à pas des Notes pratiques : L’agent n’a jamais appelé l’outil de remboursement. Deux sur les trois : contrats, vérifications et emplacements de code prêts à l’emploi pour les équipes qui implémentent ce modèle.

Notes pratiques : Moyens intelligents d’améliorer les réponses des agents IA en production : Guide pas à pas des Notes pratiques : Moyens intelligents d’améliorer les réponses des agents IA en production, incluant des contrats, des vérifications et des blocs de code prêts à l’emploi pour les équipes qui mettent en œuvre ce modèle.

Quand un agent IA échoue, à qui en accuser ? Suivre la chaîne d’échec : Pourquoi l’affirmation « le modèle a halluciné » est insuffisante : une analyse de la chaîne d’échec de l’agent, de l’intention et de la récupération des données jusqu’aux outils, aux tentatives de réessai et aux traçages, ainsi que des éléments à observer.