Logiciel défectueux : ce que la directive 2024/2853 change pour un éditeur B2B

Illustration : planche de texte annotée sur l'article 4 de la directive (UE) 2024/2853, avec un appareil connecté dont l'écran affiche un symbole de code et l'étiquette « Produit ».

Sources vérifiées le 31 octobre 2026. Prochaine revue le 9 décembre 2026. Temps de lecture : 14 minutes.

RégulationMémoire

Pour les produits mis sur le marché ou mis en service après le 9 décembre 2026, un logiciel est un produit au sens de la responsabilité sans faute, qu’il soit installé, embarqué ou fourni en SaaS (directive (UE) 2024/2853, article 4 et considérant 13). Le droit à réparation naît au profit des seules personnes physiques, pour trois types de dommages : la mort ou les lésions corporelles, y compris l’atteinte médicalement reconnue à la santé psychologique ; les biens qui ne servent pas exclusivement à un usage professionnel ; les données qui ne sont pas utilisées à des fins professionnelles. Leur assureur subrogé ou une personne agissant pour leur compte peut l’exercer (article 5).

Pour un éditeur qui vend à des entreprises, les pertes propres d’un client professionnel, données et chiffre d’affaires compris, restent hors de ce régime : elles relèvent du contrat et du droit commun de la responsabilité. Ce qui change, c’est l’exposition aux dommages subis par des personnes, que le logiciel soit utilisé seul ou intégré par un client dans son propre produit, et l’impossibilité de limiter cette responsabilité envers la victime (article 15). Au 31 octobre 2026, nous n’avons trouvé aucun texte français de transposition.

  • Texte : directive (UE) 2024/2853 du 23 octobre 2024 relative à la responsabilité du fait des produits défectueux, articles 2, 4 à 18 et 21 à 23 ; considérants 13, 14, 15, 17, 22, 51 et 55
  • Auteur : Parlement européen et Conseil de l’Union européenne
  • Date : signée le 23 octobre 2024 ; en vigueur depuis le 8 décembre 2024 (article 23) ; à transposer au plus tard le 9 décembre 2026 (article 22)
  • Application : produits mis sur le marché ou mis en service après le 9 décembre 2026 (article 2) ; l’ancienne directive 85/374/CEE reste applicable aux produits antérieurs (article 21)
  • Qui est concerné : les éditeurs de logiciels, y compris en SaaS, et les fabricants de produits qui intègrent un logiciel ou un service numérique connexe
  • Source primaire : texte de la directive sur EUR-Lex

Pour l’ensemble du texte : notre dossier de référence sur le Cyber Resilience Act, tenu à jour.

Sommaire
  1. Votre logiciel est-il un « produit » ?
  2. Qui peut vous demander réparation, et pour quels dommages ?
  3. Les mises à jour vous engagent-elles ?
  4. Votre clause de limitation de responsabilité tient-elle encore ?
  5. La victime aura-t-elle moins de mal à prouver le défaut ?
  6. Quels produits, à partir de quand, et pour combien de temps ?
  7. Où en est la France ?
  8. Comment on en est arrivé là
  9. Ce que cela change pour une ETI
  10. Notre lecture
  11. Ce que nous ne savons pas encore
  12. Questions fréquentes
  13. Ce qui a changé depuis la publication
  14. Sources

Prenons un éditeur de 60 salariés, construit pour l’exemple. Il fournit à un fabricant de thermostats connectés le logiciel de régulation embarqué dans ses appareils, vendus à des particuliers à partir de février 2027 ; le fabricant l’autorise, par contrat, à diffuser lui-même les mises à jour. En avril, une mise à jour bloque le chauffage à pleine puissance. Chez un particulier propriétaire de son logement, la surchauffe abîme un parquet et un ordinateur personnel ; les photos de famille qu’il contenait sont perdues. Le fabricant décide de rappeler 4 000 appareils.

Au regard de la directive, ce particulier, ou son assureur habitation qui l’a indemnisé, peut demander réparation du parquet, de l’ordinateur et des photos au fabricant du thermostat comme à l’éditeur, fabricant d’un composant défectueux ; les deux peuvent être tenus solidairement (articles 8 et 12). Le coût du rappel n’entre pas dans ce régime : il se règle entre l’éditeur et son client, selon leur contrat et le droit commun. Nous y revenons au fil de l’analyse.

