Comment monitorer un système IA post-marché selon Article 72 de l'AI Act

L'essentiel en 30 secondes - L'Article 72 du Règlement (UE) 2024/1689 impose aux fournisseurs d'IA de haut risque un système de surveillance après commercialisation pour détecter activement les dérives. - Dix catégories de systèmes d'IA de haut risque sont concernées (Art. 6(2) et Annexe III). - Le plan de monitoring doit inclure des indicateurs de performance, des seuils d'alerte et une documentation traçable. - Les PME fournisseurs doivent conserver les rapports pendant au moins 10 ans (Art. 18). - Les incidents graves doivent être notifiés aux autorités sous 15 jours maximum (Art. 73). - Le non-respect expose à des amendes pouvant atteindre 15 millions d'euros ou 3 % du chiffre d'affaires mondial (Art. 99(4)).

La mise sur le marché d'un système d'IA de haut risque ne marque pas la fin de vos obligations. Elle en marque le début. L'Article 72 du Règlement (UE) 2024/1689 — l'EU AI Act — crée une obligation continue de surveillance qui s'étend sur toute la durée de vie du système. Cet article détaille les étapes opérationnelles pour bâtir un dispositif conforme, adapté aux ressources d'une PME française.

1. Comprendre l'obligation légale de monitoring post-marché

L'Article 72 du Règlement (UE) 2024/1689 instaure un dispositif appelé « post-market monitoring system » (PMM). Il s'agit d'un processus structuré et continu, propre au fournisseur, qui collecte et analyse les données de performance du système d'IA tout au long de son cycle de vie.

L'objectif est triple : vérifier que le système reste conforme aux exigences du Chapitre III, détecter les évolutions de risque non anticipées et documenter ces observations pour les autorités de surveillance du marché.

Le périmètre d'application vise principalement les fournisseurs au sens de l'Art. 3(3), c'est-à-dire toute entité qui développe ou fait développer un système d'IA et le met sur le marché sous son nom. Pour une PME française qui édite un logiciel SaaS intégrant un modèle décisionnel, l'obligation s'applique pleinement dès lors que le système relève du haut risque.

Élément	Exigence Art. 72	Référence légale
Forme	Système documenté et proportionné	Art. 72(1)
Périmètre	Toute la durée de vie du système	Art. 72(1)
Données collectées	Performance + interactions + retours d'usage	Art. 72(2)
Plan formel	Inclus dans la documentation technique	Art. 72(3)
Coopération autorités	Données transmises sur demande	Art. 72(1)

À retenir : le PMM n'est pas un audit ponctuel. C'est une posture organisationnelle qui s'inscrit dans le système de gestion de la qualité prévu à l'Art. 17.

2. Identifier les systèmes d'IA soumis à l'Article 72

Avant de bâtir un plan de surveillance, il faut établir si votre système relève bien du haut risque. Deux voies de qualification existent.

Voie 1 — Annexe I (Art. 6(1)) : le système d'IA est un composant de sécurité d'un produit soumis à la législation d'harmonisation de l'Union (jouets, dispositifs médicaux, ascenseurs, équipements radio, etc.) ET ce produit fait l'objet d'une évaluation de conformité par tiers.

Voie 2 — Annexe III (Art. 6(2)) : le système relève de l'une des huit catégories d'usage à haut risque. La numérotation passe à dix avec les sous-catégories pratiques utilisées par la doctrine.

Catégorie Annexe III	Exemple PME concret
Biométrie à distance	Solution de contrôle d'accès par reconnaissance faciale
Infrastructures critiques	Optimisation IA d'un réseau de distribution d'eau
Éducation et formation	Outil de notation automatisée d'examens
Emploi et RH	Logiciel de tri de CV ou de scoring de candidats
Services essentiels (crédit)	Modèle de scoring de solvabilité pour prêts
Forces de l'ordre	Analyse prédictive (usage régalien, rarement PME)
Migration et asile	Évaluation de risque migratoire (régalien)
Administration de la justice	Aide à la décision judiciaire
Processus démocratiques	Influence sur le comportement électoral
Assurance vie et santé	Tarification IA de polices d'assurance

Pour le scoring de candidats RH, l'Annexe III, point 4(a) qualifie expressément l'outil de système à haut risque. Un éditeur PME français qui propose ce type de solution doit donc déployer un PMM dès la mise sur le marché.

