Introduction
Une organisation peut valider un système d’intelligence artificielle, documenter son usage, tester ses performances, encadrer ses risques et conclure qu’il est conforme. Pourtant, quelques mois plus tard, le même système peut produire des résultats moins fiables, plus biaisés ou moins adaptés au contexte métier.
Le problème ne vient pas toujours d’une mauvaise conception initiale. Il vient souvent d’un phénomène plus discret : le model drift, c’est-à-dire la dérive progressive d’un système IA après son déploiement.
Dans un environnement réel, les données évoluent, les comportements utilisateurs changent, les processus métier se transforment, les modèles sont mis à jour, les fournisseurs modifient leurs API, les usages se déplacent. Un système IA validé à un instant donné peut donc perdre progressivement les conditions qui justifiaient sa conformité initiale.
La question devient centrale pour la gouvernance IA :
Une IA peut-elle rester conforme si ses données, son usage, ses performances ou son contexte métier évoluent ?
Cette question est directement liée aux nouveaux cadres de conformité. ISO/IEC 42001 exige d’établir, maintenir et améliorer continuellement un système de management de l’IA. ISO/IEC 23894 fournit des lignes directrices pour intégrer le management des risques dans les activités liées à l’IA. L’AI Act impose, pour les systèmes IA à haut risque, une logique de gestion des risques continue sur l’ensemble du cycle de vie.
Le model drift : quand la réalité change plus vite que le modèle
Un modèle IA apprend à partir d’un état passé du monde. Il est entraîné ou paramétré sur des données, des règles, des comportements et des objectifs observés à un moment donné. Or, dans la réalité, ces éléments ne restent pas stables.
Le drift peut prendre plusieurs formes.
Type de dérive | Ce qui change | Exemple |
Data drift | La distribution des données d’entrée | Les profils clients, les images, les requêtes ou les documents traités ne ressemblent plus aux données initiales |
Concept drift | La relation entre les variables et le résultat attendu | Un modèle de détection de fraude devient moins fiable parce que les fraudeurs changent de stratégie |
Performance drift | Les résultats du modèle se dégradent | Le taux d’erreur augmente ou la précision diminue |
Usage drift | Les utilisateurs emploient l’IA différemment de l’usage prévu | Un outil d’aide à la décision devient un outil de décision quasi automatique |
Context drift | Le contexte métier, réglementaire ou organisationnel évolue | Une politique interne, une règle métier ou une obligation réglementaire change sans mise à jour du système IA |
Les travaux académiques sur le concept drift montrent que les environnements évolutifs peuvent entraîner des dysfonctionnements, parfois critiques, et que la détection de ces dérives reste un sujet de recherche actif, notamment dans les contextes non supervisés où les labels ne sont pas immédiatement disponibles.
Le point important est le suivant : le drift n’est pas uniquement un sujet technique. Dans un système IA utilisé pour recruter, scorer un risque, prioriser des dossiers, détecter une fraude ou assister une décision médicale, une dérive devient rapidement un sujet de conformité, de responsabilité et de gouvernance.
La conformité initiale est une photographie, pas une garantie durable
Une validation initiale prouve qu’un système respecte certains critères à un moment donné. Elle peut démontrer que le modèle atteint un niveau de performance acceptable, que les risques connus ont été évalués, que les données ont été documentées et que les contrôles nécessaires ont été prévus.
Mais cette validation reste une photographie.
Le système conforme au moment du déploiement peut devenir problématique si les données changent, si les utilisateurs développent de nouveaux usages, si le modèle est réentraîné sans contrôle suffisant, ou si les seuils de décision ne sont plus adaptés.
C’est précisément ce que montre la recherche sur le data drift dans les systèmes critiques. Une étude publiée dans Nature Communications sur des données d’imagerie médicale réelles a évalué plusieurs méthodes de détection de drift, notamment avec l’émergence du COVID-19 dans les radiographies thoraciques. Les auteurs montrent que le simple suivi de la performance n’est pas toujours un bon indicateur de dérive et que la détection dépend fortement de la taille des échantillons et des caractéristiques des patients.
Cette conclusion est très importante pour les entreprises : surveiller uniquement l’accuracy ou le taux d’erreur global peut donner une impression de stabilité, alors que certaines populations, certains cas d’usage ou certains segments métier sont déjà affectés.
Le vrai risque : une IA toujours utilisée, mais plus conforme à son intention initiale
Le model drift fragilise la conformité parce qu’il rompt progressivement le lien entre trois éléments :
- l’intention déclarée,
- le comportement réel du système,
- l’impact produit dans l’organisation.
Un système IA peut rester techniquement disponible, produire des résultats, être utilisé quotidiennement, tout en s’éloignant de son objectif initial. C’est dans cet écart que le risque apparaît.
Exemple : une IA de scoring client a été validée pour assister une décision commerciale. Avec le temps, les équipes l’utilisent comme critère principal de priorisation. Le système n’a pas nécessairement changé, mais son usage réel a évolué. Le risque n’est plus seulement technique. Il devient organisationnel.
Autre exemple : un modèle de classification documentaire a été testé sur un corpus stable. Quelques mois plus tard, les formats de documents changent, de nouvelles typologies apparaissent et les erreurs augmentent sur certains cas. Si personne ne surveille cette évolution, l’organisation continue de faire confiance à un système qui ne fonctionne plus dans les mêmes conditions.
Dans les deux cas, la conformité initiale devient insuffisante. Le sujet n’est plus “le système a-t-il été validé ?” mais “le système reste-t-il maîtrisé dans ses conditions réelles d’utilisation ?”
L’AI Act transforme le drift en obligation de surveillance continue
L’AI Act pousse clairement vers une logique de conformité continue. Pour les systèmes IA à haut risque, le règlement prévoit un système de management des risques établi, documenté et maintenu. Il précise que ce système doit être compris comme un processus continu et itératif, mené sur l’ensemble du cycle de vie du système, avec des revues et mises à jour régulières.
L’article 72 va encore plus loin avec le post-market monitoring. Les fournisseurs de systèmes IA à haut risque doivent établir et documenter un système de surveillance post-marché proportionné à la nature de la technologie et aux risques. Ce système doit collecter, documenter et analyser des données pertinentes sur la performance du système tout au long de sa durée de vie, afin d’évaluer sa conformité continue.
Cette exigence change la logique de conformité. Le moment de mise sur le marché ou de mise en service ne clôture pas le sujet. Il ouvre une phase de surveillance.
Pour une entreprise, cela signifie qu’un dossier de conformité IA doit intégrer :
- les critères initiaux de performance ;
- les seuils d’alerte ;
- les indicateurs de dérive ;
- les responsabilités de surveillance ;
- les modalités de remontée d’incidents ;
- les procédures de correction ;
- les conditions de réévaluation du système.
La conformité IA devient alors un processus vivant.
ISO/IEC 42001 : installer une gouvernance capable d’absorber le changement
ISO/IEC 42001 est particulièrement pertinente face au model drift, car elle ne se limite pas à la validation technique d’un modèle. Elle vise l’établissement, la mise en œuvre, le maintien et l’amélioration continue d’un système de management de l’IA.
Cette logique est essentielle : le drift ne se traite pas uniquement avec un outil de monitoring. Il exige une organisation capable de détecter, décider, corriger et documenter.
Un système de management IA mature doit donc répondre à plusieurs questions :
- Qui surveille les performances du système ?
- Qui analyse les alertes de drift ?
- Qui décide du réentraînement ou de la suspension ?
- Qui valide les modifications ?
- Qui met à jour l’analyse de risques ?
- Qui informe les métiers, les utilisateurs ou les clients ?
- Qui conserve les preuves pour l’audit ?
Sans cette chaîne de responsabilité, le monitoring reste technique. Avec cette chaîne, il devient un mécanisme de gouvernance.
ISO/IEC 23894 : intégrer le drift dans le management des risques IA
ISO/IEC 23894 complète cette approche en fournissant des lignes directrices pour gérer les risques spécifiques liés à l’IA et les intégrer dans les activités de l’organisation.
Le model drift doit être traité comme une source de risque à part entière. Il peut affecter plusieurs dimensions :
Dimension affectée | Effet possible du drift |
Performance | baisse de précision, hausse des faux positifs ou faux négatifs |
Équité | dégradation sur certains groupes ou segments |
Sécurité | vulnérabilité accrue à certains comportements malveillants |
Conformité | écart entre documentation initiale et fonctionnement réel |
Supervision humaine | difficulté à interpréter des résultats moins stables |
Responsabilité | incertitude sur la cause d’une erreur ou d’un impact |
Le drift doit donc être intégré dans l’analyse de risques initiale, puis réévalué périodiquement. Une organisation qui ne prévoit pas de mécanisme de surveillance post-déploiement accepte implicitement que son niveau de risque réel puisse s’éloigner de son niveau de risque documenté.
NIST AI RMF : mesurer et piloter les risques dans le cycle de vie
Le NIST AI Risk Management Framework est également utile pour structurer cette réflexion. Il vise à aider les organisations à intégrer des considérations de confiance dans la conception, le développement, l’utilisation et l’évaluation des systèmes IA.
La logique du NIST AI RMF repose notamment sur quatre fonctions : gouverner, cartographier, mesurer et piloter. Le drift se situe au croisement de ces fonctions. Il faut gouverner les responsabilités, cartographier les usages, mesurer les signaux de dérive et piloter les actions correctives.
Le NIST a aussi publié en 2026 un rapport sur les défis du monitoring des systèmes IA déployés. Il identifie plusieurs catégories de surveillance : fonctionnalité, opérations, facteurs humains, sécurité, conformité et impacts à grande échelle. Le rapport mentionne explicitement la détection de la dégradation de performance et du drift comme une barrière pratique, aux côtés de la fragmentation des logs et de la complexité du paysage réglementaire.
Ce point est crucial : le monitoring IA ne doit pas uniquement suivre les métriques du modèle. Il doit aussi surveiller l’infrastructure, les usages humains, les risques de sécurité, les obligations réglementaires et les impacts réels.
Conclusion : la conformité IA se joue après le déploiement
Le model drift rappelle une vérité fondamentale : un système IA n’est pas conforme une fois pour toutes. Sa conformité dépend de sa capacité à rester fiable, contrôlé et aligné avec son usage prévu dans un environnement qui change.
La validation initiale reste nécessaire. Elle permet de poser un cadre, des critères et des preuves. Mais la vraie maturité se joue après le déploiement : dans la surveillance, la détection des dérives, l’analyse des signaux faibles, la réaction aux incidents et l’amélioration continue.
ISO/IEC 42001 apporte le cadre de management. ISO/IEC 23894 structure l’approche par les risques. L’AI Act impose une logique de surveillance continue pour les systèmes à haut risque. Le NIST AI RMF complète cette approche en insistant sur la mesure et le pilotage des risques tout au long du cycle de vie.
