Dérive du modèle : détecter, décider, prouver

La dérive du modèle, c’est le moment où un modèle validé cesse, sans bruit, d’être le modèle que vous avez validé. Personne n’a touché au code, aucune version n’a été déployée, et pourtant les prédictions ont bougé, parce que le monde qu’elles décrivent a bougé. La plupart des guides traitent le sujet comme une affaire d’ingénieurs : un test statistique, un tableau de bord, un réentraînement planifié. C’est utile, mais insuffisant. Au regard du règlement européen sur l’IA (AI Act), du principe d’exactitude du RGPD et des attentes des superviseurs bancaires, la dérive est l’endroit précis où un système qui a passé son évaluation de conformité peut cesser de tenir l’exactitude qu’il a déclarée, sans que personne n’ait validé ce changement.

L’essentiel

• La dérive du modèle est la baisse de performance d’un modèle en production, causée par un changement des données d’entrée ou de la relation entre ces données et le résultat.
• L’article 15 de l’AI Act impose aux systèmes à haut risque une performance constante sur tout leur cycle de vie, mesurée par rapport aux niveaux d’exactitude déclarés.
• Le RGPD (principe d’exactitude) et le CEPD traitent la dérive des données comme un risque identifié, assorti de mesures attendues.
• Un réentraînement hors d’une enveloppe prévue dès l’évaluation de conformité peut constituer une modification substantielle.
• Pour les LLM, la dérive du modèle vient souvent du fournisseur : figer les versions et exiger un préavis contractuel sont des contrôles à part entière.

Qu’est-ce que la dérive du modèle ?

La dérive du modèle (en anglais « model drift ») désigne la dégradation, progressive ou brutale, de la qualité prédictive d’un modèle d’apprentissage automatique une fois qu’il tourne sur des données réelles. La CNIL a inscrit la notion dans son glossaire sous l’entrée « Dérive du modèle », et la page de référence d’IBM en donne une lecture proche : le modèle a été ajusté sur une photographie de la réalité, et la réalité a continué d’avancer. Trois mécanismes se cachent derrière ce terme, et ils n’appellent pas la même réponse.

• Dérive des données (covariate shift). La distribution des entrées change. Un modèle antifraude entraîné sur des paiements par carte physique voit arriver une majorité de paiements par portefeuille mobile : il travaille désormais dans des zones qu’il a à peine vues à l’entraînement.
• Dérive conceptuelle (concept drift). La relation entre entrées et cible se déplace. Un profil d’endettement jugé peu risqué en période stable devient plus risqué en pleine poussée d’inflation. Les données paraissent familières, leur signification a changé.
• Dérive des étiquettes (label drift). La fréquence de base du résultat évolue. Si le taux de fraude double, un modèle calibré sur l’ancien taux déclenchera trop peu d’alertes.

La dérive peut être brutale (une pandémie, une nouvelle réglementation), graduelle (un lent changement démographique), saisonnière ou récurrente. Retenez aussi ceci : les défauts de la chaîne de données en amont ressemblent trait pour trait à une dérive. Une colonne renommée, des euros devenus des centimes, un connecteur qui remplace les valeurs manquantes par zéro, et vos indicateurs s’affolent alors que le monde n’a pas changé.

Dérive du modèle, dérive des données, dérive conceptuelle

<table header-row= »true »> <tr> <td>Terme</td> <td>Ce qui change</td> <td>Signal typique</td> <td>Première réponse</td> </tr> <tr> <td>Dérive des données</td> <td>La distribution des entrées</td> <td>PSI ou KS en hausse sur des variables clés</td> <td>Vérifier la chaîne de données, puis mesurer l’effet sur la performance</td> </tr> <tr> <td>Dérive conceptuelle</td> <td>La relation entre entrées et cible</td> <td>Performance en baisse, entrées apparemment stables</td> <td>Réévaluer sur des données étiquetées récentes, envisager un réentraînement</td> </tr> <tr> <td>Dérive des étiquettes</td> <td>La répartition de la variable cible</td> <td>Taux de défaut ou de fraude qui s’écarte de la référence</td> <td>Recalibrer les seuils, contrôler la représentativité</td> </tr> <tr> <td>Dérive du modèle (effet global)</td> <td>La performance en production face à la référence validée</td> <td>Métriques sous la ligne de base déclarée</td> <td>Déclencher le plan de réponse, documenter la décision</td> </tr> </table>

Pourquoi la dérive du modèle est un sujet de conformité, pas seulement de MLOps

