Pourquoi chaque action d'un agent IA doit être auditée

Un journal d'audit d'agent IA est la trace de chaque action qu'un agent a effectuée dans vos outils : quel outil il a appelé, sous l'autorité de qui, quand, si cela a réussi et quel enregistrement il a touché. Il ne stocke pas le contenu de ce qui a été lu ou écrit. Sans lui, personne ne peut répondre à « qui a déplacé cette affaire ? » ou « pourquoi ce ticket est-il fermé ? » quand la réponse est « c'est l'agent », et c'est précisément le moment où la confiance dans l'agent s'effondre.

Cet article traite du côté opérationnel, pas du modèle. Nous dirigeons une entreprise d'une douzaine de personnes avec des outils où un agent peut créer des tickets, déplacer des affaires et publier des mises à jour, et nous avons raté la journalisation une fois avant de la réussir. Voici la conception que nous utilisons aujourd'hui, les normes qui la soutiennent et une liste de contrôle applicable à tout agent que vous connectez.

Ce qu'est réellement une action d'agent

Un humain qui clique sur « fermer le ticket » accomplit une action. Un agent qui ferme un ticket déclenche une chaîne : une personne (ou une planification) a lancé une exécution d'agent, l'exécution a appelé un outil, l'outil a vérifié une portée, la portée était liée à un jeton, le jeton à une personne, et alors seulement le ticket a changé d'état. N'importe lequel de ces maillons peut être celui qui a lâché.

C'est pourquoi « c'est l'agent » n'est pas une réponse. La question à laquelle un journal d'audit doit répondre est : quelle exécution, avec le jeton de qui, a appelé quel outil, sur quel enregistrement, avec quel résultat. S'il manque l'un de ces cinq éléments, le journal est un réconfort, pas un contrôle.

Pourquoi un simple journal applicatif ne suffit pas

La plupart des produits journalisent déjà quelque chose. Les serveurs web enregistrent les requêtes. Les bases de données enregistrent les modifications. Les outils de discussion gardent l'historique. La tentation est de dire que les actions de l'agent sont « quelque part là-dedans ». Trois choses font échouer cette idée en pratique :

L'attribution se perd à la frontière. Une requête d'un agent arrive généralement comme une requête de l'utilisateur d'intégration ou de la personne dont l'agent porte le jeton. Le journal applicatif affiche « Moeid a fermé le ticket 412 ». Il ne montre pas que Moeid déjeunait et qu'une exécution lancée par une planification nocturne l'a fait.
Les lectures sont invisibles. Les journaux applicatifs enregistrent les écritures. Un agent qui a lu la valeur de chaque affaire puis les a résumées dans un message de discussion n'a laissé aucune trace de la lecture, et la fuite est dans le résumé, pas dans la base.
Les journaux ne sont pas relisibles. Un journal qui mélange les actions de l'agent avec dix mille lignes de bruit de requêtes n'est pas quelque chose qu'un fondateur ouvre un vendredi pour vérifier ce que l'agent a fait cette semaine. Si personne ne le lit, ce n'est pas de la supervision.

Les recommandations d'Anthropic sur la construction d'agents sont claires : privilégier la transparence en montrant explicitement les étapes de planification de l'agent, prévoir des pauses pour un retour humain à des points de contrôle et inclure des conditions d'arrêt, comme un nombre maximal d'itérations. Le journal d'audit est ce qui permet à cette transparence de survivre une fois l'exécution terminée et la fenêtre de discussion fermée.

Ce que demandent les normes

Trois documents méritent d'être connus, parce qu'ils définissent ce que « suffisant » veut dire et parce que les services achats de vos clients vous les citeront.

