Incidents graves impliquant un système d'IA : détecter, qualifier et notifier (article 73 de l'AI Act) — le guide RSSI 2026

En une phrase : un incident grave impliquant un système d'IA doit être déclaré en 15, 10 ou 2 jours selon sa catégorie — et le compte à rebours ne démarre pas à l'incident, mais au moment où vous établissez le lien entre votre système et le préjudice.

Ce guide ne commente pas l'article 73 de l'AI Act. Il vous dit comment détecter, qualifier et notifier un incident d'IA, comment l'articuler avec le RGPD, NIS2 et DORA, et pourquoi la préparation ne peut pas attendre décembre 2027.

Il traite la réponse à l'incident. La prévention — durcissement, injection de prompt, recommandations de l'ANSSI — est l'objet de notre guide sur la sécurité des IA génératives. Les deux sont complémentaires : la prévention réduit la fréquence, la réponse borne l'impact et le risque juridique.

Introduction : le jour où votre IA « tombe »

Un modèle de scoring crédit refuse soudain 30 % de dossiers de plus qu'hier, tous dans le même quartier. Un chatbot RH conseille à une candidate enceinte de « réfléchir à sa disponibilité ». Un assistant de diagnostic passe à côté d'une série d'anomalies après une mise à jour. Un système de vidéoanalyse identifie la mauvaise personne.

Dans chacun de ces cas, une même question tombe sur le bureau du RSSI : est-ce un « incident grave » au sens de l'AI Act ? Ai-je 2 jours, 10 jours, 15 jours — ou dois-je aussi prévenir la CNIL sous 72 heures ?

La plupart des organisations françaises n'ont pas de réponse. Elles ont un plan de réponse aux incidents cyber, souvent branché sur NIS2 ou DORA, un registre RGPD, parfois un SOC. Mais l'incident d'IA est un objet nouveau : il n'est ni purement cyber — le système n'est pas piraté, il dérive — ni purement « données », puisque le préjudice peut être une atteinte aux droits fondamentaux sans la moindre fuite. L'article 73 crée une obligation de notification autonome, avec ses propres délais, sa propre définition et sa propre autorité destinataire.

1. Ce que disent exactement les articles 72 et 73

L'AI Act traite l'incident en deux temps indissociables.

L'article 72 — la surveillance après commercialisation. Le fournisseur d'un système à haut risque doit collecter et analyser en continu, sur la base d'un plan documenté, les données de performance et de sécurité de son système pendant toute sa vie. C'est le capteur : sans surveillance post-marché, on ne voit pas l'incident, donc on ne le déclare pas.

L'article 73 — la déclaration des incidents graves. Dès qu'un fournisseur établit un lien de causalité — ou sa probabilité raisonnable — entre son système d'IA et un incident grave, il le déclare aux autorités de surveillance du marché de l'État membre concerné, puis mène une enquête, réalise une évaluation des risques de l'incident et prend des mesures correctives.

Deux acteurs sont visés en pratique :

• le fournisseur, qui développe et met sur le marché le système, porte l'obligation de déclaration ;
• le déployeur, l'organisation qui utilise le système, a un rôle décisif : c'est presque toujours lui qui constate l'incident sur le terrain. L'article 26 lui imposera d'informer sans délai le fournisseur, et le cas échéant l'autorité — obligation reportée au 2 décembre 2027 avec le reste de l'annexe III, mais que rien n'empêche d'appliquer dès maintenant : c'est le seul moyen que le fournisseur déclare dans les délais.

*En pratique, pour une PME, une ETI ou une collectivité qui utilise de l'IA sans la fabriquer, la première obligation opérationnelle est simple : remonter l'incident au fournisseur immédiatement — et le tracer.*

2. Qu'est-ce qu'un « incident grave » ? La grille en 4 catégories

Un incident grave est un incident ou un dysfonctionnement d'un système d'IA qui entraîne, directement ou indirectement, l'un des quatre types de préjudice suivants :

1. le décès d'une personne ou une atteinte grave à sa santé ;

2. une perturbation grave et irréversible de la gestion ou de l'exploitation d'infrastructures critiques ;

3. la violation d'obligations du droit de l'Union visant à protéger les droits fondamentaux ;

4. une atteinte grave à des biens ou à l'environnement.

Trois pièges de qualification méritent d'être connus avant l'incident, pas pendant.

« Directement ou indirectement ». Le lien n'a pas besoin d'être immédiat. Un biais algorithmique qui prive systématiquement une population d'un droit compte, même sans « bug » technique visible.

La catégorie 3 est la plus large et la plus sous-estimée. Discrimination à l'embauche par un outil RH, refus de prestation sociale par un système public, atteinte à la vie privée : ce sont des incidents graves sans fuite de données ni panne. C'est le point aveugle numéro un des RSSI habitués au prisme cyber.

