Le manuel des incidents d'IA : comment réagir en cas de piratage de votre modèle (2026)

## Table of Contents

- [Partie 1 : Le triage de 90 minutes (L'heure d'or)](#partie-1-le-triage-de-90-minutes-lheure-dor)
  - [Minute 0 à 15 : Séparer la compromission du modèle de la compromission des données](#minute-0-à-15-séparer-la-compromission-du-modèle-de-la-compromission-des-données)
  - [Minute 16-30 : Lancer la salle de guerre des incidents IA](#minute-16-30-lancer-la-salle-de-guerre-des-incidents-ia)
  - [Minutes 31 à 60 : Préserver la scène](#minutes-31-à-60-préserver-la-scène)
  - [Minutes 61 à 90 : Classification initiale et escalade](#minutes-61-à-90-classification-initiale-et-escalade)
- [Partie 2 : Les analyses médico-légales 24 heures sur 24 (Découvrez ce qui s'est passé)](#partie-2-les-analyses-médico-légales-24-heures-sur-24-découvrez-ce-qui-sest-passé)
  - [Scénario A : pondérations des modèles détournés](#scénario-a-pondérations-des-modèles-détournés)
  - [Scénario B : empoisonnement des données de formation](#scénario-b-empoisonnement-des-données-de-formation)
- [Partie 3 : Les 7 jours de confinement et de récupération](#partie-3-les-7-jours-de-confinement-et-de-récupération)
  - [Jour 1 : Contenir](#jour-1-contenir)
  - [Jours 2 et 3 : Notifier (ou non)](#jours-2-et-3-notifier-ou-non)
  - [Jours 4 à 7 : Corriger et apprendre](#jours-4-à-7-corriger-et-apprendre)
- [Partie 4 : La récupération en 30 jours (Retour aux opérations)](#partie-4-la-récupération-en-30-jours-retour-aux-opérations)
  - [Semaines 2 et 3 : Reconstruire](#semaines-2-et-3-reconstruire)
  - [Semaine 4 : Soumission d’un audit réglementaire](#semaine-4-soumission-dun-audit-réglementaire)
- [Partie 5 : Exercices de simulation de réponse aux incidents (à réaliser tous les trimestres)](#partie-5-exercices-de-simulation-de-réponse-aux-incidents-à-réaliser-tous-les-trimestres)
  - [Exercice 1 : Injection de prompt avec grand modèle de langage (LLM) contenant une porte dérobée](#exercice-1-injection-de-prompt-avec-grand-modèle-de-langage-llm-contenant-une-porte-dérobée)
  - [Exercice 2 : Empoisonnement des données dans un modèle de détection de fraude](#exercice-2-empoisonnement-des-données-dans-un-modèle-de-détection-de-fraude)
  - [Exercice 3 : Vol de modèle](#exercice-3-vol-de-modèle)
- [Les modèles dont vous avez besoin (téléchargeables)](#les-modèles-dont-vous-avez-besoin-téléchargeables)
- [Le coût de l'absence de playbook](#le-coût-de-labsence-de-playbook)
- [Construisez votre plan d’intervention en cas d’incident d’IA en 30 jours (si vous n’en avez pas encore)](#construisez-votre-plan-dintervention-en-cas-dincident-dia-en-30-jours-si-vous-nen-avez-pas-encore)
  - [Semaine 1 : Rassemblez l’équipe et définissez les rôles](#semaine-1-rassemblez-léquipe-et-définissez-les-rôles)
  - [Semaine 2 : Documentez vos modèles](#semaine-2-documentez-vos-modèles)
  - [Semaine 3 : Construisez votre pipeline de collecte de preuves](#semaine-3-construisez-votre-pipeline-de-collecte-de-preuves)
  - [Semaine 4 : Exécutez votre première simulation](#semaine-4-exécutez-votre-première-simulation)
- [Cinq erreurs fatales (et comment les éviter)](#cinq-erreurs-fatales-et-comment-les-éviter)
- [Reporting réglementaire : les modèles](#reporting-réglementaire-les-modèles)
  - [FCA (Royaume-Uni) - Formulaire D (Incident important)](#fca-royaume-uni---formulaire-d-incident-important)
  - [MAS (Singapour) - Formulaire 18 (Incident de risque technologique)](#mas-singapour---formulaire-18-incident-de-risque-technologique)
  - [Loi de l'UE sur l'IA - Article 64 (Accès aux données) et article 61 (Surveillance post-commercialisation)](#loi-de-lue-sur-lia---article-64-accès-aux-données-et-article-61-surveillance-post-commercialisation)
- [Le briefing du Conseil d'administration (30 secondes)](#le-briefing-du-conseil-dadministration-30-secondes)
- [Le Playbook en un coup d'œil](#le-playbook-en-un-coup-dœil)
- [Conclusion](#conclusion)
- [Sources](#sources)

---

## Partie 1 : Le triage de 90 minutes (L'heure d'or)

!AI incident response playbook flowchart with detection, containment, eradication, recovery

**L'horloge démarre :** Au moment où votre SOC reçoit la première alerte générée par l'IA pouvant indiquer un modèle compromis.

### Minute 0 à 15 : Séparer la compromission du modèle de la compromission des données

Deux types d'incidents différents nécessitent des réponses distinctes :

| Type d'incident | Indicateur initial | Priorité immédiate |
|-----------------|---------------------|---------------------|
| **Compromission du modèle** | Sorties inhabituelles, comportement anormal, preuve d’un réglage fin par une partie non autorisée | Empêcher le modèle de diffuser des prédictions |
| **Compromission des données d'entraînement** | Ensemble de données empoisonné détecté, étiquettes corrompues identifiées | Isoler le pipeline de formation, préserver les preuves |
| **Injection de prompt active** | Acteur externe manipulant actuellement les sorties du modèle | Bloquer d’abord le vecteur d’accès de l’attaquant |
| **Vol de modèle** | Poids exfiltrés, clés API abusées | Faire pivoter les clés, filigraner le modèle volé si possible |

**Action :** Classez dans les 15 minutes. Si ce n’est pas clair, supposez une **compromission du modèle** : c’est le scénario de gravité la plus élevée.

### Minute 16-30 : Lancer la salle de guerre des incidents IA

Créez un canal Slack/Teams dédié aux incidents nommé « #incident-ai-<date>-<type> ». Invitez :
- **Responsable de l’incident** (RSSI ou adjoint désigné)
- **Responsable ingénierie ML** (l’équipe propriétaire du modèle)
- **Responsable forensic** (opérations de sécurité)
- **Légal/Conformité** (décisions de reporting réglementaire)
- **PR/Comms** (si une notification client/réglementaire est nécessaire)
- **Responsable du modèle** (data scientist ayant entraîné le modèle)

N’incluez PAS les fournisseurs au départ – vous avez d’abord besoin d’un alignement interne.

### Minutes 31 à 60 : Préserver la scène

**Ne redémarrez pas, ne recyclez pas et ne redéployez pas.** Votre modèle constitue une preuve.

1. **Prendre un instantané du fichier modèle** - calculez un hachage SHA256, copiez le fichier `.safetensors` ou `.bin` dans un coffre-fort médico-légal (stockage immuable)
2. **Préserver les journaux d’entraînement** : extrayez tous les journaux des 7 derniers jours d’exécutions d’entraînement (CloudWatch, GCP Cloud Logging, Azure Monitor)
3. **Capturer les journaux d’inférence** - toutes les requêtes traitées par le modèle au cours des dernières 24 à 48 heures
4. **Isolez l’environnement d’exécution** : arrêtez le serveur de modèles, mais conservez l’environnement intact pour l’analyse médico-légale
5. **Verrouiller les journaux d’accès** : qui disposait de clés API, d’un accès SSH ou d’un accès à la console d’administration au cours des 30 derniers jours ?

Exécutez cette commande sur l’hôte du modèle (s’il est toujours accessible) :

```bash
# Script de collecte de preuves
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
tar -czf /forensics-vault/model-evidence-$TIMESTAMP.tar.gz \
  /models/served-model.safetensors \
  /var/log/model-server/*.log \
  /etc/model-serving/config.yaml \
  ~/.aws/credentials 2>/dev/null || vrai
sha256sum /forensics-vault/model-evidence-$TIMESTAMP.tar.gz > /forensics-vault/model-evidence-$TIMESTAMP.sha256

## Partie 3 : Les 7 jours de confinement et de récupération

### Jour 1 : Contenir

Sur la base des découvertes médico-légales, exécutez l'une de ces démarches :

**Chemin A – Le modèle est de type porte dérobée :**
1. **Rappeler le modèle** - arrêter immédiatement sa mise en service. Déployez la dernière version connue (si disponible).
2. **Auditer tous les systèmes en aval** : quels services ont consommé la sortie de ce modèle ? Sont-ils compromis ?
3. **Invalider les sorties mises en cache** - si vous utilisez Redis ou un système similaire pour la mise en cache des prédictions, videz toutes celles issues de la période compromise.
4. **Faire pivoter tous les secrets** : clés API, comptes de service, informations d'identification de bases de données auxquelles le modèle avait accès.

**Chemin B – Données d'entraînement empoisonnées :**
1. **Réentraîner à partir de données propres** : identifiez le dernier instantané de l’ensemble de données fiable, puis recyclez le modèle.
2. **Auditer tous les modèles entraînés sur cet ensemble de données** - tout autre modèle utilisant le même corpus empoisonné doit être mis en quarantaine.
3. **Pas de clients si le modèle a influencé des décisions** - si le modèle empoisonné a pris des décisions concernant des personnes (crédit, embauche, modération de contenu), ces décisions peuvent être annulées.

**Chemin C – Injection de prompt active :**
1. **Corriger l'invite système** - renforcer la hiérarchie des instructions, ajouter des délimiteurs de jetons.
2. **Ajouter une couche de désinfection des entrées** - filtrer les entrées suspectes avant qu'elles n'atteignent le modèle.
3. **Limite de débit et détection d’anomalies** : bloquer tout utilisateur envoyant des prompts inhabituellement longs ou codés.

### Jours 2 et 3 : Notifier (ou non)

Il s’agit d’une décision juridique, non technique. Consultez un avocat. Voici le cadre :

**Article 33 du RGPD (UE) - Notification dans les 72 heures si :**
- Les données personnelles ont été consultées, divulguées, modifiées ou détruites.
- Probabilité de risque pour les droits et libertés des individus.

**Incident IA** : si la sortie de votre modèle contenait des données personnelles, ou si la compromission a influencé des décisions du modèle concernant des personnes, vous devez en informer.

**FCA (Royaume-Uni) - Avertissez « sans délai » si :**
- L’incident présente une « probabilité raisonnable de causer un préjudice important » aux clients ou aux marchés.
- Les incidents liés à l’IA sont présumés devoir être signalés en vertu du SMCR (Senior Managers & Certification Regime).

**MAS (Singapour) - Avertissez dans les 24 heures si :**
- Une défaillance du système d’IA a un impact significatif sur les opérations des services financiers.
- Tout incident affectant l’intégrité du modèle dans une fonction réglementée.

**En cas de doute, informez-le.** Le défaut de déclaration constitue une violation réglementaire distincte, susceptible d’entraîner des amendes.

**Exigences relatives au contenu des notifications (normes 2026) :**
1. Que s’est-il passé (en langage simple, sans jargon) ?
2. Quels systèmes d’IA étaient impliqués ?
3. Quelles données ont été potentiellement affectées ?
4. Quelles mesures prenez-vous pour contenir la situation ?
5. Que doivent faire les clients (le cas échéant) ?
6. Calendrier de remédiation.

**Ne dites PAS :** « Nous enquêtons » - dites : « Nous avons maîtrisé l’incident et menons des analyses médico-légales. » Les régulateurs attendent une réponse rapide de confinement.

### Jours 4 à 7 : Corriger et apprendre

1. **Analyse des causes profondes (RCA)** - rédigez un rapport RCA impeccable. Inclure :
   - Comment l’attaquant a pénétré le système (chaîne d’approvisionnement, vol d’identifiants, initiation ?)
   - Quels contrôles ont échoué (absence de signature du modèle, validation des entrées, etc.)
   - Quelles preuves manquaient qui auraient permis de détecter la faille plus tôt.

2. **Remédiation client** - si des clients ont été affectés :
   - Proposez des actions concrètes : suivi du crédit, alertes de compte, etc.
   - Documentez tous les coûts de réparation (qui peuvent être assurables).

3. **Engagement du régulateur

```markdown
## Partie 4 : La récupération en 30 jours (Retour aux opérations)

### Semaines 2 et 3 : Reconstruire

1. **Réentraîner le modèle à partir de zéro** en utilisant un ensemble de données propre et des dépendances vérifiées
2. **Mise en œuvre de nouveaux contrôles** découverts lors de l’analyse des causes racines (RCA) :
   - Signature et vérification du modèle
   - Couche de désinfection d’entrée
   - Surveillance renforcée de la dérive du modèle
   - Environnement de formation séparé

3. **Déploiement progressif** : commencer par un déploiement vers un Canari 1 % du trafic, surveiller pendant 72 heures, puis étendre

### Semaine 4 : Soumission d’un audit réglementaire

La majorité des régulateurs (FCA, MAS, autorités de l’UE AI Act) exigeront un rapport post-incident. Inclure :

- Résumé exécutif (1 page)
- Chronologie de détection → confinement → récupération
- Cause profonde avec détails techniques
- Données concernées (le cas échéant)
- Clients informés (compte, méthode)
- Actions correctives mises en œuvre
- Contrôles préventifs pour l’avenir
- Attestation que le modèle compromis n’est plus en production

**Ne cachez pas les faits.** La coopération avec les régulateurs après un incident est un facteur atténuant dans l’évaluation des amendes.

---

## Partie 5 : Exercices de simulation de réponse aux incidents (à réaliser tous les trimestres)

Il est essentiel de s’entraîner régulièrement. Effectuez des simulations de 90 minutes avec votre équipe SOC et ML.

### Exercice 1 : Injection de prompt avec grand modèle de langage (LLM) contenant une porte dérobée

**Scénario :** Votre chatbot de support client commence à fournir des conseils malveillants à 3 % des utilisateurs. L’attaquant a intégré un déclencheur caché dans votre ensemble de données de réglage fin.

**Questions :**
- Comment détectez-vous cela ? (Anomalie dans le sentiment des réponses ? Inquiétudes du client ?)
- Qui contactez-vous en premier ?
- Prévenez-vous les clients ayant reçu de mauvais conseils ?
- Comment prouvez-vous aux régulateurs que le modèle est propre après recyclage ?

### Exercice 2 : Empoisonnement des données dans un modèle de détection de fraude

**Scénario :** Votre modèle de détection de fraude commence soudainement à approuver des transactions provenant d’un pays spécifique à un taux dix fois supérieur à la normale. Un concurrent a empoisonné votre ensemble de données d’entraînement pour réduire ses faux positifs.

**Questions :**
- À quelle vitesse pouvez-vous revenir à la version du modèle de la semaine précédente ?
- Quelle est l’exposition financière maximale pendant la réparation ?
- Signalez-vous cette anomalie aux régulateurs financiers comme une défaillance du système ?

### Exercice 3 : Vol de modèle

**Scénario :** Un ancien employé a exfiltré vos pondérations de grand modèle de langage (LLM) exclusives et gère un service concurrent. Vous découvrez cela via une alerte de filigrane du modèle.

**Questions :**
- S’agit-il d’une infraction pénale ? Qui appelez-vous : la police ou les avocats ?
- Pouvez-vous prouver que le modèle volé est le vôtre ?
- Informez-vous les clients que l’adresse IP de leur modèle pourrait être compromise ?

---

## Les modèles dont vous avez besoin (téléchargeables)

**Ressources disponibles :**

1. **Modèle de Runbook de réponse aux incidents IA** - un document Word de 12 pages avec des listes de contrôle pour chaque étape (triage, criminalistique, notification, récupération)
2. **Modèles de lettres de notification aux régulateurs** - lettres pré-rédigées pour la FCA, le MAS et l’UE, avec des espaces réservés pour les détails de l’incident
3. **Modèles de communication client** - versions d’e-mails, SMS et communiqués de presse pour différents niveaux de gravité
4. **Scripts de collecte de preuves médico-légales** - scripts bash/Python pour capturer l’état du modèle, les journaux et les artefacts de formation
5. **Playbook de rollback de modèle** - instructions étape par étape pour revenir à une version précédente du modèle sans interruption

---

## Cinq erreurs fatales (et comment les éviter)

**Erreur 1 – Perdre du temps à déterminer « était-ce vraiment un incident ? »**

*La solution :* Commencez par la présomption de compromis. Vous pourrez rétrograder plus tard. Vous ne pouvez pas récupérer le temps perdu.

**Erreur 2 - Ne pas conserver les preuves**

*Le correctif :* La collecte de preuves prend entre 0 et 15 minutes. Verrouillez l’hôte du grand modèle de langage (LLM). Ne le redémarrez pas. Ne le redéployez pas. Traitez-le comme une scène de crime.

**Erreur 3 - Attendre d'informer les régulateurs jusqu'à ce que vous ayez tous les faits**

*Le correctif :* Vous disposez de 72 heures (RGPD) ou 24 heures (MAS) pour notifier. Vous n'avez pas besoin de 100 % des faits. Il en faut suffisamment pour dire : « Cela s’est produit, nous l’avons contenu, nous enquêtons. » Mettez à jour les régulateurs à mesure que vous en apprenez davantage.

**Erreur 4 - Oublier les systèmes en aval**

*Le correctif :* Les sorties de votre modèle sont intégrées dans 12 autres systèmes. Ces systèmes peuvent avoir stocké des décisions corrompues. Auditez chaque consommateur en aval.

**Erreur 5 - Recyclage sur le même ensemble de données empoisonné**

*La solution :* Si vous ne comprenez pas comment le poison est entré, vous recyclerez la même porte dérobée. Auditez votre pipeline de données de bout en bout avant de le reconstruire.

---

## Reporting réglementaire : les modèles

### FCA (Royaume-Uni) - Formulaire D (Incident important)

Obligatoire dans les 72 heures si :  
- L'incident présente une « probabilité raisonnable de causer un préjudice important » aux clients ou aux marchés.  
- Des systèmes d'IA sont impliqués – présumés déclarables.

**Champs clés :**  
- Type d'incident : « Compromis à l'intégrité du modèle IA »  
- Systèmes concernés : répertoriez tous les modèles d'IA impliqués  
- Impact client estimé : nombre de clients concernés, type de préjudice  
- Cause première (connue) : « Compromis de la chaîne d'approvisionnement lors du réglage fin de l'ensemble de données »  
- Statut du confinement : « Modèle retiré, version backdoored identifiée »

### MAS (Singapour) - Formulaire 18 (Incident de risque technologique)

Obligatoire dans les 24 heures si :  
- Impact significatif sur les opérations de services financiers  
- Intégrité du système d'IA/ML compromise

**Champs clés :**  
- Catégorie d'incident : « Compromission du modèle - Porte dérobée/Empoisonnement »  
- Systèmes impactés : cas d'utilisation de l'IA concernés  
- Perte financière estimée : directe + indirecte  
- Temps d'arrêt : heures d'interruption de service  
- Cause première : « Package malveillant installé via le typosquatting PyPI »

### Loi de l'UE sur l'IA - Article 64 (Accès aux données) et article 61 (Surveillance post-commercialisation)

Vous devez conserver des dossiers sur :  
- Toutes les versions du modèle et leur provenance  
- Rapports d'incidents et actions correctives  
- Données de surveillance post-commercialisation montrant la dérive du modèle

Cette documentation est ce que vous fournirez aux régulateurs lors d’un audit. Votre réponse à un incident doit alimenter ce dossier continu.