L'administration Trump mise sur les procès : qui paiera en cas de dérapage d'une IA ?

L'administration Trump a fait de la responsabilité juridique son principal levier pour garantir la sécurité de l'IA, rapporte Bloomberg. L'approche paraît économique : pas besoin de créer une autorité de licences ni de négocier des listes d'architectures interdites. Il suffit de faire comprendre que les dommages se paieront. Mais ce schéma a un point faible, déjà visible : la loi ne dit pas, pour l'instant, qui doit payer quand un modèle « part en vrille ». Ceux qui l'ont créé, ou ceux qui l'ont intégré à leur produit.

La publication de Bloomberg ne cite ni article de loi précis, ni montants, ni délais : les détails du mécanisme restent donc flous. La logique, en revanche, est claire, et on peut l'analyser à la lumière de litiges déjà survenus.

Deux chaînes de responsabilité

Tout système d'IA en production implique au moins deux acteurs. Le premier entraîne le modèle et définit son comportement de base. Le second le connecte à ses propres données, rédige le prompt système, lui fournit des outils et décide où il peut être utilisé. Le plus souvent, le dommage naît à la jonction des deux : le modèle se trompe, et l'entreprise lui a donné accès à des ressources auxquelles elle n'aurait pas dû lui donner accès.

L'AI Act européen a inscrit cette séparation dans ses définitions : il distingue le « fournisseur » et le « déployeur », dont les obligations diffèrent. Aux États-Unis, il n'existe pas de cadre unique. Restent la responsabilité du fait des produits, les règles sur la négligence et le droit des contrats. Les tribunaux les appliquent à l'IA par analogie, et le résultat est imprévisible.

Un exemple révélateur date de 2024 : un tribunal de la Colombie-Britannique a jugé qu'Air Canada était responsable des informations erronées sur les réductions fournies par son chatbot. La compagnie aérienne a tenté de démontrer que le bot était une entité distincte. Sans succès. C'est celui qui a déployé le système face au client qui a été tenu pour responsable, et non celui qui l'a entraîné.

Ce que cela change pour les développeurs

Auparavant, la Californie avait examiné en 2024 le projet de loi SB 1047, qui prévoyait des règles de responsabilité pour les développeurs de grands modèles. Le gouverneur Newsom y a opposé son veto, en grande partie à cause des objections de l'industrie. Aujourd'hui, l'idée de responsabilité revient, mais cette fois au niveau fédéral et dans une logique de soutien au marché, non de frein.

La défense habituelle des développeurs repose sur les conditions d'utilisation, qui reportent le risque sur le client. L'exception : la protection contre les poursuites pour atteinte au droit d'auteur, que Microsoft, Google et OpenAI ont proposée à leurs clients professionnels. Pour les dommages causés par le comportement d'un modèle, aucune garantie de ce type n'existe. Si la responsabilité devient réelle, ces conditions devront être réécrites.

Les principaux points de tension :

• La frontière entre défaut du modèle et mauvais déploiement : qui doit prouver ce qui a réellement dysfonctionné.
• Les systèmes agentiques : plus ils ont d'autonomie et d'accès à des outils, plus il est difficile de répartir la faute le long de la chaîne.
• Les clauses contractuelles : les développeurs pourront-ils continuer à se décharger de leur responsabilité dans leurs licences ?
• L'assurance : le marché de la couverture des risques liés à l'IA reste mince, et les tarifs dépendront des premières décisions retentissantes.
• Les modèles ouverts : on ne sait pas qui répond du préjudice si des tiers ont téléchargé les poids et réalisé un fine-tuning.

Ce que les entreprises doivent faire dès maintenant

Inutile d'attendre les règles définitives : la logique est claire, et la préparation coûte peu. Les entreprises qui déploient de l'IA devraient passer en revue leurs contrats avec les fournisseurs de modèles et déterminer quels risques le fournisseur assume, et lesquels restent à leur charge. Il est utile de tenir des journaux des actions des agents et de conserver les versions des prompts et des configurations : dans un litige sur l'origine d'une erreur, ce sont ces données qui montreront de quel côté se situe la faute.

Les développeurs de modèles ont intérêt à documenter leurs tests et les limitations connues. Ce sera leur principal argument pour établir que le produit ne comportait pas de défaut. Pour tous les autres, la conclusion pratique est simple : limitez les droits des agents au strict nécessaire et gardez un humain dans la boucle aux points où une erreur coûte cher. Quand la responsabilité deviendra l'objet de procès, ce sont précisément ces choix que le tribunal examinera.