Ni la cyberattaque ni la panne ne sont automatiquement des incidents graves — mais elles le deviennent dès qu'elles produisent l'un des quatre préjudices. L'indisponibilité d'un système d'IA de tri des urgences hospitalières bascule vite en catégorie 1 ou 2.

3. Les délais : 15 jours, 10 jours, 2 jours

L'article 73 impose une notification sans retard injustifié, et au plus tard :

Le point de départ n'est pas la date de l'incident, mais la date à laquelle vous prenez connaissance du lien de causalité, ou de sa probabilité raisonnable.

Corollaire opérationnel, et il est plus important que tout le reste : votre capacité à dater précisément la prise de connaissance est votre meilleure défense. Elle suppose un registre d'incidents horodaté, tenu avant l'incident, pas reconstitué après.

En cas d'urgence, une déclaration initiale incomplète est admise, à compléter après enquête. Mieux vaut déclarer à temps et compléter que rater le délai.

4. À qui déclare-t-on ?

Systèmes à haut risque. Déclaration à l'autorité de surveillance du marché de l'État membre où l'incident s'est produit. En France, l'écosystème d'autorités se met en place autour de la coordination nationale prévue par l'AI Act ; la désignation officielle est à suivre, la CNIL et l'ANSSI y jouant un rôle central.

Modèles d'IA à usage général à risque systémique. Déclaration à l'AI Office, le Bureau de l'IA de la Commission — et cette obligation-là est en vigueur depuis le 2 août 2025, avec le chapitre V de l'AI Act. La Commission a publié un modèle de déclaration dédié en novembre 2025. Ce qui a changé le 2 août 2026, ce n'est pas l'obligation : ce sont les pouvoirs d'exécution de la Commission et les amendes qui vont avec.

Volet données personnelles. Si l'incident implique une violation de données à caractère personnel, notification à la CNIL sous 72 heures (article 33 du RGPD), et information des personnes en cas de risque élevé (article 34).

Volet cyber sectoriel. NIS2 impose aux entités essentielles et importantes une alerte précoce sous 24 heures. DORA impose au secteur financier une notification initiale d'incident majeur sous 4 heures après classification. Ces deux régimes s'appliquent déjà.

Le guichet unique : ce qui est proposé, et ce qui n'est pas encore droit

Un point d'entrée unique, confié à l'ENISA et adossé à la plateforme du règlement sur la cyberrésilience, doit permettre de router une seule déclaration vers les régimes applicables : RGPD, NIS2, DORA, CER et eIDAS. Une simplification des notifications est proposée dans le même mouvement.

Attention à ne pas s'en prévaloir trop tôt. Le paquet Digital Omnibus a deux volets : le volet IA est adopté et en vigueur depuis le 27 juillet 2026 ; le volet données, celui qui porte précisément le guichet unique, est encore en négociation et n'est pas attendu avant la fin 2026 au plus tôt. Aujourd'hui, les canaux restent séparés — et c'est sur cette base qu'il faut construire.

5. Pourquoi « c'est reporté à 2027 » est un faux ami

L'obligation formelle de l'article 73 pour les systèmes à haut risque de l'annexe III s'applique au 2 décembre 2027, alignée sur le report des obligations haut risque décidé par le Digital Omnibus sur l'IA. S'en remettre à cette date est pourtant une erreur de RSSI, pour quatre raisons.

Les obligations connexes sont déjà en vigueur. RGPD 72 heures, NIS2 24 heures, DORA 4 heures : la quasi-totalité des incidents d'IA « qui comptent » tombent aussi sous l'un de ces régimes. Le report de l'AI Act n'en suspend aucun.

Le GPAI à risque systémique déclare depuis le 2 août 2025. Si vous fournissez ou affinez un grand modèle au-delà des seuils, vous êtes dedans depuis un an, et l'exécution est ouverte depuis le 2 août 2026.

La méthode est déjà publique. La Commission a mis en consultation, le 26 septembre 2025, un projet de lignes directrices et un modèle de déclaration pour les incidents graves de l'article 73. La version définitive est attendue ; le projet, lui, est lisible aujourd'hui et décrit déjà la qualification, les délais et le contenu attendu d'une déclaration. Rien n'oblige à attendre le texte final pour s'organiser sur cette base.

On ne construit pas une chaîne de 2 jours pendant la crise. Détecter, qualifier, mobiliser le fournisseur, l'autorité, le DPO, la direction, rédiger une déclaration recevable : c'est un processus à répéter à froid. Le monter en décembre 2027 sous la pression d'un premier incident, c'est le rater.

La vraie question n'est donc pas « quand ? » mais « suis-je capable, aujourd'hui, de qualifier un incident d'IA et de déclencher la bonne notification dans les temps ? » Pour la plupart, la réponse est non.

6. Le prérequis que personne ne mentionne : sans inventaire, pas de qualification

