Plan de surveillance après mise sur le marché pour les agents IA : ce qu'exige l'article 72 du Règlement européen sur l'IA

Commencez par la classification, pas par les étiquettes

Les agents IA ne constituent pas une catégorie juridique distincte dans le Règlement sur l'IA. Le déclencheur de l'article 72 n'est pas le mot agent. Le déclencheur est le fait que le système soit qualifié de haut risque ou fasse partie d'un système à haut risque.

Un assistant interne qui rédige des notes de réunion n'est pas traité de la même manière qu'un agent utilisé pour l'octroi de crédit, le triage des sinistres, le recrutement, la vérification d'identité, l'aide à la décision dans le secteur public ou d'autres cas d'usage relevant de l'annexe III. Si vous n'avez pas encore réalisé ce travail de qualification, commencez par Classer les systèmes d'IA à haut risque au titre du Règlement européen sur l'IA et Conformité des agents IA au titre du Règlement européen sur l'IA. Une fois le système dans le périmètre, la surveillance après mise sur le marché fait partie du modèle opérationnel ; ce n'est plus une simple bonne pratique optionnelle.

Ce qu'exige réellement l'article 72

L'article 72 impose aux fournisseurs de systèmes d'IA à haut risque de mettre en place et de documenter un système de surveillance après mise sur le marché proportionné à la nature de la technologie IA et aux risques du système. Cette surveillance doit rester active pendant toute la durée de vie du système.

En pratique, cette obligation comporte cinq éléments. Vous devez collecter, documenter et analyser de manière active et systématique les données pertinentes après le déploiement ; évaluer la conformité continue aux exigences du chapitre III, section 2 ; inclure, lorsque c'est pertinent, l'interaction avec d'autres systèmes d'IA ; fonder le dispositif sur un plan de surveillance après mise sur le marché ; et intégrer ce plan à la documentation de l'annexe IV. Les processus sectoriels existants peuvent être réutilisés lorsqu'un autre texte de l'Union impose déjà une gouvernance équivalente, mais seulement si le dispositif intégré garantit effectivement le même niveau de protection.

• Collecter des données pertinentes après le déploiement de manière systématique, et non ponctuelle.
• Examiner ces données au regard des exigences de conformité continue, et pas seulement des KPI produit.
• Couvrir les interactions avec les autres systèmes d’IA et les outils externes lorsque cela est pertinent.
• Documenter le plan dans l'annexe IV afin qu'un examinateur puisse comprendre concrètement comment fonctionne la surveillance.
• Intégrer les processus sectoriels existants uniquement si le niveau de protection obtenu reste équivalent.

Un tableau de bord n'est pas un plan

L'échec le plus courant consiste à confondre observabilité et conformité. Un tableau de bord peut vous indiquer la latence, le taux de succès, le coût ou l'usage des tokens. Un plan de surveillance après mise sur le marché doit expliquer à un examinateur quels risques sont suivis, quels signaux prouvent que les contrôles fonctionnent toujours, quels seuils déclenchent une escalade, qui revoit quoi, et comment les mesures correctives sont documentées.

C'est pourquoi la surveillance après mise sur le marché est étroitement liée à la checklist article 17 du Règlement européen sur l'IA, à Pistes d'audit des agents IA : des logs aux preuves et à votre socle de preuves sous-jacent. Si vous ne pouvez pas montrer comment la télémétrie devient une preuve effectivement revue, vous n'avez pas encore de véritable modèle opérationnel conforme à l'article 72.

• Quels risques sont surveillés : reliés explicitement au registre de risques de l’article 9.
• Quels signaux comptent : pas seulement les sorties, mais aussi les appels outils, les approbations, les interventions et les effets aval.
• Quels seuils comptent : ce qui est purement informatif, ce qui exige une revue dans la journée, et ce qui impose un gel de production.
• Quels enregistrements résistent à un audit : incidents, raisonnement des relecteurs, actions correctives et exports de preuve liés aux versions.

Pourquoi l'article 72 pèse davantage sur les agents IA

Les systèmes de prédiction statiques peuvent échouer silencieusement. Les agents échouent au travers de plusieurs systèmes. Ils récupèrent des données, appellent des outils, déclenchent des workflows, transmettent du travail à d'autres modèles et opèrent avec des degrés variables d'autonomie. La surveillance des agents doit donc être au niveau du workflow, pas seulement au niveau du modèle.

