AI Act : surveillance après commercialisation et signalement des incidents graves d'une IA à haut risque (articles 72 et 73)

AI Act : surveillance après commercialisation et signalement des incidents graves d’une IA à haut risque (articles 72 et 73)

Les articles 72 et 73 du règlement (UE) 2024/1689 obligent le fournisseur d’un système d’IA (intelligence artificielle) à haut risque à surveiller ce système une fois qu’il est mis sur le marché, puis à signaler tout incident grave dans un délai de 2, 10 ou 15 jours. Sur le papier, ce sont deux paragraphes de conformité. En pratique, il faut construire une chaîne de collecte, de qualification et de preuve qui traverse le périmètre du fournisseur et celui de ses clients.

Explication de la marmotte

Un fabricant de voitures ne s’arrête pas de travailler le jour où il vend une voiture : il continue de vérifier qu’elle se comporte bien sur la route. Si l’une d’elles provoque un accident sérieux, il doit prévenir les autorités rapidement. Une intelligence artificielle utilisée pour des décisions sensibles est soumise au même devoir de vigilance.

→ Lire l’explication complète de la marmotte

Ce que les articles 72 et 73 exigent, texte à l’appui

L’article 72 demande au fournisseur d’établir et de documenter un système de surveillance après commercialisation, défini à l’article 3, point 25, comme l’ensemble des activités du fournisseur qui recueillent et analysent les données issues de l’expérience d’utilisation « de manière à repérer toute nécessité d’appliquer immédiatement une mesure préventive ou corrective ». Le paragraphe 2 précise que ce système collecte, documente et analyse « de manière active et systématique » les données sur les performances tout au long du cycle de vie, afin de vérifier que les exigences du chapitre III, section 2 restent respectées en permanence. Le mot « active » exclut une boîte aux lettres de réclamations : attendre que le client appelle ne constitue pas une surveillance.

Trois précisions du texte pèsent sur l’architecture :

• la surveillance inclut, le cas échéant, l’interaction avec d’autres systèmes d’IA (paragraphe 2) ;
• elle ne couvre pas les données opérationnelles sensibles des déployeurs qui sont des autorités répressives (paragraphe 2) : pour ces clients, la télémétrie doit être conçue sans ces données ;
• elle repose sur un plan qui fait partie de la documentation technique de l’annexe IV (paragraphe 3). Le règlement prévoyait un acte d’exécution fixant le modèle de ce plan au plus tard le 2 février 2026. Pour savoir si cet acte a été adopté et sous quelle forme, il faut consulter la version consolidée sur EUR-Lex. Rien ne remplace cette vérification.

Le paragraphe 4 permet aux produits relevant de l’annexe I, section A (dispositifs médicaux, machines, etc.) d’intégrer ces éléments dans le plan de surveillance sectoriel existant, à condition d’obtenir une protection équivalente. La même option s’applique aux établissements financiers pour les systèmes de l’annexe III, point 5. Construire un second dispositif parallèle dans ces cas revient à doubler le coût et à multiplier les incohérences.

L’article 73 porte sur le signalement des incidents graves. L’article 3, point 49, les définit comme un incident ou dysfonctionnement entraînant, directement ou indirectement :

• a) le décès d’une personne ou une atteinte grave à sa santé ;
• b) une perturbation grave et irréversible d’infrastructures critiques ;
• c) la violation d’obligations du droit de l’Union protégeant les droits fondamentaux ;
• d) un dommage grave à des biens ou à l’environnement.

Le signalement est adressé aux autorités de surveillance du marché de chaque État membre où l’incident s’est produit (paragraphe 1). Un même défaut constaté chez trois clients situés dans trois pays donne donc lieu à trois notifications. Deux régimes allégés existent. Le paragraphe 9 vise les fournisseurs de l’annexe III déjà soumis à une obligation de signalement équivalente. Le paragraphe 10 vise les dispositifs médicaux relevant des règlements (UE) 2017/745 et 2017/746. Dans ces deux cas, seuls les incidents du point 49 c) restent à notifier au titre de l’AI Act.

