Une journalisation qui raconte l'histoire : des preuves fiables (sans se noyer dans les données)
- Daniel Bertrand

- Mar 22
- 4 min read
Idée en langage clair : Une bonne journalisation de l'IA ne doit pas être un flot incessant de détails techniques, mais plutôt un récit court et fiable que vous pouvez rejouer : qui a demandé, pourquoi c'était important, quel outil a agi, combien de données ont été transférées et où elles sont allées. Lorsque quelque chose semble anormal, ces faits vous permettent de prendre rapidement une décision et de corriger le problème en toute confiance.

Pourquoi la journalisation « axée sur le récit » est préférable à « plus de journaux »
Si un assistant IA commet une erreur, vous n'avez pas seulement besoin de savoir ce qui s'est passé, vous devez également connaître pourquoi cela s'est produit et sous l'autorité de qui. Mille événements bruts ne vous aideront pas s'ils ne peuvent pas être assemblés pour former un récit clair. Enregistrez les points clés de l'intrigue, pas chaque étape.
Les sept points clés que chaque action IA doit enregistrer
Restez simple et cohérent pour tous les agents :
Qui : le nom et le propriétaire de l'agent (personne réelle/équipe).
Pourquoi : le plan de l'agent en une ou deux phrases (avant qu'il n'agisse).
Quoi : l'outil/la commande qu'il a réellement utilisé (pas seulement la pièce jointe finale).
Où : la source de données qu'il a consultée (CRM, SIRH, lecteur, boîte de réception).
Combien : une mesure rapide (lignes/enregistrements consultés, nombre de fichiers, taille des fichiers).
À qui : destination exacte (dossier nommé, liste de distribution, système).
Sous l'autorité de qui : une autorisation humaine était-elle requise et enregistrée ?
Conseil : capturez une simple différence entre « plan et action ». Si le plan indiquait « examiner le résumé », mais que l'action était « exporter le tableau complet », c'est un signal d'alarme.
Les deux étiquettes spéciales qui accélèrent les enquêtes
Provenance : la demande provenait-elle de l'intérieur ou de l'extérieur (e-mail, web, téléchargement, ticket client) ?
Sensibilité : les données sont-elles publiques, internes ou sensibles ?
Lorsqu'un incident survient, vous verrez immédiatement apparaître des schémas tels que « extérieur → sensible → exportation » et vous pourrez réagir en conséquence.
À quoi ressemble une « bonne » entrée (texte brut, facile à lire)
05/02/2026 14h30 Agent : FinOps
Plan : « Envoyer le résumé mensuel des effectifs à Finance-Metrics. »
Action : hris.export_headcount() Lignes : 1 204
Provenance : interne Données : internes
Destination : Finance-Metrics (liste de diffusion)
Approbation : non requise (conformément à la politique)
Propriétaire : Pat Lee (Finance Ops)
Si un problème survient, vous souhaitez disposer d'une poignée d'entrées comme celle-ci, suffisamment claires pour que les services juridiques, la direction et le service informatique puissent s'accorder sur les faits.

Confidentialité, sécurité et conservation (respectez les règles)
N'enregistrez pas de données sensibles brutes. Enregistrez les comptages et les hachages, pas le contenu lui-même.
Conservez les invites/pièces jointes, mais nettoyez-les. Stockez des copies expurgées afin de pouvoir reproduire ce que l'agent a vu sans exposer d'informations supplémentaires.
Rendez les journaux inviolables. Enchaînez les entrées afin que les suppressions laissent une trace.
Choisissez une conservation à taille humaine. Exemple : 90 jours pour les entrées de routine, 1 an pour les actions ou incidents liés à des données sensibles.
L'accès est limité aux personnes qui ont besoin de connaître. Traitez le journal comme un système sensible, et non comme un tableau d'affichage public.
Des tableaux de bord qui aident réellement (pas besoin de cartes thermiques)
Extérieur → Sensible → Exportation (30 derniers jours)
Premières actions de tout agent (nouvel outil, nouvelle destination)
Mouvements importants après les heures de travail (exportations importantes à 2 heures du matin)
Approbations manquantes alors que la politique les rend « obligatoires »
Destinations principales (afin que vous puissiez supprimer les listes de distribution inutilisées et les dossiers « fourre-tout » risqués)

« Ensemble de preuves d'incident » en un clic
Lorsqu'une alerte se déclenche, vous ne voulez pas avoir à chercher. Vos journaux doivent être exportés en une seule fois :
Chronologie des entrées clés
Graphique indiquant qui a demandé quoi à qui, avec les approbations intermédiaires
Reçus des appels d'outils (quoi/où/combien)
Textes du plan et notes d'approbation
Un bref résumé que la direction peut lire en 2 minutes
(Si vous avez suivi, cela s'inscrit parfaitement dans le cadre du « courtier » et de la carte de transfert que nous avons abordés dans les autres articles.)
Un déploiement en une semaine à la portée de tous
Jours 1-2 : choisissez un format unique (comme dans l'exemple ci-dessus) et appliquez-le à vos trois meilleurs agents.
Jours 3-4 : activez les différences « plan vs action » et ajoutez les deux étiquettes (provenance, sensibilité).
Jour 5 : ajoutez un bouton « Télécharger le dossier de preuves » dans votre workflow de ticketing.
Jours 6-7 – Asseyez-vous avec un cas de quasi-accident. Pouvez-vous raconter clairement l'histoire ? Si ce n'est pas le cas, modifiez le format.
Ce qui incombe à chaque rôle
Cadres : approuvez une politique d'une page stipulant qu'« aucun agent ne peut travailler sans avoir d'abord consigné son histoire ».
Responsables : assurez-vous que les agents de votre équipe consignent les sept points clés et désignent des responsables.
Personnel de première ligne : si le plan d'un agent ne correspond pas à ce qu'il a fait, signalez-le : c'est ainsi que les mesures de protection s'améliorent.
Informatique/Sécurité : appliquez le format, conservez des journaux inviolables et ajoutez des alertes pour « extérieur → sensible → exportation ».
Comment cela s'inscrit dans une orientation plus large
Cette approche « story-first » s'aligne sur la gestion pratique des risques du NIST, les pratiques informées sur les menaces du MITRE et l'état d'esprit « excessive agency »/safe-by-design repris par l'OWASP et la CISA. Vous n'avez pas besoin d'adopter toute la bibliothèque, il suffit de faire en sorte que vos journaux reflètent rapidement la vérité.