La logique de la surveillance après mise sur le marché est particulièrement pertinente pour les systèmes agentiques même lorsque le modèle n'est pas continuellement réentraîné. Le risque émergent peut provenir de changements de prompt, de mises à jour de politique, de remplacements de modèle, d'un élargissement de l'accès aux outils, de modifications de la chaîne de récupération, d'une dérive d'intégration ou d'évolutions du workflow côté déployeur. Le système peut devenir plus risqué sans cycle d'entraînement classique.

• Exécution des outils : actions échouées, réessais, effets de bord et tentatives non autorisées.
• Signaux de contrôle politique : refus, quasi-refus, files d’approbation et motifs d’intervention.
• Comportement inter-systèmes : ce qui se produit lorsque l'agent s'appuie sur d'autres services IA ou sur des automatisations externes.
• Résultats pertinents au regard des droits : disparités, plaintes, recours et effets aval matériellement dommageables.

Ce qui doit figurer dans un plan d'article 72 défendable

Un plan défendable n'est pas long pour paraître sérieux. Il est suffisamment précis pour qu'un examinateur comprenne comment vous détectez une dégradation, qui enquête sur les anomalies et comment les preuves reviennent alimenter la conformité et le contrôle des changements.

Pour les agents IA, le plan devrait généralement contenir au moins les éléments suivants. C'est aussi le moment où de nombreuses équipes associent l'exigence juridique au modèle de plan de surveillance après mise sur le marché, au playbook de procédure de supervision humaine et à la checklist du dossier de preuves afin que le processus soit réellement exploitable par les équipes ingénierie et opérations, pas seulement par les juristes.

• Identification du système et finalité prévue : nom exact du système, version, entité fournisseur, périmètre de version déployée, contexte de déploiement, utilisateurs concernés, frontières du système et logique de qualification haut risque.
• Objectifs de surveillance reliés au registre de risques : chaque risque significatif devrait avoir au moins un signal surveillé, un responsable et une voie d’escalade.
• Sources de données et méthodes de collecte : logs d’exécution, traces outils, événements d’approbation, enregistrements d’intervention, plaintes, sorties échantillonnées, tickets d’incident et historiques de changement d’intégration.
• Métriques, seuils et niveaux de gravité : taux d’échec des tâches, taux d’erreur des outils, taux d’hallucination ou d’action non étayée lorsque pertinent, fréquence des interventions, indicateurs de disparité, événements de retour arrière et logique de conséquences liée aux seuils.
• Politique d’échantillonnage et cadence de revue : télémétrie continue, revue à 100 % des actions critiques, échantillonnage de base pour les sorties à moindre risque et intensification après les mises en production, changements de modèle ou incidents.
• Données de supervision humaine et d’intervention : ce qui a été escaladé, qui a revu, quel contexte était visible, ce qui a été modifié et si le même schéma d’échec se répète.
• Gestion des incidents et lien avec l’article 73 : qui enquête, ce qui devient un incident, quels délais d’autorité s’appliquent et comment le point de départ du délai est identifié et démontré.
• Mesures correctives et contrôle des changements : qui peut suspendre, désactiver, revenir en arrière ou retirer le système, et comment les constats issus de la surveillance après mise sur le marché réalimentent la gestion des risques de l’article 9 et le système qualité de l’article 17.
• Conservation des preuves et préparation à l’audit : comment les logs, notes de revue, incidents et actions correctives sont conservés, protégés, reliés aux versions et exportés pour revue réglementaire.

Quand la surveillance devient un signalement au titre de l'article 73

Votre plan de surveillance doit indiquer clairement quand une alerte devient un incident, qui est propriétaire du triage et quand le signalement au titre de l'article 73 est déclenché. Ce calendrier ne doit pas être laissé à l'improvisation.

Dans le cadre actuel de l'article 73, le délai butoir ordinaire est de 15 jours à compter du moment où le fournisseur ou le déployeur a connaissance d'un incident grave. Le délai butoir est de 2 jours en cas d'atteinte généralisée aux obligations visant à protéger les droits fondamentaux ou de perturbation grave et irréversible d'une infrastructure critique, et de 10 jours lorsqu'une personne est décédée dès lors qu'un lien de causalité, ou une suspicion raisonnable de lien, est établi. Le point opérationnel essentiel est simple : vos seuils et règles d'escalade doivent faire remonter ces situations assez vite pour que le signalement reste possible.

• Décès ou atteinte grave à la santé : exige le triage le plus rapide et un chemin de décision de causalité clairement démontré.
• Perturbation grave et irréversible d’une infrastructure critique : ne doit pas passer par des files de revue internes lentes.
• Atteintes aux droits fondamentaux : ce ne sont pas des abstractions juridiques ; elles doivent être reliées à des déclencheurs opérationnels fondés sur les plaintes, interventions, recours et effets dommageables en aval.
• Mesures correctives au titre de l'article 20 : elles doivent être intégrées au même workflow afin que l'atténuation ne dépende pas de la finalisation du dossier de signalement.