Pour une équipe data, la dérive du modèle se gère avec des alertes et des jobs de réentraînement. Pour la conformité, la question est autre : le système fait-il encore ce que l’organisation a affirmé qu’il faisait ? Trois ancrages juridiques la rendent incontournable. L’exactitude déclarée. L’article 15 de l’AI Act exige que les systèmes à haut risque atteignent un niveau approprié d’exactitude, de robustesse et de cybersécurité, et fonctionnent de manière constante à cet égard tout au long de leur cycle de vie (paragraphe 1). Le paragraphe 3 impose de déclarer les niveaux d’exactitude et les métriques dans la notice d’utilisation. Une dérive du modèle non détectée transforme donc une déclaration exacte au jour de la mise sur le marché en affirmation inexacte six mois plus tard. Le même article demande aux systèmes qui continuent d’apprendre de traiter les boucles de rétroaction, où des sorties biaisées réalimentent l’entraînement futur. L’exactitude des données personnelles. L’article 5, paragraphe 1, point d) du RGPD pose le principe d’exactitude. Le Contrôleur européen de la protection des données (CEPD) l’a relié à la dérive dans ses lignes directrices sur la gestion des risques des systèmes d’IA du 11 novembre 2025. Écrit pour les institutions de l’Union, le document éclaire tout autant le secteur privé. Il consacre un risque aux résultats inexacts dus à la dérive des données et à la dégradation de la qualité des données en entrée, avec un exemple parlant : un modèle de scoring de crédit entraîné en période stable, puis utilisé en pleine crise. Quatre mesures sont attendues : détection de la dérive, surveillance de la qualité des données, réentraînement planifié ou déclenché par la dérive détectée, retours des utilisateurs. En France, la CNIL reste l’interlocuteur naturel sur ce volet, et un établissement supervisé par l’ACPR retrouvera ces exigences dans sa gestion du risque de modèle. L’équité qui s’érode. La dérive du modèle ne frappe pas uniformément. Un modèle peut garder une exactitude globale correcte tout en se dégradant fortement sur un sous-groupe, les jeunes emprunteurs par exemple. Qui ne suit que la moyenne ne voit rien. Le suivi par sous-groupe relève directement de la maîtrise des biais de l’IA, et c’est souvent là qu’un auditeur regarde en premier.

Ce que les textes exigent

Aucun texte ne parle de PSI ni de fenêtre glissante. Tous supposent en revanche qu’une organisation sache si son modèle se comporte encore comme prévu. Voici les dispositions qui comptent face à la dérive du modèle. <table header-row= »true »> <tr> <td>Régime</td> <td>Disposition</td> <td>Ce que cela signifie pour la dérive du modèle</td> </tr> <tr> <td>AI Act</td> <td>Article 15</td> <td>Performance constante sur le cycle de vie, métriques déclarées dans la notice</td> </tr> <tr> <td>AI Act</td> <td>Article 9, paragraphe 2, point c)</td> <td>Évaluer les risques à partir des données de surveillance après commercialisation</td> </tr> <tr> <td>AI Act</td> <td>Article 12</td> <td>Journalisation automatique, matière première de la détection</td> </tr> <tr> <td>AI Act</td> <td>Article 26, paragraphe 5</td> <td>Le déployeur surveille le fonctionnement et informe le fournisseur en cas de risque</td> </tr> <tr> <td>AI Act</td> <td>Article 72</td> <td>Système de surveillance après commercialisation, plan intégré à la documentation technique</td> </tr> <tr> <td>AI Act</td> <td>Article 73</td> <td>Notification des incidents graves dans des délais fixés</td> </tr> <tr> <td>NIST AI RMF</td> <td>MEASURE 2.4, MANAGE 4.1</td> <td>Surveiller le comportement en production, appliquer des plans de surveillance après déploiement</td> </tr> <tr> <td>ISO/IEC 42001</td> <td>Clause 9.1, mesure de l’Annexe A sur l’exploitation et la surveillance</td> <td>Surveiller, mesurer, analyser et évaluer les systèmes d’IA</td> </tr> <tr> <td>Banques américaines</td> <td>SR 26-2</td> <td>Gestion du risque de modèle fondée sur le risque, IA générative et agentique exclues</td> </tr> </table> Article 72 et calendrier après l’Omnibus. L’article 72 oblige les fournisseurs de systèmes à haut risque à établir et documenter un système de surveillance après commercialisation, qui collecte et analyse activement et systématiquement les données pertinentes pendant toute la durée de vie du système. Le plan fait partie de la documentation technique de l’Annexe IV. Le texte initial prévoyait un acte d’exécution et un modèle pour le 2 février 2026. Le règlement Omnibus numérique, règlement (UE) 2026/1744 publié au Journal officiel le 24 juillet 2026 et en vigueur depuis le 27 juillet 2026, l’a remplacé par des lignes directrices de la Commission, modèle compris, attendues d’ici le 2 septembre 2027. Les obligations des systèmes à haut risque s’appliquent désormais le 2 décembre 2027 (systèmes autonomes de l’Annexe III) et le 2 août 2028 (produits de l’Annexe I). Pas de raison d’attendre le modèle officiel : le plan doit exister lors de l’évaluation de conformité. En cas de doute sur le périmètre, commencez par qualifier votre système d’IA à haut risque. NIST. Le playbook MEASURE du NIST AI RMF prévoit, pour la sous-catégorie 2.4, la surveillance du comportement du système en production. Il nomme la dérive et recommande de comparer les métriques de production à celles d’avant le déploiement, avec des alertes sur les changements de distribution. MANAGE 4.1 ajoute des plans de surveillance après déploiement, incluant retours des utilisateurs, recours et gestion des changements. Supervision bancaire. Pour un lecteur européen, la référence la plus directe est le guide de la BCE sur les modèles internes, dont la révision de juillet 2025 ajoute une section sur l’apprentissage automatique : explicabilité, arbitrage performance et complexité, validation. Aux États-Unis, la Réserve fédérale a publié le 17 avril 2026 la lettre SR 26-2, qui remplace SR 11-7 (2011) et SR 21-8, en parallèle du bulletin OCC 2026-13. Une note de bas de page exclut pourtant les modèles génératifs et agentiques, jugés nouveaux et trop changeants, et annonce un appel à commentaires. Les modèles les plus exposés à une dérive imposée par le fournisseur sont donc ceux que le texte laisse de côté.

