Un agent IA qui a pris une mauvaise décision ne laisse aucune trace utile si personne n'a prévu de l'enregistrer. Le journal de trajectoire est le seul document qui permet, après coup, de reconstituer ce que l'agent a lu, ce qu'il a décidé, quel système il a touché et ce qui en est sorti. Sans lui, vous ne pouvez ni expliquer un comportement à un client, ni corriger la cause, ni prouver quoi que ce soit à un auditeur.
Chaque action de l'agent est correcte, c'est l'enchaînement qui est faux
Prenons un cas courant. Un distributeur de fournitures industrielles a mis en place un agent qui traite les demandes de devis reçues par courriel. L'agent lit le message, cherche les références dans le catalogue, vérifie le stock dans l'ERP, calcule une remise selon la grille client et envoie une proposition. Chaque étape prise isolément est correcte. Un jour, un client reçoit un devis avec une remise de grand compte alors qu'il commande pour la première fois.
Personne dans l'équipe ne sait dire ce qui s'est passé. Le prestataire qui a construit l'agent répond qu'il n'a rien changé. Le DSI regarde les journaux de l'ERP et voit une lecture de fiche client, rien d'anormal. La messagerie montre un envoi, rien d'anormal non plus. C'est l'enchaînement qui était faux, et cet enchaînement n'a été enregistré nulle part.
Un agent IA d'entreprise n'exécute pas un script prévu à l'avance. Il choisit, à chaque étape, l'action suivante en fonction de ce qu'il vient de lire. Si vous n'enregistrez pas ce chemin, vous n'avez qu'un résultat final et aucun moyen de remonter jusqu'à la décision qui l'a produit.
Ce qu'est une trajectoire : décision, outil appelé, système atteint, résultat
On appelle trajectoire la suite ordonnée de tout ce qui s'est passé entre le déclenchement de l'agent et sa fin, qu'elle soit réussie, interrompue ou en erreur. Une trajectoire se décompose en pas, et chaque pas contient quatre éléments.
La décision, d'abord. C'est le raisonnement intermédiaire du modèle, ou au moins le résumé de ce qu'il a compris et de ce qu'il compte faire. Dans l'exemple du devis, on y lirait quelque chose comme « le client mentionne un volume annuel élevé, j'applique la grille grand compte ». C'est précisément la phrase qui manque quand on cherche à comprendre l'erreur.
L'outil appelé, ensuite. Un agent agit à travers des fonctions qu'on lui a exposées, par exemple « rechercher un article », « lire la fiche client », « envoyer un courriel ». Le journal note quelle fonction a été appelée, avec quels paramètres exacts. Pas une paraphrase, les valeurs réelles.
Le système atteint, en troisième. Derrière la fonction, il y a un ERP, un CRM, une base de données, une API tierce. On enregistre lequel, avec quel compte technique, et quelle réponse il a renvoyée. Cet élément est celui qui permet de faire le lien avec les journaux des systèmes eux-mêmes, ceux que le DSI a déjà consultés.
Le résultat, enfin. Ce que l'agent a fait de la réponse. A-t-il continué, s'est-il arrêté, a-t-il demandé une validation, a-t-il produit une sortie visible par un humain ? Le dernier pas porte la responsabilité, mais c'est rarement là que se trouve la cause.
Ce que le journal doit contenir pour être relu par un humain
Un journal technique brut, celui que produisent par défaut les bibliothèques d'agents, n'est pas relisible. Il mélange identifiants de session, messages système et réponses de modèle sur des milliers de lignes. Pour qu'un responsable métier ou un DSI puisse s'en servir, il faut structurer.
Chaque trajectoire porte un identifiant unique, une date et une heure de début et de fin, la version du modèle utilisé, la version des instructions données à l'agent, et l'identité de ce qui l'a déclenchée (un courriel entrant, une tâche planifiée, une action d'un utilisateur). Sans la version des instructions, vous ne saurez jamais si l'erreur vient d'une modification récente ou d'un défaut présent depuis le départ.
Chaque pas porte son rang dans la trajectoire, la décision en clair, l'outil et ses paramètres, la réponse reçue, la durée et le coût en jetons. Le coût sert d'alerte : une trajectoire qui consomme trois fois plus que la moyenne signale souvent un agent qui a tourné en boucle, et c'est souvent visible avant que le résultat ne soit faux.
Enfin, le journal doit être consultable autrement qu'en ouvrant un fichier texte. Une interface minimale qui liste les trajectoires, permet de filtrer par date, par déclencheur, par résultat, et d'ouvrir une trajectoire pas à pas suffit. Dans une PME de services qui exploite un agent de qualification de demandes entrantes, ce sont les commerciaux, avec cette vue, qui ont détecté les premières dérives, pas les ingénieurs.
Relire une trajectoire après une plainte client
Revenons au devis avec la remise indue. Avec un journal correctement tenu, la relecture prend quelques minutes. On cherche la trajectoire par l'adresse du client ou par la date d'envoi. On ouvre la suite des pas. Au troisième pas, l'agent a lu la fiche client et obtenu un champ « segment » vide, parce que le client était nouveau. Au quatrième, sa décision indique qu'il a interprété le courriel, où le client parlait de ses « besoins annuels importants », comme un signal de grand compte. Au cinquième, il a appelé la fonction de calcul de remise avec le paramètre « grand compte ».
La cause est identifiée. Ce n'est ni l'ERP, ni la messagerie, ni un changement du prestataire. C'est une règle implicite que l'agent a déduite lui-même parce que les instructions ne disaient pas quoi faire d'un segment vide. La correction est claire. On ajoute une règle explicite, on force la remise « standard » quand le segment n'est pas renseigné, et on ajoute un test qui rejoue cette trajectoire exacte pour vérifier que le nouveau comportement tient.
Le journal transforme une discussion où chacun se défend en une lecture factuelle. C'est pour cette raison que la journalisation des trajectoires d'agents fait partie de ce que nous mettons en place dès qu'un agent passe en production, avec les autres garde-fous décrits dans notre liste de contrôle pour sécuriser un agent IA en production, avant même de parler de supervision.
Journal et validation humaine sur les actions sensibles
Le journal ne sert pas qu'à regarder en arrière. Il structure aussi les points où un humain doit intervenir avant que l'action ne parte. Certaines fonctions exposées à l'agent sont sans conséquence si elles échouent, lire une fiche, chercher une référence. D'autres engagent l'entreprise, envoyer un devis, modifier une commande, créer un virement, répondre à un client au nom de la société.
Pour cette seconde catégorie, la bonne pratique consiste à faire écrire l'action dans le journal avec un statut « en attente de validation », puis à la présenter à une personne désignée. La validation, ou le refus, s'enregistre à son tour dans la trajectoire, avec l'identité du valideur et l'heure. Vous obtenez ainsi un journal qui ne montre pas seulement ce que l'agent a voulu faire, mais aussi qui a laissé passer quoi.
Une ETI de la logistique a appliqué cette règle à son agent de traitement des litiges transporteurs. L'agent propose une réponse et un avoir, un gestionnaire valide en un clic. Après quelques semaines, les refus se concentraient sur un type de litige précis. Le journal a permis de rejouer ces cas et de corriger la lacune dans les instructions. Sans journal, l'entreprise aurait conclu que « l'agent ne marche pas bien sur les litiges ».
Ce que l'AI Act et vos clients attendent en matière de traçabilité
Le règlement européen sur l'intelligence artificielle impose, pour les systèmes classés à haut risque, une journalisation automatique des événements pendant toute la durée de vie du système, une conservation de ces journaux et la possibilité pour un humain de surveiller le fonctionnement. La plupart des agents déployés dans une PME ou une ETI ne relèvent pas de la catégorie « haut risque ». Un agent de tri de demandes commerciales n'y entre pas. Un agent qui participe à une décision de recrutement, d'octroi de crédit ou d'accès à un service essentiel, oui.
Raisonner uniquement sur cette classification serait pourtant une erreur. Les frontières bougent avec les usages, un agent conçu pour préqualifier des dossiers peut, au fil des évolutions, se retrouver à en écarter. Et surtout, vos clients n'attendent pas la réglementation pour vous demander des comptes. Un fournisseur qui déploie un agent au contact des données de son donneur d'ordre se voit demander, dans les questionnaires fournisseurs et les audits de sécurité, comment il trace les traitements automatisés, combien de temps il garde ces traces et qui peut y accéder. Un journal de trajectoire bien tenu répond en une page. Son absence transforme chaque audit en négociation.
Un journal conforme réunit donc trois propriétés. Il est automatique, personne n'a à l'activer. Il est protégé en écriture : une trajectoire enregistrée ne peut plus être modifiée, et toute tentative laisse une trace. Et il est lisible par un non-technicien, avec la décision en clair et pas seulement le code d'appel.
Le journal contient des données, il faut donc le protéger
Une trajectoire d'agent contient, par construction, tout ce que l'agent a lu. Si l'agent traite des courriels clients, le journal contient ces courriels. S'il consulte des fiches salariés, il contient ces fiches. Le journal devient lui-même un traitement de données personnelles, avec ses propres obligations.
Trois décisions sont à prendre avant la mise en production. La durée de conservation, d'abord, fixée selon l'usage, le délai de réclamation raisonnable et les exigences contractuelles de vos clients, et non par défaut à « pour toujours ». Le filtrage, ensuite. Numéros de compte, données de santé, identifiants d'accès que l'agent aurait pu lire en passant n'ont pas à figurer en clair. On les masque à l'écriture, pas à la lecture. L'accès, enfin. Le journal est un outil d'équipe métier, mais il ne doit pas devenir un raccourci pour consulter des données auxquelles on n'a pas accès par ailleurs.
La question de la gestion des données par les agents dépasse la seule journalisation. Nous l'avons traitée plus largement dans notre article sur les agents IA et la gestion des données, qui passe en revue les usages et les obstacles à anticiper.
Comment le journal alimente le rapport d'activité et les tests
Le journal sert aussi de source à deux choses que tout dirigeant finit par demander.
Le rapport d'activité, en premier lieu. Combien de trajectoires par jour, quelle part terminée sans intervention, quelle part validée ou refusée, combien en erreur, quelle durée et quel coût moyens. Ces chiffres se calculent directement depuis le journal. Ils donnent au dirigeant une vue mensuelle de ce que l'agent fait réellement pour l'entreprise, et au DSI les signaux avant-coureurs d'une dérive, par exemple une hausse du coût moyen par trajectoire après une mise à jour du modèle.
Les tests, en second lieu. Chaque trajectoire qui a posé problème, une fois corrigée, devient un cas de test. On la rejoue avec les nouvelles instructions et on vérifie que l'agent prend la bonne décision. Au fil des mois, ces cas s'accumulent et forment une base de non-régression qui protège contre les changements futurs, y compris ceux qu'impose l'éditeur du modèle quand il déprécie une version. Un agent connecté à un ERP, comme nous l'avons décrit dans notre guide pour connecter un ERP à un agent IA par API, est particulièrement exposé à ce risque, parce qu'une modification de l'API ou du modèle change silencieusement le comportement.
Le journal de trajectoire s'inscrit ainsi dans un ensemble plus large, celui du maintien en condition opérationnelle des systèmes IA. Nous en décrivons les autres composantes, supervision, détection des anomalies, remise à niveau planifiée, dans notre guide sur la supervision des agents IA en entreprise et sur notre page de maintenance applicative supervisée. Pour situer le journal dans l'ensemble d'un projet, notre article de référence sur l'agent IA en entreprise reprend la définition, les usages et le déploiement.
Si vous avez un agent en production aujourd'hui, la question à poser à votre équipe ou à votre prestataire est simple. Prenez une trajectoire de la semaine dernière, au hasard, et demandez à la voir pas à pas, avec les décisions en clair. Si la réponse prend plus d'une heure, ou si elle se résume à un fichier de plusieurs milliers de lignes, vous n'avez pas encore de journalisation. Vous avez des traces.
