Comment surveiller les systèmes d'IA en vertu du règlement IA de l'UE
Une fois qu'un système d'IA est en service, le droit cesse de demander « a-t-il été construit correctement ? » pour demander « se comporte-t-il encore correctement ? ». En vertu du règlement IA de l'UE, surveiller un système d'IA en exploitation est une obligation juridique continue, et non une option facultative. Ce guide explique quoi surveiller, qui en est responsable, comment adapter l'effort au niveau de risque du système, et une distinction qui déconcerte la plupart des équipes : surveiller un système d'IA n'est pas la même chose que surveiller les personnes qui l'utilisent.
La surveillance est une obligation juridique, pas une option
Plusieurs articles du règlement IA, lus conjointement, rendent la surveillance continue obligatoire pour les systèmes d'IA à haut risque :
- Surveillance après commercialisation (article 72) — Les fournisseurs doivent collecter, documenter et analyser de manière active et systématique les données sur les performances du système tout au long de sa vie, afin de confirmer son maintien en conformité.
- Journalisation automatique (articles 12 et 19) — Les systèmes à haut risque doivent enregistrer automatiquement les événements tout au long de leur vie, et les journaux doivent être conservés pendant au moins six mois.
- Surveillance par le déployeur (article 26) — Les organisations qui utilisent un système à haut risque doivent surveiller son fonctionnement au regard de la notice d'utilisation et signaler les risques ou les incidents graves.
- Exactitude et robustesse sur le cycle de vie (article 15) — Les niveaux de performance déclarés doivent se maintenir de façon constante en production, pas seulement le jour du lancement.
- Contrôle humain (article 14) — Le contrôle doit rester effectif pendant l'utilisation du système, avec la capacité d'en interpréter les résultats, d'intervenir et de l'arrêter.
- Signalement des incidents graves (article 73) — Les incidents qui causent un préjudice grave doivent être signalés aux autorités immédiatement, et au plus tard 15 jours après en avoir eu connaissance.
Les dix dimensions de la surveillance d'un système d'IA
Concrètement, surveiller un système d'IA revient à observer dix dimensions tout au long de sa vie. Vous n'avez pas besoin d'une équipe de science des données pour les renseigner — la plupart se lisent dans des journaux et des revues qu'un responsable de la conformité contrôle déjà.
| Dimension | Ce que vous observez | Un KPI que vous pouvez réellement rapporter |
|---|---|---|
| Performance vs référence | Exactitude ou qualité réelle au regard de la valeur déclarée lors de la mise en service | Exactitude observée vs déclarée (p. ex. 92 % → 88,5 %, −3,5 pp) |
| Dérive des données et du concept | Si les entrées — et la relation entrée-résultat — se sont écartées de l'entraînement | Indice de dérive par caractéristique clé vs seuil ; % d'entrées hors distribution |
| Qualité des données | Intégrité des données entrant dans le système avant que le modèle ne les traite | % d'enregistrements passant la validation ; taux de valeurs nulles/obsolètes ; enregistrements mis en quarantaine |
| Fiabilité et latence | Si le service est disponible et suffisamment rapide en tant que système opérationnel | % de disponibilité vs SLA ; latence p95 ; taux d'erreurs techniques |
| Biais et équité | Si les résultats diffèrent de façon injustifiée entre groupes protégés ou sensibles | Disparité du taux de sélection (règle des 80 %) ; écart de taux d'erreur entre groupes |
| Sécurité et abus | Attaques et usages détournés : injection de requête, entrées adversariales, fuite de données | Tentatives de contournement détectées ; taux de déclenchement des garde-fous ; fuites bloquées |
| Contrôle humain | Qu'une personne puisse réellement superviser les résultats et passer outre — et le fasse | Taux de dérogation ; % de décisions à fort impact revues par un humain ; escalades |
| Incidents et quasi-incidents | Résultats nuisibles ou erronés, et ceux qui ont été interceptés à temps | Incidents par gravité ; temps de détection/résolution ; % signalés dans les délais |
| Changements et gestion des versions | Un historique auditable de chaque modification du système en exploitation | Version active + date de mise en production ; % de changements passés par le contrôle d'approbation ; retours arrière |
| Revue périodique | Une réattestation planifiée que le système reste adapté à sa destination | % de revues réalisées à temps ; jours de retard ; systèmes avec une validation en cours valide |
Qui surveille quoi : fournisseur vs déployeur
La responsabilité est partagée entre l'organisation qui construit le système (le fournisseur) et celle qui l'utilise (le déployeur). Beaucoup d'entreprises sont les deux — elles achètent un modèle et l'intègrent dans leur propre produit.
Le fournisseur intègre la capacité de surveillance dans le système, exécute le plan de surveillance après commercialisation, conserve les journaux sous son contrôle, déclare les métriques d'exactitude dans la notice d'utilisation et signale les incidents graves aux autorités.
Le déployeur surveille le fonctionnement quotidien au regard de la notice d'utilisation, conserve ses propres journaux pendant au moins six mois, informe le fournisseur et les autorités des risques ou incidents et — pour les organismes publics et certains services — réalise une analyse d'impact sur les droits fondamentaux avant la mise en service.
Surveiller à la mesure du risque
Le règlement IA est fondé sur le risque, tout comme l'effort de surveillance. N'appliquez pas tout l'appareil à chaque système — adaptez la profondeur au risque et à votre taille :
- Systèmes à haut risque (annexe III) — l'appareil complet : un plan de surveillance après commercialisation documenté, une journalisation automatique, un contrôle humain, des KPI de dérive et de performance, et le signalement des incidents graves.
- Systèmes à risque limité / à seule transparence — une approche plus légère : un suivi d'usage de base, un référent désigné pour le contrôle et une revue périodique — pas l'appareil complet.
- PME et petites entreprises à moyenne capitalisation — le règlement autorise expressément une documentation et une gestion de la qualité simplifiées et proportionnées. Dimensionnez la profondeur selon le risque et la taille de l'entreprise, plutôt que de tout maximiser.
Le Digital Omnibus (accord provisoire, mai 2026) a reporté les obligations relatives au haut risque au 2 décembre 2027 (annexe III) et au 2 août 2028 (annexe I), et a remplacé le modèle obligatoire de plan de surveillance par un cadre flexible. La leçon pour tout dispositif de surveillance : construisez une base configurable que vous pourrez réorienter à mesure que paraissent les orientations, et non un dispositif ponctuel calé sur un formulaire figé. (Ces modifications sont convenues mais en attente de publication définitive, traitez donc les dates comme quasi définitives plutôt qu'acquises.)
Surveiller le système n'est pas surveiller les salariés
Surveiller un système d'IA n'est pas la même chose que surveiller les personnes qui utilisent l'IA. La première observe le modèle et ses résultats et relève du règlement IA. La seconde observe votre propre personnel — qui utilise quel outil d'IA, combien et pour quoi — et c'est de la surveillance sur le lieu de travail, régie par le RGPD, les règles ePrivacy et le droit du travail national, pas par le règlement IA.
Suivre l'usage que les salariés font d'un outil tel qu'un assistant d'IA requiert généralement une base légale, une analyse d'impact relative à la protection des données, une transparence préalable et — dans plusieurs États de l'UE — un accord avec les représentants du personnel avant de l'activer (en France, une consultation du CSE). Gardez les deux programmes distincts : responsables différents, bases légales différentes, preuves différentes. Faire entrer la surveillance du personnel dans la « surveillance de l'IA » est une erreur coûteuse.
À quoi ressemble une bonne preuve
Lorsqu'un auditeur — ou, de plus en plus, un demandeur au titre de la directive révisée sur la responsabilité du fait des produits — demande comment vous surveillez, voici les artefacts qui répondent :
- Un plan de surveillance après commercialisation documenté, avec des KPI, des seuils et une cadence de revue définis.
- Des enregistrements de métriques chronologiques, et les alertes déclenchées au franchissement d'un seuil.
- Des journaux immuables de l'utilisation du système et de chaque dérogation ou intervention humaine.
- Un registre des incidents avec analyse des causes profondes et preuve d'une notification réglementaire en temps voulu.
- Un compte rendu de revue périodique signé, nommant le responsable redevable et la décision de poursuite de l'utilisation.
Comment LandingRed vous aide : LandingRed en fait un système opérationnel — un plan de surveillance après commercialisation par système d'IA, un suivi des KPI avec des alertes de seuil qui se transforment automatiquement en incidents, des journaux immuables au titre de l'article 12 avec conservation imposée, des enregistrements de contrôle humain et un dossier de preuves prêt pour l'audit — dimensionné au niveau de risque de chaque système.
LandingRed automatise tout cela
Arrêtez de gérer la conformité dans des feuilles de calcul. Classifiez, documentez, évaluez et surveillez vos systèmes d'IA depuis une seule plateforme.