Le drift silencieux qui a refusé 3 200 crédits éligibles : qui paie ?

Imaginez la situation suivante, qui n'a rien d'exceptionnel dans une banque en ligne. Un modèle de scoring crédit tourne en production depuis dix-huit mois. Les pipelines sont vertes, les latences nominales, les tableaux de bord d'infrastructure ne signalent rien. Pourtant, sur un trimestre, le taux de refus a grimpé de quatre points sans qu'aucune décision produit ne l'explique.

La cause se trouve en amont : la population des demandeurs a changé. Une nouvelle offre marketing a attiré un profil de clientèle que le modèle n'avait jamais vu lors de son entraînement. Les distributions des variables d'entrée ont glissé — c'est ce qu'on appelle le data drift — et les sorties du modèle ont suivi. Le scoring continue de répondre, avec aplomb, mais il se trompe désormais sur une fraction croissante des dossiers.

Ce qui rend ce type d'incident redoutable, c'est précisément son silence. Un service qui plante réveille une astreinte en quelques minutes. Un modèle qui dérive ne plante pas : il dégrade. Sans monitoring du drift et des performances métier, personne ne le voit avant que le préjudice ne soit constitué.

Reprenons des ordres de grandeur réalistes. Sur le trimestre concerné, l'audit interne identifie environ 3 200 dossiers refusés à tort, c'est-à-dire des demandeurs qui auraient été acceptés par un modèle correctement recalibré. Le préjudice se décompose en plusieurs strates.

Le point essentiel pour comprendre l'enjeu assurantiel : il n'y a ici aucun dommage matériel. Personne n'est blessé, aucun serveur n'a brûlé, aucun bien n'est détruit. Le préjudice est entièrement immatériel : c'est de la valeur économique perdue à cause d'une prestation intellectuelle défaillante. C'est précisément la catégorie de dommage que les contrats grand public ne couvrent jamais et que la RC Pro est faite pour prendre en charge.

La tentation, face à un drift, est de dire : « le modèle a été conçu par les data scientists, je ne fais qu'opérer la chaîne. » C'est une défense fragile. Le rôle de l'ingénieur MLOps consiste justement à industrialiser et surveiller le cycle de vie du modèle en production. L'absence de détection de drift n'est pas un défaut de conception du modèle : c'est un défaut de la chaîne d'opération, votre périmètre.

Concrètement, la responsabilité se discute autour de questions très opérationnelles :

• Aviez-vous mis en place un monitoring du drift des features et des prédictions (Evidently, Arize, ou équivalent maison) ?
• Des seuils d'alerte étaient-ils définis et reliés à une astreinte ou à un processus de réentraînement ?
• Le contrat ou la fiche de mission mentionnait-il la surveillance de la performance comme un livrable attendu ?
• Une procédure de rollback ou de désactivation du modèle existait-elle en cas de dégradation ?

Si la réponse à ces questions est négative, l'ingénieur — qu'il soit indépendant, en ESN ou prestataire d'une scale-up — s'expose à une mise en cause pour manquement à son obligation de moyens. Le client n'a pas à prouver que vous avez mal codé : il lui suffit de démontrer qu'un professionnel diligent aurait surveillé ce que vous n'avez pas surveillé.

Beaucoup d'ingénieurs pensent être protégés parce qu'ils ont « une assurance ». Mais la majorité des contrats personnels ou des extensions vaguement professionnelles excluent deux choses qui se cumulent ici.

Premièrement, les dommages immatériels non consécutifs. Un dommage immatériel « non consécutif » est un préjudice financier qui ne découle pas d'un dommage matériel préalable. C'est exactement notre cas : aucun bien endommagé, seulement une perte économique. Sans garantie spécifique, ce poste — qui est ici la quasi-totalité du préjudice — reste à votre charge.

Deuxièmement, la défense juridique. Même si vous estimez votre responsabilité discutable, il faut la défendre. Expertises, échanges d'avocats, reconstitution du timeline technique : les frais de défense s'accumulent avant même qu'un euro d'indemnisation ne soit versé. Une RC Pro adaptée aux métiers de la donnée inclut cette protection et prend en charge la défense et le recours.

Le drift n'est pas un bug exotique : c'est le mode de défaillance le plus banal et le plus coûteux d'un système de machine learning en production. L'assurer relève de l'hygiène professionnelle, pas de la précaution excessive.

Pour comprendre l'ensemble des risques propres à ce métier et les garanties associées, vous pouvez consulter notre page dédiée à l'assurance de l'ingénieur MLOps.

Pour bien se défendre, encore faut-il nommer précisément ce qui s'est produit. On confond souvent deux phénomènes qui appellent des réponses différentes.

Le data drift décrit un changement dans la distribution des variables d'entrée : la population des demandeurs évolue, mais la relation entre les caractéristiques et le résultat reste valable. Le concept drift, lui, décrit un changement dans la relation elle-même : ce qui faisait un bon emprunteur hier n'en fait plus un aujourd'hui, à cause d'un choc économique par exemple. Le premier se détecte en surveillant les entrées ; le second exige de surveiller la performance réelle une fois les vérités terrain connues.

Cette distinction n'est pas un détail académique : elle conditionne votre responsabilité. Un expert pourra reprocher de n'avoir surveillé que les entrées en ignorant la dérive de performance, ou inversement. Démontrer que vous aviez couvert les deux régimes de surveillance est un argument décisif. À l'inverse, un dispositif partiel laisse une brèche que la partie adverse exploitera.

Un dernier piège mérite l'attention : le feedback loop. Quand le modèle refuse un crédit, on n'observe jamais ce que le client aurait remboursé. Les données de réentraînement sont donc biaisées par les décisions passées du modèle lui-même, ce qui peut amplifier le drift au lieu de le corriger. Identifier ce mécanisme dans un dossier de sinistre fait souvent la différence entre une faute reconnue et une fatalité partagée.

Un sinistre se gagne ou se perd souvent avant qu'il ne survienne, sur la qualité des traces que vous laissez. Trois réflexes font la différence.

1. Documentez la surveillance. Un dashboard de drift archivé, des seuils versionnés, des logs d'alerte horodatés : ces éléments prouvent que vous avez exercé votre obligation de moyens. En cas de litige, ils déplacent la discussion de « avez-vous surveillé ? » vers « la dégradation était-elle détectable dans les délais ? ».
2. Cadrez le périmètre par écrit. Si la surveillance post-déploiement n'entre pas dans votre mission, écrivez-le. Si elle y entre, dites quels seuils et quelle réactivité sont attendus. Le flou contractuel se retourne presque toujours contre le prestataire.
3. Assurez le bon poste. Vérifiez que votre contrat couvre explicitement les dommages immatériels non consécutifs et les missions effectuées en France et dans l'Union européenne. C'est le cœur de la couverture pour un métier dont les fautes ne cassent rien de tangible.

Le coût d'une telle protection est sans commune mesure avec l'exposition : à partir de 18,90 €/mois, là où un seul sinistre de drift peut se chiffrer en centaines de milliers d'euros.