Votre logiciel est-il un « produit » ?

L’article 4 définit le produit comme tout meuble et précise que le terme comprend les logiciels. Le considérant 13 ajoute que le logiciel est un produit « aux fins de l’application de la responsabilité sans faute », quel que soit son mode de fourniture, y compris lorsqu’il est fourni « dans le cadre d’un modèle de logiciel en tant que service ». Qu’il soit installé chez le client, embarqué dans un objet ou accessible en ligne, le logiciel a le même statut.

Intégré dans un autre produit, le logiciel en devient un composant (article 4, point 4). Son fabricant répond du dommage lorsque ce composant a été intégré sous le contrôle du fabricant du produit et a causé le défaut (article 8, paragraphe 1, point b). C’est la situation de notre éditeur.

La directive vise aussi le service connexe : un service numérique intégré à un produit ou interconnecté avec lui, au point que son absence empêcherait le produit de remplir une ou plusieurs de ses fonctions (article 4, point 3). Elle ne s’applique pas aux services en tant que tels (considérant 17) et ne désigne pas le fournisseur d’un service connexe parmi les responsables : c’est le fabricant du produit qui répond des composants, services connexes compris, intégrés sous son contrôle (article 8, paragraphe 1).

Le logiciel libre est exclu, mais seulement s’il est développé ou fourni « en dehors du cadre d’une activité commerciale » (article 2, paragraphe 2, et considérant 14). Le fabricant qui intègre une bibliothèque libre à un produit qu’il commercialise peut répondre de son défaut ; l’auteur de la bibliothèque, lui, n’est pas visé (considérant 15).

Qui peut vous demander réparation, et pour quels dommages ?

Le droit à réparation appartient à « toute personne physique » qui subit un dommage causé par un produit défectueux (article 5, paragraphe 1). Il peut être exercé par la personne qui lui a succédé ou qui est subrogée dans ses droits, comme son assureur, ou par une personne agissant pour son compte (article 5, paragraphe 2). Une entreprise ne peut pas l’invoquer pour ses propres pertes. L’article 6 limite ensuite les dommages réparables :

  • la mort ou les lésions corporelles, y compris l’atteinte médicalement reconnue à la santé psychologique ;
  • le dommage causé à des biens, sauf le produit défectueux lui-même, le produit endommagé par un composant défectueux intégré par son fabricant ou sous son contrôle, et les biens utilisés exclusivement à des fins professionnelles ;
  • la destruction ou la corruption de données qui ne sont pas utilisées à des fins professionnelles ; des données utilisées, même en partie, à des fins professionnelles sont exclues (considérant 22).

Dans notre cas, le thermostat n’est pas indemnisé : c’est le produit défectueux lui-même. Le parquet, l’ordinateur et les photos du particulier sont couverts, avec les pertes matérielles qui en découlent (article 6, paragraphe 2). Si le même logiciel tournait dans une usine, les machines et les historiques de production resteraient hors du régime ; les lésions d’un opérateur, elles, y entreraient.

Ce régime ne supprime pas les autres actions : la directive laisse intactes la responsabilité contractuelle et la responsabilité extracontractuelle fondée sur d’autres motifs que la défectuosité (article 2, paragraphe 4).

Les mises à jour vous engagent-elles ?

Elles comptent, sans être obligatoires : la directive « n’impose aucune obligation de fournir des mises à jour ou mises à niveau pour un produit » (considérant 51). Elle retient en revanche qu’il y a contrôle du fabricant lorsqu’il effectue lui-même, ou autorise ou permet chez un tiers, l’intégration d’un composant ou une modification du produit, mises à jour comprises, ou lorsqu’il a la capacité de fournir des mises à jour, lui-même ou par un tiers (article 4, point 5).

