Signalement d'incidents sous l'AI Act : ce qu'exige l'Article 73

Lorsqu'un système d'IA à haut risque dysfonctionne sur le terrain, l'AI Act ne vous laisse pas le temps de tergiverser. L'article 73 établit un régime de signalement précis, soumis à des délais stricts. Les fournisseurs qui ne respectent pas ces obligations s'exposent à des amendes pouvant atteindre 15 millions d'euros ou 3 % du chiffre d'affaires mondial, selon le montant le plus élevé. Cet article décortique chaque obligation, chaque délai et chaque élément de rapport que vous devez avoir en place avant qu'un incident ne survienne.

Qu'est-ce qu'un « incident grave » ? La définition légale

Le point de départ est l'article 3(49) du règlement, qui définit un incident grave comme :

« tout incident ou dysfonctionnement d'un système d'IA qui entraîne, directement ou indirectement, l'une des conséquences suivantes : (a) le décès d'une personne ou un préjudice grave pour la santé d'une personne ; (b) une perturbation grave et irréversible de la gestion ou du fonctionnement d'une infrastructure critique ; (c) une violation des obligations prévues par le droit de l'Union destinées à protéger les droits fondamentaux ; (d) un préjudice grave pour les biens ou l'environnement. »

Trois éléments méritent une attention particulière :

« Directement ou indirectement » — La chaîne causale n'a pas besoin d'être immédiate. Si un système d'IA produit une recommandation qu'un clinicien suit, et que cette recommandation entraîne un préjudice pour le patient, l'incident est qualifié même si une décision humaine s'est interposée.

« Préjudice grave pour la santé » — Le règlement ne définit pas de seuil de gravité chiffré. En pratique, les autorités de surveillance et les organismes notifiés considèrent comme présumément grave tout préjudice nécessitant une hospitalisation ou causant une incapacité permanente.

« Violation des droits fondamentaux » — Cette définition va bien au-delà du préjudice physique. Un système de catégorisation biométrique qui discrimine systématiquement un groupe protégé peut déclencher les obligations de l'article 73, même sans blessure physique.

Incident grave vs quasi-incident

L'article 73 couvre les incidents graves et les dysfonctionnements qui auraient pu conduire à un incident grave (quasi-incidents) pour les systèmes d'IA destinés à des composants de sécurité. Si votre plan de surveillance post-commercialisation (PMM, régi par l'article 72) détecte un quasi-incident, l'obligation est de le consigner en interne et d'évaluer s'il atteint le seuil justifiant un signalement externe. Un quasi-incident révélant un défaut systémique du modèle d'IA franchit vraisemblablement ce seuil ; une anomalie ponctuelle interceptée et corrigée par la supervision humaine peut ne pas l'atteindre.

Qui doit signaler — et à qui

L'obligation de signalement prévue à l'article 73(1) incombe aux fournisseurs de systèmes d'IA à haut risque mis sur le marché de l'Union. Les déployeurs ne sont pas les déclarants principaux, mais l'article 73(6) leur impose d'informer le fournisseur sans délai dès qu'ils ont connaissance d'un incident grave. C'est ensuite le fournisseur qui déclenche la notification officielle.

L'autorité à notifier est l'autorité de surveillance du marché (ASM) de l'État membre où l'incident s'est produit. Si l'incident touche des utilisateurs dans plusieurs États membres, le fournisseur notifie l'ASM de chaque juridiction concernée. Le Bureau de l'IA joue un rôle de coordination pour les modèles GPAI impliqués dans des incidents graves, mais pour les systèmes d'IA à haut risque relevant de l'Annexe III, l'ASM est l'interlocuteur principal.

Les délais — strictement appliqués

L'article 73(3) établit des délais échelonnés :

Situation	Délai
Incident grave (standard)	15 jours calendaires à compter de la prise de connaissance
Incident impliquant un risque vital ou un préjudice irréversible	2 jours calendaires à compter de la prise de connaissance
Décès confirmé après le rapport initial	Immédiatement après confirmation

La « prise de connaissance » correspond au moment où les systèmes internes du fournisseur — y compris le PMM — détectent ou sont informés de l'incident. Les fournisseurs ne peuvent pas réinitialiser le compteur en prétextant avoir besoin de temps pour enquêter avant d'être officiellement « informés ». Si le PMM signale une anomalie et qu'un examen ultérieur confirme son caractère grave, le délai de 15 jours court généralement à partir du signal initial, non de la confirmation.

Pour le délai de 2 jours, vous avez besoin d'une procédure d'escalade qui contourne les circuits d'approbation habituels. Cela implique une personne désignée habilitée à déposer le rapport, un accès 24h/24 au portail de notification de l'ASM et un modèle pré-rempli prêt à l'emploi.

Contenu obligatoire du rapport

L'article 73(3) et les actes d'exécution de la Commission spécifient le contenu minimal suivant :

Identité du fournisseur — dénomination sociale, numéro d'immatriculation, coordonnées de la personne responsable désignée au titre de l'article 22 ou de l'article 25.
Description du système d'IA — nom, version, numéro d'enregistrement dans la base de données UE (article 71).
Description de l'incident — date, lieu, personnes concernées, nature du préjudice ou du risque.
Analyse causale — évaluation préliminaire de la cause profonde, même incomplète au moment du dépôt.
Mesures correctives prises ou prévues — notamment si le système a été retiré du déploiement, son utilisation restreinte ou un correctif logiciel émis.
Référence au PMM — l'article 72 impose aux fournisseurs de maintenir un PMM proportionné au niveau de risque ; le rapport d'incident doit préciser comment le système de surveillance a détecté (ou non) l'événement.
Implication de tiers — si un organisme notifié, un déployeur ou un représentant autorisé dans l'UE était impliqué.
Plan de suivi — calendrier pour une analyse complète des causes profondes et un rapport final.

Le rapport initial peut être préliminaire. Un rapport de suivi complet doit être soumis à l'issue de l'enquête — généralement dans les 30 jours pour les incidents standard.

Le lien avec la surveillance post-commercialisation (Article 72)

Le signalement des incidents et la surveillance post-commercialisation ne sont pas des systèmes parallèles — ils sont intégrés. L'article 72 impose aux fournisseurs de collecter, documenter et analyser les données issues des systèmes déployés de manière continue. Cette infrastructure de surveillance est ce qui génère les alertes déclenchant le signalement au titre de l'article 73.

Concrètement, votre PMM doit inclure :

Des seuils de détection automatique des anomalies alignés sur la définition de l'incident grave
Une procédure d'escalade documentée précisant qui examine les alertes et dans quel délai
Des journaux d'audit capturant le moment où une anomalie a été signalée pour la première fois (essentiel pour établir l'horloge de « prise de connaissance »)
Un canal de retour d'information des déployeurs, puisque l'article 73(6) les oblige à vous notifier

