L'essentiel en 30 secondes - Les incidents IA se classent en 4 niveaux de criticité (L1 à L4) selon leur impact sur les droits fondamentaux, la sécurité et la santé. - Le Règlement (UE) 2024/1689 (EU AI Act) impose une procédure de signalement des incidents graves pour les systèmes à haut risque (Article 73). - La CNIL exige une notification dans les 72 heures pour toute violation de données personnelles (RGPD, Article 33). - La norme ISO/IEC 42001:2023 conditionne la certification d'un système de management de l'IA à la tenue d'un registre d'incidents. - Les PME doivent documenter tout incident à partir du niveau L2 et conserver les preuves pendant au moins 10 ans (Art. 18 AI Act).
La gestion d'incidents n'est plus une option pour les PME qui exploitent des systèmes d'IA. Entre l'EU AI Act, le RGPD et la norme ISO/IEC 42001:2023, trois cadres réglementaires convergent vers une exigence commune : détecter, qualifier, notifier et corriger les incidents IA dans des délais contraints. Cet article décrit un workflow opérationnel à quatre niveaux (L1 à L4) directement transposable dans une PME française de 10 à 250 salariés.
1. Pourquoi une procédure de gestion des incidents IA est-elle obligatoire ?
L'obligation découle de quatre sources de droit qui se cumulent. Chacune impose ses propres délais, ses propres autorités de notification et son propre régime de sanctions.
Exigence de l'EU AI Act. Le Règlement (UE) 2024/1689 consacre tout son Article 73 au signalement des incidents graves pour les systèmes d'IA à haut risque. Le fournisseur doit notifier l'autorité de surveillance du marché de l'État membre concerné « immédiatement après que le fournisseur a établi un lien causal entre le système d'IA et l'incident grave ou la probabilité raisonnable d'un tel lien, et au plus tard 15 jours après que le fournisseur ou, le cas échéant, le déployeur, a eu connaissance de l'incident grave » (Article 73, paragraphe 2). Le délai tombe à 2 jours pour une infraction généralisée et à 10 jours pour un décès.
Obligation RGPD. Si l'incident IA implique des données personnelles, l'Article 33 du Règlement (UE) 2016/679 s'applique en parallèle. La notification à la CNIL doit intervenir « dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance ». Au-delà, la PME doit motiver le retard.
Exigence ISO/IEC 42001:2023. La norme dédie sa clause A.10.2 (« AI system impact assessment ») et son annexe B.6.2.8 au traitement des défaillances. Sans procédure formalisée et registre d'incidents, aucun organisme certificateur ne délivre la certification.
Protection de la réputation. Une fuite mal gérée détruit la confiance client en quelques heures. Une procédure documentée, testée et appliquée transforme un incident potentiellement réputationnel en démonstration de maîtrise.
| Cadre | Article applicable | Délai de notification | Autorité destinataire |
|---|---|---|---|
| EU AI Act (haut risque) | Art. 73 §2 | 15 jours (général), 10 jours (décès), 2 jours (infraction généralisée) | Autorité de surveillance du marché |
| RGPD | Art. 33 | 72 heures | CNIL |
| ISO/IEC 42001:2023 | Clause A.10 / B.6 | Non applicable (interne) | Comité IA + auditeur |
| Code de la santé publique (si dispositif médical) | Vigilance ANSM | Variable selon la classe | ANSM |
Pour un panorama complet du cadre applicable aux PME, consultez le guide AI Act PME France.
2. Les 4 niveaux de criticité des incidents IA (L1-L4)
La classification L1-L4 n'est pas imposée par le règlement, mais elle structure le travail des équipes techniques et juridiques. Elle permet d'aligner le délai de notification, l'instance saisie et le niveau d'investigation requis. Ce modèle s'inspire des grilles ITIL adaptées aux spécificités IA.
| Niveau | Intitulé | Exemples typiques | Délai d'action interne | Notification externe |
|---|---|---|---|---|
| L1 | Impact faible | Biais mineur isolé, latence dégradée, drift détecté sans conséquence client | 5 jours ouvrés | Aucune (registre interne) |
| L2 | Impact modéré | Erreur de prédiction sur un cas client, fuite de log non sensible, dérive métrique > seuil | 48 heures | Comité IA + DPO si données |
| L3 | Impact élevé | Décision automatisée erronée avec impact financier, biais discriminatoire avéré, indisponibilité critique | 24 heures | DPO + autorité de surveillance si haut risque |
| L4 | Impact critique | Violation massive de données personnelles, atteinte à la santé, discrimination systémique, atteinte à un droit fondamental | 4 heures | CNIL (72 h) + autorité AI Act (2 à 15 jours) |
Critères de classement. Quatre dimensions guident le diagnostic : nombre de personnes affectées, nature des données ou des décisions touchées, réversibilité du préjudice, exposition médiatique probable. Un incident qui combine deux dimensions L3 monte automatiquement en L4.
Cas particulier des incidents graves. L'Article 3, point 49, de l'AI Act définit l'« incident grave » comme tout incident qui « entraîne directement ou indirectement » l'un des résultats suivants : décès, atteinte grave à la santé, perturbation grave d'infrastructures critiques, violation des droits fondamentaux, atteinte grave aux biens ou à l'environnement. Tout incident grave est par construction un L4.
3. Workflow de gestion des incidents IA
Le workflow se déroule en cinq étapes. Chaque étape produit un livrable opposable à un auditeur ou à une autorité.
- Détection et classification. Les sources de détection sont multiples : alertes du modèle (drift, dégradation), signalement client, audit interne, lanceur d'alerte. Dès la détection, l'astreinte qualifie l'incident en L1, L2, L3 ou L4 à l'aide de la grille du paragraphe 2. La classification est journalisée avec horodatage UTC.
- Notification interne. L1 reste au niveau de l'équipe technique. L2 remonte au responsable IA et au DPO. L3 et L4 déclenchent la convocation immédiate de la cellule de crise (direction générale, DPO, responsable IA, RSSI, communication).
- Containment et analyse. L'objectif premier est d'arrêter la propagation : isolement du modèle, désactivation de l'endpoint, gel des données d'entraînement. L'analyse de cause racine s'appuie sur la traçabilité prévue par l'Article 12 de l'AI Act (logs automatiques).
- Correction et communication. Correction technique (recalibrage, patch, retrain), communication interne, communication aux personnes concernées si requise par l'Article 34 RGPD, communication aux autorités selon les délais du paragraphe 1.
- Documentation et amélioration. Le registre des incidents s'enrichit. La procédure est révisée si l'incident a révélé une faiblesse du dispositif. L'analyse post-incident est conservée 10 ans (durée minimale de conservation de la documentation technique selon Article 18 AI Act).
[Détection] → [Classification L1-L4] → [Notification interne]
↓
[Containment] → [Analyse cause racine] → [Correction]
↓
[Notification autorités si L3-L4] → [Communication clients] → [Registre + révision]
Pack documentaire incidents IA prêt à l'emploi
regulia fournit la procédure complète, le registre d'incidents conforme ISO 42001, les modèles de notification CNIL et AI Act, et la grille de classement L1-L4 adaptée à votre secteur.
Demander le pack incidents IA4. Exemple de procédure pour un incident L2
Contexte. Une PME de services RH déploie un modèle de prédiction salariale pour aider ses clients à benchmarker leurs grilles. L'équipe data détecte un biais : le modèle sous-évalue systématiquement les fonctions support de 3 % à 5 %. Aucun client n'a encore exploité une décision basée sur ce biais.
| Étape | Action | Responsable | Délai |
|---|---|---|---|
| 1 | Isoler le modèle de production, activer la version précédente | Lead data | H+2 |
| 2 | Notifier responsable IA + DPO via canal incident | Astreinte | H+4 |
| 3 | Identifier les données biaisées (sous-représentation des fonctions support dans le jeu d'entraînement) | Data scientist | H+24 |
| 4 | Recalibrer le modèle avec un échantillon stratifié | Data scientist | J+5 |
| 5 | Tests de non-régression, documentation, communication aux clients exposés | Lead data + commercial | J+7 |
| 6 | Inscription au registre, mise à jour de la procédure de validation | DPO | J+10 |
L'incident reste en L2 tant qu'aucune décision RH effective n'a été prise sur la base du biais. S'il s'avère qu'un client a fondé un plan de revalorisation salariale erroné sur les sorties du modèle, l'incident bascule en L3 et déclenche une notification au comité de surveillance interne ainsi qu'une analyse de l'impact sur les droits du travailleur (potentiellement Article 22 RGPD si décision automatisée).
5. Exemple de procédure pour un incident L4
Contexte. Un assistant conversationnel interne, branché sur la base CRM, est compromis par une attaque par injection de prompt. Pendant 36 heures, des collaborateurs externes reçoivent par erreur des extraits de fiches clients incluant nom, email, adresse, et historique de commandes. Environ 4 200 personnes sont concernées.
- Containment immédiat (H+0 à H+2). Désactivation de l'assistant conversationnel. Révocation des tokens d'accès au CRM. Activation de la cellule de crise (DG, DPO, RSSI, responsable IA, communication).
- Analyse forensique (H+2 à H+24). Reconstitution des logs Article 12 AI Act. Identification précise des fiches exfiltrées. Évaluation de la gravité au sens du considérant 86 RGPD : données d'identification + comportement d'achat = risque élevé pour les droits et libertés.
- Notification CNIL (H+24 à H+72). Transmission via le téléservice de notification de violation. Inclure la nature, les catégories de données, le nombre de personnes, les conséquences probables et les mesures prises (Article 33 §3 RGPD).
- Notification AI Act (J+1 à J+15). Si l'assistant relève d'un cas d'usage à haut risque (Annexe III), notification à l'autorité de surveillance du marché au titre de l'Article 73. En France, la désignation des autorités de surveillance est en cours de finalisation [à vérifier selon décret d'application].
- Communication aux personnes (J+1 à J+5). Article 34 RGPD impose une communication directe lorsque le risque est élevé. Lettre ou email personnalisé indiquant la nature de l'incident, le DPO, les conséquences possibles et les mesures prises.
- Correction technique (J+1 à J+30). Hardening du prompt système. Filtrage des sorties contenant des PII. Cloisonnement strict entre l'assistant et la base CRM. Audit de sécurité externe.
- Documentation et clôture (J+30 à J+60). Rapport d'incident final, mise à jour du DPIA, révision de la procédure, formation renforcée des équipes.
Les sanctions encourues en cas de défaillance dans la gestion d'un L4 cumulent jusqu'à 4 % du chiffre d'affaires mondial pour la violation RGPD et jusqu'à 7 % pour les pratiques interdites de l'AI Act (Article 99). Le détail figure dans l'article AI Act sanctions PME amendes.
6. Outils pour la gestion des incidents IA
Aucun outil n'est imposé par le règlement. La PME doit néanmoins démontrer la traçabilité, la rapidité de détection et la rigueur du traitement. Quatre catégories d'outils couvrent l'essentiel.
| Catégorie | Fonction | Exemples ouverts |
|---|---|---|
| Surveillance et observabilité IA | Mesure du drift, détection d'anomalies, monitoring des métriques de fairness | Outils MLOps avec module monitoring, dashboards Grafana |
| SIEM et logs de sécurité | Corrélation d'événements, détection d'attaques, alertes | Solutions SIEM open source ou propriétaires |
| Ticketing et gestion d'incidents | Workflow L1-L4, escalade, traçabilité, SLA | Plateformes ITSM, outils de tracking d'incident |
| Registre des incidents IA | Base de données conforme ISO 42001, exportable, horodatée | Tableur structuré, base interne, GRC |
Critères de choix pour une PME. Trois critères priment : intégration avec le SI existant, capacité d'export pour audit, hébergement compatible RGPD (UE de préférence). Un tableur structuré et versionné suffit pour démarrer si l'effectif est inférieur à 50 personnes.
Données minimales à journaliser par incident. Identifiant unique, horodatage de détection, source de détection, classification L1-L4, système d'IA concerné, données impliquées, nombre de personnes affectées, actions menées, autorité notifiée et date de notification, statut, date de clôture, leçons apprises.
7. Entraînement et simulation
Une procédure non testée est une procédure qui ne fonctionnera pas. Trois pratiques garantissent l'opérationnalité du dispositif.
Simulations annuelles L3-L4. Au moins un exercice par an de scénario L3 ou L4. Format recommandé : table-top exercise de 4 heures avec direction, DPO, responsable IA, RSSI et un observateur externe. Le scénario doit être réaliste et inspiré des tendances sectorielles.
Formation continue des équipes. Les équipes techniques connaissent la grille L1-L4. Les équipes métier savent à qui escalader. Le DPO maîtrise les délais RGPD et AI Act. La formation se renouvelle tous les 12 mois.
Test des canaux de notification. Vérification annuelle que le téléservice CNIL est accessible, que le contact de l'autorité de surveillance du marché est à jour, que la cellule de crise est joignable hors heures ouvrées.
Mise à jour post-simulation. Chaque exercice produit un rapport et une liste d'actions correctives. Les écarts détectés sont intégrés dans la version suivante de la procédure dans un délai de 30 jours.
| Type d'exercice | Fréquence | Participants | Livrable |
|---|---|---|---|
| Table-top L4 | Annuel | DG, DPO, RSSI, responsable IA, com | Rapport d'exercice + plan d'action |
| Test technique L3 | Semestriel | Équipe data, RSSI | Rapport technique |
| Drill notification 72 h | Annuel | DPO, juridique | Procès-verbal |
| Revue de procédure | Annuel | Comité IA | Version révisée |
Audit gratuit de votre dispositif d'incident IA
regulia analyse votre procédure existante au regard de l'EU AI Act, du RGPD et d'ISO 42001 et identifie les écarts en moins de 48 heures.
Demander un audit incident IA8. Documentation et amélioration continue
La documentation est ce que regarde un auditeur. Elle est ce que demande la CNIL en cas de contrôle. Elle est ce qui prouve la diligence de la PME en cas de litige civil.
Registre des incidents. Le registre est la pièce maîtresse. Il liste tous les incidents L1 à L4 avec les données minimales du paragraphe 6. Il est conservé pendant 10 ans par cohérence avec l'Article 18 AI Act sur la documentation technique.
Analyse post-incident. Pour tout incident L2 et au-delà, un rapport formalisé documente la cause racine, les facteurs contributifs, les actions correctives et les actions préventives. La méthodologie 5 Whys ou Ishikawa est suffisante pour la majorité des cas.
Mise à jour de la procédure. Chaque incident L3 ou L4 déclenche automatiquement une révision de la procédure dans les 60 jours. La traçabilité des versions est essentielle.
Audit régulier. Audit interne tous les 12 mois. Audit externe tous les 24 à 36 mois si la PME prépare une certification ISO 42001 ou si elle est fournisseur d'un système à haut risque.
Indicateurs de pilotage. Cinq indicateurs minimaux : nombre d'incidents par niveau, délai moyen de détection, délai moyen de notification, taux de respect des SLA L1-L4, nombre d'actions correctives clôturées dans les délais.
| Indicateur | Cible recommandée | Source |
|---|---|---|
| Délai moyen de classification | < 4 heures | Registre |
| Taux de notification CNIL dans 72 h | 100 % | Registre + accusé CNIL |
| Taux de notification AI Act dans 15 j | 100 % | Registre + accusé autorité |
| Incidents L4 par an | Tendance à 0 | Registre |
| Délai moyen de clôture L2 | < 30 jours | Registre |
Pour aller plus loin sur les définitions, consultez le glossaire regulia et la liste consolidée des sources officielles.
FAQ
Qu'est-ce qu'un incident IA selon l'EU AI Act ?
L'Article 3, point 49, du Règlement (UE) 2024/1689 définit l'« incident grave » comme un dysfonctionnement ou une défaillance d'un système d'IA qui entraîne directement ou indirectement un décès, une atteinte grave à la santé, une perturbation grave d'infrastructures critiques, une violation d'obligations relatives aux droits fondamentaux ou un dommage grave aux biens ou à l'environnement. Tous les autres incidents (L1 à L3 dans notre grille) ne sont pas couverts par l'Article 73 mais doivent néanmoins être tracés au titre d'ISO 42001 et du RGPD si des données personnelles sont concernées.
Quelles sont les sanctions pour ne pas gérer les incidents IA ?
L'Article 99 de l'EU AI Act prévoit jusqu'à 35 millions d'euros ou 7 % du chiffre d'affaires annuel mondial pour les pratiques interdites, jusqu'à 15 millions d'euros ou 3 % pour les autres infractions, et jusqu'à 7,5 millions d'euros ou 1 % pour la fourniture d'informations inexactes. L'Article 83 RGPD prévoit en parallèle jusqu'à 20 millions d'euros ou 4 % du CA mondial. Les sanctions sont cumulables.
Comment notifier un incident à la CNIL ?
La notification s'effectue via le téléservice dédié sur cnil.fr, dans les 72 heures suivant la prise de connaissance de la violation. La notification doit décrire la nature de la violation, les catégories et le nombre approximatif de personnes concernées, les conséquences probables, les mesures prises et les coordonnées du DPO. En cas d'impossibilité de fournir toutes les informations en 72 heures, une notification initiale est envoyée et complétée ultérieurement.
Quel est le rôle du DPO dans la gestion des incidents IA ?
Le DPO valide la classification de tout incident à partir de L2, supervise la notification à la CNIL pour les incidents impliquant des données personnelles, conseille sur la communication aux personnes concernées (Article 34 RGPD), et participe aux exercices de simulation. Il est également garant de la cohérence entre le registre des incidents et le registre des traitements (Article 30 RGPD).
Comment tester la procédure de gestion des incidents IA ?
Au minimum un exercice annuel de simulation L3 ou L4 sous forme de table-top, un drill semestriel de notification 72 heures, et une revue annuelle de la procédure. Les scénarios sont inspirés d'incidents réels du secteur et impliquent direction, DPO, RSSI, responsable IA et communication. Chaque exercice produit un rapport et un plan d'action correctif clôturé sous 30 jours.
Sources officielles
- Règlement (UE) 2024/1689 — texte consolidé
- Règlement (UE) 2024/1689 — version officielle EUR-Lex
- CNIL — fiches pratiques IA et notification de violations
- AI Act Service Desk — Commission européenne
- ISO/IEC 42001:2023 — Systèmes de management de l'IA (norme officielle, accès payant via iso.org)
- ISO/IEC 23894:2023 — Gestion du risque appliquée à l'IA
Cet article fournit des informations générales sur l'EU AI Act applicables aux PME françaises. Il ne constitue pas un conseil juridique. Pour toute décision opérationnelle, faites valider votre démarche par votre DPO ou conseil juridique. regulia décline toute responsabilité quant à l'usage qui peut être fait de ces informations.