OWASP Top 10 pour les applications agentiques (2026). Publié le 9 décembre 2025 par l'OWASP GenAI Security Project, avec plus de 100 contributeurs. La journalisation insuffisante est l'un des dix risques nommés, aux côtés de l'agentivité excessive, du mésusage des outils et de l'empoisonnement de la mémoire. Les analyses secondaires ne s'accordent pas sur la numérotation des catégories ; citez-le donc par son nom, pas par son identifiant.
Règlement européen sur l'IA, article 12. « Les systèmes d'IA à haut risque permettent techniquement l'enregistrement automatique des événements (journaux) tout au long de la durée de vie du système. » La journalisation doit permettre une traçabilité « adaptée à la destination » : repérer les situations susceptibles de présenter un risque, la surveillance après commercialisation et le suivi du fonctionnement. Il s'applique à partir du 2 décembre 2027 pour les systèmes de l'annexe III et du 2 août 2028 pour ceux de l'annexe I. Le gestionnaire de tickets d'une petite équipe n'est pas un système à haut risque, mais la formulation est une bonne définition de ce à quoi sert un journal.
Anthropic, « Building effective agents » (décembre 2024). Pas une norme, mais le guide de praticiens le plus cité : transparence des étapes de planification, points de contrôle humains, tests en environnement isolé avec des garde-fous. Rédigé avant l'existence de la plupart des outils actuels, et toujours juste.