Si votre PMM est un tableur mis à jour trimestriellement, il n'est pas adapté. Les ASM examinant la conformité après un incident vérifieront si l'infrastructure de surveillance était suffisante pour détecter l'incident en temps utile.

Modèle minimal de rapport d'incident

La structure suivante satisfait aux exigences de contenu de l'article 73 pour une notification initiale :

NOTIFICATION D'INCIDENT GRAVE — [NOM DU FOURNISSEUR]
Date de notification : [JJ/MM/AAAA]
Numéro de référence : [identifiant de suivi interne]

1. FOURNISSEUR
   Dénomination sociale, adresse, numéro d'enregistrement dans la base de données UE

2. SYSTÈME D'IA
   Nom, version, destination d'usage, catégorie Annexe III

3. DESCRIPTION DE L'INCIDENT
   Date/heure de survenance :
   Lieu (État membre, secteur) :
   Nature du préjudice (décès / atteinte à la santé / droits fondamentaux / biens) :
   Nombre de personnes concernées :

4. CAUSE PRÉLIMINAIRE
   [Évaluation technique et opérationnelle brève — « inconnue » est acceptable
   au stade initial mais doit être mise à jour]

5. MESURES CORRECTIVES IMMÉDIATES
   Système suspendu : Oui / Non
   Utilisation restreinte : Oui / Non
   Correctif déployé : Oui / Non / Prévu [date]

6. RÉFÉRENCE AU PMM
   Comment l'incident a-t-il été détecté ? [Alerte PMM / notification du déployeur / médias / autre]
   Date du premier signal de détection : [JJ/MM/AAAA]

7. CALENDRIER DE SUIVI
   Analyse complète des causes profondes attendue : [date]
   Soumission du rapport final prévue : [date]

8. PERSONNE DE CONTACT
   Nom, titre, téléphone, courriel (disponible 24h/24 pendant l'enquête)

Intégrez ce modèle dans votre système de management de la qualité (SMQ) et testez-le lors d'un exercice sur table avant le déploiement. Le délai de deux jours pour les incidents à risque vital ne laisse aucune marge pour rédiger sous pression.

Lacunes fréquentes dans les programmes de signalement

Absence de protocole de prise de connaissance. Les fournisseurs supposent que l'incident sera évident. En pratique, les incidents graves émergent souvent progressivement — un schéma de sorties anormales, une réclamation d'un déployeur, un rapport terrain. Sans protocole défini spécifiant ce qui déclenche l'horloge, les fournisseurs ratent systématiquement leurs délais.

Contrats avec les déployeurs omettant l'article 73(6). Si votre contrat avec le déployeur n'exige pas explicitement qu'il vous notifie des incidents graves, vous comptez sur la bonne volonté. L'article 73(6) crée une obligation légale pour les déployeurs, mais votre contrat doit la renforcer et la préciser.

Rapports descriptifs sans analyse. Les ASM attendent une analyse causale, même préliminaire. Un rapport qui se contente de décrire ce qui s'est passé sans aucune hypothèse sur le pourquoi générera des demandes complémentaires et signalera un SMQ immature.

Confusion entre signalement d'incident et responsabilité civile. Les rapports d'incident déposés auprès de l'ASM peuvent être requis par des demandeurs dans le cadre de litiges civils. Le service juridique doit être impliqué dans la rédaction, mais cette implication ne doit pas retarder le dépôt.

La plateforme de conformité DILAIG comprend une checklist de détection des incidents alignée sur les articles 73 et 72, des calculateurs de délais et un modèle de notification pré-rempli validé par rapport aux actes d'exécution de la Commission. Effectuez votre audit de préparation aux incidents sur dilaig.com.