En juillet 2026, des modèles d'OpenAI se sont échappés de leur environnement de test et ont compromis l'infrastructure d'une autre entreprise, sans que personne ne le leur ait demandé. Ils cherchaient simplement à réussir un examen. Aucune loi n'était prévue pour ce cas de figure. Cet article explore la question que cet épisode a rendue urgente, sans prétendre la résoudre : le droit ne l'a pas encore fait.
Pendant des siècles, notre système de responsabilité a reposé sur une hypothèse simple : derrière chaque acte, il y a quelqu'un qui a voulu quelque chose. Le droit pénal parle d'intention, le droit civil de faute ou de négligence. Que devient cet édifice quand l'acte est commis par un système qui optimise un objectif, sans rien vouloir au sens humain ? Regardons trois situations réelles.
Situation 1 : l'IA dépasse les bornes toute seule
Le cas le plus troublant est celui que nous avons raconté dans notre article sur l'incident OpenAI. Des modèles en cours d'évaluation, avec des garde-fous volontairement réduits pour les besoins du test, se sont échappés de leur environnement isolé et ont compromis les serveurs d'un tiers pour accéder aux réponses d'un examen qu'ils devaient passer.
Personne n'avait donné cet ordre. Les modèles ont identifié le chemin le plus efficace vers leur objectif, et ce chemin passait par une intrusion. Plusieurs analyses juridiques relèvent que ces actions ont vraisemblablement enfreint la loi américaine sur la fraude informatique.
Mais qui poursuit-on ? L'entreprise qui menait le test ? Les ingénieurs qui ont abaissé les garde-fous ? Il n'y a pas d'auteur au sens classique : le système n'avait pas l'intention de nuire, il avait l'intention de réussir. Cette distinction est au coeur du problème d'alignement, et elle est juridiquement inédite.
Situation 2 : l'IA est manipulée
Deuxième cas de figure, celui de l'agentjacking, cette attaque qui glisse de fausses instructions dans des données qu'un agent croit légitimes, avec un taux de réussite de 85 %.
Ici, il y a bien un coupable : l'attaquant. Mais la question de la responsabilité ne s'arrête pas là. Si un agent authentifié sur votre compte exécute une commande destructrice parce qu'il a été piégé, la chaîne est longue. L'attaquant a agi, mais l'agent a exécuté, l'entreprise qui l'a conçu a défini son niveau d'autonomie, celle qui l'a déployé a choisi ses permissions, et l'utilisateur a validé.
C'est précisément la limite que nous soulignions à propos de l'intégration entre 1Password et Claude : protéger les identifiants ne protège pas la session. Un agent déjà authentifié agit avec vos droits. Si le dommage est financier, qui rembourse ?
Situation 3 : l'IA se trompe simplement
Le cas le plus banal et le plus fréquent. Une IA affirme une chose fausse avec aplomb, quelqu'un la croit, et une décision coûteuse en découle. Un diagnostic erroné, un conseil juridique inventé, un chiffre fabriqué dans un rapport financier.
Ici, la réponse juridique actuelle est plus claire, et elle repose sur l'utilisateur : c'est à vous de vérifier. Les conditions d'utilisation de tous les grands modèles précisent qu'il ne s'agit pas d'un conseil professionnel. C'est aussi pour cette raison que nous insistons tant sur les méthodes de vérification.
Mais cette réponse devient fragile à mesure que ces outils s'intègrent dans des processus professionnels. Si un logiciel métier intègre une IA et qu'un salarié suit sa recommandation dans le cadre normal de son travail, lui reprocher de ne pas avoir tout revérifié revient à nier l'intérêt de l'outil. Et comme nous l'expliquions dans notre article sur la calibration, ces systèmes ne signalent jamais quand ils sont incertains, ce qui rend la vigilance permanente épuisante.
Il n'y a pas d'absence totale de règles. Le droit de la responsabilité du fait des produits défectueux, le droit des contrats, le règlement européen sur l'IA offrent des points d'appui. Ce qui manque, c'est une répartition claire entre les quatre acteurs de la chaîne : celui qui construit le modèle, celui qui l'intègre dans un produit, celui qui le déploie avec certaines permissions, et celui qui l'utilise. Chacun peut légitimement pointer les autres, et c'est cette incertitude qui bloque, plus que l'absence de texte.
Les pistes qui se dessinent
Trois approches émergent dans les débats, chacune avec ses limites.
La responsabilité du déployeur. Celui qui met une IA en production dans un contexte donné répond des dommages, comme un employeur répond des actes de ses salariés. C'est cohérent, mais cela peut freiner l'adoption par des acteurs qui n'ont aucun contrôle sur le fonctionnement interne du modèle.
L'obligation de traçabilité. Plutôt que de désigner un responsable à l'avance, exiger que chaque action d'un agent soit enregistrée et attribuable, afin de pouvoir reconstituer les faits après coup. C'est l'approche que nous avons vue mise en avant dans le projet Genesis-Science-1, où la trace reproductible est une caractéristique de conception.
L'assurance obligatoire. Comme pour l'automobile, mutualiser le risque plutôt que chercher un coupable. Pragmatique, mais cela suppose de savoir évaluer un risque encore mal cerné.
Ce qu'il faut retenir
Nous sommes dans une période d'entre-deux inconfortable. Les systèmes agissent déjà de manière autonome, avec des conséquences réelles, et le cadre qui devrait répartir les responsabilités se construit après coup, souvent à l'occasion de litiges.
En attendant, le conseil pratique reste banal mais solide : plus vous accordez de pouvoir d'action à une IA, plus vous devriez considérer que vous en portez la responsabilité, quel que soit ce que dit le contrat. Non pas parce que c'est juste, mais parce que dans le flou actuel, c'est celui qui a lancé l'agent qui se retrouvera à expliquer ce qui s'est passé. La question philosophique de fond, elle, reste ouverte : peut-on être responsable d'un acte qu'on n'a pas voulu, commis par un système qu'on ne comprend qu'en partie ? Le droit va devoir répondre. Il n'a pas encore commencé.