Un opérateur peut d’ordinaire s’exonérer en prouvant qu’il est probable que le défaut n’existait pas lors de la mise sur le marché, ou qu’il est apparu après (article 11, paragraphe 1, point c). Cette défense tombe lorsque le défaut vient d’un service connexe, d’un logiciel ou de ses mises à jour, de l’absence des mises à jour nécessaires au maintien de la sécurité, ou d’une modification substantielle, dès lors que l’élément relève du contrôle du fabricant (article 11, paragraphe 2). Dans notre cas, le fabricant du thermostat a autorisé l’éditeur à diffuser ses mises à jour : celle d’avril est sous son contrôle, et l’apparition tardive du défaut ne peut pas être invoquée.

À l’inverse, si l’utilisateur n’installe pas une mise à jour qui lui a été fournie, sa négligence peut réduire ou supprimer la responsabilité de l’opérateur (article 13, paragraphe 2, et considérants 51 et 55). L’exploitation d’une faille par un tiers, elle, ne la réduit pas (article 13, paragraphe 1).

Pour juger du défaut, le juge tient compte notamment des exigences de cybersécurité pertinentes pour la sécurité du produit, de sa capacité à poursuivre son apprentissage ou à acquérir de nouvelles caractéristiques, et de tout rappel du produit (article 7, paragraphe 2). Le rappel des 4 000 thermostats entrera donc dans l’appréciation. Le Cyber Resilience Act impose déjà aux fabricants de signaler leurs failles activement exploitées : voir notre analyse de son article 14.

Votre clause de limitation de responsabilité tient-elle encore ?

Pas envers la victime : la responsabilité prévue par la directive ne peut être ni limitée ni exclue par une clause contractuelle ou par le droit national (article 15). Le particulier de notre cas n’a d’ailleurs signé aucun contrat avec l’éditeur.

Lorsque plusieurs opérateurs répondent du même dommage, ils peuvent être tenus solidairement (article 12, paragraphe 1), et celui qui a indemnisé la victime peut se retourner contre les autres selon le droit national (article 14). Le contrat entre l’éditeur et le fabricant de thermostats règle ces recours et ce que la directive ne couvre pas, comme le coût du rappel ; il ne s’impose pas à la victime.

Deux règles jouent en faveur de l’éditeur. Le fabricant d’un composant est exonéré s’il prouve que la défectuosité est due à la conception du produit dans lequel le composant a été intégré, ou aux instructions données par le fabricant de ce produit (article 11, paragraphe 1, point f) : garder la trace des spécifications reçues devient utile. Et le fabricant du produit peut renoncer par contrat à son recours contre le fabricant d’un composant logiciel, si celui-ci était une micro ou petite entreprise lors de la mise sur le marché (article 12, paragraphe 2).

La victime aura-t-elle moins de mal à prouver le défaut ?

À la demande d’une victime qui a présenté des faits et éléments de preuve suffisants pour étayer la plausibilité de sa demande, le juge peut ordonner au défendeur de divulguer les éléments de preuve pertinents dont il dispose (article 9, paragraphe 1), dans la limite de ce qui est nécessaire et proportionné, secrets d’affaires protégés (article 9).

Le défaut est présumé dans trois cas : le défendeur ne divulgue pas ces éléments ; le produit ne respecte pas des exigences obligatoires en matière de sécurité des produits destinées à protéger contre le risque du dommage subi ; le dommage résulte d’un dysfonctionnement manifeste lors d’une utilisation raisonnablement prévisible ou dans des circonstances ordinaires (article 10, paragraphe 2). Une fois le défaut établi, le lien de causalité est présumé si le dommage est d’une nature généralement compatible avec ce défaut (article 10, paragraphe 3).

Enfin, le juge présume le défaut, le lien de causalité ou les deux lorsque la victime se heurte à des difficultés excessives, notamment du fait de la complexité technique ou scientifique, et qu’elle démontre qu’ils sont probables, même après la divulgation de preuves (article 10, paragraphe 4). Le défendeur peut renverser chacune de ces présomptions (article 10, paragraphe 5). Pour notre éditeur, l’historique des versions, des tests et des déploiements devient une pièce du dossier.

Quels produits, à partir de quand, et pour combien de temps ?