Le fil commun : le journal doit être automatique (pas un compte rendu manuel après coup), continu (chaque action, pas un échantillon) et adapté à sa finalité (assez pour reconstituer ce qui s'est passé, pas une copie de tout).

Les cinq champs, et la seule chose à laisser dehors

Voici l'enregistrement que nous gardons pour chaque appel d'un agent, et nous soutenons que c'est le minimum pour toute équipe :

Champ	Exemple	Pourquoi il est là
Outil	`crm_move_deal`	Quelle capacité a été utilisée, nommée comme l'agent la voit
Acteur	jeton `atx_…c41`, détenu par une personne nommée	Sous l'autorité de qui l'appel a tourné : le jeton, et la personne derrière
Objet	`deal`, id `d_8f2…`	Ce qui a été touché : le type et l'identifiant, pour qu'un relecteur puisse l'ouvrir
Résultat	`ok`, `refused: scope`, `error: 429`	Réussi, refusé par la couche de permissions, ou échoué
Heure	`2026-10-27T09:14:02Z`	Quand, à la seconde, dans un seul fuseau horaire

Et ce qu'il faut laisser dehors : le contenu. Ni la valeur de l'affaire, ni le corps du ticket, ni le texte du message. Pour deux raisons. D'abord, le journal doit pouvoir être montré à quiconque est autorisé à voir le journal ; s'il contient le contenu, il hérite des permissions de tout ce qu'il journalise, et vous finissez par ne plus pouvoir le montrer à la personne qui en a le plus besoin. Ensuite, le contenu vit déjà dans l'enregistrement. L'identifiant de l'objet y renvoie ; l'historique des versions de l'enregistrement montre ce qui a changé.

Un journal qui contient outil, acteur, objet, résultat et heure répond à toutes les questions de cet article. Un journal qui contient aussi le contenu est une seconde copie de votre base de données avec un contrôle d'accès plus faible.

Les lectures comptent autant que les écritures

Le réflexe est de ne journaliser que les écritures, parce que ce sont elles qui cassent des choses. Les agents changent ce calcul. Un agent avec un accès en lecture au CRM peut se voir demander, dans une fenêtre de discussion et par n'importe qui ayant accès à l'agent, de lister chaque affaire avec sa valeur. Le système de permissions du CRM a été conçu en supposant que lire les valeurs des affaires exige une permission précise ; si le jeton de l'agent l'a et que la personne qui demande ne l'a pas, le journal de cette lecture est la seule preuve de la fuite.

Notre règle : journaliser les lectures avec la même granularité que les écritures, mais garder le champ résultat honnête. Une lecture refusée (« refused: crm.value.view ») est plus utile à un relecteur que mille lectures réussies, parce qu'elle montre la couche de permissions en action et qui tâtait le terrain.

Les limites de débit font partie de l'audit

Un journal vous dit ce qui s'est passé. Une limite empêche la mauvaise chose de se produire dix mille fois avant que quelqu'un lise le journal. Les deux vont ensemble. Une limite par jeton sur les appels, et une plus stricte sur les écritures, signifie qu'un agent en boucle ou un jeton volé fait des dégâts bornés, et le journal montre les 429 comme un pic qu'un humain peut voir.

Dans Atrix, chaque jeton MCP est limité à 120 appels et 30 écritures par minute. C'est bas volontairement : un agent qui aide une personne dans sa journée de travail ne s'en approche jamais, et une boucle l'atteint en moins de dix secondes.

Comment Atrix journalise les actions des agents

Atrix AI expose son espace de travail aux agents via un serveur MCP de 85 outils derrière OAuth 2.1. Chaque appel est audité avec exactement les cinq champs ci-dessus : outil, résultat, type et identifiant de l'objet, et le jeton et la personne derrière. Le contenu n'est jamais écrit dans le journal d'audit. Il en va de même pour les appels à l'API REST, documentée sur /developers.

Trois choix de conception font l'essentiel du travail :

Les portées sont étroites et ne s'élargissent jamais. Un jeton reçoit des portées précises (49 sont attribuables en octobre 2026). Une portée d'écriture implique sa lecture ; rien d'autre n'est implicite. Neuf portées exigent en plus la permission correspondante sur le compte de la personne, de sorte qu'un jeton ne peut jamais atteindre plus que celui qui l'a créé, et les permissions sont vérifiées à chaque appel. Révoquez l'accès d'une personne et chaque jeton qu'elle a créé perd sa portée à l'instant même.
Les écritures qui notifient des personnes sont verrouillées. Publier une mise à jour dans le fil est une portée nommée à part, jamais impliquée par une portée d'écriture générale, parce qu'elle envoie des notifications sur le téléphone de tout le monde. Un agent ne peut pas en hériter par accident.
Le journal appartient à la personne, pas à l'agent. L'entrée d'audit nomme le jeton et la personne qui l'a créé. « C'est l'agent » se résout en un collègue nommé, responsable de ce qu'il a laissé l'agent faire.

Les limites, dites clairement : il s'agit d'un audit des appels passés par MCP et par l'API. Atrix ne scanne pas de code, n'exécute pas d'analyse statique, et l'« audit des exigences » de l'agent est une vérification de couverture par rapport à une base figée, pas un outil de sécurité. Le journal d'audit répond à qui a fait quoi dans l'espace de travail ; il n'évalue pas si le raisonnement de l'agent était fondé.

Mettre en place la supervision dans une petite équipe

Vous n'avez pas besoin d'une équipe sécurité. Il vous faut cinq champs, une habitude hebdomadaire et une règle sur qui a le droit de connecter un agent.

Une personne possède chaque connexion d'agent. Pas d'utilisateurs d'intégration partagés. Si un jeton est créé, il l'est par une personne nommée sur son propre compte, pour que les permissions qu'il porte soient les siennes et que le journal la nomme.
Accordez d'abord la lecture. Connectez l'agent avec des portées de lecture seules pendant une semaine. Lisez le journal. Puis ajoutez la seule portée d'écriture dont l'agent a réellement besoin.
Lisez le journal chaque semaine, filtré sur les écritures et les refus. Vingt minutes un vendredi. Vous cherchez deux choses : des écritures inattendues, et des refus qui montrent que quelqu'un a demandé plus qu'il n'aurait dû.
Gardez les écritures qui notifient sous déclencheur humain. Tout ce qui publie à toute l'équipe, envoie un courriel à un client ou déplace de l'argent doit être une portée qu'un humain accorde explicitement et relit à part.
Fixez la limite de débit sous ce qu'un humain pourrait faire à la main. Si une personne ne pourrait pas faire 30 modifications en une minute, un agent ne devrait pas y être autorisé non plus.
Décidez de la rétention avant d'en avoir besoin. Quatre-vingt-dix jours d'entrées couvrent presque toutes les questions du type « que s'est-il passé le mois dernier ». Plus longtemps convient si le journal ne contient pas de contenu, une raison de plus de ne pas en mettre.

Comparaison des approches de journalisation des agents

Approche	Attribution	Lectures journalisées	Contenu dans le journal	Relisible par un fondateur
Journaux applicatifs/serveur seuls	Perdue à la frontière d'intégration	Non	Souvent (corps des requêtes)	Non, trop bruyant
Transcription de la discussion avec l'agent	L'utilisateur du chat, pas le jeton	Seulement ce que le modèle a dit avoir fait	Oui, tout	Lisible mais peu fiable ; le récit du modèle sur lui-même
Journal d'audit par appel (cinq champs)	Jeton et personne nommée	Oui	Non	Oui, filtré sur écritures et refus
Event sourcing complet de chaque changement	Dépend du chemin d'écriture	Rarement	Oui, par conception	Nécessite de l'outillage

La transcription de discussion mérite une remarque. Il est tentant de considérer le résumé de l'agent lui-même (« j'ai déplacé trois affaires vers Gagné ») comme la trace. C'est une déclaration de la partie examinée. Le journal d'audit est la trace indépendante.

