Responsabilité produits défectueux : logiciels et IA

Le 9 décembre 2026 — dans quatre mois — un logiciel devient juridiquement un produit au sens du régime européen de la responsabilité du fait des produits défectueux. Un éditeur SaaS, un développeur d’application mobile, un intégrateur qui livre un système d’IA entrent dans un régime de responsabilité sans faute, qu’aucun contrat ne pourra limiter. C’est, à mon sens, le changement de droit numérique le plus sous-estimé de l’année en France.

Ce que change la directive (UE) 2024/2853

La directive (UE) 2024/2853 du 23 octobre 2024, publiée au JOUE le 18 novembre 2024, abroge la directive 85/374/CEE du 25 juillet 1985 — celle qui, transposée aux articles 1245 à 1245-17 du code civil, fonde depuis 1998 la responsabilité française du fait des produits défectueux.

Trois dates à retenir :

Date	Événement
9 décembre 2026	Échéance de transposition dans les droits nationaux
9 décembre 2026	Application du nouveau régime aux produits mis sur le marché ou en service à compter de cette date
9 décembre 2026	Abrogation de la directive 85/374/CEE (qui continue de régir les produits antérieurs)

Le point de bascule est la mise sur le marché, pas la date du dommage. Concrètement, les deux régimes vont cohabiter pendant une dizaine d’années : un logiciel commercialisé le 8 décembre 2026 reste sous l’ancien droit, une mise à jour substantielle du même logiciel diffusée le 10 décembre peut faire basculer le produit modifié sous le nouveau.

À ce jour — début août 2026 —, aucun texte français de transposition n’a été publié. Ni ordonnance, ni loi. Le calendrier parlementaire rend probable un passage par une loi d’habilitation ou un véhicule DDADUE en fin d’année. Ce retard n’est pas une bonne nouvelle pour les entreprises : il comprime le temps d’adaptation, alors même que le fait générateur de responsabilité — la mise sur le marché — est, lui, calé sur une date fixe.

Le logiciel devient un produit : le périmètre exact

L’article 4(1) de la directive définit le produit comme « tout bien meuble, même s’il est intégré dans un autre bien meuble ou dans un bien immeuble », et précise que la notion inclut l’électricité, les fichiers de fabrication numériques, les matières premières et les logiciels.

Cette énumération n’a rien de rhétorique. Elle met fin à vingt-cinq ans de débat doctrinal français — un débat que je suis depuis ma thèse sur la propriété informatique — sur la qualification du logiciel comme « bien meuble » au sens de l’ancien article 1245-1. La question est tranchée par le législateur européen, et elle l’est dans le sens large.

Ce qui est couvert

• Les logiciels embarqués dans un objet physique (firmware d’un objet connecté, calculateur automobile, dispositif médical).
• Les logiciels autonomes, y compris distribués en ligne : application mobile, logiciel de bureau, extension navigateur.
• Les systèmes d’IA, qui ne sont qu’une catégorie de logiciels. Le considérant 13 le dit expressément.
• Les services numériques connexes au sens de l’article 4(3) : un service numérique intégré ou interconnecté à un produit « de manière telle que son absence empêcherait le produit d’exécuter une ou plusieurs de ses fonctions ». Une application de pilotage d’un thermostat, un service de navigation embarqué, une API dont dépend le fonctionnement d’un objet — tous sont traités comme des composants au sens de l’article 4(2), et engagent la responsabilité à ce titre.
• Les fichiers de fabrication numériques : le fichier CAO destiné à l’impression 3D devient un produit à part entière.

Ce qui reste dehors

