Surveillance après commercialisation de l’IA : transformer les signaux d’utilisation en contrôles vérifiables

Ce qu’exige la surveillance après commercialisation

La surveillance après commercialisation est le système par lequel le fournisseur recueille et analyse des informations pertinentes sur les performances d’un système d’IA à haut risque après sa mise sur le marché ou sa mise en service. Son objectif n’est pas d’accumuler des journaux pour eux-mêmes : elle doit permettre au fournisseur de vérifier si le système continue de satisfaire aux exigences applicables et si des problèmes nécessitant une enquête ou une intervention sont apparus.

L’article 72 du règlement sur l’IA attribue au fournisseur la responsabilité de mettre en place et de documenter ce système. Celui-ci doit être proportionné à la nature de la technologie et aux risques du système. Le fournisseur doit également disposer d’un plan de surveillance après commercialisation intégré à la documentation technique. En pratique, le plan explique comment les données seront obtenues et analysées, quels signaux peuvent révéler un écart et comment il sera décidé s’il faut intervenir.

Cette obligation concerne les systèmes d’IA à haut risque. Elle ne signifie pas que tous les fournisseurs doivent surveiller tous les produits avec la même intensité ni qu’ils doivent collecter toutes les données disponibles. La proportionnalité compte : les sources, les indicateurs et la fréquence des examens doivent présenter un lien raisonnable avec l’utilisation prévue, le contexte de déploiement et les risques que le système est susceptible de présenter.

Il est utile de distinguer deux niveaux. L’exigence juridique consiste à disposer d’un système et d’un plan appropriés et documentés. Les indicateurs, seuils et routines proposés dans ce guide sont des options de conception destinées à rendre cette obligation opérationnelle ; ils ne constituent pas une liste universelle imposée par le règlement.

Que surveiller et d’où peuvent provenir les données

Le règlement envisage des données pertinentes communiquées par les déployeurs ainsi que des données obtenues auprès d’autres sources. Cela laisse à chaque fournisseur une marge de manœuvre pour concevoir un système adapté à son produit, sans pour autant supprimer la nécessité de justifier la pertinence d’une source ni la manière dont elle sera interprétée. Les données doivent servir à évaluer les performances du système pendant toute sa durée de vie et à détecter les changements susceptibles d’influer sur la conformité ou les risques.

Un inventaire initial peut comprendre des indicateurs de fonctionnement, des résultats anormaux, des incidents techniques, des réclamations, des retours structurés des utilisateurs, des demandes d’assistance et des changements dans les conditions d’utilisation. Selon le système, il peut aussi être pertinent de surveiller les changements dans la population utilisatrice, dans les données d’entrée ou dans les processus auxquels le système est intégré. Tous ces signaux ne sont pas obligatoires dans tous les cas : leur utilité dépend du contexte et du risque à surveiller.

Les interactions avec d’autres systèmes d’IA méritent une attention particulière lorsqu’elles sont pertinentes pour comprendre les performances ou les risques. Par exemple, un outil peut recevoir les résultats d’un autre système ou alimenter un processus automatisé avec ses propres sorties. Dans ce cas, un changement du système connecté, du format des données ou du flux de travail peut modifier le comportement observé sans que le modèle surveillé ait changé. Le plan devrait préciser quelles dépendances sont pertinentes et comment les changements qui les affectent seront détectés.

La coopération avec le déployeur est importante, car le fournisseur ne voit pas nécessairement toutes les conditions d’utilisation réelles. Un accord opérationnel peut préciser les catégories de données communiquées, la personne chargée de les préparer, leur fréquence, le canal utilisé et les destinataires des signaux urgents. Il s’agit d’une recommandation pratique : le règlement ne transforme pas cette liste précise en formulaire obligatoire. L’échange doit être limité à ce qui est nécessaire aux fins de la surveillance et respecter les autres obligations applicables.

Concevoir un plan applicable en pratique

Un plan opérationnel commence par l’utilisation prévue et les risques que le système peut présenter dans ce contexte. Il recense ensuite les données susceptibles de révéler un changement important et les décisions qui pourraient en découler. Un tableau d’indicateurs dépourvu de responsables, de critères d’examen ou de voies d’action est difficile à utiliser et ne permet guère de comprendre comment un signal a été traité.

