Détecter et traiter la dérive d'un modèle en production
Un modèle ne tombe pas en panne : il se dégrade sans rien signaler. C'est ce qui rend sa surveillance différente de celle d'un logiciel ordinaire — et ce que le contrôle A.6.2.6 vient encadrer.
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 ne fournit aucun seuil, aucune métrique et aucune méthode. C’est une liberté réelle, et une responsabilité : le seuil, c’est vous qui l’écrivez, et vous devez 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 le changement le plus significatif et le seul qui vous échappe. Il a deux conséquences normatives directes : la clause 8.2 impose de rejouer l’appréciation du risque lors d’un changement significatif, la clause 8.4 impose d’en faire autant pour l’évaluation d’impact. Et la clause 6.3 demande que le changement du système de management soit mené de façon planifiée.
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.
- 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.
- 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.
- 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é.
- Quelle est la cause ? Corriger la sortie sans chercher la cause garantit la récidive — c’est précisément ce que la clause 10.2 demande d’éviter.
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 n’impose aucun seuil — il impose que les vôtres existent, soient écrits, et déclenchent quelque chose. Et la mise à jour d’un modèle tiers est un changement significatif au sens des clauses 8.2 et 8.4, même si vous ne l’avez pas décidée.