Pour le calendrier d’application : d’après la page calendrier de l’AI Act, le volet IA de l’omnibus numérique (règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026) a reporté les exigences du haut risque au 2 décembre 2027 pour l’annexe III et au 2 août 2028 pour l’annexe I. Un dispositif de signalement se rode plus lentement qu’un texte ne se reporte. Ce délai supplémentaire sert à faire des exercices, pas à repousser le projet.

Prérequis de plateforme et d’organisation

Avant d’écrire la moindre règle d’alerte, plusieurs éléments doivent déjà exister.

• Le rôle de chacun est établi. Le fournisseur porte les articles 72 et 73, le déployeur porte l’article 26. Un intégrateur qui modifie substantiellement un système peut devenir fournisseur (voir rôles fournisseur et déployeur).
• Un inventaire des déploiements est tenu par État membre. Sans lui, on ne sait pas à quelle autorité écrire.
• La journalisation de l’article 12 fonctionne. Son paragraphe 2, point b), lie explicitement les journaux à la surveillance de l’article 72. L’article 19 impose au fournisseur de conserver au moins six mois les journaux qu’il contrôle, et l’article 26, paragraphe 6, impose la même durée au déployeur (voir journalisation).
• Les artefacts sont versionnés. Il faut pouvoir associer chaque décision produite à une empreinte cryptographique (hash) des poids du modèle, de la configuration, des seuils et du jeu de données de référence. Sans cette traçabilité, une enquête se termine par « impossible à reproduire ».
• Le système de gestion de la qualité de l’article 17 inclut les deux procédures. Le point h) couvre la surveillance après commercialisation, le point i) le signalement des incidents graves (voir évaluation de la conformité).
• Les contrats déployeurs prévoient la remontée. Il faut un canal, un délai interne en heures et un format défini. Sans clause contractuelle, la télémétrie dépend du bon vouloir de chaque client.

Architecture de collecte : du déployeur au plan de surveillance

Le schéma ci-dessous montre deux circuits distincts. Le premier transporte de la télémétrie agrégée en continu. Le second transporte des signalements d’événements à traiter tout de suite. Les deux aboutissent au même lieu de qualification, qui alimente à son tour la gestion des risques.

Le compromis central se situe ici. Plus on collecte chez le déployeur, mieux on détecte les problèmes. Mais chaque champ remonté devient une donnée personnelle potentielle, un sujet de négociation contractuelle et une nouvelle surface de fuite. La position recommandée est de faire remonter des indicateurs agrégés et des métadonnées de décision, jamais les entrées brutes par défaut. On les complète par un droit d’accès ponctuel aux journaux du déployeur lorsqu’un dossier est ouvert. Capturer en continu chaque requête complète d’un système de recrutement ou de crédit crée un second traitement de données personnelles sans base légale solide. Ce choix cesse d’être valable lorsque le risque principal relève du point 49 a) (santé) et que la détection exige le cas individuel. Dans ce cas, la collecte fine se justifie, avec pseudonymisation dès la source.

Ce choix a un prix. En agrégeant, on perd le cas isolé. Un seul refus discriminatoire ne fait pas bouger une moyenne. C’est pour cette raison que le canal événementiel de l’article 26, paragraphe 5, n’est pas optionnel. Cet article oblige le déployeur qui identifie un incident grave à en informer « immédiatement d’abord le fournisseur ». S’il ne parvient pas à le joindre, l’article 73 s’applique au déployeur lui-même (voir obligations du déployeur). Il faut donc publier un point de contact joignable en permanence. Une adresse générique relevée le lundi matin ne suffit pas.

Indicateurs de dérive et critères de qualification d’un incident grave

Un indicateur n’a d’intérêt que s’il est relié à une exigence de la section 2 du chapitre III. Le tableau suivant établit ce lien.

