Qui est responsable du code généré par IA ? Ce qui change en 2026

Pour les erreurs d'un code généré par IA, ce n'est pas l'IA qui répond, mais celui qui met le logiciel sur le marché. Cette règle de base n'a pas changé ; ce sont les conditions-cadres qui se sont durcies : avec la directive (UE) 2024/2853, les logiciels et les systèmes d'IA sont expressément considérés, à partir de décembre 2026, comme des produits au sens de la responsabilité du fait des produits, assortis d'allègements de la charge de la preuve pour les personnes lésées.

Qui répond lorsqu'un code généré par IA cause un dommage ?

Celui qui fournit ou exploite le logiciel ; le fournisseur de l'outil, en règle générale, non. Les conditions d'utilisation des fournisseurs d'IA attribuent habituellement la responsabilité du code produit à l'utilisateur ; le code généré est traité comme votre œuvre, avec toutes les conséquences.

Concrètement, le fait qu'un modèle ait écrit le code ne décharge personne. Au contraire, cela appelle une explication supplémentaire dès que se pose la question du soin apporté au contrôle.

Qu'est-ce qui change avec la nouvelle directive européenne sur la responsabilité du fait des produits ?

Trois choses, qui vont toutes dans le même sens. La directive (UE) 2024/2853 est entrée en vigueur le 9 décembre 2024 ; les États membres devaient la transposer avant le 9 décembre 2026, et le législateur allemand a adopté la réforme en 2026.

• Le logiciel est un produit. Les produits numériques, y compris les systèmes d'IA, sont expressément couverts. L'ancienne discussion sur la question de savoir si un logiciel seul relève de la responsabilité du fait des produits est ainsi close.
• Allègements de la charge de la preuve et obligations de divulgation. Les personnes lésées doivent prouver moins complètement ; les fabricants peuvent être tenus de divulguer des documents. Qui ne peut pas exposer comment le développement et les contrôles ont été conduits se trouve dans une position plus défavorable qu'auparavant.
• La cybersécurité comme critère de défaut. Une faille de sécurité peut fonder un défaut du produit. Cela relie directement la qualité du code à la question de la responsabilité.

Que signifie le Cyber Resilience Act pour le développement ?

Il apporte des échéances qui s'appliquent avant la responsabilité du fait des produits. Le règlement (UE) 2024/2847 s'adresse aux fabricants, importateurs et distributeurs de produits comportant des éléments numériques, matériel comme logiciel.

• À partir du 11 septembre 2026 : obligations de notification. Les vulnérabilités activement exploitées doivent être signalées sous 24 heures, à titre d'alerte précoce, au CSIRT compétent et à l'ENISA ; le rapport suit sous 72 heures, le rapport final sous 14 jours.
• À partir du 11 décembre 2027 : l'ensemble des obligations des fabricants, y compris le marquage CE pour la cybersécurité.

Le délai de 24 heures est le point au potentiel pratique le plus explosif. Il suppose que vous sachiez seulement ce que contient votre produit, dépendances comprises, et que vous soyez en mesure d'agir. Les deux relèvent de la discipline de développement, pas du service juridique.

Comment documenter le soin apporté dans un développement assisté par IA ?

Avec des preuves qui se produisent de toute façon dans le processus de développement, pas avec un dossier « conformité » à part. Cinq éléments qui valent quelque chose en cas de litige :

• Un historique traçable. Qui a modifié quoi, quand, avec quelle justification. La gestion de versions le fournit si les messages de commit contiennent davantage que « fix ».
• Une étape de contrôle avant la livraison. Attestée par le journal du pipeline, pas par une directive qui la prévoit.
• Un inventaire des composants. Quels paquets tiers, dans quelle version. C'est aussi la condition du délai de 24 heures.
• Des décisions documentées. Pourquoi cette voie a-t-elle été choisie ? Pour du code généré, cette information manque sinon entièrement ; voir Vibe Coding ou Agentic Coding.
• Capacité de réaction. Une voie éprouvée pour livrer rapidement un correctif.

Le dénominateur commun : tout cela est une bonne pratique de développement qui se trouve aussi être exploitable juridiquement. Qui ne la met en place que lorsqu'un avocat pose la question la met en place trop tard.

Comment régler la responsabilité avec les clients et les prestataires ?

Par trois points qui doivent figurer au contrat et qui, en l'état actuel, manquent souvent.

• Si des outils d'IA peuvent être utilisés. Une interdiction sans possibilité de contrôle est inefficace ; une autorisation assortie d'obligations de contrôle est exécutoire.
• Quels contrôles sont garantis. Non pas « selon l'état de l'art », mais des étapes de contrôle nommées, dont l'exécution peut être prouvée.
• À qui reviennent les droits sur le résultat. La qualification au regard du droit d'auteur de résultats purement générés par machine n'est pas définitivement tranchée ; une clause contractuelle sur les droits d'utilisation et d'exploitation apporte la clarté que la loi ne fournit pas actuellement.

Questions fréquentes sur la responsabilité du code IA

OpenAI ou Anthropic répondent-ils d'un code défectueux ?

Selon les conditions d'utilisation habituelles, non. La responsabilité de l'usage du code généré incombe à l'utilisateur. En cas de doute, vérifiez les conditions du service concrètement utilisé, dans la version applicable au moment de votre utilisation.

Le code généré par IA est-il protégé par le droit d'auteur ?

La question n'est pas définitivement tranchée. Selon l'opinion dominante en Allemagne, la protection par le droit d'auteur suppose une création intellectuelle personnelle, ce qui est problématique en cas de génération purement automatique. En pratique : ne comptez pas sur une protection automatique, mais réglez les droits d'utilisation par contrat.

Dois-je informer mes clients que de l'IA a été utilisée ?

À l'heure actuelle, il n'existe pas d'obligation légale générale de divulguer l'usage de l'IA dans la création d'un logiciel. Il peut en aller autrement par contrat, et les obligations de transparence du règlement sur l'IA (AI Act) concernent les systèmes d'IA que vous fournissez à vos utilisateurs, non l'outil avec lequel vous développez. Pour développer les compétences en IA selon l'art. 4 du règlement sur l'IA (AI Act), vous trouverez plus d'informations sous certificat IA.

Tout cela vaut-il aussi pour les logiciels internes ?

La responsabilité du fait des produits se rattache à la mise sur le marché ; des outils purement internes s'apprécient autrement que des produits commercialisés. Les exigences de diligence résultant de la relation de travail, de la protection des données et de la sécurité informatique s'appliquent néanmoins.

Ce qui compte en cas de litige, c'est la preuve que des contrôles ont eu lieu, pas l'intention d'en faire. Code Guardian produit cette preuve en passant : un plan avec journal des décisions avant la modification, un audit documenté après.

Sources

• Directive (UE) 2024/2853 sur la responsabilité du fait des produits défectueux : en vigueur depuis le 9 décembre 2024, délai de transposition 9 décembre 2026.
• Règlement (UE) 2024/2847 (Cyber Resilience Act).
• Règlement (UE) 2024/1689 (règlement sur l'IA, AI Act) : art. 4 et art. 50.

Date : 27 juillet 2026. Cet article est une information générale et ne constitue pas un conseil juridique. Pour l'appréciation de votre cas particulier, la rédaction des contrats et la qualification de votre produit au regard du CRA et de la responsabilité du fait des produits, vous devriez consulter un avocat.