• Les logiciels libres et ouverts développés ou fournis en dehors d’une activité commerciale. L’exclusion est réelle mais étroite : dès lors que l’open source est fourni contre rémunération, ou dans le cadre d’une activité commerciale — y compris via un modèle de support payant ou une monétisation par les données personnelles des utilisateurs —, la directive s’applique. La logique reprend celle retenue par le Cyber Resilience Act pour l’open source, avec des seuils toutefois différents : ne transposez pas mécaniquement l’analyse d’un texte à l’autre.
• Les services purs, non rattachés à un produit. Un cabinet de conseil qui délivre une prestation intellectuelle n’est pas concerné ; un éditeur qui livre du logiciel, si.
• Les logiciels développés en interne et non mis à disposition sur le marché. La notion de mise sur le marché suppose une fourniture dans le cadre d’une activité commerciale.

Pour un éditeur SaaS, la question de qualification est plus délicate qu’il n’y paraît : la directive vise le logiciel, et non le contrat par lequel il est mis à disposition. Un SaaS qui fournit une fonctionnalité logicielle à ses clients relève, sauf circonstance particulière, du périmètre — quelle que soit l’étiquette « service » du contrat. C’est le même mouvement que celui du CRA pour les éditeurs SaaS : le droit européen cesse de raisonner en « logiciel vendu contre service rendu ».

Qui peut être attaqué : la chaîne des opérateurs économiques

La directive de 1985 visait le « producteur ». La directive de 2024 raisonne en opérateurs économiques (article 8) et construit une cascade destinée à garantir qu’une victime dans l’Union trouve toujours un défendeur solvable et territorialement accessible.

Rang	Opérateur	Condition d’engagement
1	Fabricant du produit ou du composant défectueux	Toujours responsable
2	Personne apposant son nom ou sa marque sur le produit	Traitée comme fabricant
3	Personne modifiant substantiellement le produit hors du contrôle du fabricant	Responsable du produit modifié
4	Importateur et mandataire du fabricant établi hors UE	Si le fabricant est hors Union
5	Prestataire de services d’exécution des commandes (fulfilment)	À défaut d’importateur ou de mandataire dans l’UE
6	Distributeur	À défaut d’identification des précédents et s’il ne désigne pas son fournisseur dans un délai raisonnable
7	Fournisseur de plateforme de commerce en ligne	Sous conditions, lorsqu’il présente l’offre de manière à faire croire à une vente par lui-même

Trois conséquences pratiques.

Pour les revendeurs sous marque propre. Le rang 2 est le piège classique du e-commerce. Vous faites fabriquer en Asie, vous apposez votre marque, vous vendez : vous êtes fabricant, sans avoir jamais rien fabriqué. C’est exactement le mécanisme que le GPSR applique déjà en matière de sécurité des produits, et le dropshipping y est particulièrement exposé.

Pour les plateformes. Le rang 7 poursuit la logique déjà à l’œuvre dans le DSA : l’opérateur qui laisse penser au consommateur que le produit provient de lui assume la responsabilité correspondante. Les CGV de marketplace doivent être relues à cette aune, en particulier la présentation des offres tierces et la gestion du service après-vente.

Pour les fournisseurs de composants logiciels. Le rang 1 vise le fabricant du composant défectueux, pas seulement celui du produit fini. L’éditeur d’une bibliothèque intégrée, le fournisseur d’un modèle d’IA, le prestataire d’un service connexe peuvent être attraits directement par la victime. La responsabilité est solidaire entre opérateurs, chacun conservant ses recours internes. D’où l’importance des clauses de garantie et de répartition dans les contrats amont — sujet que nous traitons pour l’IA dans nos clauses contractuelles SaaS et IA.

La défectuosité se réapprécie dans le temps

L’article 7 énumère les circonstances dont le juge doit tenir compte pour dire si un produit est défectueux, c’est-à-dire s’il « n’offre pas la sécurité à laquelle on peut légitimement s’attendre ». Aux critères classiques — présentation, utilisation raisonnablement prévisible, moment de la mise sur le marché — s’en ajoutent trois qui changent la donne pour le numérique :

