Un agent IA peut enchaîner plusieurs étapes : lire une demande, consulter une source, préparer un contenu et déclencher une action dans un autre outil. Cette autonomie devient difficile à contrôler si le système ne conserve que le résultat final. Lorsqu’une erreur apparaît, il faut pouvoir comprendre ce qui a été demandé, ce que l’agent a utilisé et où le processus s’est écarté de la règle. Un journal d’exécution répond à ce besoin. Il ne garantit pas qu’un agent sera fiable, mais il rend son fonctionnement observable. Voici une méthode accessible pour créer cette trace, même avec un simple tableau.

1. Définissez ce que vous voulez pouvoir expliquer

Commencez par une question concrète : si cette automatisation produit une erreur demain, quelles informations permettront de la comprendre ? Pour une file de publications, vous voudrez retrouver l’identifiant du contenu, l’heure de traitement, l’étape exécutée, la source utilisée et le statut final. Pour un agent qui classe des demandes, vous aurez peut-être aussi besoin de la catégorie proposée et du passage qui a motivé cette décision.

Le cadre de gestion des risques liés à l’IA du NIST recommande d’intégrer les considérations de fiabilité dans la conception, l’usage et l’évaluation des systèmes. Dans un petit projet, le journal est une application pratique de cette logique : il crée une preuve de fonctionnement à examiner, sans transformer automatiquement votre dispositif en système certifié.

2. Donnez un identifiant unique à chaque exécution

Créez un identifiant avant le démarrage, puis transmettez-le à toutes les étapes. Une forme simple suffit : date, nom du flux et numéro court, par exemple « 20260924-LINKEDIN-017 ». Cet identifiant relie la demande initiale, les actions intermédiaires et le résultat. Il aide aussi à empêcher qu’une même ligne soit traitée deux fois lorsque votre outil d’automatisation redémarre.

N’utilisez pas le nom complet d’un client, son numéro ou son adresse comme identifiant. Préférez une référence interne qui ne révèle pas directement une donnée personnelle. Le journal sert à comprendre l’exécution ; il ne doit pas devenir une copie permanente de toutes les informations sensibles traversant le système.

3. Utilisez des colonnes stables et peu nombreuses

OpenTelemetry décrit un journal comme l’enregistrement horodaté d’un événement et souligne l’intérêt d’un schéma stable pour faciliter l’analyse. Vous pouvez reprendre ce principe sans infrastructure complexe. Dans Google Sheets, préparez par exemple les colonnes suivantes : identifiant, horodatage, nom du flux, étape, action demandée, source, résultat, statut et message d’erreur.

Gardez les valeurs prévisibles. Pour le statut, choisissez une courte liste : « RÉUSSI », « À VÉRIFIER », « BLOQUÉ » et « ANNULÉ ». Pour l’étape : « lecture », « préparation », « validation », « publication » et « retour ». Un texte libre reste utile pour expliquer une erreur, mais les champs réguliers permettent de filtrer rapidement les incidents et de compter les échecs récurrents.

4. Séparez les événements du contenu sensible

Évitez d’enregistrer automatiquement chaque prompt complet, chaque document et chaque réponse. Une trace utile peut indiquer qu’un fichier a été consulté, avec son identifiant et sa version, sans recopier son contenu. Si un extrait est indispensable pour comprendre une erreur, limitez-le au passage nécessaire et appliquez les règles de conservation prévues par votre organisation.

Cette prudence compte particulièrement pour les agents capables d’utiliser des outils. Le guide de l’OWASP sur les risques des systèmes agentiques propose une approche fondée sur les menaces et les mesures de réduction du risque. Le journal complète les autorisations et les validations ; il ne les remplace pas. Un agent ne doit pas obtenir davantage d’accès simplement parce que ses actions sont enregistrées.

5. Arrêtez le flux lorsqu’une action demande une décision

Définissez les moments où l’agent doit s’arrêter et attendre une personne : publication publique, envoi d’un message, suppression d’un fichier, paiement ou utilisation d’une donnée sensible. Le journal doit alors afficher le statut « À VÉRIFIER », la proposition préparée et le nom de l’étape suivante. La validation humaine devient un événement distinct, avec son propre horodatage.

Prévoyez aussi le comportement en cas d’échec. Une nouvelle tentative automatique peut être acceptable pour une panne temporaire de lecture, mais elle est dangereuse pour une action qui pourrait être exécutée deux fois. Fixez un nombre maximal de tentatives, puis passez à « BLOQUÉ ». La personne chargée du contrôle doit comprendre la situation sans avoir à reconstruire toute la conversation de l’agent.

6. Relisez le journal comme un outil d’amélioration

Une fois par semaine, filtrez les lignes « À VÉRIFIER » et « BLOQUÉ ». Regroupez les incidents par étape : mauvaise source, format non respecté, doublon, validation absente ou erreur d’accès. Corrigez d’abord la règle qui produit plusieurs incidents similaires. Une meilleure consigne peut aider, mais le problème peut aussi venir d’une permission trop large, d’une donnée mal structurée ou d’un scénario qui ne vérifie pas le résultat précédent.

Conclusion concrète : choisissez aujourd’hui une seule automatisation et ajoutez-lui neuf champs stables, un identifiant unique et trois points d’arrêt clairement nommés. Testez-la sur dix cas sans données sensibles, puis vérifiez si chaque résultat peut être expliqué à partir du journal. Si une action reste incompréhensible, ajoutez la trace manquante avant d’augmenter l’autonomie. Le bon objectif n’est pas d’enregistrer tout ce qui passe, mais de conserver assez d’informations pour détecter, comprendre et corriger.