Indicateur	Exigence surveillée	Ce qu’il détecte
Dérive des entrées (indice de stabilité de population, PSI pour Population Stability Index)	Exactitude, article 15	Population servie différente de celle de l’entraînement
Taux d’erreur par sous-groupe	Gouvernance des données (article 10), point 49 c)	Discrimination émergente
Taux de contournement par l’opérateur humain	Contrôle humain, article 14	Opérateurs qui ne font plus confiance au système, ou qui ne le contrôlent plus
Distribution des scores de confiance	Robustesse, article 15	Entrées adverses, changement de contexte
Réclamations et recours des personnes concernées	Droits fondamentaux	Préjudice que la métrique ne voit pas
Silence de la télémétrie	Le dispositif lui-même	Déployeur déconnecté ou collecte cassée

Le taux de contournement humain est l’indicateur le plus sous-estimé. S’il tombe à zéro, il ne prouve pas que le système est parfait. Il indique souvent que l’opérateur valide tout sans regarder, ce qui touche directement le contrôle humain. Ironie du secteur : le tableau de bord qui affiche « 0 % de corrections » finit fréquemment sur une slide de réussite.

Pour qualifier un événement, on répond à quatre questions, dans cet ordre :

1. Une conséquence du point 49 est-elle avérée ou plausible ? Le texte retient aussi les conséquences « indirectes ». Un système qui oriente mal une décision humaine reste en cause.
2. Existe-t-il un lien de causalité, ou une « probabilité raisonnable » de lien ? La probabilité suffit. Attendre la certitude est l’erreur de qualification la plus fréquente.
3. Quel cas s’applique : décès, point 49 b), infraction de grande ampleur au sens de l’article 3, point 61, ou cas général ? La réponse fixe le délai maximal.
4. Quels États membres sont concernés ? La réponse fixe les destinataires.

Il vaut mieux trancher en faveur du signalement. Une notification initiale qui se révèle sans objet coûte une note de clôture. Une notification tardive coûte un manquement documenté. Les articles 72 et 73 ne figurent pas nommément dans la liste de l’article 99, paragraphe 4 : ils s’y rattachent par l’article 16, point c), qui impose le système de gestion de la qualité de l’article 17, dont les procédures de surveillance et de signalement font partie (points h et i). Le plafond de ce paragraphe est de 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu (le plus faible des deux pour une PME, paragraphe 6). La qualification d’un retard précis relève du texte et d’un avocat, pas d’une page de documentation.

Horloge des délais de l’article 73 : 2, 10 et 15 jours

Le point de départ de l’horloge piège presque tout le monde. Les délais courent à partir du moment où « le fournisseur ou, le cas échéant, le déployeur a eu connaissance de l’incident grave ». Si le client met une semaine à prévenir, le fournisseur n’a plus que huit jours sur les quinze. Le schéma montre les trois plafonds. Chacun est précédé d’un « immédiatement » qui reste l’obligation principale.

Le paragraphe 5 sert d’outil opérationnel. On peut déposer un signalement initial incomplet, puis le compléter. Il faut donc préparer deux gabarits : un formulaire initial que l’on peut remplir en moins d’une heure (système, version, État membre, nature présumée au regard du point 49, mesures conservatoires prises) et un rapport complet qui reprend les résultats de l’enquête. Le paragraphe 7 prévoyait aussi des orientations de la Commission avant le 2 août 2025. Leur contenu et leurs éventuelles modifications se vérifient sur EUR-Lex et sur le site de la Commission, pas dans un modèle trouvé sur un forum.

Le paragraphe 2 précise également que le délai « tient compte de l’ampleur de l’incident grave ». Les 15 jours sont un plafond. Les traiter comme une cible, c’est confondre « au plus tard » avec « tranquillement ».

Gel des preuves avant toute modification du système (paragraphe 6)

Après le signalement, le fournisseur enquête sans tarder : il évalue les risques et définit des mesures correctives. Il ne mène toutefois aucune investigation qui exige de modifier le système d’une manière susceptible d’affecter l’évaluation ultérieure des causes, avant d’en avoir informé les autorités. Le texte n’interdit pas de corriger. Il interdit de corriger en premier et de prévenir ensuite.

Le réflexe d’ingénieur (déployer un correctif dans l’heure) entre donc en collision avec le droit. Pour sortir de ce conflit, on sépare deux actions : suspendre et modifier. Désactiver une fonctionnalité par un interrupteur de configuration, ou arrêter le service, protège les personnes sans changer l’artefact à analyser. Réentraîner, changer un seuil ou remplacer les poids modifie précisément ce que l’enquête doit examiner.