1. L’effet sur le produit de sa capacité à continuer d’apprendre ou à acquérir de nouvelles fonctionnalités après la mise sur le marché. Un système d’apprentissage continu doit rester sûr après dérive. La responsabilité ne se fige plus au jour de la livraison.
2. L’effet raisonnablement prévisible sur le produit d’autres produits utilisés conjointement, y compris par interconnexion. L’écosystème compte.
3. Les exigences applicables en matière de sécurité, y compris de cybersécurité. C’est le pont explicite entre la responsabilité civile et la conformité réglementaire.

Ce troisième critère mérite qu’on s’y arrête. Il signifie qu’un manquement aux exigences essentielles du Cyber Resilience Act devient un argument de défectuosité devant le juge civil, et non plus seulement un risque de sanction administrative. Une vulnérabilité non corrigée, une gestion des vulnérabilités défaillante, une nomenclature logicielle (SBOM) absente cessent d’être des sujets de conformité pour devenir des éléments de preuve.

Symétriquement, l’article 11 prive l’opérateur de l’exonération tirée de l’apparition ultérieure du défaut lorsque celui-ci résulte d’un service connexe, d’un logiciel (y compris ses mises à jour) ou d’une absence de mise à jour ou de mise à niveau nécessaire au maintien de la sécurité, dès lors que ces éléments restent sous son contrôle. Autrement dit : ne pas patcher engage. L’obligation de support et de mise à jour de sécurité du CRA trouve ici sa sanction civile.

Les dommages réparables : la corruption de données entre dans le champ

L’article 6 élargit la liste des préjudices indemnisables :

• Décès et lésions corporelles, y compris le préjudice psychologique médicalement reconnu — une nouveauté.
• Destruction ou détérioration d’un bien, à l’exclusion du produit défectueux lui-même et des composants qu’il incorpore.
• Destruction ou altération de données qui ne sont pas utilisées à des fins professionnelles.

Le troisième poste est celui qui intéresse le plus directement les lecteurs de ce site. Un logiciel qui corrompt les photos, les documents ou les sauvegardes d’un particulier ouvre désormais un droit à réparation dans un régime sans faute. La restriction « à des fins autres que professionnelles » exclut les données d’entreprise du bénéfice de ce régime : une PME dont l’ERP détruit la comptabilité devra revenir au terrain contractuel ou délictuel classique.

Deux exclusions importantes : les pertes purement économiques (manque à gagner, coût de remplacement du produit) et les atteintes à la vie privée ne relèvent pas de la directive. Le préjudice tiré d’une violation de données personnelles continue de se traiter sur le fondement de l’article 82 du RGPD, avec sa propre logique — responsabilité du responsable de traitement et du sous-traitant, exonération par l’absence d’imputabilité, indemnisation intégrale du dommage matériel et moral. Les deux régimes peuvent se cumuler pour un même événement : une faille de sécurité peut simultanément caractériser un manquement à l’article 32 du RGPD et un défaut de sécurité du produit au sens de la directive.

Autre changement structurant : la suppression du seuil de 500 euros qui, dans la directive de 1985, conditionnait l’indemnisation des dommages aux biens. En droit français, l’article 1245-1 du code civil fixait ce seuil, réduit à 500 € par le décret du 11 février 2005. Il disparaît. Le contentieux de faible montant devient possible — et, combiné à l’action de groupe, à l’échelle de masse.

La preuve : le vrai basculement

C’est ici que la directive produit son effet le plus puissant, et le moins commenté en France.

Divulgation forcée des éléments de preuve (article 9)

Lorsque le demandeur présente des éléments suffisants pour établir la plausibilité de sa demande, le juge peut ordonner au défendeur de divulguer les éléments de preuve pertinents dont il dispose. La mesure est encadrée par un test de nécessité et de proportionnalité, et par la protection du secret des affaires — mais elle existe.

