Litige avec le fournisseur d’un système d’IA industriel
Un site industriel déploie un système d’IA (maintenance prédictive, détection d’anomalies, optimisation, aide à la conduite) qui ne tient pas ses promesses ou contribue à un incident. Le fournisseur invoque un usage hors du domaine prévu, l’exploitant une performance annoncée non tenue. L’expertise doit établir ce que le système devait faire, dans quelles conditions, ce qu’il a fait, et comment il a été intégré et gouverné.
Quelle est la situation ?
Un exploitant a acquis ou fait développer un système d’IA et l’a intégré à son exploitation. Le système manque des événements, génère de fausses alertes, se dégrade avec le temps, ou a joué un rôle dans un incident. Des sommes importantes sont en jeu : prix du système, coûts d’intégration, pertes de production, dommages. Le litige est porté devant le juge ou devant un tribunal arbitral.
Quelles questions l’expertise doit-elle éclairer ?
- Quelles performances et quelles limites la documentation du fournisseur annonçait-elle ?
- Dans quelles conditions d’emploi le système a-t-il été validé ? Correspondaient-elles aux conditions réelles du site ?
- Les données fournies par l’exploitant étaient-elles conformes à ce qui était prévu ?
- Comment le système était-il intégré : quelle fonction lui était confiée, quelle supervision humaine, quel mécanisme d’arrêt ?
- Les dérives de performance étaient-elles surveillées ? Les mises à jour du modèle étaient-elles tracées ?
- Le système assurait-il, de fait, une fonction de barrière qui n’avait pas été reconnue comme telle ?
Pourquoi une expertise technique générale ne suffit-elle pas ?
Un expert en informatique peut évaluer le modèle. La question de savoir si son emploi était adapté à une exploitation à haut risque, et si l’organisation l’avait correctement gouverné, relève d’une double compétence : l’exploitation et l’assurance des systèmes d’IA.
Qu’apporte le sapiteur ?
- La confrontation des engagements du fournisseur aux conditions réelles d’emploi.
- L’analyse de l’intégration et de la gouvernance du système, avec le référentiel IOGP 817-1.
- L’analyse de la fonction de barrière confiée de fait au système, avec la grille ABR.
- La lecture des journaux et de l’historique des versions.
Il n’interprète pas le contrat.
Voir aussi : systèmes automatisés et IA, système d’IA dans une séquence accidentelle, le sapiteur, cadre juridique.
Questions fréquentes
Pourquoi ces litiges sont-ils techniquement difficiles ?
Parce que la performance d'un modèle dépend des données et des conditions dans lesquelles il est employé. Le fournisseur invoque un usage hors du domaine prévu ; l'exploitant, une performance annoncée non tenue. Les deux se vérifient dans la documentation et les journaux du système.
Quels documents examiner en priorité ?
La documentation technique du modèle (capacités, limites, données d'entraînement), les engagements de performance, les conditions d'emploi prévues, les essais de réception, les journaux d'exploitation et l'historique des versions. Le référentiel IOGP 817-1 décrit ce qu'un exploitant diligent conserve.
Le sapiteur dit-il qui a manqué à ses obligations contractuelles ?
Non. Il établit ce que le système devait faire, dans quelles conditions, ce qu'il a fait, et comment il était intégré et gouverné. L'interprétation du contrat appartient au juge ou à l'arbitre.
Rédigé par Carl Goodwin, sapiteur en risque industriel. Mise à jour : .
Définitions : Gestion des modifications (MOC) · Dire