Dérive ou modification substantielle ? La décision de réentraînement

Face à la dérive du modèle, réentraîner paraît évident. Juridiquement, c’est la réponse la plus délicate. L’article 3, point 23) de l’AI Act définit la modification substantielle comme un changement postérieur à la mise sur le marché, non prévu ni planifié lors de l’évaluation de conformité initiale, qui affecte la conformité du système ou modifie sa destination. Elle impose une nouvelle évaluation de la conformité. L’article 43, paragraphe 4 ouvre une porte : les changements prédéterminés par le fournisseur lors de l’évaluation initiale, et décrits dans la documentation technique, ne sont pas une modification substantielle. Tout dépend donc de ce que vous avez écrit avant la mise sur le marché. Une « enveloppe de réentraînement » solide tient en cinq éléments.

1. Ce qui peut changer. Les poids, les seuils de décision, éventuellement certaines variables ; jamais la destination ni la population cible.
2. Les données autorisées. Sources, périodes, règles de qualité et de représentativité des nouvelles données d’entraînement.
3. Les critères d’acceptation. Les niveaux minimaux, y compris par sous-groupe, qu’une nouvelle version doit atteindre.
4. La méthode de validation. Le jeu de test de référence, les tests appliqués, qui valide et avec quelle séparation des rôles.
5. La frontière. Ce qui fait sortir de l’enveloppe et déclenche une revue de modification substantielle : nouvelle architecture, nouvelle source de données, critère sous le plancher.

L’idée n’est pas neuve. La FDA l’applique aux dispositifs médicaux avec ses lignes directrices finales sur les plans de contrôle des changements prédéterminés (PCCP) du 4 décembre 2024 : décrire les modifications prévues, la méthode de développement et de validation, l’évaluation d’impact. Un réentraînement annoncé, borné et vérifié relève de la maintenance ; un réentraînement improvisé ressemble à un nouveau produit.

Comment détecter la dérive du modèle

Deux familles de méthodes permettent de repérer la dérive du modèle, et un dispositif sérieux combine les deux. La surveillance de la performance réelle. On compare les prédictions aux résultats observés et l’on suit exactitude, rappel, calibration ou erreur moyenne face à la ligne de base validée. La limite est le délai d’étiquetage : pour un scoring de crédit, savoir si un emprunteur fait défaut prend des mois. Pendant ce temps, la dérive du modèle progresse sans être mesurée. La surveillance des distributions. Elle observe entrées et sorties sans attendre les étiquettes. L’indice de stabilité de population (PSI) domine dans la finance, avec une règle empirique connue : sous 0,1, stable ; entre 0,1 et 0,25, changement modéré à investiguer ; au-delà de 0,25, changement significatif. C’est une convention de métier, pas une exigence réglementaire. Le test de Kolmogorov-Smirnov convient aux variables continues, le khi-deux aux variables catégorielles ; la distance de Wasserstein et la divergence de Jensen-Shannon mesurent l’ampleur du déplacement. Suivre la distribution des prédictions (prediction drift) donne souvent le premier signal. Deux mises en garde évitent l’essentiel des erreurs.