Pour un éditeur, cela veut dire : journaux d’exécution, historiques de versions, tickets de bug, rapports de tests, documentation d’ingénierie, résultats d’audits de sécurité. La question à se poser dès aujourd’hui n’est pas « puis-je résister à une divulgation ? » mais « que raconteront mes traces internes si un juge les met sur la table dans six ans ? ». Un ticket ouvert deux ans avant l’accident, qualifié en interne de « risque connu, non prioritaire », n’a pas la même valeur selon qu’il a été suivi d’un correctif documenté ou classé sans suite.

Présomptions de défectuosité et de causalité (article 10)

Le texte crée plusieurs présomptions réfragables. La défectuosité est présumée lorsque :

• le défendeur ne se conforme pas à l’injonction de divulgation ;
• le demandeur démontre que le produit ne respecte pas des exigences obligatoires de sécurité destinées à prévenir le risque survenu ;
• le dommage résulte d’un dysfonctionnement manifeste du produit dans des circonstances d’utilisation normales.

Le lien de causalité est présumé lorsque le dommage est typiquement compatible avec le défaut établi. Enfin — et c’est la disposition la plus significative pour l’IA —, lorsque le demandeur rencontre des difficultés excessives à prouver le défaut ou la causalité « en raison de la complexité technique ou scientifique » de l’affaire, le juge peut se contenter de la démonstration d’une probabilité.

Cette dernière règle est la réponse européenne à l’opacité algorithmique. Il ne sera plus nécessaire d’expliquer pourquoi un réseau de neurones a produit une sortie dangereuse : il suffira d’établir que c’est probable, à charge pour l’opérateur de renverser la présomption. Combinée à la divulgation forcée, elle rend la traçabilité de conception — les journaux d’entraînement, la documentation technique exigée par l’AI Act, les registres d’événements des systèmes à haut risque — directement opposable à celui qui l’a produite.

Prescription : trois ans, dix ans, vingt-cinq ans

• Article 16 — délai de prescription de 3 ans courant du jour où le demandeur a eu, ou aurait dû raisonnablement avoir, connaissance cumulativement du dommage, du caractère défectueux et de l’identité de l’opérateur.
• Article 17 — délai butoir d’extinction de 10 ans à compter de la mise sur le marché ou en service du produit. En cas de modification substantielle, le délai repart de la mise à disposition du produit modifié.
• Article 17 encore — butoir porté à 25 ans lorsque la victime n’a pas pu agir dans les dix ans en raison de la latence d’un préjudice corporel.

Vingt-cinq ans, c’est trois à cinq fois la durée de vie commerciale d’un logiciel, et bien au-delà de la durée de conservation habituelle des artefacts d’ingénierie. C’est aussi le point de friction le plus net avec le RGPD : conserver des journaux techniques identifiants pendant vingt-cinq ans « au cas où » ne se justifie pas en soi. La position défendable consiste à distinguer les traces produit (versions, tests, documentation, décisions de conception, SBOM), à conserver longuement parce qu’elles sont non personnelles, des traces utilisateur, à minimiser et à pseudonymiser en application de l’article 25 du RGPD. Cette séparation doit être décidée maintenant, à la conception : elle est impossible à reconstituer a posteriori.

L’exonération pour risque de développement subsiste — mais elle est fragilisée

L’article 11 maintient les exonérations classiques, dont celle tirée de ce que « l’état objectif des connaissances scientifiques et techniques » au moment de la mise sur le marché ne permettait pas de déceler le défaut. L’article 18 autorise toutefois les États membres à y déroger, en tout ou partie.

En droit français, cette exonération figure à l’article 1245-10, 4° du code civil, et l’article 1245-11 l’écarte déjà pour les produits issus du corps humain. La transposition sera l’occasion d’un arbitrage politique : la France retient-elle l’exonération pour les systèmes d’IA, dont l’opacité rend précisément incertain « l’état des connaissances » ? Aucune orientation gouvernementale n’a été rendue publique à ce jour. C’est le point à surveiller dans le futur texte de transposition.