L'Art. 6(3) prévoit une dérogation : un système relevant de l'Annexe III peut échapper au classement haut risque s'il ne présente pas de risque significatif (tâche procédurale étroite, amélioration d'une activité humaine antérieure, détection de schémas décisionnels sans remplacement, tâche préparatoire). Cette dérogation suppose une évaluation documentée que le fournisseur doit enregistrer dans la base EU (Art. 49(2)). Sans cette évaluation, le classement haut risque s'applique par défaut.

Pour aller plus loin sur la qualification, consultez le glossaire regulia et le pillar AI Act pour les PME françaises.

3. Élaborer un plan de monitoring post-marché

L'Art. 72(3) impose un plan de surveillance après commercialisation intégré à la documentation technique prévue à l'Annexe IV. Ce plan n'est pas un document marketing. C'est un livrable technique opposable, que les autorités peuvent exiger lors d'une inspection.

Le plan doit décrire au minimum les éléments suivants :

1. La méthode de collecte des données pertinentes (logs applicatifs, retours utilisateurs, signalements internes).
2. Les indicateurs de performance et de risque suivis.
3. Les seuils d'alerte qui déclenchent une analyse approfondie.
4. La gouvernance interne (qui surveille, qui décide, qui escalade).
5. Les modalités d'archivage et de mise à disposition des autorités.

Le futur acte d'exécution de la Commission précisera le modèle harmonisé de ce plan (Art. 72(3), 2ème alinéa), attendu avant le 2 février 2026. En attendant, le Cigref et Numeum recommandent de s'inspirer du gabarit ISO/IEC 42001:2023, section 8.4 (operational monitoring).

KPI obligatoire	Mesure	Fréquence minimale
Précision globale	Taux de réponses correctes vs. vérité terrain	Mensuelle
Dérive du modèle	Drift statistique des distributions d'entrée	Hebdomadaire
Biais démographique	Écart de performance par groupe protégé	Trimestrielle
Incidents utilisateurs	Nombre de réclamations qualifiées	Continue
Disponibilité technique	Uptime et latence	Continue

Un plan correctement calibré est proportionné : l'Art. 72(1) précise que le PMM doit l'être à la nature du système et à ses risques. Une PME n'a pas à déployer le même appareillage qu'un grand groupe industriel.

4. Mettre en place des outils de monitoring

Le choix outillé conditionne la viabilité du dispositif. Pour une PME, l'enjeu consiste à combiner solutions open source et services managés sans alourdir la dette technique.

Couche modèle IA : MLflow Tracking permet de versionner les modèles et de stocker les métriques d'évaluation. Evidently AI génère automatiquement des rapports de drift et de biais. TensorFlow Model Analysis ou Vertex AI Model Monitoring conviennent pour les environnements Google Cloud.

Couche infrastructure : Prometheus collecte les métriques système, Grafana visualise et alerte. Un seuil dépassé déclenche une notification Slack, Teams ou e-mail vers le responsable IA.

Couche métier : un formulaire de signalement intégré à l'application capte les retours utilisateurs. Les outils de ticketing classiques (Jira Service Management, Freshdesk) permettent de qualifier et historiser ces remontées.

Besoin	Solution open source	Solution managée
Tracking expériences	MLflow	Weights & Biases
Drift détection	Evidently AI	Arize, Fiddler
Métriques infra	Prometheus + Grafana	Datadog, New Relic
Logs centralisés	Loki, ELK	Splunk, Datadog Logs
Signalements utilisateurs	Issue tracker maison	Zendesk, Freshdesk

L'important n'est pas l'exhaustivité de l'outillage mais la chaîne complète : collecte → analyse → alerte → décision → traçabilité.

5. Collecter et analyser les données de performance

L'Art. 72(2) impose la collecte, l'analyse et l'évaluation des données pertinentes — qu'elles soient fournies par les déployeurs ou collectées via d'autres sources — sur la performance des systèmes d'IA pendant toute leur durée de vie.

Quatre familles de données structurent l'analyse :

• Données d'entrée : nature des inputs reçus en production, comparées à la distribution d'entraînement.
• Données de sortie : prédictions ou décisions générées, avec leur niveau de confiance.
• Métriques de qualité : précision, rappel, F1-score, AUC selon le type de modèle.
• Métriques d'impact : taux de contestation, taux de modification humaine, retours qualifiés.

L'analyse des biais mérite une attention particulière. Le Considérant 67 du Règlement et l'Art. 10(2)(f-g) imposent d'examiner les biais possibles affectant la santé, la sécurité ou les droits fondamentaux. Concrètement, il faut segmenter les performances par variable sensible (genre, âge, origine apparente, situation de handicap) et vérifier l'écart entre les groupes.

