Intro : Une bonne journalisation permet de retrouver une décision automatisée, son contexte et l’intervention humaine, sans exposer toutes les données.
Quand un workflow déplace un fichier, classe une demande ou rédige une réponse, une question finit par arriver : pourquoi cette action a-t-elle été exécutée ? Sans journal utile, l’équipe cherche dans les boîtes mail, les historiques d’outils et les souvenirs de chacun. Le diagnostic devient lent, et la correction risque d’être appliquée au mauvais endroit.
La journalisation ne consiste pas à enregistrer tout le contenu de chaque échange. Elle doit donner assez de contexte pour reconstruire le traitement, tout en limitant les informations sensibles. Une ligne de journal peut référencer une demande, un workflow, une version de règle, une décision et un résultat, sans recopier un contrat ou une conversation complète.
Définir un identifiant de traitement
Chaque exécution doit avoir un identifiant stable. Il accompagne le document ou la demande pendant son passage dans les différentes étapes. Si une opération est relancée, l’équipe doit pouvoir distinguer la première tentative de la reprise.
Enregistrez aussi l’identifiant du déclencheur lorsque vous en avez un : message, document, ticket ou événement d’API. Un même fichier peut être envoyé deux fois. La relation entre identifiant de source et identifiant d’exécution aide à repérer les doublons et à reconstituer la chronologie.
Les événements importants comprennent le début, la fin, les changements d’état, les appels à un service externe, les validations humaines et les erreurs. Pour chaque événement, ajoutez une date au format uniforme, le nom de l’étape et un statut. Un message d’erreur lisible vaut mieux qu’un simple code générique, à condition de ne pas contenir un secret.
Versionner les règles qui prennent la décision
Une exécution n’utilise pas toujours la règle actuelle. Le prompt, le modèle, le schéma de données ou le filtre peut avoir changé entre deux traitements. Le journal doit donc conserver une référence de version pour les éléments qui influencent le résultat.
Cette référence peut pointer vers un identifiant de déploiement, un numéro de configuration ou un commit. Évitez de copier une configuration complète dans chaque événement si elle contient des clés ou des données sensibles. Le lien doit permettre à une personne autorisée de retrouver la configuration réellement utilisée.
Quand une sortie est corrigée par un collaborateur, enregistrez la valeur initiale, la valeur finale si la politique de conservation le permet, le motif et l’identité de l’intervenant. Pour des données personnelles, vous pouvez stocker un résumé ou un identifiant de champ et garder le document détaillé dans un emplacement contrôlé.
Distinguer les catégories d’erreurs
Toutes les erreurs ne demandent pas la même réaction. Un service indisponible peut justifier une reprise automatique. Un champ obligatoire absent doit souvent ouvrir une revue humaine. Un refus d’accès peut révéler un problème de droits et ne doit pas être masqué par des tentatives répétées.
Utilisez des catégories simples, par exemple erreur temporaire, donnée invalide, accès refusé, doublon et décision à vérifier. Ajoutez une action attendue. Cette information aide l’équipe à traiter la file d’exceptions et montre les étapes où le processus perd du temps.
Les reprises doivent rester contrôlées. Une limite de tentatives et un délai progressif réduisent les appels répétés à un service en panne. Après la limite, l’exécution passe en attente avec une alerte exploitable. Le message doit préciser l’identifiant de traitement, l’étape, la dernière erreur et la prochaine action prévue.
Contrôler ce qui peut être consulté
Un journal centralisé devient vite une source de données sensibles. Les droits doivent séparer la lecture des métriques, des erreurs et des documents originaux. Un support technique peut avoir besoin du statut et du code d’erreur sans accéder au contenu du contrat traité.
Masquez les secrets, les jetons, les mots de passe et les données qui ne servent pas au diagnostic. Ne placez pas une requête complète dans un message d’erreur si elle contient des informations clients. Prévoyez une méthode d’accès ponctuel au document source, avec les mêmes contrôles que dans l’application.
Définissez une durée de conservation par type d’événement. Les métriques agrégées peuvent rester plus longtemps que les contenus détaillés. Documentez la suppression automatique et testez-la. Un journal conservé indéfiniment augmente le coût et la surface d’exposition sans améliorer chaque investigation.
Utiliser les journaux pour améliorer le workflow
Une fois les événements structurés, regroupez-les par workflow, étape et catégorie d’erreur. Cherchez les cas qui reviennent, comme les documents illisibles d’un même canal ou les demandes classées dans la mauvaise file. Chaque tendance doit conduire à une modification vérifiable : nouvelle règle, champ obligatoire, étape de validation ou changement de formation.
Gardez un petit échantillon de décisions pour une revue périodique. Comparez la sortie automatisée avec la décision humaine et notez les divergences. Les évaluations de workflows agentiques recommandent d’examiner les trajectoires et les résultats selon les critères du cas, plutôt que de regarder seulement si l’exécution a terminé comme l’explique la documentation d’Anthropic sur l’évaluation des agents.
Une journalisation utile répond rapidement à trois questions : quelle demande a déclenché l’action, quelle version a décidé et qui a validé le résultat. Avec ces éléments, l’équipe peut corriger le workflow sans perdre la trace du traitement déjà effectué.