FAQ

Que doit contenir un journal d'audit d'agent IA ?

Au minimum : l'outil appelé, le jeton et la personne à qui il appartient, le type et l'identifiant de l'objet, le résultat (ok, refusé, erreur) et l'heure. Laissez le contenu dehors ; l'identifiant de l'objet renvoie à l'enregistrement, et l'historique de l'enregistrement conserve le changement.

Faut-il journaliser les lectures de l'agent, ou seulement les écritures ?

Les deux. Un agent peut faire fuir des données par une lecture qu'il résume ensuite dans la discussion, et la lecture est la seule preuve. Journalisez les lectures avec la même granularité que les écritures et surveillez particulièrement les lectures refusées.

Un journal d'audit d'agent IA est-il exigé par la loi ?

Pour la plupart des petites équipes, non. L'article 12 du règlement européen sur l'IA exige l'enregistrement automatique des événements pour les systèmes d'IA à haut risque, à partir du 2 décembre 2027 pour les systèmes de l'annexe III. Un agent sur un gestionnaire de tickets ou un CRM n'est pas à haut risque. L'OWASP Top 10 pour les applications agentiques (2026) liste la journalisation insuffisante comme risque nommé : c'est une recommandation, pas une loi, mais c'est ce que les questionnaires d'achat citeront.

En quoi un journal d'audit diffère-t-il de l'historique de discussion de l'agent ?

L'historique de discussion est le récit de l'agent sur ce qu'il a fait, écrit par l'agent. Le journal d'audit est écrit par le système sur lequel l'agent a agi, au moment de l'action, en nommant le jeton et la personne. Quand les deux divergent, c'est le journal d'audit qui a raison.

Atrix journalise-t-il le contenu de ce qu'un agent lit ou écrit ?

Non. Atrix enregistre l'outil, le résultat, le type et l'identifiant de l'objet, et le jeton et la personne derrière chaque appel MCP et API. Le contenu n'est jamais écrit dans le journal d'audit. Les modifications d'un enregistrement sont visibles dans son propre historique des versions.

Combien de temps conserver les entrées d'audit des agents ?

Quatre-vingt-dix jours répondent à presque toutes les questions pratiques. Comme une entrée bien conçue ne contient pas de contenu, la garder plus longtemps présente peu de risque ; ce qui compte davantage, c'est que quelqu'un la lise chaque semaine.

Prochaine étape

Si vous connectez un agent à votre travail pour la première fois, commencez par des portées de lecture, un seul propriétaire nommé et un regard hebdomadaire sur le journal. L'agent Atrix AI fonctionne dans ces mêmes limites, et la documentation MCP liste chaque portée et ce qu'elle implique, pour décider quoi accorder avant de l'accorder.

Sources

Consultées en octobre 2026 : OWASP Top 10 for Agentic Applications for 2026, Règlement européen sur l'IA, article 12 : Enregistrement, Anthropic, Building effective agents.

Pourquoi chaque action d'un agent IA a besoin d'un journal d'audit, et ce qu'il doit contenir