Les fournisseurs portent l'article 72, mais les déployeurs l'alimentent

L'article 72 crée une obligation pour le fournisseur, mais celui-ci ne contrôle souvent pas l'intégralité du contexte opérationnel. Les déployeurs peuvent détenir les registres de plaintes, les notes de revue humaine, les tickets d'incident terrain ou les données de résultat aval qui rendent la surveillance réellement utile.

Pour les systèmes agentiques, les contrats fournisseur-déployeur devraient préciser quelles données le déployeur doit renvoyer, à quelle vitesse les incidents graves et quasi-incidents doivent être escaladés, comment les enregistrements d'intervention sont conservés et comment les changements de workflow ou d'intégration sont communiqués. Si cette interface n'est pas conçue, le plan semble complet sur le papier mais échoue en production.

• Obligations de remontée des données pour les plaintes, interventions, recours et métriques de résultat.
• Canaux de signalement des incidents avec interlocuteurs nommés et cartographie juridictionnelle.
• Notifications de changement lorsque le déployeur modifie les prompts, outils, workflows ou contrôles environnants.
• Règles de conservation et d’export pour éviter la fragmentation des preuves de surveillance après mise sur le marché entre plusieurs systèmes.

La position à tenir en mars 2026 sur le modèle et le calendrier

La formulation la plus sûre au regard du droit en vigueur est la suivante : la question du modèle de plan reste incertaine ; l'obligation du fournisseur, elle, ne l'est pas. Le texte actuel de l'article 72 renvoie toujours à un acte d'exécution de la Commission pour établir un modèle de plan. Mais le 19 novembre 2025, la Commission a proposé de remplacer cette prescription par des orientations plutôt que par un format harmonisé de plan. Cette proposition est encore à l'étude ; elle ne modifie donc pas le droit applicable aujourd'hui.

La même prudence vaut pour le calendrier. En l'état actuel du Règlement sur l'IA, la plupart des obligations relatives aux systèmes à haut risque s'appliquent le 2 août 2026, tandis que certains systèmes à haut risque intégrés à des produits bénéficient d'une transition plus longue jusqu'au 2 août 2027. La Commission a proposé des ajustements de calendrier, mais ces changements ne sont pas encore le droit. La démarche pragmatique consiste donc à construire dès maintenant un plan vérifiable, puis à adapter le format ultérieurement si la Commission finalise des orientations ou des amendements législatifs.

• Texte actuel de l'article 72 : synthèse du Service Desk AI Act sur l'article 72
• Délais actuels de signalement des incidents graves : synthèse du Service Desk AI Act sur l'article 73
• FAQ de la Commission sur le calendrier de mise en oeuvre : Navigating the AI Act
• FAQ de la Commission sur la normalisation : Understanding the standardisation of the AI Act
• Proposition de la Commission en cours d'examen : COM(2025) 811 final

Les erreurs courantes qui font échouer les plans d'article 72 en revue

Les défaillances sont généralement opérationnelles, pas théoriques. Les équipes rédigent le plan comme s'il s'agissait d'une note, alors que les régulateurs et auditeurs le traiteront comme la preuve d'une capacité opérationnelle réellement active.

Si vous voulez un test pratique, demandez-vous si un tiers pourrait lire votre plan et comprendre comment le système est surveillé, qui enquête sur les anomalies, comment les changements de production affectent l'échantillonnage et ce qui est signalé ou fait l'objet d'un retour arrière lorsque les seuils sont franchis.

• Traiter la surveillance après mise sur le marché comme un tableau de bord au lieu d'une procédure opérationnelle.
• Surveiller uniquement la qualité du modèle tout en ignorant l'usage des outils, les approbations, les interventions et les effets aval.
• Lister des métriques sans seuils, sans responsables nommés, sans logique de gravité ni délais de réponse.
• Oublier les interactions avec d'autres systèmes d'IA dans les workflows agentiques.
• Conserver les logs bruts mais pas les décisions incident, le raisonnement des relecteurs ni les preuves d’actions correctives.
• Déconnecter la surveillance du contrôle des changements, de sorte que chaque mise en production réinitialise le risque sans revue renforcée.
• Supposer que la documentation du fournisseur de modèle remplace la surveillance au niveau système que doit assurer le fournisseur.