Logs d’agents IA : le journal minimal pour enquêter après une erreur

Un agent IA qui réserve, supprime, modifie ou transmet une information ne doit jamais être une boîte noire. Lorsqu’une erreur survient, la question n’est pas seulement « quel prompt a été envoyé ? ». Il faut pouvoir reconstituer une exécution : ce que l’agent était autorisé à faire, ce qu’il a consulté, ce qu’il a décidé, les outils qu’il a appelés, les changements effectivement produits et les validations humaines intervenues.

Le piège est symétrique : tout journaliser peut créer une seconde fuite de données, parfois plus facile à exploiter que le système initial. Le bon objectif n’est donc pas une télémétrie exhaustive. C’est un journal suffisamment précis pour mener une enquête fiable, avec des données minimisées, une rétention courte et des accès strictement contrôlés.

Le journal minimal : huit événements pour reconstituer une exécution

Le niveau pertinent est celui de la session d’exécution : une tâche soumise à l’agent, y compris ses sous-étapes et ses éventuelles reprises. Attribue-lui un session_id non devinable, puis un trace_id propagé dans chaque appel. Cette corrélation évite de devoir assembler manuellement des lignes éparses après incident.

Pour chaque événement, ajoute au minimum un horodatage UTC, un identifiant d’événement, le type d’événement et son statut. Le schéma viable tient ensuite en huit familles :

• Contexte de session : session_id, acteur à l’origine de la tâche (pseudonymisé si possible), environnement, tenant ou projet, niveau de risque et objectif déclaré.
• Version des instructions : identifiant et empreinte cryptographique de la politique système, du prompt applicatif, du modèle et de la configuration. Conserve la version, pas forcément le texte complet.
• Outils disponibles : liste des outils exposés, versions, périmètres d’autorisation et scopes d’accès. C’est indispensable pour déterminer si l’agent pouvait matériellement accomplir l’action litigieuse.
• Lecture ou récupération : source consultée, identifiant de document ou de ressource, politique d’accès appliquée, nombre d’éléments retournés et empreinte du contenu. Évite de journaliser le contenu brut par défaut.
• Appel d’outil : nom de l’outil, opération, paramètres normalisés ou masqués, cible, identifiant de requête aval et horodatages de début et de fin.
• Résultat : code de succès ou d’échec, catégorie d’erreur, identifiant de l’objet créé ou modifié, compteur d’objets touchés et empreinte de la réponse utile.
• Décision de l’agent : action proposée, motif court et structuré, niveau de confiance si disponible, règle de politique déclenchée et éventuelle alternative rejetée. Ne confonds pas ce motif avec une « explication » fiable du raisonnement interne du modèle.
• Validation humaine et erreur : identité ou rôle du valideur, décision approuvée/refusée, justification, puis exception technique, refus de politique, timeout ou échec métier.

Un format événementiel JSON facilite l’ingestion dans un SIEM ou un entrepôt d’observabilité. Par exemple :

{
  "event_type": "tool_call",
  "session_id": "ses_8f…",
  "trace_id": "tr_31…",
  "instruction_version": "sha256:…",
  "tool": "crm.update_contact",
  "action": "update",
  "target_ref": "contact:4b…",
  "params_digest": "sha256:…",
  "approval_id": "apr_12…",
  "outcome": "success",
  "timestamp": "2026-08-06T10:15:21Z"
}

Journaliser des preuves, pas des secrets

Les logs d’agents concentrent vite des prompts, réponses de modèles, tickets clients, données CRM et jetons techniques. Applique donc la minimisation dès la conception. En pratique, préfère un identifiant de ressource à son contenu, une empreinte à une charge utile et une catégorie d’erreur à une stack trace contenant des secrets.

Quelques règles évitent les erreurs les plus coûteuses :

• Masque avant écriture : secrets, mots de passe, clés API, cookies, jetons OAuth, coordonnées bancaires et identifiants personnels doivent être retirés ou remplacés côté collecteur, avant persistance.
• Sépare les niveaux de preuve : le journal opérationnel contient des métadonnées. Une pièce sensible exceptionnelle — export, réponse d’API, document — va dans un coffre chiffré, référencée par identifiant et accessible sur autorisation.
• Utilise des empreintes avec prudence : un hash permet de prouver qu’un contenu correspond à une version observée, mais un hash non salé d’une donnée à faible entropie peut être deviné. Pour des valeurs sensibles, utilise un HMAC géré avec une clé dédiée.
• Interdis les champs libres non filtrés : prompts complets, sorties intégrales et descriptions d’erreur brutes sont des vecteurs classiques de fuite. Prévois des champs structurés et une liste blanche.
• Journalise les refus : un appel bloqué par une règle, un scope insuffisant ou une validation absente est aussi instructif qu’un succès.