La directive vaut pour les produits mis sur le marché, c’est-à-dire mis à disposition pour la première fois, ou mis en service après le 9 décembre 2026 (articles 2 et 4). Pour les produits antérieurs, l’ancienne directive continue de s’appliquer (article 21), donc, en France, les articles 1245 et suivants du code civil. Ce régime ne mentionne pas le logiciel. Les thermostats de notre cas, vendus à partir de février 2027, relèvent du nouveau.

La victime dispose de trois ans à partir du moment où elle a eu connaissance, ou aurait dû raisonnablement avoir connaissance, du dommage, du défaut et de l’identité de l’opérateur responsable (article 16). Sauf procédure engagée entre-temps, son droit s’éteint dix ans après la mise sur le marché ou la mise en service ou, en cas de modification substantielle, après la remise à disposition du produit modifié ; ce délai passe à vingt-cinq ans lorsque la victime n’a pas pu agir à cause de la période de latence d’une lésion corporelle (article 17).

Où en est la France ?

La règle actuelle figure aux articles 1245 à 1245-17 du code civil, issus de la transposition de la directive de 1985. Interrogé par le député Sacha Houlié (question publiée au Journal officiel du 9 décembre 2025), le ministère de la Justice a répondu le 12 mai 2026 qu’un groupe de travail interministériel, piloté par la direction des affaires civiles et du sceau, prépare la transposition, que des consultations devaient être conduites au premier trimestre 2026 et qu’« un texte dédié est envisagé à ce stade ». La réponse ne donne aucune date.

Au 31 octobre 2026, nous n’avons trouvé aucun texte de transposition déposé au Parlement ni publié au Journal officiel. Si la France n’a pas transposé le 9 décembre, la directive ne s’imposera pas directement dans un litige entre personnes privées ; une fois le délai expiré, le juge devra toutefois interpréter le droit national, autant que possible, à la lumière de la directive (Cour de justice, Marleasing, 13 novembre 1990, C-106/89 ; Adeneler, 4 juillet 2006, C-212/04).

Mémoire

Comment on en est arrivé là

La directive 85/374/CEE du 25 juillet 1985 définissait le produit comme tout meuble, à l’exception des matières premières agricoles et des produits de la chasse, électricité comprise, sans un mot sur le logiciel. La France devait la transposer avant le 30 juillet 1988. Un projet de loi, déposé le 23 mai 1990, a été abandonné après la commission mixte paritaire du 15 décembre 1992, le Gouvernement n’ayant pas soumis son texte aux assemblées ; la Cour de justice a condamné la France pour manquement le 13 janvier 1993. La transposition n’est venue qu’avec la loi n° 98-389 du 19 mai 1998, issue d’une proposition de loi, près de dix ans après l’échéance.

En septembre 2022, la Commission a proposé de remplacer ce texte (proposition COM(2022) 495 du 28 septembre 2022). La directive adoptée, signée à Strasbourg le 23 octobre 2024, fait entrer le logiciel dans la définition du produit. Le délai de transposition est cette fois de deux ans.

À prévoir avant le 9 décembre 2026 :

  1. Lister les logiciels, modules et services que vous mettrez sur le marché ou en service après le 9 décembre 2026 et, pour chacun, les dommages possibles aux personnes : lésions, biens privés, données non professionnelles.
  2. Repérer les clients qui intègrent votre logiciel dans un produit utilisé par des particuliers ou au contact de personnes : c’est par eux que vous pouvez être mis en cause comme fabricant de composant. Conserver les spécifications et instructions qu’ils vous donnent.
  3. Documenter la diffusion de chaque correctif de sécurité (date, versions, canal). Si une mise à jour nécessaire à la sécurité manque alors qu’elle relevait de votre contrôle, vous ne pourrez pas soutenir que le défaut est apparu après la mise sur le marché ; si l’utilisateur ne l’a pas installée, votre responsabilité peut être réduite.
  4. Conserver et dater l’historique des versions, des tests et des déploiements : le juge peut en ordonner la divulgation.
  5. Revoir avec vos clients intégrateurs les clauses de recours et le partage des coûts que la directive ne couvre pas, comme les rappels.
  6. Demander à votre assureur, par écrit, si votre contrat de responsabilité civile couvre les dommages causés par un logiciel mis sur le marché après le 9 décembre 2026.

Notre lecture

