Forensic IA : quelles traces préserver pour comprendre un incident impliquant un modèle ?
Par Emmanuel Forgues - 8 mai 2026
L’essor de l’intelligence artificielle (IA) dans les systèmes d’information transforme la façon dont les organisations prennent des décisions, mais introduit également une nouvelle catégorie d’incidents : ceux qui concernent directement les modèles. Analyser ces dysfonctionnements nécessite une approche forensique adaptée, capable de capturer et de conserver des artefacts très différents de ceux habituellement collectés en cybersécurité traditionnelle. Cet article décrit le cadre normatif, la typologie des traces à préserver, les bonnes pratiques d’acquisition et d’analyse, ainsi que les limites techniques et juridiques auxquelles les équipes doivent se préparer.
Introduction – Un incident IA qui bouleverse les pratiques
Imaginez une banque qui utilise un modèle de scoring credit basé sur le machine learning pour approuver ou refuser des demandes en temps réel. En pleine saison de prêts immobiliers, le taux d’acceptation chute brutalement : 30 % des dossiers sont refusés alors que les historiques montrent une stabilité à plus de 85 %. L’enquête révèle que le modèle a été « poisonné » par l’injection de données manipulées dans le pipeline d’entraînement, altérant ainsi sa capacité de généralisation.
Ce scénario, qui n’est plus hypothétique selon le AI Incident Database (voir [1]), montre que les incidents IA ne se limitent pas à une simple panne logicielle ou à un accès non autorisé : ils touchent la qualité et l’intégrité du modèle, ainsi que son environnement d’exécution. La réponse forensique doit donc s’étendre bien au‑delà des journaux système classiques pour inclure :
- les jeux de données d’entraînement et leurs métadonnées,
- les hyperparamètres et la configuration du pipeline CI/CD,
- les poids (weights) et l’architecture du modèle déployé,
- les artefacts de conteneurisation ou de virtualisation,
- les traces d’accès aux API d’inférence.
Comprendre ces éléments, c’est pouvoir reconstituer le when‑how‑why de la compromission, identifier les acteurs (internes, externes ou automatisés) et mettre en place des mesures correctives robustes. Le présent article propose une cartographie exhaustive des traces à préserver, un processus d’acquisition fiable et un cadre d’analyse aligné sur les normes internationales.
1. Cadre conceptuel : de la forensic traditionnelle à la forensic IA
| Dimension | Forensic informatique classique | Forensic IA (nouveau) |
|---|---|---|
| Objet | Systèmes, réseaux, fichiers binaires, logs d’accès | Modèles, jeux de données, pipelines d’entraînement, artefacts de déploiement |
| Périmètre temporel | Principalement post‑incident (analyse rétroactive) | Nécessite une préservation continue dès la phase d’ingestion des données |
| Sources de preuve | Journaux système, images disque, captures réseau | Snapshots de dataset, métadonnées de versionnage, fichiers de configuration, artefacts de conteneurs |
| Normes de référence | ISO/IEC 27043 (Gestion des incidents), NIST SP 800‑86 (Guide forensics) | ISO/IEC 27035‑2 (Réponse aux incidents IA), NIST AI RMF, AI Act (art. 14) |
Les standards de forensic informatique (ISO/IEC 27043, NIST SP 800‑86) restent pertinents pour la collecte des logs d’infrastructure et la préservation de l’intégrité des preuves. Cependant, le NIST Artificial Intelligence Risk Management Framework (AI RMF) et les annexes du Règlement européen sur l’IA (§ 14) introduisent explicitement la notion de « traces de modèle » comme éléments à protéger lors d’un incident IA [2][3].
2. Typologie des artefacts à collecter
2.1 Données d’entrée et de formation
- Jeux de données brutes – fichiers CSV, images, logs d’événements, bases NoSQL.
- Métadonnées de provenance – horodatage de collecte, source (API, capteur), version du schéma.
- Annotations et labels – scripts de génération de labels, politiques de validation.
2.2 Artefacts du pipeline d’entraînement
| Élément | Description | Pourquoi le préserver |
|---|---|---|
| Code source (scripts Python/Scala, notebooks) | Représente la logique de pré‑traitement et d’apprentissage. | Permet de reproduire exactement les transformations appliquées aux données. |
| Configuration du job – fichiers YAML/JSON (ex. : mlflow.yaml, kubeflow pipeline) | Déclare hyperparamètres, ressources, version des bibliothèques. | Facilite la reconstitution du contexte d’entraînement et l’identification de changements non autorisés. |
| Environnement d’exécution – images Docker, dépendances (requirements.txt), versions de frameworks (TensorFlow 2.8, PyTorch 1.12) | Garantit la reproductibilité logicielle. | Crucial pour détecter des différences de version qui pourraient introduire des vulnérabilités ou des biais. |
| Poids du modèle – fichiers .pt, .h5 | Le cœur fonctionnel du modèle. | Toute altération (ex. : injection d’un back‑door) est directement observable via hachage et comparaison de checksum. |
2.3 Artefacts de déploiement et d’inférence
- Conteneurs ou VM – images immuables, manifests Kubernetes (Deployment, Service), fichiers Helm.
- Endpoints d’API – spécifications OpenAPI/Swagger, logs d’appels (payloads, réponses).
- Métriques d’observabilité – traces distribuées (Jaeger, Zipkin), métriques Prometheus (latency, error_rate), alertes de sécurité.
2.4 Journaux d’infrastructure et de sécurité
- Logs système – syslog, journald.
- Audit des accès IAM/RBAC – qui a déployé ou modifié le modèle ? (ex. : CloudTrail AWS, Azure Activity Log).
- Alertes IDS/IPS – détections d’anomalies réseau autour du service d’inférence.
3. Chaîne de préservation – du point d’entrée au stockage sécurisé
3.1 Points de capture stratégiques
| Phase | Point de capture | Artefacts associés |
|---|---|---|
| Ingestion des données | Avant toute transformation (raw bucket, data lake) | Jeux de données brutes, métadonnées d’acquisition |
| Pré‑traitement / Feature engineering | Après chaque étape critique (ex. : normalisation) | Scripts, logs de transformation |
| Entraînement | À la fin du job (snapshot) | Poids du modèle, hyperparamètres, artefacts CI/CD |
| Déploiement | Au moment du docker push ou kubectl apply | Image Docker, manifests, signatures numériques |
| Inférence | À chaque appel critique (ex. : décision financière) | Payloads d’entrée/sortie, traces de logs |
3.2 Méthodes d’acquisition fiables
- Snapshot immuable – Utilisation de systèmes de fichiers en mode append‑only (ex. : Amazon S3 Object Lock, Azure Immutable Blob Storage) pour garantir l’inaltérabilité.
- Hashage cryptographique – Calcul SHA‑256 ou BLAKE2b sur chaque artefact au moment du snapshot ; stockage des hash dans un registre de preuves (blockchain privée ou service d’ancrage temporel tel que OpenTimestamps).
- Horodatage sécurisé – Utilisation de services NTP authentifiés et de signatures électroniques (X.509) pour attester la chronologie.
- Chiffrement au repos – AES‑256 GCM, avec gestion des clés via HSM ou KMS afin de concilier préservation et exigences de confidentialité.
3.3 Conservation à long terme
Le NIST SP 800‑101 recommande une durée minimale de conservation de trois ans pour les artefacts liés aux incidents critiques [4]. Les organisations doivent toutefois aligner cette période sur les obligations du RGPD (article 30) et, le cas échéant, sur l’AI Act, qui impose la rétention des données d’audit pendant au moins cinq ans pour les systèmes à haut risque.
4. Analyse forensique – reconstruire l’incident IA
4.1 Reconstitution du pipeline
En comparant les snapshots successifs (avant/après incident) on identifie :
- Différences de jeu de données : ajout ou suppression d’enregistrements, modification de labels (détection via diff sur hashes).
- Modification d’hyperparamètres : variation inattendue du taux d’apprentissage, nombre d’époques – souvent indicateur d’une ré‑entraînement non autorisée.
- Altération des poids : comparaison binaire ou via métriques de similarité (cosine similarity) entre le modèle suspect et la version signée.
4.2 Détection d’attaques spécifiques
| Type d’attaque | Signes révélateurs |
|---|---|
| Poisoning de données | Concentration d’échantillons malveillants dans un batch, outliers détectés par clustering (t‑SNE) sur les embeddings. |
| Back‑door / Trigger | Activation du modèle uniquement pour des entrées contenant une séquence spécifique (ex. : pixel pattern). Analyse de la fonction de décision via Feature Attribution (SHAP, LIME). |
| Model extraction | Volume anormalement élevé d’appels d’inférence provenant d’une même IP, logs d’API montrant des requêtes structurées pour reconstruire le modèle. |
| Adversarial evasion | Augmentation soudaine du taux de « false negative » sur les métriques d’évaluation en production; inspection des gradients adversaires via FGSM ou PGD. |
4.3 Attribution et chaîne de responsabilité
En croisant :
- Les logs IAM (qui a déclenché le job d’entraînement) ,
- Les commits Git associés aux scripts de pré‑traitement,
- Les tickets JIRA/ServiceNow liés au déploiement,
on peut établir une chronologie d’action et identifier les acteurs potentiels (développeur, data scientist, automatisation CI/CD). La traçabilité doit être documentée dans un Incident Report conforme à ISO 27043.
5. Cas d’usage – Incident de poisoning sur un modèle de scoring crédit
Contexte
Une banque française utilise CreditScoreNet, réseau de neurones entraîné chaque semaine sur les nouvelles demandes de crédit. Le pipeline CI/CD s’appuie sur GitLab, Docker et Kubeflow.
Déroulement de l’incident
- Jour J‑2 : Un nouveau jeu de données d’entraînement est ingéré depuis un bucket S3 partagé avec un partenaire marketing.
- Jour J‑1 : Le job d’entraînement démarre automatiquement, crée une image Docker contenant les poids creditscorenet_v20230715.pt.
- Jour J : Après le déploiement, le taux de refus passe de 15 % à 45 %. Les analystes détectent un pic d’erreurs dans la catégorie « revenu faible ».
- Enquête : Analyse des snapshots montre que 2 % du jeu de données contiennent des enregistrements falsifiés (revenus artificiellement élevés) provenant du répertoire partagé /partner/data/.
- Conclusion : Le partenaire a accidentellement injecté un sous‑ensemble de données contenant des valeurs manipulées, entraînant un label flipping qui biaise le modèle.
Preuves préservées
| Artefact | Méthode de capture |
|---|---|
| Jeu de données brut (S3) | Versionnage S3 avec Object Lock + hash SHA‑256 |
| Script d’ingestion (ingest.py) | Commit Git signé GPG, horodaté |
| Snapshot du modèle (creditscorenet_v20230715.pt) | Stockage immuable dans Glacier Deep Archive, signature RSA |
| Logs Kubeflow et Docker | Forwarded vers SIEM (Elastic) avec retention 2 ans |
Leçons tirées
- Ségrégation des sources de données – Mettre en place des data contracts et des contrôles d’intégrité (checksum) avant ingestion.
- Audit automatisé du pipeline – Utiliser des tests de robustesse (ex. : Data Validation via Deequ ou Great Expectations).
- Gestion des accès IAM – Restreindre les droits d’écriture sur le bucket partagé aux seules équipes autorisées.
6. Risques et limites de la forensic IA
| Risque | Description | Mitigation |
|---|---|---|
| Volume massif d’artefacts (datasets TB, modèles GB) | Stockage coûteux, temps de collecte long. | Compression lossless + archivage sélectif (exemple : ne conserver que les diffs entre versions). |
| Confidentialité des données – jeux de données contenant des PII. | Risque de fuite lors de la préservation ou du partage avec les équipes forensiques. | Chiffrement avant transfert, anonymisation partielle, accès basé sur le principe du moindre privilège. |
| Volatilité du cloud – ressources éphémères (serverless). | Difficulté à capturer des snapshots cohérents. | Utiliser les services natifs d’immutable storage et les API de snapshot (ex. : AWS EBS Snapshots, Azure Disk Snapshot) dès le déclenchement de l’incident. |
| Jurisdiction & souveraineté – données stockées dans plusieurs régions. | Conflits avec le RGPD ou le AI Act sur la localisation des preuves. | Définir une politique de data residency et s’appuyer sur des fournisseurs offrant des zones géographiques dédiées. |
| Altération malveillante des preuves (tampering). | Un attaquant peut tenter de modifier les logs pour masquer son action. | Chaînes de confiance basées sur signatures numériques, horodatage tierce partie et stockage en write‑once. |
7. Recommandations opérationnelles – Guide à l’intention des décideurs
7.1 Gouvernance
- Créer un « AI Forensics Playbook » aligné sur ISO/IEC 27035‑2, incluant les rôles (Data Custodian, AI Incident Responder) et les procédures d’escalade.
- Intégrer la forensic IA dans le SOC – les alertes de déviation des métriques de modèle doivent déclencher automatiquement un workflow d’acquisition d’artefacts.
7.2 Architecture technique
| Action | Implémentation concrète |
|---|---|
| Versionnage immuable des datasets | S3 Object Lock + AWS Glacier Deep Archive, ou Azure Immutable Blob Storage. |
| Signature de modèles | Utiliser mlflow avec plugin model signatures (hash SHA‑256 + certificat X.509). |
| Capture automatisée des pipelines | Déployer un side‑car container qui exporte les métadonnées CI/CD vers le SIEM à chaque run. |
| Horodatage fiable | Service de timestamping RFC 3161 (ex. : DigiCert Timestamp), intégré aux scripts d’acquisition. |
7.3 Processus d’investigation
- Déclenchement – Alertes de métriques ou demande manuelle.
- Isolation – Mettre en pause le pipeline incriminé (ex. : kubectl scale deployment creditscorenet --replicas=0).
- Acquisition – Snapshots immuables des jeux de données, modèles, conteneurs et logs.
- Analyse – Comparaison de hash, reconstruction du graphe d’entraînement, recherche de patterns d’attaque.
- Rapport – Documenter la chaîne de causalité, les impacts business, les recommandations.
- Remédiation – Restauration à partir de versions signées, mise à jour des contrôles de qualité.
7.4 Formation et culture
*
- Former les data scientists aux bonnes pratiques de data provenance (ex. : utilisation de Data Version Control – DVC).