Il est utile de répartir les responsabilités. Une équipe technique peut valider la qualité des données et analyser le comportement ; l’équipe produit peut évaluer les changements de fonctionnalités ou de conditions d’utilisation ; la fonction conformité peut vérifier les obligations applicables et la documentation ; enfin, une personne ou une équipe disposant d’une autorité clairement définie peut décider s’il convient de faire remonter le problème. Dans les petites organisations, une même personne peut assumer plusieurs rôles, mais les décisions et leurs motifs doivent rester identifiables.

Les indicateurs doivent être formulés de façon à permettre un examen cohérent. Ils peuvent inclure les taux d’erreur, les indisponibilités, les changements de distribution des entrées, les écarts entre des groupes pertinents pour l’évaluation du système ou l’augmentation du nombre de résultats nécessitant une vérification humaine. Un indicateur n’est utile que si son mode de calcul, la période observée et ses limites sont définis. Il ne faut pas présenter une mesure comme une preuve concluante si elle constitue seulement un signal à examiner.

Le fournisseur peut définir des niveaux d’alerte internes. Par exemple, un changement dépassant un seuil convenu peut déclencher un examen technique ; si ce changement se répète ou apparaît dans plusieurs déploiements, une évaluation plus large peut être justifiée. Ces seuils sont des outils de gestion recommandés, et non des valeurs fixées de manière générale par l’article 72. Il convient de les réexaminer en cas de changement de l’utilisation, des éléments disponibles ou du profil de risque.

Examiner les signaux et consigner les décisions

Un signal ne constitue pas automatiquement un manquement. Il peut être dû à des données incomplètes, à un changement dans le processus du client, à un problème temporaire ou à une véritable dégradation. L’examen doit permettre de distinguer ces possibilités et de consigner les informations analysées. Si le signal concerne plusieurs déploiements, il est utile de vérifier s’il existe une cause commune, telle qu’une version particulière, une dépendance partagée ou un changement des conditions d’entrée.

Un registre de décisions utile indique la date de détection, la source, le système et la version concernés, la description du signal, la personne chargée de l’évaluation, les éléments examinés, la conclusion et les étapes suivantes. Si aucune mesure n’est adoptée, le registre devrait expliquer pourquoi les informations disponibles ne justifiaient pas d’agir et quelles conditions conduiraient à rouvrir le dossier. Ce niveau de détail constitue une bonne pratique documentaire, et non un format fermé prescrit par le règlement.

Les mesures possibles dépendent du constat. Elles peuvent consister à corriger un défaut, à mettre à jour les instructions, à modifier une intégration, à renforcer les contrôles humains, à limiter temporairement certaines utilisations ou à lancer un examen technique plus approfondi. La mesure choisie doit être en rapport avec le problème observé et être documentée. Si le signal indique que le système ne satisfait plus aux exigences applicables ou que des risques non pris en compte sont apparus, le fournisseur doit relier ce constat à ses processus d’évaluation et de gestion des risques, plutôt que de le traiter comme une simple demande isolée au service client.

Le déployeur doit également savoir quelles informations sont importantes pour utiliser correctement le système et signaler les problèmes pertinents. Le plan doit donc prévoir un canal de remontée et un mécanisme de retour d’information vers le fournisseur. Pour les produits utilisés par plusieurs clients, une voie cohérente évite que des signaux similaires restent dispersés entre différentes équipes d’assistance.

Surveillance, gestion des risques, évaluations d’impact et incidents

La surveillance après commercialisation ne remplace pas la gestion des risques. Celle-ci est un processus plus large d’identification, d’analyse et de traitement des risques qui doit accompagner le système. La surveillance fournit des informations sur son fonctionnement réel et peut révéler qu’une hypothèse antérieure ne tient plus, qu’un nouveau risque est apparu ou qu’une mesure de contrôle ne fonctionne pas comme prévu. Le plan doit permettre à ces signaux d’atteindre les personnes en mesure de réexaminer les évaluations et les mesures existantes.