Le 9 décembre 2026 ne rend pas inopérantes les clauses de limitation de responsabilité entre un éditeur et ses clients professionnels : les pertes propres de ces clients restent hors d’un régime qui ne bénéficie qu’aux personnes physiques et à ceux qui exercent leurs droits. La directive ne neutralise ces clauses qu’envers la victime.

L’exposition nouvelle concerne les logiciels qui peuvent blesser une personne, abîmer ses biens ou détruire ses données privées, seuls ou intégrés dans le produit d’un client : objets connectés, équipements industriels, santé, mobilité. La directive n’impose pas de mises à jour, mais elle prive le fabricant d’une défense lorsqu’une mise à jour nécessaire à la sécurité manque.

Ce que nous ne savons pas encore

  • La date et la forme du texte français de transposition ; la réponse ministérielle du 12 mai 2026 n’en donne pas.
  • Comment les juges appliqueront la date du 9 décembre 2026 à un SaaS mis en service avant cette date et mis à jour en continu, et à partir de quand une mise à jour devient une modification substantielle (article 4, point 18).
  • Si la transposition conservera une voie nationale pour les dommages aux biens professionnels : le régime issu de la loi de 1998 les couvre, la directive les exclut.
  • Si la France notifiera, avant le 9 décembre 2026, le maintien de l’exception qu’elle prévoit déjà au risque de développement pour les produits issus du corps humain (article 18, paragraphe 1). Aucune extension aux logiciels n’est annoncée.

Questions fréquentes

Un éditeur SaaS qui ne vend qu’à des entreprises est-il concerné ?

Son logiciel est un produit au sens de la directive. Seules des personnes physiques, ou ceux qui exercent leurs droits comme leur assureur, peuvent agir, pour des lésions, des biens privés ou des données non professionnelles. Les pertes propres de ses clients professionnels relèvent du contrat et du droit commun.

Les logiciels vendus avant le 9 décembre 2026 sont-ils concernés ?

En principe non, s’ils ont été mis sur le marché ou en service avant cette date : l’ancien régime s’applique (articles 2 et 21). Deux réserves : une modification substantielle ultérieure, et la question, non tranchée, du SaaS mis à jour en continu. L’ancien régime ne mentionne pas le logiciel.

Le logiciel libre que nous intégrons nous expose-t-il ?

L’exclusion ne vaut que pour le logiciel libre développé ou fourni en dehors d’une activité commerciale. Le fabricant qui intègre une bibliothèque libre à un produit commercialisé peut répondre de son défaut, son auteur non (considérants 14 et 15).

Peut-on s’exonérer en prouvant que le défaut n’était pas détectable ?

La directive maintient cette exonération, dite risque de développement, lorsque l’état objectif des connaissances scientifiques et techniques ne permettait pas de déceler le défaut (article 11, paragraphe 1, point e). L’article 18 permet aux États de conserver les exceptions existantes et, sous conditions, d’en créer pour des catégories précises de produits.

Ce qui a changé depuis la publication

31 octobre 2026 : publication.

Sources

  1. Directive (UE) 2024/2853 du 23 octobre 2024 relative à la responsabilité du fait des produits défectueux : articles 2, 4 à 18 et 21 à 23 ; considérants 13, 14, 15, 17, 22, 51 et 55.
  2. Directive 85/374/CEE du 25 juillet 1985 relative à la responsabilité du fait des produits défectueux : article 2.
  3. Loi n° 98-389 du 19 mai 1998 relative à la responsabilité du fait des produits défectueux ; rapport n° 226 (1997-1998) de Pierre Fauchon au Sénat, pour l’historique de la transposition.
  4. Assemblée nationale, question écrite n° 11448 de Sacha Houlié, publiée au Journal officiel du 9 décembre 2025 ; réponse du ministère de la Justice au Journal officiel du 12 mai 2026, page 4170.
  5. Proposition de directive COM(2022) 495 du 28 septembre 2022, fiche du Sénat.
  6. Cour de justice : Marleasing, 13 novembre 1990, C-106/89 ; Adeneler, 4 juillet 2006, C-212/04.

Sur le site : le calendrier des échéances numériques et notre analyse de l’article 14 du Cyber Resilience Act.

Dans la même rubrique