Acteurs IA et produits défectueux : quelles responsabilités en cas de défaut de sécurité du produit IA ?

Contrairement à la proposition de directive du Parlement européen et du Conseil relative à l'adaptation des règles en matière de responsabilité civile extracontractuelle au domaine de l'intelligence artificielle, communément appelée "Directive sur la responsabilité en matière d'IA", qui avait été envisagée par l'Union européenne pour adapter spécifiquement les règles de responsabilité civile aux particularités des systèmes d'IA, la directive 2024/2853 du 23 octobre 2024 ("PLD") relative à la responsabilité des produits défectueux ne traite pas spécifiquement des acteurs de l'IA et/ou des produits d'IA lorsqu'il s'agit de répartir les responsabilités en cas de dommages : elle les soumet au même régime que n'importe quel fabricant ou distributeur d'un produit entrant dans son champ d'application.

‍

Premièrement, il convient de préciser que, si l'IA est visée par la PLD, tout élément numérique ne tombe pas sous le coup de la PLD.

‍

Ainsi, en application de la PLD, la donnée n'est pas, en tant que telle, considérée comme un produit et échappe donc à ce régime de responsabilité (considérant 13). Le logiciel est expressément qualifié de produit (article 4, § 1), et le seul code source, assimilé à une information, en est exclu (considérant 13). Le mode de fourniture du logiciel est par ailleurs indifférent : qu'il soit installé localement, accessible via le cloud ou fourni en mode SaaS, il demeure un produit. La difficulté résiduelle porte sur le « service connexe » (service numérique, au sens de l'article 4) : celui-ci n'est pas un produit en tant que tel, mais il est assimilé à un composant — et relève donc du régime — lorsqu'il est intégré ou interconnecté à un produit ; un service purement autonome, non intégré, échappe en revanche à la qualification de produit.

‍

Ensuite, la PLD distingue plusieurs catégories d'opérateurs économiques (selon la notion employée par la PLD) susceptibles d'engager leur responsabilité. Le fabricant du produit défectueux demeure responsable en premier lieu : même si le terme n'est pas corrélé aux notions de l'IA Act, il s'étend aux développeurs d'outils IA commercialisés. L'outil d'IA constitue alors un produit défectueux en lui-même, séparément du produit dans lequel il est incorporé.

‍

Les distributeurs voient également leur responsabilité renforcée. L'article 8 de la directive prévoit que le distributeur répond du dommage lorsque, saisi par la personne lésée d'une demande d'identification de l'opérateur économique (ou du distributeur) lui ayant fourni le produit, il n'y donne pas suite dans un délai d'un mois. Il s'agit d'une responsabilité subsidiaire, qui ne se déclenche qu'à défaut d'identification d'un opérateur économique de premier rang établi dans l'Union. Elle ne doit pas être confondue avec la responsabilité solidaire prévue à l'article 12, qui joue lorsque plusieurs opérateurs sont responsables d'un même dommage.

‍

Cette nomenclature, plutôt applicable à un produit "standard", devra néanmoins être transposée à l'écosystème IA, caractérisé par les nombreux intermédiaires

techniques.

‍

1. Répartition de la responsabilité dans l'écosystème IA

‍

1.1. Responsabilité du développeur

‍

Le développeur/concepteur qui conçoit l'architecture algorithmique et entraîne le modèle assume, en qualité de fabricant du produit, la responsabilité principale. Cette responsabilité s'étend aux choix de données d'entraînement, aux méthodes d'apprentissage et aux mécanismes de validation.
La sous-traitance du développement ne décharge pas le donneur d'ordre de sa qualité de fabricant. Une entreprise qui fait développer un outil IA par un prestataire externe demeure responsable vis-à-vis des utilisateurs finaux, sauf à démontrer que le défaut résulte exclusivement du sous-traitant, par exemple d'une mauvaise prise en compte des instructions ou du cahier des charges.

‍

Les développeurs qui utilisent des modèles pré-entraînés pour créer des applications spécialisées assument la responsabilité de l'adaptation et de l'intégration. Si le défaut provient du modèle de base, ils peuvent exercer un recours contre le fournisseur du modèle, mais restent responsables vis-à-vis de leurs utilisateurs.
Enfin, aux termes de la PLD, un opérateur qui, sans fabriquer le produit, y apporte une modification substantielle, suivie d'une mise à disposition sur le marché ou d'une mise en service, en devient juridiquement le fabricant au sens de la PLD.

‍

1.2. Responsabilité des distributeurs

‍

Appliquée aux systèmes IA, la notion de distributeur est moins évidente que pour d'autres types de produits.

‍

La PLD définit le distributeur comme toute personne physique ou morale faisant partie de la chaîne d'approvisionnement qui met un produit à disposition sur le marché, autre que le fabricant ou l'importateur de ce produit.

‍

Il appartiendra à la jurisprudence de préciser qui peut entrer dans cette catégorie en matière d'IA : les revendeurs d'éditeurs IA qui proposent des solutions tierces sans les modifier ? Les plateformes SaaS intermédiaires qui donnent accès à un modèle IA développé par un tiers sans transformation substantielle ? La multiplicité des intervenants dans la chaîne, avant l'apport de la solution finale au client, rend l'identification des distributeurs plus complexe que pour un bien physique.

‍

2. Articulation avec la responsabilité contractuelle

‍

La responsabilité du fait des produits défectueux est un régime dérogatoire et exclusif qui ne se cumule pas avec la responsabilité contractuelle de droit commun. Lorsque la responsabilité du fabricant est recherchée pour un défaut de sécurité, peu importe qu'il existe ou non un contrat entre l'utilisateur victime et le fabricant, c'est le régime de responsabilité des produits défectueux qui va s'appliquer, si un dommage corporel est démontré ou un dommage matériel autre que le produit défectueux lui-même.

‍

Contrairement à la directive de 1985, la PLD prévoit en son article 1er l'application du texte aux seules personnes physiques, ce qui devrait exclure les dommages causés dans le cadre de l'activité professionnelle. Dès lors, dans un recours entre professionnels, la responsabilité du fait des produits défectueux issue de cette directive ne pourra en principe être invoquée.

‍

Lorsque le régime de responsabilité des produits défectueux est écarté, d'autres fondements de responsabilité peuvent s'appliquer. Un utilisateur professionnel peut invoquer la garantie de conformité contractuelle pour des défauts de performance qui ne constituent pas nécessairement des défauts de sécurité au sens de la directive sur les produits défectueux ; un fournisseur d'équipements qui causent un dommage matériel peut agir sur le fondement des vices cachés dès lors qu'aucun dommage corporel n'est causé.

‍

Ce même raisonnement de fondements alternatifs de responsabilité pourra être appliqué en matière de dommages causés par IA, dès lors qu'aucune atteinte à la sécurité ne pourra être démontrée notamment.

‍

3. Stratégies de prévention des risques pour les développeurs / concepteurs d'outils IA

‍

3.1. Documentation et traçabilité techniques

‍

La constitution d'une documentation technique constitue la première ligne de défense. Cette documentation doit couvrir les choix d'architecture, les jeux de données utilisés, les méthodes de validation et les tests de robustesse effectués.

‍

Cet impératif documentaire est encore renforcé par le nouveau mécanisme de divulgation des preuves prévu par la PLD, en cours de transposition en France. Dès lors que le juge peut ordonner la diffusion de l'ensemble des éléments de preuve à disposition du fabricant, et qu'un refus de coopérer entraîne une présomption de défectuosité, la documentation ne joue plus seulement un rôle défensif : elle conditionne la capacité même de l'opérateur à démontrer l'absence de défaut. Les créateurs d'outils IA ont donc intérêt à anticiper cette obligation en organisant, dès la conception, la conservation structurée de leurs preuves techniques, tout en identifiant les éléments relevant du secret des affaires susceptibles de bénéficier d'une protection lors de leur communication. Le texte de transposition en droit français permettra d'éclairer sur les limites qui seront posées par le législateur à cette règle de « discovery » européenne.

‍

3.2. Tests de robustesse et validation continue

‍

Les développeurs / concepteurs d'outils IA doivent implémenter des protocoles de test adaptés aux spécificités de l'apprentissage automatique, tels que les tests adversariaux, qui vérifient la résistance du système à des inputs malveillants.

‍

3.3. Gestion des interfaces et intégrations

‍

L'intégration d'outils IA tiers impose une diligence particulière dans l'évaluation des risques. Il convient de s'assurer que le cahier des charges du client est clair et bien compris, et qu'un audit technique est réalisé. Enfin, il est recommandé, pour le client, de vérifier les couvertures assurantielles du fournisseur et leur adéquation au regard des risques.

‍

3.4. Contractualisation des responsabilités

‍

La contractualisation des responsabilités avec les fournisseurs doit prévoir des mécanismes de recours et d'allocation des responsabilités ; une relecture attentive des clauses de responsabilité doit être effectuée. Par exemple, les clauses qui visent à écarter ou limiter la responsabilité du fait des produits défectueux sont interdites et réputées non écrites aux termes de l'article 1245-14 du Code civil, mais restent possibles dans les contrats B2B, de manière encadrée : elles ne peuvent porter ni sur les dommages corporels ni sur les dommages causés aux biens de consommation utilisés à des fins privées. Les clauses limitatives de responsabilité plus générales, qui ont vocation à s'appliquer à toute réparation d'une partie à l'autre, sont quant à elles soumises au régime de droit commun : pour être valables, elles ne doivent pas contredire l'obligation essentielle du débiteur, en la vidant de sa substance. La clause sera donc réputée non écrite si elle limite drastiquement la responsabilité en permettant à la personne protégée de ne pas exécuter son obligation principale sans subir de conséquences.

‍

Inversement, le contractant doit se garder d'accepter un contrat sans clause limitative de responsabilité ou avec une clause aux conséquences excessives compte tenu de la pratique, sous peine de voir un assureur RC refuser sa garantie.

‍

4. Couverture assurantielle spécialisée

‍

Le marché de l'assurance développe des produits spécifiques aux risques IA. Ces polices couvrent généralement la responsabilité civile professionnelle étendue aux algorithmes, les coûts de rappel produit et les frais de défense juridique. Certaines polices RC prévoient aussi parfois un plafond de garantie pour les dommages aux données informatiques / numériques confiées, c'est-à-dire celles des tiers. Mais le plafond est souvent relativement bas.

‍

La souscription d'une assurance cyber dédiée complète la protection, notamment pour les risques d'attaque, de corruption des modèles d'apprentissage et de pertes de données des tiers.

‍

5. Questions fréquentes (FAQ)

‍

5.1. Quelle est la différence entre responsabilité contractuelle et responsabilité du fait des produits défectueux pour l'IA ?

‍

La responsabilité contractuelle suppose un lien contractuel et permet l'aménagement des obligations par accord des parties. La responsabilité du fait des produits défectueux s'applique sans contrat et impose une obligation de sécurité impérative que les clauses contractuelles ne peuvent écarter pour les dommages corporels. Ces deux régimes ne peuvent se cumuler : la victime doit choisir l'un ou l'autre.

‍

5.2. Comment prouver qu'un outil IA présente un défaut ?

‍

La victime doit établir le dommage, le défaut et le lien de causalité. Pour l'IA, le défaut peut résulter d'un dysfonctionnement technique, d'une information insuffisante sur les limites du système, ou d'un niveau de sécurité inférieur aux attentes légitimes compte tenu de l'état de l'art. La PLD facilite désormais cette preuve grâce au mécanisme de divulgation des éléments de preuve (sous réserve des limites et des aménagements permis par la PLD et par la législation nationale) : le juge peut ordonner au fabricant de communiquer l'ensemble des preuves pertinentes à sa disposition, et son refus de coopérer fait présumer la défectuosité du produit.

‍

5.3. Quelle couverture d'assurance prévoir pour un créateur d'outils IA ?

‍

Une couverture optimale combine responsabilité civile professionnelle étendue aux données numériques / informatiques, assurance produits défectueux avec garantie rappel, et protection juridique pour les frais de défense. Les montants doivent tenir compte des dommages potentiels spécifiques à l'IA. Certains acteurs du marché de l'assurance, notamment en assurance cyber, prévoient un service d'assistance technique internalisé pour plus de réactivité.

‍

5.4. Comment gérer la responsabilité lors d'une collaboration entre plusieurs acteurs contribuant à la fabrication d'un produit IA ?

‍

La responsabilité peut être solidaire entre co-développeurs selon leur contribution respective. Il convient de contractualiser précisément les responsabilités de chacun, de définir qui assume le rôle de fabricant principal, et d'aménager les mécanismes de recours et/ou la responsabilité.