Vous ne pouvez pas qualifier un incident sur un système que vous ne savez pas exploiter. Tenir l'article 73 suppose, au préalable :

• un registre des systèmes d'IA qui indique, pour chacun : finalité, classification au regard de l'AI Act, fournisseur, déployeur interne, données traitées, criticité, autorité compétente ;
• une pré-qualification du préjudice possible par système : lesquels peuvent produire l'une des quatre catégories ?
• une pré-cartographie des délais et des destinataires par système : celui-ci, 2 jours plus CNIL sous 72 heures ; celui-là, 15 jours.

Autrement dit, la préparation à l'incident grave est une sortie directe de la cartographie et de la gouvernance de l'IA. C'est aussi la raison pour laquelle SiyadAI relie inventaire, classification et registre d'incidents dans un même graphe.

7. Le playbook RSSI en 7 étapes

1 — Détecter. Instrumentez la surveillance post-marché : métriques de performance et de dérive, seuils d'alerte, journaux. Doublez-la d'une boucle de remontée humaine — support, métiers, utilisateurs. Un incident d'IA se voit autant dans une plainte RH que dans une courbe.

2 — Recevoir et horodater. Un point d'entrée interne unique pour tout signalement de comportement anormal d'une IA. Horodatez la réception : c'est le futur point de départ de vos délais, et la seule chose que vous pourrez produire si on vous reproche un retard.

3 — Qualifier. Trois questions dans l'ordre. Un système d'IA est-il en cause ? Y a-t-il l'un des quatre préjudices graves, direct ou indirect ? Le lien de causalité est-il établi ou raisonnablement probable ? Si oui, déterminez la catégorie — elle fixe le délai.

4 — Déclencher les notifications en parallèle. Ouvrez d'un seul geste tous les canaux applicables : autorité de surveillance du marché, AI Office si un modèle GPAI est en cause, CNIL sous 72 heures si des données personnelles sont touchées, NIS2 sous 24 heures ou DORA sous 4 heures selon le secteur. Ne traitez jamais ces délais en série : le plus court gouverne.

5 — Informer le fournisseur. Si vous êtes déployeur, notification sans délai au fournisseur du système. Conservez la preuve d'envoi.

6 — Enquêter et corriger. Évaluation des risques de l'incident, mesures correctives — retour arrière, désactivation, recalibrage, mesures compensatoires pour les personnes affectées — puis déclaration complémentaire à l'autorité.

7 — Clôturer et capitaliser. Consignez tout dans le registre d'incidents : chronologie, qualification, notifications, mesures, enseignements. Ce registre est votre preuve de conformité et votre mémoire de gouvernance.

8. Rôles : qui fait quoi

L'incident d'IA est transverse, et c'est ce qui le rend lent quand rien n'a été préparé. Le RSSI pilote la détection et la coordination. Le DPO gère le volet RGPD et l'appréciation « droits fondamentaux ». La DSI exécute les mesures techniques. Le métier propriétaire du système fournit le contexte et le lien de causalité. La direction juridique valide la qualification. La direction générale assume la décision de notifier.

Sans comité IA et sans rôles pré-attribués, la seule qualification prend plusieurs jours — et le délai de 2 jours est perdu avant d'avoir commencé.

9. Sanctions : ce que coûte le silence

Le manquement aux obligations des fournisseurs et des déployeurs, dont l'article 73, expose à des amendes administratives pouvant atteindre 15 000 000 € ou 3 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. S'y ajoutent, selon le cas, les sanctions RGPD — jusqu'à 20 M€ ou 4 % — pour un défaut de notification de violation, et les régimes NIS2 et DORA.

La sanction financière n'est pourtant pas le pire. Un incident grave non notifié qui remonte par un tiers — un média, une personne lésée, une autorité — détruit une confiance qui ne se reconstitue pas : celle des clients, des administrations et des assureurs cyber.

10. Conclusion : préparez la crise à froid

L'article 73 ne récompense pas ceux qui connaissent le texte, mais ceux qui savent l'exécuter sous pression. La différence se joue avant l'incident : un inventaire à jour, une grille de qualification partagée, des délais et des autorités pré-mappés, un registre d'incidents prêt, des rôles attribués.

C'est un exercice de gouvernance, pas de veille juridique.

Vous ne savez pas, aujourd'hui, lesquels de vos systèmes d'IA vous mettraient en compte à rebours de 2 jours ? C'est exactement le point de départ.

Contenu informatif, ne constitue pas un conseil juridique. La couche datée — statut définitif des lignes directrices de la Commission, désignation des autorités françaises de surveillance du marché, sort du volet « données » du Digital Omnibus — doit être revérifiée à chaque évolution. La couche méthode — quatre préjudices, trois délais, playbook en sept étapes, articulation multi-régimes — reste valable indépendamment.