La CNIL, dans ses fiches pratiques IA publiées entre 2024 et 2025, recommande d'utiliser des métriques d'équité standardisées (parité démographique, égalité des chances, calibration par groupe). Le choix de la métrique dépend de l'usage et doit être documenté.

Type de problème	Métrique d'équité recommandée
Recrutement, accès au crédit	Disparate impact ratio (objectif > 0,8)
Diagnostic médical	Equal opportunity (TPR par groupe)
Notation automatisée	Calibration (taux d'erreur par groupe)
Modération de contenu	Equalized odds (TPR + FPR équilibrés)

Ces analyses doivent être conduites avant la mise en production, puis répétées au rythme défini par le plan de surveillance.

6. Gérer les anomalies et les déviations

Détecter une anomalie n'est utile que si elle déclenche une action. Le PMM doit donc inclure une procédure de gestion des incidents articulée avec l'Art. 73 (notification des incidents graves).

Étape 1 — Qualification. L'anomalie est-elle un faux positif, une dégradation transitoire ou une dérive structurelle ? Le responsable IA dispose de critères écrits pour trancher.

Étape 2 — Notification interne. Toute anomalie qualifiée est consignée dans le registre des incidents. Le dirigeant et le DPO sont informés selon la gravité.

Étape 3 — Action corrective. Selon la cause racine : réentraînement du modèle, ajustement des seuils, retrait temporaire, mise à jour de la documentation.

Étape 4 — Notification externe. L'Art. 73(1) impose au fournisseur de signaler tout incident grave à l'autorité de surveillance du marché de l'État membre où l'incident s'est produit. L'Art. 3(49) définit l'incident grave comme tout incident entraînant le décès ou un préjudice grave à la santé, une perturbation grave d'une infrastructure critique, une violation du droit de l'Union protégeant les droits fondamentaux ou un préjudice grave à des biens ou à l'environnement.

Type d'incident	Délai de notification	Référence
Incident grave (général)	Immédiat, max 15 jours	Art. 73(2)
Décès	Max 10 jours	Art. 73(3)
Perturbation infrastructure critique	Max 2 jours	Art. 73(4)
Violation grave droits fondamentaux	Immédiat, max 15 jours	Art. 73(2)

L'autorité française de surveillance du marché pour l'AI Act n'est pas encore désignée définitivement à ce jour [à vérifier selon évolution réglementaire]. La CNIL coordonne la position française et publie ses recommandations sur cnil.fr/fr/ai-act.

Pour comprendre l'échelle des sanctions, voir AI Act sanctions PME amendes.

7. Documenter et rapporter les résultats

La documentation est le socle probatoire de votre conformité. En cas de contrôle, l'autorité ne se contente pas d'observer le système : elle réclame des preuves traçables que le PMM fonctionne réellement.

Trois registres minimaux structurent la documentation :

1. Registre des audits trimestriels : date, périmètre, indicateurs mesurés, écarts constatés, signature du responsable.
2. Registre des incidents et anomalies : horodatage, qualification, action corrective, statut de résolution.
3. Journal de bord du modèle : versions, ré-entraînements, modifications de seuils, changements de jeu de données.

L'Art. 18 impose au fournisseur de conserver la documentation technique pendant 10 ans après la mise sur le marché du système. Cette durée s'applique aussi aux rapports de PMM puisqu'ils en font partie intégrante (Annexe IV, point 9).

Document	Durée de conservation	Base légale
Documentation technique complète	10 ans	Art. 18(1)
Logs générés automatiquement	6 mois minimum	Art. 19(1)
Déclaration UE de conformité	10 ans	Art. 47(1)
Rapports PMM	10 ans (partie doc technique)	Art. 18(1) + Annexe IV

Côté outillage, un coffre-fort numérique horodaté (type Digiposte Pro, Yousign Vault) garantit la non-répudiation. Un dépôt Git privé avec signatures GPG fait également l'affaire pour les artefacts techniques.

8. Exemples concrets pour les PME

Cas 1 — Éditeur SaaS de scoring crédit (15 salariés, Lyon). Le système attribue un score de solvabilité à des dossiers de prêt à la consommation. Classement : haut risque (Annexe III, point 5(b)). Le PMM mis en place comprend un dashboard Grafana qui suit en continu le drift des variables d'entrée, un rapport mensuel d'équité par tranche d'âge et code postal, et une revue trimestrielle signée par le dirigeant et un consultant juridique externe.

Cas 2 — Plateforme de tri de CV (40 salariés, Paris). Le moteur de matching repose sur des embeddings sémantiques. Classement : haut risque (Annexe III, point 4(a)). Le PMM combine MLflow pour le versioning, Evidently AI pour les rapports de biais (genre, origine apparente détectée par proxy), et un formulaire de contestation intégré à l'interface candidat. Tout candidat refusé peut déclencher une revue humaine documentée — exigence couplée à l'Art. 26 (obligations des déployeurs) côté entreprise cliente.

Cas 3 — Logiciel d'aide au diagnostic dermatologique (12 salariés, Bordeaux). L'application analyse des photos de lésions cutanées. Double qualification : haut risque par Annexe I (dispositif médical de classe IIa sous MDR) ET potentiellement par Annexe III. Le PMM s'articule avec le système de vigilance médicale ANSM existant. Les incidents graves sont notifiés simultanément à l'ANSM et à l'autorité AI Act dans les délais cumulatifs les plus courts.

PME type	Outils retenus	Coût annuel indicatif
Scoring crédit (15p)	MLflow + Grafana + audit externe	8 000 – 15 000 €
Tri CV (40p)	MLflow + Evidently + ticketing	12 000 – 20 000 €
Diagnostic médical (12p)	MLflow + outils ANSM existants	15 000 – 25 000 €

Ces ordres de grandeur incluent la mise en place initiale et la première année d'exploitation. Ils excluent les coûts liés à une éventuelle évaluation de conformité par organisme notifié.

FAQ

Q : Quels sont les systèmes d'IA de haut risque concernés par le monitoring post-marché ?

R : Les systèmes d'IA de haut risque couvrent les huit catégories de l'Annexe III du Règlement (UE) 2024/1689 (avec leurs sous-catégories) ainsi que les composants de sécurité de produits soumis à la législation d'harmonisation de l'Union (Annexe I). Pour les PME françaises, les cas les plus fréquents concernent le scoring crédit, le tri de candidatures, la notation pédagogique et certains dispositifs médicaux. Le glossaire regulia précise chaque catégorie.

Q : Quelles sont les conséquences d'une non-conformité avec l'Article 72 ?

R : Le manquement aux obligations de monitoring est sanctionné selon l'Art. 99(4) du Règlement : amendes administratives jusqu'à 15 millions d'euros ou 3 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu. Pour les PME, l'Art. 99(6) prévoit que la sanction est calculée sur le montant le plus bas, ce qui ne réduit pas mécaniquement le risque. L'autorité peut également ordonner le retrait du système. Détails dans AI Act sanctions PME amendes.

Q : Comment les PME peuvent-elles mettre en place un monitoring efficace avec des ressources limitées ?

R : Trois leviers concrets : combiner des outils open source (MLflow, Evidently, Prometheus, Grafana) pour le socle technique, mutualiser la fonction de responsable IA avec le DPO ou le RSSI existant, et s'appuyer sur des modèles documentaires éprouvés plutôt que de tout rédiger. Le pillar AI Act PME France détaille la feuille de route opérationnelle.

Q : Quelle est la fréquence minimale des audits de monitoring post-marché ?

R : Le Règlement n'impose pas de fréquence chiffrée universelle. L'Art. 72(1) exige une surveillance « proportionnée à la nature des technologies d'IA et aux risques » du système. La pratique consolidée par Cigref (janvier 2025) et Numeum (mars 2025) recommande un audit trimestriel formel, complété par une supervision continue automatisée des indicateurs de drift et de biais.

Q : Doit-on notifier les autorités en cas de détection d'anomalies ?

R : Toute anomalie ne déclenche pas une notification. Seuls les incidents graves au sens de l'Art. 3(49) doivent être signalés à l'autorité de surveillance du marché compétente, conformément à l'Art. 73. Les délais varient de 2 à 15 jours selon la nature de l'incident. Les anomalies non graves doivent être consignées dans le registre interne et traitées via le processus correctif documenté.

Sources officielles

• Texte consolidé du Règlement (UE) 2024/1689 — artificialintelligenceact.eu
• Version officielle EUR-Lex du Règlement IA
• CNIL — Page dédiée à l'AI Act
• AI Act Service Desk de la Commission européenne
• Pillar regulia : AI Act pour les PME françaises
• Sanctions et amendes Art. 99 — calculateur regulia
• Glossaire regulia
• Liste complète des sources

---

Disclaimer. Cet article fournit des informations générales sur l'EU AI Act applicables aux PME françaises. Il ne constitue pas un conseil juridique. Pour toute décision opérationnelle, faites valider votre démarche par votre DPO ou conseil juridique. regulia décline toute responsabilité quant à l'usage qui peut être fait de ces informations.