Surveillance post-marché sous l'AI Act : l'obligation de l'Article 72 expliquée
L'Article 72 de l'AI Act impose aux fournisseurs d'IA à haut risque de maintenir un système actif de surveillance post-marché tout au long de la durée de vie du système. Ce guide explique ce que doit contenir le plan, son lien avec la déclaration d'incidents (Article 73) et les échéances clés.
La plupart des organisations qui se préparent à la conformité AI Act se concentrent principalement sur les obligations pré-marché : documentation technique, évaluations de conformité, marquage CE. L'Article 72 est différent. Il impose une obligation continue qui commence dès qu'un système d'IA à haut risque est mis sur le marché et se poursuit pendant toute sa durée de vie commerciale. Pourtant, dans la plupart des programmes de conformité, il ne reçoit qu'une fraction de l'attention qu'il mérite.
Ce guide explique ce que la surveillance post-marché (SPM) exige concrètement, qui est obligé, à quoi ressemble un plan conforme, et comment elle s'articule avec les obligations de déclaration d'incidents de l'Article 73.
Qu'est-ce que la surveillance post-marché ?
La surveillance post-marché est la collecte et l'examen systématiques de données sur les performances d'un système d'IA à haut risque après son déploiement. Le principe est emprunté directement à la réglementation sur les dispositifs médicaux (Article 83 du RDM), et l'analogie est intentionnelle : tout comme un dispositif médical doit être surveillé pour détecter des événements indésirables après que les patients commencent à l'utiliser, un système d'IA à haut risque doit être surveillé pour détecter une dérive de performance, des erreurs et des risques non anticipés après que les déployeurs commencent à l'utiliser.
L'Article 72(1) stipule :
« Les fournisseurs de systèmes d'IA à haut risque établissent et documentent un système de surveillance après commercialisation d'une manière proportionnée à la nature des technologies d'IA et aux risques du système d'IA à haut risque. »
La proportionnalité est importante ici. Un modèle de classification simple utilisé dans un seul pays a des exigences SPM différentes d'un outil de prédiction policière déployé dans quinze États membres. L'obligation évolue en fonction du risque réel et de l'ampleur du déploiement.
Qui est obligé ?
La surveillance post-marché est une obligation du fournisseur au titre de l'Article 72. Les déployeurs ne sont pas tenus d'exploiter eux-mêmes un système SPM, mais ils jouent un rôle d'appui essentiel.
En vertu de l'Article 26(5), les déployeurs doivent informer les fournisseurs de tout incident grave ou dysfonctionnement qu'ils observent dans le système déployé. Ce n'est pas optionnel. Sans les données remontant des déployeurs, le système SPM d'un fournisseur ne peut pas fonctionner efficacement.
Les fournisseurs de systèmes d'IA à haut risque intégrés dans des produits réglementés par d'autres législations d'harmonisation européenne (par exemple, les dispositifs médicaux ou les machines) doivent intégrer leur SPM aux systèmes de surveillance après commercialisation requis par ces autres cadres. Il n'y a pas d'exemption — c'est une obligation d'intégration.
Ce que doit contenir un plan SPM conforme
L'Article 72(3) fait référence à l'Annexe VII pour le contenu de la surveillance post-marché dans les systèmes utilisant des approches statistiques. Plus généralement, un plan SPM conforme devrait couvrir les éléments suivants.
1. Périmètre et description du système
Le plan doit clairement identifier le système d'IA couvert, sa finalité prévue, les contextes de déploiement et les catégories d'utilisateurs (déployeurs) et de personnes affectées. Une description vague ne suffit pas — les limites opérationnelles du système doivent être définies pour que les anomalies puissent être détectées de manière pertinente.
2. Métriques de performance et seuils
Le plan doit spécifier les KPI selon lesquels le système sera évalué après déploiement. Ceux-ci doivent refléter les métriques d'exactitude et de robustesse documentées dans la documentation technique au titre de l'Article 11 et de l'Annexe IV, mais doivent également inclure :
- Des indicateurs de glissement de distribution (détection du moment où les données d'entrée ne ressemblent plus aux données d'entraînement)
- Le suivi du taux d'erreur par contexte de déploiement (différents déployeurs, différents cas d'usage)
- Des seuils de dégradation des performances déclenchant un examen formel
Sans seuils explicites, il n'y a aucune base pour décider si les performances observées justifient une intervention.
3. Mécanismes de collecte de données
Le plan doit décrire comment les données de performance sont collectées à partir des systèmes déployés. Cela implique typiquement :
- Des boucles de retour structurées des déployeurs (rapports d'incidents, journaux d'anomalies)
- Une journalisation automatisée des sorties du système et des scores de confiance lorsque cela est techniquement faisable
- Des protocoles d'échantillonnage si une journalisation complète des sorties n'est pas possible
Les fournisseurs doivent également traiter la protection des données : les données de surveillance des performances peuvent inclure des données personnelles, ce qui déclenche les obligations RGPD de minimisation des données, de limitation des finalités et d'accords de traitement avec les déployeurs.
4. Détection de dérive et processus de revue
La dérive de performance dans les systèmes d'IA est courante — le comportement du modèle évolue à mesure que les données réelles s'éloignent des distributions d'entraînement. Le plan SPM doit inclure :
- Une méthodologie définie pour détecter la dérive (tests statistiques, tableaux de bord de surveillance, ou les deux)
- Des intervalles de revue adaptés au profil de risque (trimestriel pour les déploiements à risque plus faible ; surveillance continue avec revues mensuelles pour les systèmes à fort enjeu)
- Des critères d'escalade : quel niveau de dérive déclenche une mise à jour du modèle, un réentraînement ou un retrait ?
5. Procédures d'escalade des incidents
Le plan SPM doit définir le processus interne d'identification, de documentation et d'escalade des incidents graves. C'est le pont opérationnel vers l'Article 73 (déclaration d'incidents aux autorités). Le processus doit préciser :
- Qui reçoit les rapports d'incidents des déployeurs
- Les critères de triage interne (ce qui qualifie d'incident grave vs. mineur)
- Les délais d'investigation interne
- Les points de décision pour déclencher une déclaration externe au titre de l'Article 73
6. Fréquence des revues et gouvernance
Le plan doit préciser la fréquence à laquelle le système SPM lui-même est examiné — non seulement les performances du système d'IA, mais aussi l'adéquation du processus de surveillance. Cela implique généralement une revue annuelle au minimum, avec des revues ad hoc déclenchées par des incidents significatifs ou des mises à jour du système.
La documentation de gouvernance doit nommer la fonction responsable (équipe d'assurance qualité, responsable de la gouvernance IA, ou équivalent) et définir la composition et les attributions du comité de revue.
Modèle minimal de plan SPM
La structure suivante satisfait aux exigences essentielles de l'Article 72 pour la plupart des systèmes d'IA à haut risque :
| Section | Contenu |
|---|---|
| 1. Identification du système | Nom, version, finalité prévue, contextes de déploiement |
| 2. KPI de performance | Métriques d'exactitude, taux d'erreur, distribution des scores de confiance |
| 3. Indicateurs de dérive | Surveillance de la distribution des entrées, métriques de stabilité des sorties |
| 4. Collecte de données | Sources, méthodologie d'échantillonnage, garanties RGPD |
| 5. Calendrier de revue | Intervalles standards (ex. trimestriel) + revues déclenchées par événements |
| 6. Procédure d'incident | Réception, triage, investigation, délai d'escalade |
| 7. Actions correctives | Critères de mise à jour, réentraînement, restriction ou retrait |
| 8. Gouvernance | Fonction responsable, comité de revue, contrôle documentaire |
Ce modèle est un point de départ. Les systèmes à haut risque dans des secteurs sensibles (santé, maintien de l'ordre, emploi) requièrent une plus grande profondeur, notamment dans les sections 2 et 6.
Le lien avec l'Article 73 : déclaration d'incidents
L'Article 72 (SPM) et l'Article 73 (déclaration d'incidents) sont les deux faces d'un même cadre de conformité. La SPM est le mécanisme de détection ; l'Article 73 est l'obligation de déclaration déclenchée lorsque la SPM détecte un incident grave.
En vertu de l'Article 73(1), les fournisseurs doivent signaler tout incident grave aux autorités de surveillance du marché des États membres où l'incident s'est produit. Un incident grave est défini à l'Article 3(49) comme tout incident causant directement ou indirectement, ou susceptible de causer :
- Un décès ou un préjudice grave pour la santé
- Une perturbation grave et irréversible d'infrastructures critiques
- Une violation des droits fondamentaux
- Des dommages graves aux biens ou à l'environnement
Le calendrier de déclaration au titre de l'Article 73(1) est structuré : un rapport initial dès que le fournisseur a connaissance de l'incident, suivi d'un rapport d'investigation détaillé dans les délais définis par l'autorité de surveillance du marché.
Sans un système SPM fonctionnel, les fournisseurs ne peuvent pas détecter de manière fiable les incidents graves avant qu'ils ne soient signalés par des tiers ou des régulateurs — une position de conformité significativement plus défavorable.
Délai de conformité
Suite à l'accord provisoire AI Omnibus (7 mai 2026), le délai pour les obligations haut-risque Annexe III — dont l'Article 72 SPM — est repoussé au 2 décembre 2027 (systèmes Annexe III autonomes) et au 2 août 2028 (produits intégrant une IA couverts par l'Annexe I). La date initiale d'août 2026 ne s'applique plus. Pour les systèmes déjà sur le marché avant les nouvelles échéances, les dispositions transitoires de l'Article 111(2) s'appliquent à condition que le système reste inchangé.
Le report n'est pas un signal pour attendre. Concevoir un système SPM, établir les flux de données avec les déployeurs, poser les métriques de référence et intégrer le plan dans la documentation technique demande 6 à 12 mois. Les organisations qui s'y mettront fin 2026 ou en 2027 construiront sous pression — exactement les conditions qui produisent une conformité incomplète.
La plateforme de conformité DILAIG inclut un constructeur de plan de surveillance post-marché aligné sur l'Article 72, avec des modèles calibrés pour chaque catégorie de l'Annexe III. Générez votre plan SPM en quelques minutes et intégrez-le directement à votre documentation technique sur dilaig.com.