Enfin, l’article 15 interdit toute limitation ou exonération conventionnelle de la responsabilité à l’égard de la personne lésée. Vos conditions générales de vente, vos CLUF et vos plafonds contractuels sont inopposables à la victime. Ils conservent leur utilité entre professionnels, dans les recours en garantie — pas comme bouclier.

Ce qu’il faut faire d’ici décembre 2026

1. Qualifier votre position dans la chaîne. Fabricant, marque apposée, importateur, distributeur, plateforme, fournisseur de composant : la réponse détermine tout le reste. Documentez-la.
2. Inventorier vos produits logiciels et vos services connexes. Un simple registre des composants tiers et de leurs versions vous mettra déjà en avance sur la majorité des éditeurs français.
3. Aligner le calendrier de mise sur le marché. Un produit lancé après le 9 décembre 2026 relève du nouveau régime. Une refonte majeure prévue début 2027 doit être documentée en conséquence.
4. Traiter le patch comme une obligation, pas comme une politique. Définissez une durée de support, publiez-la, tenez-la. L’absence de mise à jour de sécurité sous votre contrôle est expressément privée d’effet exonératoire.
5. Auditer vos traces d’ingénierie dans la perspective d’une divulgation judiciaire. Le vocabulaire des tickets internes compte.
6. Séparer conservation produit et conservation utilisateur, pour tenir vingt-cinq ans sans conserver vingt-cinq ans de données personnelles.
7. Réviser les contrats amont : garanties, recours, obligations d’information mutuelle en cas de défaut, assurance.
8. Vérifier votre couverture d’assurance RC produits. L’extension au logiciel, à l’IA et à la corruption de données n’est pas acquise dans les polices anciennes ; le point est à poser explicitement à votre courtier.
9. Rapprocher les chantiers CRA, AI Act et produits défectueux. Ce sont les mêmes composants, les mêmes versions, les mêmes preuves — voir notre analyse de la double conformité CRA / AI Act.

Le point 9 est celui où l’on perd le plus de temps. Maintenir trois référentiels parallèles — cybersécurité, IA, responsabilité produit — sur les mêmes actifs logiciels garantit qu’ils auront divergé dans six mois. C’est précisément ce recoupement documentaire que Legiscope automatise, en partant d’un inventaire unique.

Recevez nos analyses conformité chaque semaine. Produits défectueux, CRA, AI Act, RGPD : une lecture par semaine pour comprendre ce qui change et ce qu’il faut faire. S’inscrire à la newsletter.

Et l’IA dans tout ça ?

Il faut être clair sur un point souvent mal restitué : il n’existe pas de régime européen spécifique de responsabilité civile du fait de l’IA. La proposition de directive sur la responsabilité en matière d’intelligence artificielle (AILD), déposée le 28 septembre 2022, a été retirée par la Commission dans son programme de travail publié le 11 février 2025, faute d’accord prévisible — malgré l’opposition de la commission IMCO du Parlement européen.

La directive 2024/2853 est donc, de fait, le principal régime européen de responsabilité applicable aux dommages causés par l’IA. Elle n’a pas été conçue pour cela seul, mais l’article 7 (apprentissage continu), l’article 10(4) (difficultés excessives de preuve) et l’article 4 (le logiciel est un produit) la rendent opérante. Le complément se trouve dans le droit commun français — articles 1240 et 1242 du code civil, responsabilité contractuelle — comme nous l’analysons pour l’IA agentique. L’AI Act, lui, organise la conformité et la répartition des rôles ; il n’impute pas les dommages.

Ce qu’il faut retenir