Les fonctions de sécurité et de gouvernance documentées par Microsoft pour Copilot Studio illustrent cette direction : contrôles d’environnement, gestion des données, administration et mécanismes de gouvernance doivent accompagner le déploiement, pas arriver après le premier incident. Le guide de sécurité et de gouvernance de Copilot Studio doit toutefois être lu comme une documentation de plateforme, et non comme un substitut à ton propre modèle de journalisation.

Rétention et accès : les logs sont eux-mêmes un actif sensible

Définis une durée de conservation par classe de journal. Un point de départ raisonnable consiste à garder les événements techniques de routine pendant une période courte, par exemple 30 à 90 jours, puis à conserver plus longtemps les traces liées aux actions à fort impact, aux accès privilégiés et aux incidents ouverts. Ce ne sont pas des durées universelles : obligations contractuelles, secteur, pays et politique interne peuvent imposer autre chose.

La rétention doit être automatisée et vérifiable : suppression ou anonymisation à échéance, sauvegardes incluses, et registre des exceptions. N’accorde pas un accès large aux équipes produit « parce que cela aide à déboguer ». Mets en place un contrôle d’accès par rôle, le principe du moindre privilège, une journalisation des consultations de journaux sensibles et une revue régulière des droits.

Pour les investigations sensibles, sépare l’accès de lecture de la capacité à modifier ou supprimer les preuves. Un stockage append-only, une chaîne d’intégrité ou des signatures d’événements renforcent la valeur probante du journal. Ils ne rendent pas le système infaillible, mais révèlent plus facilement une altération.

Transformer les traces en procédure de réponse à incident

Un journal n’a de valeur que si une équipe sait s’en servir sous pression. Relie chaque trace_id à un runbook d’incident et prévois quatre étapes simples.

1. Trier et contenir : qualifie l’impact — lecture indue, modification, exfiltration possible, erreur de paiement — puis désactive l’outil, le connecteur ou le compte de service concerné. Évite de supprimer les journaux pendant cette phase.
2. Préserver : exporte la trace complète, les versions d’instructions, la configuration des outils et les validations. Horodate l’export et calcule une empreinte afin de préserver son intégrité.
3. Reconstruire : suis la séquence lecture → décision → appel → résultat. Compare la version des instructions et les scopes autorisés avec ceux attendus. Cherche les sessions partageant le même outil, la même version ou la même erreur.
4. Corriger et apprendre : révoque les secrets si nécessaire, réduit les permissions, ajoute une validation humaine sur l’action concernée et crée un test de non-régression. Enfin, vérifie que le nouveau contrôle produit lui-même un événement exploitable.

Le kit de gouvernance présenté par Microsoft pour Copilot Studio peut fournir des repères organisationnels pour suivre les usages et administrer des environnements, selon les composants que tu déploies. Consulte sa documentation de présentation pour évaluer son adéquation à ton contexte. Mais garde un principe d’architecture : les logs nécessaires à une réponse à incident ne doivent pas dépendre uniquement d’un tableau de bord fournisseur.

Commence par les actions irréversibles ou coûteuses

Tu n’as pas besoin d’instrumenter parfaitement tous les agents dès le premier jour. Cartographie d’abord les outils capables d’écrire, d’envoyer, de publier, de supprimer ou d’accéder à des données sensibles. Pour chacun, impose le schéma minimal, le masquage des secrets, un trace_id de bout en bout et une règle de validation humaine lorsque le risque le justifie.

Fais ensuite un exercice concret : choisis une modification erronée fictive et demande à une personne qui n’a pas conçu l’agent de la reconstituer avec les seuls journaux disponibles. Si elle ne peut pas répondre rapidement à « qui a lancé quoi, avec quelle version, sur quelle cible, avec quelle autorisation et quel résultat ? », ton audit est encore insuffisant. Si elle peut lire des données qu’elle n’aurait jamais dû voir, tes logs sont trop riches.