La surveillance ne se confond pas non plus avec une évaluation d’impact préalable au déploiement. Une évaluation préalable examine les effets possibles dans un contexte et avant une utilisation donnée, lorsqu’elle est applicable. La surveillance observe des informations tout au long du cycle de vie du système et aide à détecter les changements qui ne deviennent visibles qu’en situation d’utilisation. Ces activités se complètent : aucune ne prouve à elle seule que le système continuera à se comporter de la même manière après son déploiement.

La notification des incidents graves prévue à l’article 73 répond à un autre déclencheur et poursuit un autre objectif : elle concerne les incidents qui doivent être signalés conformément aux règles applicables. La surveillance, en revanche, doit fonctionner de manière systématique et ne pas attendre qu’un incident grave se produise. Un signal peut justifier une enquête et des mesures préventives même s’il n’a pas encore atteint le seuil d’un incident à notifier. Et si un incident soumis à notification est identifié, le processus de surveillance ne remplace pas la communication exigée.

Pour éviter toute confusion, les organisations peuvent relier les processus sans les fusionner : un même événement peut ouvrir une enquête de surveillance et, séparément, déclencher l’évaluation de l’obligation de notifier un incident. Le registre devrait indiquer quelle voie a été envisagée, qui a pris la décision et quelles actions ont été lancées. Cette séparation aide à ne pas sous-estimer un signal précoce ni à traiter automatiquement chaque écart mineur comme un incident grave.

Cas particuliers et calendrier réglementaire

L’article 72 prévoit une précaution particulière pour certains systèmes à haut risque utilisés dans le domaine répressif : le système de surveillance ne couvre pas les données opérationnelles sensibles détenues par les autorités répressives. Cette exclusion est spécifique. Elle ne doit pas être interprétée comme une exemption générale de surveillance pour tout système utilisé par une autorité, ni comme une autorisation d’ignorer d’autres signaux pertinents susceptibles d’être traités conformément aux règles applicables.

La réforme réglementaire de 2026 a modifié la disposition relative aux orientations de la Commission. Le règlement prévoit que la Commission publie des orientations et un modèle facultatif de plan de surveillance après commercialisation avant le 2 septembre 2027. Le modèle ne doit donc pas être présenté comme un outil déjà disponible ni comme une exigence obligatoire en soi. Dans l’intervalle, les fournisseurs peuvent structurer leur documentation à partir des obligations juridiques en vigueur et de leurs besoins opérationnels.

Le calendrier d’application des règles aux systèmes à haut risque a également été modifié. Le texte consolidé établit des dates différentes selon la catégorie : pour les systèmes à haut risque visés à l’annexe III, l’application des obligations pertinentes commence le 2 décembre 2027 ; pour les systèmes à haut risque régis par la législation d’harmonisation énumérée à l’annexe I, elle commence le 2 août 2028. La classification et la date applicable doivent être vérifiées pour chaque système ; il convient de ne pas extrapoler une date à tous les produits d’IA.

Ces dates ne diminuent pas l’intérêt de préparer le cycle de surveillance à l’avance. La conception des sources de données, des accords d’échange et des responsabilités exige souvent une coordination entre fournisseur et client. Toutefois, la préparation opérationnelle ne doit pas être confondue avec l’affirmation qu’une obligation s’applique déjà à un système donné avant la date pertinente.

Liste de contrôle pour examiner le plan

La valeur pratique d’un plan ne se mesure pas à sa longueur, mais à sa capacité à permettre de reconstituer la manière dont le système est surveillé et ce qui se passe lorsqu’un signal apparaît. Les questions ci-dessous peuvent servir à un examen interne. Elles ne remplacent pas l’analyse juridique du système, de sa classification ou de ses obligations particulières.

Un plan solide identifie le système et ses utilisations pertinentes, explique les sources d’information utilisées et les raisons de ce choix, attribue des responsabilités et définit une routine d’analyse. Il prévoit également comment les signaux circulent entre le fournisseur et le déployeur, comment les décisions sont conservées et comment les constats sont reliés à un réexamen des risques ou à une mesure corrective.

L’examen devrait également vérifier si les indicateurs sont interprétables, si les alertes débouchent sur des actions concrètes et si l’équipe sait distinguer une anomalie dans les données d’une dégradation du système. Si un changement de version, une nouvelle intégration ou une modification du contexte est susceptible d’affecter les performances, le plan doit préciser comment ce changement sera détecté et comment la surveillance sera réexaminée.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.