• La directive (UE) 2024/2853 doit être transposée au plus tard le 9 décembre 2026 et s’applique aux produits mis sur le marché ou en service à compter de cette date. Aucun texte français de transposition n’a été publié à ce jour.
• Le logiciel est un produit (art. 4(1)), y compris autonome, y compris l’IA. Les services numériques connexes sont des composants (art. 4(2) et (3)). Seul l’open source non commercial est exclu.
• La chaîne des opérateurs économiques (art. 8) va du fabricant à la plateforme en ligne, en passant par celui qui appose sa marque, l’importateur, le prestataire de fulfilment et le distributeur. La responsabilité est solidaire et aucune clause contractuelle ne peut la limiter à l’égard de la victime (art. 15).
• La preuve bascule : divulgation forcée des éléments détenus par le défendeur (art. 9), présomption de défectuosité en cas de non-conformité aux exigences de sécurité ou de dysfonctionnement manifeste, et simple probabilité suffisante lorsque la complexité technique crée des difficultés excessives (art. 10).
• Les délais passent à 3 ans de prescription, 10 ans de butoir, 25 ans en cas de préjudice corporel latent. La destruction ou l’altération de données non professionnelles devient un dommage réparable et le seuil de 500 € disparaît.

FAQ

Mon SaaS est-il concerné par la directive sur les produits défectueux ?

Très probablement oui. La directive vise le logiciel en tant que tel (art. 4(1)), indépendamment de la qualification contractuelle retenue par le fournisseur. Un SaaS qui met une fonctionnalité logicielle à disposition dans le cadre d’une activité commerciale relève du régime. La qualification « service » dans vos CGV ne constitue pas une exclusion — d’autant que l’article 15 interdit les aménagements conventionnels de responsabilité à l’égard de la personne lésée.

La directive s’applique-t-elle aux logiciels déjà commercialisés avant décembre 2026 ?

Non. Le nouveau régime ne vise que les produits mis sur le marché ou mis en service à compter du 9 décembre 2026 ; les produits antérieurs restent régis par la directive 85/374/CEE et les articles 1245 et suivants du code civil dans leur rédaction actuelle. Attention toutefois : une modification substantielle intervenue après cette date, hors du contrôle du fabricant d’origine, fait naître un nouveau produit — avec un nouveau point de départ du délai butoir de dix ans.

Une entreprise peut-elle être indemnisée de la perte de ses données ?

Pas sur le fondement de cette directive. L’article 6 limite le poste « destruction ou altération de données » aux données qui ne sont pas utilisées à des fins professionnelles. Une entreprise victime d’une corruption de ses fichiers doit se placer sur le terrain contractuel, sur celui de la responsabilité délictuelle de droit commun, ou — si des données personnelles sont en cause et qu’un manquement au RGPD est caractérisé — sur l’article 82 du RGPD.

Faut-il conserver ses journaux techniques pendant vingt-cinq ans ?

La bonne réponse n’est pas binaire. Les artefacts non personnels — versions, SBOM, rapports de tests, décisions de conception, documentation technique — méritent une conservation longue, alignée sur le risque de mise en cause : ils constituent votre défense. Les journaux contenant des données personnelles doivent au contraire être minimisés, pseudonymisés et purgés selon leur propre finalité. La séparation des deux flux se décide à la conception, au titre de l’article 25 du RGPD, et ne se rattrape pas ensuite.

Le retrait de la directive sur la responsabilité de l’IA laisse-t-il un vide juridique ?

Non, mais il laisse une incertitude. La proposition AILD a été retirée en février 2025 ; les dommages causés par des systèmes d’IA relèvent donc de la directive 2024/2853 lorsque les conditions en sont réunies — produit défectueux, dommage réparable, causalité — et, à défaut, du droit commun de la responsabilité civile. L’AI Act organise la conformité, pas l’indemnisation. C’est précisément ce que les présomptions de l’article 10 viennent compenser.

---

Thiébaut Devergranne est docteur en droit (Paris II) et consultant en protection des données depuis plus de vingt ans, dont six passées au sein des services du Premier ministre (SGDN/DCSSI). Il est le fondateur de donneespersonnelles.fr et de Legiscope.