---
name: tech-reconstituer-les-actions-d-un-agent-d-ia
description: "Cadre l’assistant pour aider un expert ou une experte en cybersécurité à reconstituer, après un événement suspect, les actions d’un agent d’IA qui agit sur les systèmes (messagerie, tickets, stockage, déploiement) : sources de traces, conservation, chronologie distinguant ce que l’agent a lu, décidé et exécuté, et compte avec lequel il a agi. À utiliser dès qu’une action anormale est attribuée à un agent, avant de le désactiver ou de purger ses journaux."
---

# Reconstituer ce qu’un agent d’IA a fait : journaux, preuves et chronologie

## Quand s’en servir

Un agent d’IA a envoyé un message qui n’aurait pas dû partir, supprimé ou partagé des fichiers, modifié un ticket ou une configuration. On ne sait pas s’il a mal compris, s’il a suivi une instruction cachée dans un document, ou si quelqu’un s’est servi de son compte. La Skill sert à établir les faits de façon à pouvoir les montrer à la direction, à un client, à un assureur ou à un enquêteur.

## Ce que l’assistant doit savoir

Les actions d’un agent laissent des traces à plusieurs endroits qui ne s’alignent pas toujours : journaux de la plateforme d’agent (consignes, appels d’outils, réponses), journaux des systèmes touchés, journaux d’authentification du compte de service. Leur durée de conservation dépend des réglages et des contrats : une désactivation précipitée peut les faire disparaître. La chronologie doit séparer ce que l’agent a reçu (consigne, documents lus), ce qu’il a produit et ce qui a réellement été exécuté sous son identité. Une explication fournie après coup par l’agent lui-même n’est pas une trace : c’est un texte généré.

Si l’agent a exposé, modifié ou supprimé des données personnelles, la reconstitution alimente les obligations du RGPD. L’article 33, paragraphe 5, impose de documenter toute violation « en indiquant les faits concernant la violation des données à caractère personnel, ses effets et les mesures prises pour y remédier » : la chronologie établie ici en est la matière. L’article 33, paragraphe 1, fait courir la notification à l’autorité « dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance » : la reconstitution ne doit pas retarder l’alerte de la personne qui décide. Si la plateforme d’agent est opérée par un prestataire sous-traitant, l’article 33, paragraphe 2, l’oblige à notifier toute violation au responsable du traitement dans les meilleurs délais, et le contrat exigé par l’article 28, paragraphe 3, dit ce qu’il doit fournir comme journaux. Si l’organisation est fabricant du produit dans lequel l’agent est intégré, l’article 14 du règlement (UE) 2024/2847, applicable depuis le 11 septembre 2026, peut imposer une alerte précoce au plus tard 24 heures après connaissance d’un incident grave ayant des répercussions sur la sécurité du produit ; ce point se tranche avec le juridique. Les règles de conservation des preuves et les personnes à informer figurent dans la procédure de réponse aux incidents.

## Marche à suivre

1. Geler les traces avant toute désactivation : exporter les journaux de la plateforme d’agent, des systèmes touchés et de l’authentification, avec date, heure et empreinte ; demander par écrit au prestataire de la plateforme les journaux qu’il détient.
2. Identifier le compte sous lequel l’agent agit, ses droits au moment des faits et les personnes ou processus qui pouvaient le déclencher.
3. Reconstituer la chronologie en trois colonnes : reçu (consigne, documents), produit (réponses, appels d’outils), exécuté (effets constatés dans les systèmes).
4. Repérer dans les documents lus par l’agent tout contenu qui ressemble à une instruction, et le conserver tel quel.
5. Noter chaque trou dans les traces et sa cause probable, sans le combler par une hypothèse.
6. Signaler sans attendre à la personne qui conduit l’incident tout indice que des données personnelles ont été touchées, avec l’heure de prise de connaissance (article 33 du RGPD).
7. Rédiger la synthèse factuelle à remettre à la personne qui conduit l’incident : faits établis, hypothèses, traces manquantes, mesures conservatoires, éléments utiles à la documentation prévue par l’article 33, paragraphe 5, du RGPD.

## Lignes rouges

- Ne jamais désactiver l’agent ni purger ses journaux avant d’avoir conservé les traces.
- Ne jamais présenter l’explication que l’agent donne de ses actions comme une preuve.
- Ne jamais combler un trou de la chronologie par une hypothèse présentée comme un fait.
- Ne jamais attribuer l’action à une personne sans trace d’authentification qui le montre.
- Ne jamais différer l’alerte d’une possible violation de données personnelles le temps de terminer la reconstitution.

## Ce que la Skill ne fait pas

Elle ne conduit pas l’enquête judiciaire, ne qualifie pas les faits et ne refait pas la configuration de l’agent. Pour réagir à une injection de consigne dans une fonctionnalité, voir tech-incident-d-injection-de-consigne ; pour encadrer les agents de codage, voir tech-agents-de-codage-dans-les-depots.

## Modèle de sortie

~~~
ÉVÉNEMENT : signalé le ... / action anormale constatée / systèmes touchés
TRACES GELÉES : source / période couverte / exporté le ... / empreinte
JOURNAUX DEMANDÉS AU PRESTATAIRE : le ... / reçus le ... / base contractuelle (article 28, paragraphe 3, du RGPD)
COMPTE DE L’AGENT : identifiant / droits au moment des faits / déclencheurs possibles
CHRONOLOGIE : heure / reçu / produit / exécuté / source de la trace
CONTENU SUSPECT DANS LES DOCUMENTS LUS : ...
TROUS DANS LES TRACES : période / cause probable
DONNÉES PERSONNELLES TOUCHÉES : non / oui, prise de connaissance le ... à ..., signalé à ... (article 33 du RGPD)
FAITS ÉTABLIS : ...
HYPOTHÈSES : ...
MESURES CONSERVATOIRES : ...
REMIS À : ... le ...
~~~