L’essentiel
- Un incident IA désigne tout événement où la conception, le déploiement ou la défaillance d’un système d’IA provoque, directement ou indirectement, un dommage réel. La notion dépasse le simple bug logiciel comme l’accident du travail.
- L’article 73 du règlement IA impose aux fournisseurs de systèmes d’IA à haut risque de signaler les incidents graves aux autorités de surveillance du marché. L’obligation s’applique à partir du 2 août 2026.
- Les délais sont courts et différenciés : 2 jours en cas d’atteinte de grande ampleur ou de perturbation grave d’une infrastructure critique, 10 jours en cas de décès, 15 jours pour les autres incidents graves.
- L’incident grave est défini à l’article 3, point 49 : décès ou atteinte grave à la santé, perturbation grave et irréversible d’une infrastructure critique, violation d’obligations de protection des droits fondamentaux, ou dommage grave aux biens ou à l’environnement.
- Le signalement des incidents IA ne tient que s’il repose sur un processus interne reproductible : détecter, qualifier, décider de la déclarabilité, notifier dans les temps, puis enquêter et remédier.
Qu’est-ce que le signalement d’incident, et qu’a de particulier un incident IA
Le signalement d’incident consiste à consigner un événement inattendu afin de comprendre ce qui s’est produit, de limiter les dégâts et d’éviter la récidive. En santé, en sécurité au travail ou en gestion des services informatiques, la pratique est rodée : un presque-accident, une blessure ou une panne se consigne sur un formulaire normalisé, et la trace alimente l’enquête puis l’action corrective. L’IA déplace le problème, et c’est précisément là que le signalement des incidents IA se distingue de sa version générique. Le préjudice causé par un système d’IA est souvent indirect. Le modèle ne renverse personne et ne déverse aucun produit ; il produit une sortie sur laquelle une personne ou un autre système agit, et le dommage apparaît en aval. Une suggestion de triage médical erronée, un refus de crédit biaisé ou une défaillance de modération peuvent causer un préjudice sérieux sans panne visible. La chaîne entre la cause et la conséquence est longue, statistique et difficile à imputer. C’est pourquoi régulateurs et organismes de normalisation ont forgé des définitions propres à l’IA. Dans son rapport de 2024 Defining AI Incidents and Related Terms, l’OCDE pose la taxonomie de référence : un incident IA est un événement où le développement, l’usage ou la défaillance d’un système d’IA conduit, directement ou indirectement, à un dommage (atteinte aux personnes, perturbation d’infrastructure critique, violation des droits humains, atteinte aux biens ou à l’environnement). L’OCDE sépare le danger IA, simple circonstance susceptible de mener à un incident, de l’incident IA, où le dommage survient réellement, et ajoute la catastrophe IA, un incident grave qui désorganise une collectivité. Ces nuances déterminent ce que l’organisation doit surveiller, consigner et, parfois, déclarer. Elles structurent aussi la manière dont AI Sigil aborde la gestion des risques liés à l’IA.
L’obligation du règlement IA : le signalement des incidents graves à l’article 73
Pour qui opère sur le marché de l’Union ou y vend ses produits, la bonne pratique devient une obligation légale. Le mécanisme est l’article 73 du règlement IA, colonne vertébrale de toute démarche de conformité au règlement IA pour les systèmes à haut risque.
Qui doit signaler, et à qui
Le texte est sans détour : les fournisseurs de systèmes d’IA à haut risque mis sur le marché de l’Union signalent tout incident grave aux autorités de surveillance du marché de l’État membre où l’incident s’est produit (règlement IA, article 73). Le déployeur n’est pas spectateur : lorsqu’il a connaissance d’un incident grave, l’obligation le conduit à informer le fournisseur et, dans les cas prévus, l’autorité. En France, la CNIL et l’ANSSI occupent une place centrale dans le dispositif national de supervision.
Ce qui constitue un incident grave
Le déclencheur est la définition de l’article 3, point 49. Un incident grave est un incident ou un dysfonctionnement qui entraîne, directement ou indirectement, l’une de quatre conséquences : le décès d’une personne ou une atteinte grave à sa santé ; une perturbation grave et irréversible de la gestion ou de l’exploitation d’une infrastructure critique ; une violation des obligations du droit de l’Union visant à protéger les droits fondamentaux ; ou un dommage grave aux biens ou à l’environnement. À défaut, l’événement peut mériter une consignation interne sans pour autant être un incident grave déclarable.
Les délais de signalement
L’article 73 fixe une horloge à plusieurs vitesses, et elle tourne vite.
- 2 jours : atteinte de grande ampleur, ou perturbation grave et irréversible d’une infrastructure critique.
- 10 jours : décès d’une personne.
- 15 jours : tous les autres incidents graves.
La règle de base relie le tout : le fournisseur signale immédiatement après avoir établi un lien de causalité, ou la probabilité raisonnable d’un tel lien, entre le système d’IA et l’incident, et en tout état de cause au plus tard 15 jours après en avoir eu connaissance. Comme ces fenêtres sont étroites, le règlement autorise un signalement initial incomplet, suivi d’un rapport complet une fois les faits clarifiés.
Après le signalement
Le signalement n’est pas un point final. À la suite d’un incident grave, le fournisseur mène sans délai les investigations nécessaires, y compris une évaluation des risques de l’incident, et prend des mesures correctives. L’autorité de surveillance du marché dispose alors de sept jours pour prendre les mesures appropriées.
Quand l’horloge démarre, et les lignes directrices de septembre 2025
La question opérationnelle la plus délicate est de savoir quand le délai commence. L’obligation tient à la connaissance et au lien de causalité : le délai court dès l’instant où le fournisseur établit, ou pourrait raisonnablement établir, un lien entre le système d’IA et le dommage. En septembre 2025, la Commission européenne a publié un projet de lignes directrices et un modèle de déclaration pour rendre l’exercice praticable. Le projet, diffusé le 26 septembre 2025 et ouvert à consultation jusqu’au 7 novembre 2025, précise qu’un lien de causalité indirect suffit, à l’appui d’exemples comme une analyse médicale erronée à l’origine d’un dommage ultérieur ou une évaluation de crédit défaillante (Latham & Watkins, 2025). Le projet traite aussi du chevauchement avec les règles sectorielles : pour un opérateur d’infrastructure critique déjà soumis à NIS2, seul un incident touchant aux droits fondamentaux appelle une déclaration distincte au titre de l’article 73, les autres suivant le canal sectoriel. L’obligation s’applique à partir du 2 août 2026, date d’entrée en vigueur des règles applicables aux systèmes à haut risque. Repousser la conception du processus jusque-là, c’est devoir le bâtir dans l’urgence, pendant un incident réel.
Incidents des modèles à usage général et risque systémique
Les systèmes à haut risque ne sont pas seuls concernés. Les fournisseurs de modèles d’IA à usage général présentant un risque systémique portent leurs propres obligations au titre de l’article 55 : suivre, documenter et signaler les incidents graves au Bureau de l’IA, accompagnés des mesures correctives envisageables. Le code de bonnes pratiques pour les modèles à usage général, dont le chapitre Sûreté et sécurité a été finalisé en juillet 2025, traduit ce devoir en engagements concrets : tenir un suivi des incidents graves, transmettre les informations utiles au Bureau de l’IA et aux autorités nationales selon des délais définis, et conserver la documentation nécessaire à l’analyse a posteriori. Pour les plus grands fournisseurs de modèles, le signalement des incidents IA devient une obligation de surveillance continue plutôt qu’une déclaration ponctuelle. AI Sigil l’intègre à une plateforme de gouvernance de l’IA unique plutôt qu’à un silo séparé.
Où le signalement s’inscrit dans les normes : NIST et ISO
La réglementation pose le socle. Les normes volontaires fournissent le mode opératoire. Le cadre de gestion des risques liés à l’IA du NIST organise le travail autour de quatre fonctions : Gouverner, Cartographier, Mesurer et Gérer. La réponse aux incidents relève surtout de la fonction Gérer, qui appelle une surveillance post-déploiement, des dispositifs de remontée et de traitement des problèmes, et une réponse aux incidents, une reprise et une gestion du changement documentées. La fonction Gouverner ajoute les politiques et la responsabilité qui empêchent ces dispositifs de tomber en désuétude. La norme ISO/IEC 42001, relative au système de management de l’IA, place la gestion des incidents dans un cycle certifiable Planifier-Déployer-Contrôler-Agir. L’organisation qui exploite un système 42001 maintient un processus défini de traitement des incidents IA, le relie au traitement des risques et prouve à l’auditeur que la boucle se referme. Pour une équipe déjà certifiée ISO/IEC 27001, le processus d’incident IA peut s’articuler avec le processus d’incident de sécurité existant au lieu de le concurrencer.
Bâtir un processus interne de signalement des incidents IA
Une obligation de signalement ne vaut que par le processus qui la porte. Un processus de signalement des incidents IA opérationnel comporte quatre étapes, chacune avec un responsable nommé.
Détecter et réceptionner
La plupart des incidents IA sont d’abord repérés par un utilisateur, un agent de support ou un système en aval, non par un tableau de bord. Offrez à chaque canal un point de réception unique : un formulaire, une file ou une ligne dédiée, ouvert à tous sans présumer du caractère déclarable. Saisissez l’essentiel dès la réception (ce qui s’est passé, quel système, quand, quel dommage observé) pour que les faits utiles au calcul du délai existent dès la première minute.
Qualifier et décider de la déclarabilité
C’est la décision dont dépendent les délais. Confrontez chaque signalement au test de l’article 3, point 49 : l’événement a-t-il entraîné, directement ou indirectement, un décès ou une atteinte grave à la santé, une perturbation d’infrastructure critique, une violation des droits fondamentaux, ou un dommage grave aux biens ou à l’environnement ? Un arbre de décision court, confié à un rôle nommé, garantit une qualification cohérente et tracée. Consignez le raisonnement même lorsque la réponse est non, car cette trace est la défense de l’organisation si la décision est plus tard contestée.
Notifier dans le délai
Une fois l’événement qualifié d’incident grave, l’horloge différenciée s’applique. Identifiez l’autorité de surveillance du marché compétente, préparez la déclaration sur le modèle de la Commission et transmettez dans les 2, 10 ou 15 jours selon la catégorie. Privilégiez le signalement initial incomplet plutôt que le dépassement du délai.
Enquêter, remédier et journaliser
Après la transmission, recherchez la cause racine, menez l’évaluation des risques exigée par l’article 73 et prenez les mesures correctives. Journalisez le tout dans un registre qui relie l’incident au système, à la version du modèle, aux utilisateurs touchés et à la remédiation. Des bases externes comme l’AI Incident Database (AIID), le répertoire AIAAIC et l’Observatoire des incidents de l’IA de l’OCDE servent de points de repère pour apprendre des incidents du secteur, un travail que le CSET a passé en revue dans sa note de janvier 2025.
En quoi le signalement des incidents IA diffère des autres régimes
Un même événement peut déclencher plusieurs obligations à la fois. Une fuite de données dans un système d’IA peut être une violation de données à caractère personnel au sens du RGPD, avec sa notification sous 72 heures à l’autorité de contrôle au titre de l’article 33, un incident grave au sens de l’article 73 et, pour une entité financière, une déclaration d’incident TIC au titre de DORA. NIS2 ajoute des obligations pour les entités essentielles et importantes, et les règles sectorielles (dispositifs médicaux, aviation, services financiers) en ajoutent d’autres. La leçon pratique : cartographier ses obligations de signalement une fois, à l’avance, et concevoir un point de réception unique capable d’irriguer les bons régimes. L’équipe qui traite le signalement des incidents IA comme une tâche isolée du règlement IA finira par déclarer le même événement trois fois, sous trois formats et trois horloges, ou pire, en oubliera une. Centraliser la cartographie des obligations est précisément ce que permet une plateforme de gouvernance de l’IA.
Questions fréquentes
Qu’est-ce que le signalement des incidents IA ? Le signalement des incidents IA est le processus structuré qui consiste à détecter, documenter et, lorsque la loi l’exige, notifier aux autorités les événements où un système d’IA cause ou favorise un dommage. Au titre du règlement IA, c’est une obligation légale pour les fournisseurs de systèmes à haut risque et de certains modèles à usage général, pas seulement une bonne pratique interne. Quelles sont les étapes du signalement d’un incident IA ? Détecter et consigner l’événement à un point de réception unique ; le qualifier au regard de la définition de l’incident grave de l’article 3, point 49 ; s’il est éligible, notifier l’autorité de surveillance du marché compétente dans le délai applicable ; puis rechercher la cause racine, évaluer les risques et prendre des mesures correctives. Conservez une trace écrite à chaque étape, y compris du raisonnement pour les événements non déclarés. Que contient un rapport d’incident IA ? Au minimum : une description des faits, le système d’IA et la version du modèle en cause, la date de prise de connaissance, le type et la gravité du dommage, les personnes ou biens touchés, le lien de causalité présumé et les mesures correctives prises ou prévues. Le modèle de déclaration de la Commission au titre de l’article 73 structure ces champs. Qu’est-ce qu’un incident grave au sens du règlement IA ? L’article 3, point 49, le définit comme un incident ou un dysfonctionnement qui entraîne, directement ou indirectement, le décès d’une personne ou une atteinte grave à sa santé, une perturbation grave et irréversible d’une infrastructure critique, une violation des obligations de protection des droits fondamentaux du droit de l’Union, ou un dommage grave aux biens ou à l’environnement. Quand l’article 73 s’applique-t-il, et sous quel délai signaler ? L’obligation s’applique à partir du 2 août 2026. Les délais courent dès que l’organisation a connaissance de l’incident et peut établir un lien de causalité : 2 jours pour une atteinte de grande ampleur ou une perturbation grave d’infrastructure critique, 10 jours en cas de décès, 15 jours pour les autres incidents graves. En quoi cela diffère-t-il d’une notification de violation de données ? Une violation au sens du RGPD concerne les données personnelles et impose une notification sous 72 heures. Un incident grave au sens du règlement IA concerne le dommage causé par le système d’IA lui-même, sur l’horloge de 2, 10 ou 15 jours. Le même événement peut déclencher les deux, plus des régimes sectoriels comme NIS2 ou DORA : mieux vaut cartographier ces devoirs ensemble.
Conclusion
Le signalement des incidents IA passe du réflexe de culture sécurité à l’obligation légale ferme, assortie de délais courts et de responsabilités nommées. Les organisations qui l’aborderont sereinement sont celles qui décident dès maintenant qui détient la réception, comment se qualifie un incident grave et quelle autorité notifier dans quelle fenêtre. Le travail à mener avant le 2 août 2026 n’est pas seulement d’interprétation juridique : c’est le processus permanent qui transforme l’article 73 en routine maîtrisée. AI Sigil aide les équipes des secteurs réglementés à convertir ce type d’obligation en processus vivants et auditables au sein d’un même système de gouvernance.