• Significatif ne veut pas dire pertinent. Sur des millions d’observations, un test KS signale le moindre écart. Fixez des seuils sur l’ampleur de l’effet, pas sur la seule p-valeur.
• Une dérive des données sans perte de performance appelle une investigation, pas un réentraînement automatique. Réentraîner à chaque alerte, c’est risquer d’apprendre du bruit ou un défaut de pipeline, et de sortir de l’enveloppe sans le savoir.

La dérive du modèle dans les LLM et les modèles tiers

Avec les grands modèles de langage, la dérive du modèle vient souvent de chez le fournisseur. L’étude de Chen, Zaharia et Zou, « How is ChatGPT’s behavior changing over time? », l’a montré : pour distinguer nombres premiers et composés, GPT-4 est passé de 84 % d’exactitude en mars 2023 à 51 % en juin 2023, sous le même nom de service. Le respect des instructions avait aussi reculé. Aucun client n’avait rien modifié. Côté déployeur, les contrôles utiles sont concrets.

• Figer les versions. Appeler une version datée, jamais un alias mobile de type « latest », qui ne devrait pas être approuvé pour un usage à haut risque.
• Rejouer un jeu d’évaluation fixe à chaque changement de version. Mêmes cas, mêmes critères, comparaison documentée : c’est l’usage le plus rentable d’un benchmark d’IA interne.
• Contractualiser le préavis. Exiger une notification avant toute modification ou dépréciation de modèle, avec le temps de revalider. Ce point relève de la due diligence des fournisseurs d’IA.
• Surveiller les entrées et les corpus de récupération. Dans une architecture RAG, des documents obsolètes produisent des réponses obsolètes, même avec un modèle inchangé.

Un plan de surveillance qu’un auditeur acceptera

Un auditeur ne vous demandera pas quel test statistique vous préférez. Il voudra voir le plan de surveillance de la dérive du modèle, puis la preuve qu’il a été suivi. Sept éléments le rendent crédible.

1. Périmètre et responsabilités. Quels modèles, quelles versions, quel responsable nommé. Le point de départ est un inventaire à jour, tel qu’un registre des systèmes d’IA.
2. Métriques et lignes de base. Les métriques déclarées au titre de l’article 15, leurs valeurs de référence à la validation, leur déclinaison par sous-groupe.
3. Sources de données. Les journaux de l’article 12, les résultats observés, les retours des déployeurs.
4. Fréquence. Proportionnée au risque et au volume : quotidienne pour la fraude, mensuelle pour un scoring à faible rotation.
5. Seuils et escalade. Des niveaux d’alerte chiffrés et, pour chacun, qui est prévenu et sous quel délai.
6. Procédure de réponse. Ce que l’on fait quand un seuil est franchi, écrit à l’avance.
7. Traces. Chaque alerte, analyse et décision, avec sa justification, conservée et retrouvable.

Ce plan s’insère dans votre dispositif de surveillance de la conformité des systèmes d’IA. Dernier point, souvent négligé : un tableau de bord passé au rouge puis revenu au vert ne prouve rien. Sans la trace de la décision prise entre les deux, l’auditeur ne voit qu’un incident dont personne ne peut rendre compte.

Répondre à la dérive du modèle : la méthode en cinq étapes

Quand une alerte de dérive du modèle se déclenche, la tentation est de réentraîner aussitôt. Une réponse ordonnée suit plutôt cinq étapes.

1. Qualifier la cause. Commencer par la chaîne de données : schéma, unités, valeurs par défaut, connecteurs. Réentraîner sur des données corrompues aggrave le problème.
2. Évaluer l’impact. Mesurer l’écart aux métriques déclarées, globalement et par sous-groupe, et identifier les décisions affectées depuis le début de la dérive.
3. Contenir. Augmenter le taux de revue humaine, ajuster les seuils, revenir à la version précédente ou suspendre le système. Ces leviers relèvent de la supervision humaine prévue à l’article 14.
4. Corriger. Réentraîner dans l’enveloppe documentée, ou ouvrir une revue de modification substantielle si la correction en sort.
5. Déclarer et apprendre. Vérifier s’il s’agit d’un incident grave au sens de l’article 3, point 49). Si oui, l’article 73 fixe les délais : 15 jours en règle générale, 10 jours en cas de décès, 2 jours pour une infraction généralisée ou une perturbation grave d’une infrastructure critique. La procédure de signalement des incidents d’IA doit être prête avant d’en avoir besoin. Les enseignements nourrissent ensuite la gestion des risques de l’IA (article 9, paragraphe 2, point c).