L’ordre recommandé est le suivant :

1. Capturer un instantané scellé : empreintes des poids et du conteneur d’inférence, configuration et seuils, version des données de référence, journaux de la période concernée, état des indicateurs. Le tout est placé dans un stockage WORM (Write Once Read Many) avec un horodatage signé.
2. Placer les journaux sous conservation légale. La durée minimale de six mois prévue par l’article 19 ne doit pas effacer les pièces d’un dossier en cours. Une purge automatique qui tourne pendant une enquête est le pire moment pour découvrir que la rétention fonctionne bien.
3. Suspendre si le risque persiste, sans modifier l’artefact.
4. Informer les autorités de la modification envisagée, puis appliquer les mesures correctives de l’article 20. Ces mesures peuvent aller jusqu’au retrait, à la désactivation ou au rappel, avec information des distributeurs, des déployeurs et des importateurs.

Un retour arrière vers la version précédente est aussi une modification. Il faut d’abord sceller la version fautive.

Exemple : incident grave sur un système de tri de candidatures

Prenons un système de présélection de candidatures relevant de l’annexe III, point 4 (emploi). Il est déployé chez des recruteurs établis dans deux États membres. Après la mise à jour d’un connecteur chez un client, les dossiers venant d’un format de diplôme étranger sont systématiquement mal analysés et déclassés. Le schéma suit le dossier depuis la détection jusqu’à la clôture.

Trois points ressortent de cet exemple. D’abord, l’horloge démarre chez le déployeur A, pas au moment où le fournisseur reçoit le ticket. Ensuite, « deux pays touchés » ne fait pas une infraction de grande ampleur. L’article 3, point 61, exige une atteinte aux intérêts collectifs de personnes résidant dans au moins deux États membres autres que celui de l’origine de l’acte ou de l’établissement du fournisseur (point a), ou une même infraction simultanée dans au moins trois États membres (point b). Ici, le cas général s’applique : quinze jours au plus. Cela n’autorise pas à les prendre, le signalement reste dû « immédiatement » une fois le lien probable établi. Si un troisième recruteur, dans un autre pays, signale le même défaut, la qualification change et le plafond tombe à deux jours. Enfin, le point 49 c) déclenche l’information des autorités de l’article 77 par l’autorité de surveillance du marché (paragraphe 7). Le dossier doit donc décrire précisément quels droits sont en cause et quelles personnes sont touchées.

Horloges parallèles : RGPD, NIS 2, CRA et article 55

Un même événement peut relever de plusieurs régimes de notification. Chacun a son propre déclencheur, son propre destinataire et son propre délai, et aucun signalement ne vaut pour un autre. Le schéma place ces régimes côte à côte sans les fusionner.

En pratique, un empoisonnement du modèle par une vulnérabilité exploitée dans la chaîne d’inférence peut relever à la fois de l’article 73, du CRA, de NIS 2 et du RGPD. La cellule de qualification doit appliquer une grille unique qui teste chaque régime séparément, avec une horloge par régime. Une seule horloge globale ne fonctionne pas. Le régime CRA s’applique depuis le 11 septembre 2026 aux fabricants de produits comportant des éléments numériques. Le fournisseur d’un système d’IA à haut risque qui intègre un modèle d’IA à usage général tiers ne porte pas l’article 55. En revanche, il doit pouvoir transmettre les éléments utiles au fournisseur du modèle (voir risque systémique).

Surface d’attaque de la chaîne de surveillance

Le dispositif de surveillance est lui-même un système qui transporte des données sensibles et sur lequel reposent des décisions réglementaires. Il présente donc sa propre surface d’attaque.

