Modèle d'IA biaisé : qui paie quand l'algorithme se trompe ?

On parle souvent du biais algorithmique sous l'angle moral. Pour le data scientist qui le construit, le sujet est avant tout juridique et financier. Un modèle de scoring qui écarte systématiquement une catégorie de clients, un moteur de recommandation qui sous-estime un segment, un modèle de churn qui surévalue le risque de départ : dans chaque cas, votre client prend des décisions sur la foi de votre livrable. Et ces décisions ont un coût.

Prenons un cas typique. Vous livrez à une fintech un modèle d'octroi de crédit. Six mois plus tard, un audit interne révèle que le modèle refuse 30 % de dossiers solvables à cause d'une variable corrélée à un critère discriminant. La fintech a perdu du chiffre d'affaires, doit reconstruire le modèle et craint un signalement. Elle se retourne vers vous.

Le préjudice ici est immatériel : pas de bien détruit, pas de blessure, mais une perte d'exploitation et un risque réputationnel directement reliés à votre travail. C'est précisément ce type de dommage que la majorité des contrats généralistes excluent, et que seule une RC Pro adaptée aux métiers IT prend en charge.

Le piège, c'est que ces dommages immatériels dits "non consécutifs" — c'est-à-dire qui ne découlent pas d'un dommage matériel ou corporel préalable — sont le cœur du métier de data scientist. Vous ne cassez rien physiquement : vous produisez un chiffre, une prédiction, un score. Or beaucoup de contrats RC généralistes, pensés pour des artisans ou des commerçants, ne couvrent les immatériels que s'ils sont consécutifs à un sinistre matériel. Pour un métier 100 % intellectuel, cette nuance fait toute la différence entre une couverture réelle et une coquille vide.

En droit français, votre responsabilité contractuelle dépend de la nature de votre engagement. C'est la distinction la plus importante de votre métier.

• Obligation de moyens : vous vous engagez à mettre en œuvre les compétences et les méthodes d'un data scientist diligent. Si le modèle échoue malgré un travail conforme à l'état de l'art, le client doit prouver votre faute pour engager votre responsabilité.
• Obligation de résultat : vous garantissez un livrable précis (un taux de précision, un seuil de performance). En cas d'échec, la faute est présumée — c'est à vous de prouver que la cause est extérieure.

Le piège classique : promettre une performance chiffrée dans une proposition commerciale ("modèle à 95 % de précision"). Vous basculez alors en obligation de résultat sur un terrain incertain par nature, puisque la performance d'un modèle dépend de données que vous ne maîtrisez pas toujours.

Conseil de rédaction : formulez vos engagements en obligation de moyens. "Mise en œuvre de protocoles de validation conformes à l'état de l'art" protège bien mieux que "garantie d'un taux de précision de 95 %".

La jurisprudence sur les prestataires intellectuels est constante : le juge requalifie l'engagement en fonction de ce qui a été réellement promis, pas du titre du contrat. Un devis qui mentionne un "modèle performant" reste en obligation de moyens. Un devis qui chiffre une garantie de performance bascule en obligation de résultat, même si le contrat global parle de "prestation de conseil". Soyez donc particulièrement vigilant sur les annexes techniques, les cahiers des charges et les échanges de mails : ce sont eux qui, en cas de litige, définiront la nature exacte de votre engagement.

Quand un modèle dérape, la responsabilité se répartit rarement sur une seule tête. Trois acteurs interviennent généralement.

C'est ici que votre traçabilité devient décisive. Si vous pouvez démontrer que vous aviez alerté le client sur la non-représentativité de son dataset, que vous aviez conduit des tests d'équité et documenté vos choix, vous transformez une faute présumée en cause extérieure. À l'inverse, sans aucune trace, vous serez la cible la plus facile.

Il faut aussi compter avec le devoir de conseil, particulièrement exigeant pour les prestataires techniques. Le juge attend du data scientist, professionnel averti, qu'il alerte un client profane sur les limites et les risques de ce qu'il livre. Livrer un modèle en silence, alors qu'on en connaît les angles morts, peut suffire à caractériser une faute, même si le code est techniquement irréprochable. Le manquement au devoir de conseil est l'un des fondements les plus fréquents de mise en cause des prestataires IT devant les tribunaux.

Une RC Pro orientée data et IT intervient quand votre responsabilité est engagée pour un dommage causé à un tiers. Concrètement, sur un cas de biais, elle prend en charge :

• l'indemnisation du préjudice immatériel du client (perte d'exploitation, coûts de reconstruction du modèle) après expertise ;
• les frais de défense et d'expertise technique, souvent supérieurs à 10 000 € pour faire trancher un litige complexe ;
• les dommages liés à une atteinte involontaire à la propriété intellectuelle (jeu de données ou modèle pré-entraîné mal licencié).

En revanche, l'assurance ne couvre ni la faute intentionnelle (vous saviez que le dataset était biaisé et l'avez tu), ni les engagements de résultat irréalistes que vous auriez signés. L'assurance protège le data scientist diligent, pas l'imprudent. D'où l'importance de coupler bonne pratique contractuelle et couverture.

Au-delà de l'assurance, votre meilleure protection se construit pendant la mission.

1. Documentez vos tests d'équité. Conservez les métriques de biais par sous-groupe, les features écartées et la justification. Un notebook horodaté vaut mille explications a posteriori.
2. Formalisez les limites par écrit. Si le dataset fourni est trop petit ou non représentatif, dites-le par mail. Cette alerte écrite déplace la responsabilité vers le client.
3. Cadrez le périmètre de décision. Précisez que votre modèle est un outil d'aide à la décision et que la décision finale reste humaine. Cela limite votre exposition aux conséquences directes.

Ces réflexes ne suppriment pas le risque, mais ils déplacent le curseur de la responsabilité et donnent à votre assureur les arguments pour vous défendre efficacement. Pour comprendre comment se construit votre couverture sur mesure, consultez notre page dédiée au métier data science et big data.

Un dernier point, sur la temporalité de l'assurance. Le sinistre d'un data scientist se révèle souvent longtemps après la mission : un biais peut ne produire ses effets visibles qu'au bout de plusieurs mois d'exploitation. C'est pourquoi la notion de garantie subséquente — la période pendant laquelle vous restez couvert après la fin du contrat ou de la mission — est cruciale dans ce métier. Un contrat qui s'arrête net le jour où vous résiliez vous laisse exposé aux réclamations tardives sur des missions passées. Vérifiez systématiquement cette durée de reprise du passé et de maintien de garantie : c'est un critère aussi important que le montant du plafond, et trop souvent ignoré au moment de choisir une couverture sur le seul critère du prix.