Détecter et traiter la dérive d'un modèle en production

Un serveur qui tombe se voit. Un modèle qui se dégrade continue de répondre, avec le même temps de réponse et le même taux d’erreur technique — simplement, ses réponses sont devenues moins bonnes.

C’est la raison pour laquelle la surveillance d’un système d’IA ne se réduit pas à de la supervision applicative, et c’est ce que vient encadrer le contrôle A.6.2.6.

Quatre dégradations distinctes

On parle souvent de « dérive » au singulier. Il y en a plusieurs, et elles ne se détectent pas de la même façon.

La dérive des données. La distribution des entrées change : nouvelle clientèle, nouveau canal, saisonnalité, changement de format en amont. Le modèle reçoit des données qui ne ressemblent plus à celles sur lesquelles il a été construit. Se détecte en comparant la distribution courante à une référence.

La dérive du concept. La relation entre les entrées et ce qu’on cherche à prédire change. Le monde a bougé, pas les données. C’est la plus insidieuse : les entrées paraissent normales, les prédictions deviennent fausses. Se détecte uniquement avec un retour de vérité — l’issue réelle des cas traités.

La dégradation de la qualité. Sur un système génératif, elle prend des formes propres : réponses moins fondées sur les sources, hallucinations plus fréquentes, écart croissant entre la question et la réponse.

Le biais émergent. L’écart de performance entre groupes se creuse alors qu’il était acceptable à la mise en production. Ne se détecte qu’avec des mesures désagrégées : une performance globale stable peut masquer une dégradation concentrée sur un groupe.

Ce que la norme demande, et ce qu’elle ne demande pas

Elle demande que la surveillance soit définie, mise en œuvre et tracée. Elle n’impose aucun seuil, aucune métrique et aucune méthode : son Annexe B se contente d’exemples — taux d’erreur, durée de traitement, score F1 — et recommande de fixer des valeurs acceptables en s’appuyant sur des experts du domaine et sur les attentes des parties intéressées. C’est une liberté réelle, et une responsabilité : le seuil, c’est vous qui l’écrivez, et mieux vaut pouvoir dire pourquoi celui-là.

Un seuil utile a une propriété : il déclenche une décision. Annoncer qu’on surveille la précision ne constitue pas un dispositif. Écrire que, sous 0,85 de précision constatée sur deux relevés consécutifs, le propriétaire du système est saisi et tranche entre réentraînement et retour arrière — voilà un dispositif.

Le contrôle A.6.2.8, relatif à l’enregistrement des journaux d’événements, est le complément naturel : sans journal, aucune dérive ne peut être établie a posteriori, et aucune décision ne peut être reconstituée. Notons-le au passage, car le point est souvent mal rapporté : A.6.2.8 est un contrôle de l’Annexe A, donc susceptible d’être écarté avec justification. Une organisation peut rester certifiée en l’ayant exclu — ce qui n’a aucune incidence sur ses obligations réglementaires de journalisation, qui existent indépendamment de la norme.

Le déclencheur que vous ne maîtrisez pas

Votre fournisseur met le modèle à jour. Rien n’a changé chez vous, et le système en production n’est plus celui que vous avez évalué.

C’est un changement qui vous échappe, et vous seul pouvez dire s’il est significatif — la norme ne le dit pas à votre place, ce sont vos critères écrits à l’avance qui en décident. Dans tous les cas, la clause 8.1 s’applique : un changement que vous n’avez pas voulu s’examine pour ses effets, avec des mesures si ces effets sont défavorables, et ce qu’un tiers vous fournit reste sous votre maîtrise. Si vous le jugez significatif, la clause 8.2 impose de refaire l’appréciation du risque, que le changement soit annoncé ou déjà survenu. La clause 8.4 impose de refaire l’évaluation d’impact lorsqu’un tel changement est envisagé : son texte, contrairement à celui de 8.2, ne vise pas celui qu’on découvre après coup — raison de plus pour suivre les préavis de votre fournisseur. Quant à la clause 6.3, elle ne concerne que les évolutions de votre système de management : elle n’entre en jeu que si cette mise à jour vous conduit à le modifier.

Trois parades, par ordre de solidité : épingler la version du modèle quand le fournisseur le permet, suivre ses annonces de dépréciation, et prévoir un relevé de contrôle après chaque mise à jour. La première n’est pas toujours disponible ; la troisième l’est toujours.

Que faire quand la dérive est constatée

Le réflexe de réentraîner est souvent prématuré. Quatre questions d’abord.

1. La dérive est-elle réelle ou est-ce le relevé qui a changé ? Un changement de méthode de mesure produit une fausse dérive.
2. Porte-t-elle sur tous les cas ou sur un segment ? Une dégradation concentrée sur un groupe n’appelle pas la même réponse — et relève de l’évaluation d’impact, pas seulement de la performance.
3. Le système peut-il continuer à servir dans l’intervalle ? Sinon, il faut un retour arrière, et il faut qu’il ait été préparé.
4. Quelle est la cause ? Corriger la sortie sans chercher la cause garantit la récidive. Une dérive relève d’abord de l’exploitation du système (A.6.2.6) ; si elle met au jour une exigence non satisfaite, elle devient une non-conformité, et la clause 10.2 fait alors rechercher ses causes.

Ce qu’il faut retenir

La dérive n’est pas une panne : elle est silencieuse, et elle a plusieurs formes qui ne se détectent pas de la même façon.

Le contrôle A.6.2.6 ne fixe aucun seuil : il demande de définir et de mettre par écrit ce qu’exige l’exploitation du système dans la durée, et recommande d’y traiter au moins les réparations, les mises à jour, le support, et le suivi du système comme de ses performances. Les valeurs acceptables relèvent d’une recommandation de l’Annexe B, et qu’un seuil franchi déclenche une décision n’est pas exigé — c’est simplement ce qui rend votre surveillance utile et démontrable. Quant à la mise à jour d’un modèle tiers, elle peut constituer un changement significatif, même si vous ne l’avez pas décidée : c’est à vous d’en juger, et la clause 8.1 s’applique de toute façon.