• Empoisonnement de la télémétrie. Un acteur qui injecte des indicateurs falsifiés peut masquer une dérive ou en fabriquer une. Contre-mesure : chaque déployeur signe ses envois avec une clé qui lui est propre, transportée en mTLS (mutual Transport Layer Security), et le collecteur vérifie la vraisemblance des séries reçues.
• Altération des journaux pour effacer un incident. Il peut s’agir d’un acteur malveillant interne ou d’une pression commerciale. Contre-mesure : stockage WORM et chaînage des empreintes. De plus, les personnes qui ont livré la version en cause ne doivent pas pouvoir supprimer des données.
• Exfiltration par le canal de remontée. Un collecteur qui reçoit des entrées brutes de plusieurs clients devient une cible très attractive. Contre-mesure : agrégation à la source, cloisonnement par déployeur et chiffrement au repos avec des clés distinctes.
• Déni de service par signalements fictifs. Un flot d’alertes fabriquées sature la cellule pendant qu’un incident réel attend son tour. Contre-mesure : authentification du canal événementiel, déduplication et priorisation selon le point 49 concerné.
• Suppression du signalement. C’est l’attaque la plus simple : quelqu’un décide que « ce n’est pas grave ». Contre-mesure : une qualification tracée, une double validation obligatoire pour tout classement sans suite, et une revue a posteriori par la fonction qualité.

Le modèle lui-même reste exposé à ses propres attaques (entrées adverses, empoisonnement des données d’entraînement). La surveillance les détecte après coup. Elle ne les empêche pas.

Ce que la surveillance après commercialisation ne garantit pas

• Elle ne détecte que ce qu’on mesure. Un préjudice sans indicateur associé, ni réclamation, ni journal reste invisible. Un indicateur qui semble rassurant traduit souvent une couverture de mesure insuffisante.
• Elle ne vaut pas conformité. Le système doit respecter la section 2 dès sa mise sur le marché ; la surveillance vérifie que cela reste vrai dans le temps. La conception relève de la gestion des risques (article 9, dont le paragraphe 2, point c), intègre les données de surveillance) et de la documentation technique (annexe IV, point 9).
• Elle ne couvre pas les données opérationnelles sensibles des autorités répressives. Sur ce périmètre, la vigilance repose sur le déployeur.
• Elle n’acquitte aucune autre obligation. Un signalement au titre de l’article 73 ne remplace ni la notification RGPD, ni la notification NIS 2, ni celle du CRA.
• Elle ne décharge pas le déployeur. L’article 26 lui impose de surveiller le fonctionnement, de conserver ses journaux et de faire remonter les incidents.

Exploitation : clés, rétention, supervision et exercices

• Clés de signature de la télémétrie : une clé par déployeur, rotation annuelle au minimum, révocation immédiate en fin de contrat, et un inventaire de ces clés tenu à jour. La clé du collecteur qui scelle les instantanés doit être conservée dans un module matériel ou un service de gestion de clés, séparé de l’environnement de production.
• Rétention : au moins six mois (articles 19 et 26), avec une conservation légale qui suspend la purge dès qu’un dossier est ouvert. La documentation technique, dont le plan de surveillance, suit les règles de conservation de l’article 18.
• Supervision du dispositif : le silence d’un déployeur doit déclencher une alerte. La télémétrie qui cesse sans que personne s’en aperçoive est la panne la plus fréquente, et la plus difficile à justifier devant une autorité.
• Sauvegarde et reprise : le stockage des preuves se sauvegarde hors du domaine d’administration de la production, et l’on teste régulièrement la restauration d’un instantané scellé.
• Exercices : au moins un exercice par an, de bout en bout, avec un incident fictif signalé par un déployeur un vendredi soir. On chronomètre chaque étape : réception, qualification, instantané, signalement initial. L’écart entre la procédure écrite et le temps réellement mesuré constitue le vrai plan d’action.

🐝 Ce qui arrive si on s’en passe

Sans collecte active, une dérive progresse en silence et le fournisseur apprend l’existence de l’incident par l’autorité ou par la presse, avec une horloge qui a démarré chez le déployeur des jours plus tôt. Sans canal événementiel contractualisé, le délai de 2, 10 ou 15 jours est souvent dépassé avant même l’ouverture du dossier. Sans instantané scellé, le premier correctif efface l’état fautif : la cause devient impossible à démontrer, et le fournisseur se retrouve à avoir modifié le système avant d’en informer les autorités. Sans boucle vers la gestion des risques, le même défaut réapparaît dans la version suivante, puisque rien n’a signalé qu’il fallait le corriger.