Questions fréquentes

Qu’est-ce que la dérive du modèle, en termes simples ? La dérive du modèle, c’est la perte de performance d’un modèle d’IA en production, parce que les données qu’il reçoit ou la réalité qu’il prédit ont changé depuis son entraînement. Le code est identique, mais le modèle répond à un monde qui n’existe plus tout à fait. Elle peut survenir brutalement, après un choc économique, ou s’installer sur plusieurs mois. Dans les deux cas, elle ne se voit que si l’on mesure : seule une surveillance continue, avec métriques et seuils définis à l’avance, protège réellement. Quelle différence entre dérive des données et dérive du modèle ? La dérive des données décrit un changement dans la distribution des entrées : nouveaux profils de clients, nouveaux canaux. La dérive du modèle désigne l’effet qui compte, la baisse de performance. Les deux ne vont pas toujours ensemble : une dérive des données peut rester sans conséquence si le modèle généralise bien, et une dérive conceptuelle peut dégrader le modèle avec des entrées stables. Une alerte sur les distributions justifie donc une investigation, tandis qu’une baisse mesurée de performance déclenche le plan de réponse. Les LLM sont-ils concernés par la dérive du modèle ? Oui, souvent pour une raison différente : le fournisseur peut modifier le modèle servi sous un même nom. Chen, Zaharia et Zou ont mesuré une chute de 84 % à 51 % d’exactitude de GPT-4 sur une tâche mathématique entre mars et juin 2023. S’y ajoutent l’évolution des questions des utilisateurs et le vieillissement des corpus documentaires dans les architectures RAG. Les contrôles clés sont le gel des versions, un jeu d’évaluation rejoué à chaque changement et une clause contractuelle de préavis. Un réentraînement est-il une modification substantielle ? Pas nécessairement. Selon l’article 43, paragraphe 4, de l’AI Act, les changements prédéterminés par le fournisseur lors de l’évaluation de conformité initiale et décrits dans la documentation technique ne sont pas des modifications substantielles. Un réentraînement qui respecte une enveloppe documentée reste de la maintenance. En revanche, un réentraînement qui change l’architecture, introduit une nouvelle source de données ou affecte la conformité sans avoir été prévu peut exiger une nouvelle évaluation. À quelle fréquence contrôler la dérive du modèle ? Aucun texte ne fixe de fréquence. Elle dépend du risque, du volume de décisions et de la vitesse à laquelle l’environnement change. Un modèle antifraude traitant des milliers de transactions par heure justifie une surveillance quotidienne des distributions. Un scoring de crédit peut être revu mensuellement sur ses entrées, avec une mesure de performance trimestrielle quand les défauts deviennent observables. L’important est que la fréquence soit justifiée par écrit dans le plan de surveillance, puis respectée. La dérive du modèle est-elle un incident grave au sens de l’article 73 ? Pas en elle-même. Elle le devient lorsqu’elle entraîne l’une des conséquences de l’article 3, point 49) : décès ou atteinte grave à la santé, perturbation grave et irréversible d’une infrastructure critique, violation d’obligations protégeant les droits fondamentaux, dommage grave aux biens ou à l’environnement. Un modèle de recrutement dont la dérive produit une discrimination systématique peut entrer dans ce cadre. Les délais courent alors : 15 jours en général, 10 jours en cas de décès, 2 jours pour une infraction généralisée ou une atteinte grave à une infrastructure critique.

Conclusion

La dérive du modèle ne s’élimine pas, elle s’encadre. Avant la mise en service, trois pièces doivent exister : des métriques déclarées avec leurs lignes de base, y compris par sous-groupe ; un plan de surveillance qui fixe seuils, fréquence et responsables ; une enveloppe de réentraînement qui sépare la maintenance de la modification substantielle. S’y ajoute la discipline qui fait la différence en audit : tracer chaque alerte et chaque décision, y compris celle de ne rien faire. C’est ce qui montre qu’un système reste conforme à ce qu’il a déclaré, et pas seulement qu’il l’était le jour de son évaluation. AI Sigil relie chaque modèle du registre à son plan de surveillance, à ses décisions en matière de dérive et à ses preuves, pour que la réponse à un auditeur soit un rapport, et non une reconstitution.