🦫 Explication de la marmotte 🍫

Certaines intelligences artificielles prennent part à des décisions qui comptent : trier des candidatures, aider à soigner, gérer un réseau électrique. La loi européenne oblige l’entreprise qui les fabrique à continuer de les surveiller après les avoir vendues. Pour cela, les clients qui utilisent ces systèmes renvoient régulièrement des mesures : combien d’erreurs, pour quels groupes de personnes, combien de fois un humain a corrigé la machine. L’entreprise compare ces chiffres à des limites fixées à l’avance. Lorsqu’une limite est dépassée, ou qu’un client signale un problème, une équipe vérifie s’il s’agit d’un « incident grave » : une mort, une atteinte sérieuse à la santé, une panne grave d’un service vital, une atteinte aux droits des personnes ou des dégâts importants. Si c’est le cas, elle doit prévenir l’autorité de contrôle de chaque pays touché. Le délai maximal est de deux jours pour les cas les plus étendus, dix jours en cas de décès, quinze jours dans les autres cas, et il commence dès que le client est au courant. On a le droit d’envoyer d’abord un message incomplet, puis le dossier complet. Avant de réparer, il faut enregistrer une copie verrouillée de l’état exact du système et prévenir l’autorité, sinon les traces de l’erreur disparaissent. Si personne ne surveille, l’erreur continue de toucher des gens sans que personne le sache.

À lire aussi

• AI Act : articuler les obligations de sécurité avec NIS 2, le CRA et le RGPDComment le règlement (UE) 2024/1689 sur l'IA s'articule avec NIS 2, le Cyber Resilience Act et le RGPD : qui relève de quoi, quels ponts présument la conformité, ce qu'il faut refaire, comment notifier un incident en parallèle et mutualiser les preuves.
• AI Act : champ d'application, qui est concerné et qui en sort (article 2)Lecture de l'article 2 du règlement (UE) 2024/1689, de la territorialité aux exclusions défense, recherche et logiciel libre, avec la condition qui fait tomber chacune.
• AI Act : bacs à sable réglementaires et mesures PME (art. 57 à 63)Ce que les articles 57 à 63 de l'AI Act, modifiés par le règlement (UE) 2026/1744, prévoient pour les bacs à sable réglementaires de l'IA, les essais en conditions réelles et les allègements destinés aux PME, avec les exigences d'architecture qui en découlent.
• AI Act : analyse d'impact sur les droits fondamentaux (article 27)Ce qu'exige l'article 27 du règlement (UE) 2024/1689, qui doit réaliser l'analyse d'impact sur les droits fondamentaux, avec quel contenu, et comment l'articuler avec l'analyse d'impact relative à la protection des données.

Pages voisines

La citent

• AI Act : enregistrement dans la base de données de l'UE (articles 49 et 71)
• AI Act : mandataire, importateur et distributeur d'une IA à haut risque (articles 22 à 24)
• AI Act : articuler les obligations de sécurité avec NIS 2, le CRA et le RGPD
• AI Act : bacs à sable réglementaires et mesures PME (art. 57 à 63)

AI Act : surveillance après commercialisation et signalement des incidents graves d'une IA à haut risque (articles 72 et 73)

Elle cite

• ⇄Lien dans les deux sens :AI Act : évaluation de la conformité, déclaration UE et marquage CE d'une IA à haut risque (articles 17, 43 et 49)
• ⇄Lien dans les deux sens :AI Act : journalisation automatique d'une IA à haut risque (articles 12, 19 et 26)
• ⇄Lien dans les deux sens :AI Act : système de gestion des risques d'une IA à haut risque (article 9)
• AI Act : obligations du déployeur d'une IA à haut risque (article 26)
• AI Act : calendrier d'application 2025-2030 et ce qui s'applique déjà
• AI Act : contrôle humain d'une IA à haut risque (article 14)
• AI Act : documentation technique d'une IA à haut risque (article 11, annexe IV)
• AI Act : fournisseur, déployeur, importateur et requalification en fournisseur

⇄ : les deux pages se citent l’une l’autre.