Le 9 décembre 2026, votre logiciel devient un « produit défectueux » (et votre clause de limitation de responsabilité ne vaudra plus rien)

Dans moins de trois mois, le droit cessera de considérer votre logiciel comme un service

Il y a une phrase que j'entends dans presque tous les contrats de développement que je relis : « la responsabilité du prestataire est limitée au montant des sommes versées au titre du présent contrat ».

Cette phrase a protégé l'industrie logicielle pendant trente ans. Le 9 décembre 2026, elle cesse d'opérer face à la personne qui subit le dommage.

La directive (UE) 2024/2853, adoptée le 23 octobre 2024, abroge et remplace la directive de 1985 sur la responsabilité du fait des produits défectueux — ce texte qui, depuis quarante ans, permet à une victime d'obtenir réparation d'un fabricant sans avoir à démontrer la moindre faute de sa part. Jusqu'ici, il visait des objets : un grille-pain qui prend feu, un airbag qui ne se déclenche pas, un médicament mal dosé.

Son article 4 range désormais le logiciel parmi les produits. Au même titre que l'électricité, les matières premières et les fichiers de fabrication numérique. Les systèmes d'intelligence artificielle sont expressément inclus, et la modalité de fourniture est indifférente : installé sur un appareil, embarqué dans une machine, exécuté dans le cloud ou vendu en SaaS, c'est un produit.

Les États membres ont jusqu'au 9 décembre 2026 pour transposer. Le texte s'appliquera aux produits mis sur le marché ou mis en service à partir de cette date. Source : synthèse officielle EUR-Lex.

Ce que « responsabilité sans faute » veut vraiment dire

C'est le point que la plupart des dirigeants sous-estiment, parce qu'ils raisonnent avec le réflexe contractuel : *« s'il y a un problème, on regardera qui n'a pas fait son travail »*.

La responsabilité du fait des produits défectueux ne fonctionne pas comme ça. Elle est objective. La victime n'a pas à prouver que vous avez été négligent, que vos tests étaient insuffisants ou que votre développeur a bâclé une revue de code. Elle doit établir trois choses, et trois seulement : le défaut, le dommage, et le lien de causalité entre les deux.

Un produit est défectueux, au sens de l'article 7, lorsqu'il « n'offre pas la sécurité à laquelle une personne peut légitimement s'attendre ». Pour apprécier cette attente, le juge tiendra compte de critères taillés pour le numérique : la capacité du produit à continuer d'apprendre ou à acquérir de nouvelles fonctionnalités après sa mise sur le marché, l'effet des mises à jour, et — c'est nouveau — les exigences applicables en matière de cybersécurité.

Autrement dit : une vulnérabilité non corrigée peut caractériser un défaut. C'est exactement le pont entre ce texte et le Cyber Resilience Act, dont la première échéance vient de tomber. Le CRA vous dit comment sécuriser et signaler en amont ; la directive 2024/2853 organise la réparation en aval quand vous ne l'avez pas fait.

La directive ajoute deux mécanismes qui changent la donne procédurale, et qu'il faut avoir en tête :

• •La divulgation des éléments de preuve (article 9). Une victime qui présente des éléments rendant sa demande plausible peut obtenir du juge qu'il vous ordonne de produire les preuves pertinentes que vous détenez. Concrètement : votre documentation technique, vos journaux, vos rapports de tests, votre historique de correctifs. Le code cesse d'être une boîte noire que l'éditeur seul peut ouvrir.
• •Les présomptions (article 10). Le défaut est présumé notamment en cas de dysfonctionnement manifeste du produit, ou lorsque la victime se heurte à des difficultés excessives — typiquement une complexité technique — et rend probable l'existence du défaut. La charge de la preuve bascule alors vers vous.

Ce couple divulgation-présomption est, à mon sens, le vrai changement. Ce qui protégeait l'éditeur, ce n'était pas tant le droit que l'asymétrie d'information. Elle est en train d'être supprimée.

Êtes-vous concerné ? (la nuance que la plupart des articles oublient)

Ici, je vais être plus prudent que ce que vous lirez ailleurs, parce que le périmètre a des bornes nettes et qu'annoncer aux dirigeants que « tout le monde est exposé » serait faux.

Cette directive protège les personnes physiques. Elle n'est pas conçue pour régler les litiges entre entreprises. Et son article 6, qui liste les dommages réparables, exclut expressément deux catégories :

• •les dommages aux biens utilisés exclusivement à des fins professionnelles ;
• •la destruction ou la corruption de données utilisées à des fins professionnelles, même de façon non exclusive.

Ce que la directive répare, c'est le décès, les lésions corporelles — y compris une atteinte à la santé psychologique médicalement reconnue, ce qui est nouveau —, les dommages aux biens privés, et la destruction ou l'altération de données non professionnelles. Elle ne répare pas le manque à gagner d'une entreprise dont le logiciel métier est tombé. Ce préjudice-là reste sur le terrain contractuel classique.

Trois cas piègent particulièrement les PME, et méritent qu'on s'y arrête.

Premier cas : le logiciel sur mesure. L'idée que le développement spécifique échappe mécaniquement au texte parce qu'il n'est pas « mis sur le marché » est une lecture confortable, mais elle n'est pas acquise. L'analyse dépend de la façon dont le logiciel est fourni, de sa mise en service, et de son interaction avec un produit. Un logiciel développé pour un seul client mais qui pilote une machine, équipe une flotte ou est ensuite diffusé à des utilisateurs finaux ne se range pas si facilement hors du champ. Ne pariez pas votre couverture assurantielle sur cette exclusion sans un avis juridique sur votre cas précis.

Deuxième cas : le fabricant de composant. Si vous éditez une brique logicielle — un module de calcul, un SDK, une API embarquée, un firmware — et qu'elle est intégrée dans le produit d'un tiers, vous pouvez être recherché directement comme fabricant de ce composant. Beaucoup de petits éditeurs français sont dans cette position sans y avoir jamais pensé.

Troisième cas : la modification substantielle. Reprendre un produit existant et le modifier au point d'en changer les fonctions, d'en affecter la sécurité ou d'en augmenter le risque, hors du contrôle du fabricant d'origine, fait de vous le responsable de la partie modifiée. C'est le scénario typique de la reprise d'un existant développé par quelqu'un d'autre — une situation que je rencontre très souvent.

Ce que vous risquez concrètement

Le régime est plus sévère que celui de 1985 sur quatre points précis.

• •Le seuil de 500 € disparaît. L'ancienne directive n'indemnisait les dommages matériels qu'au-delà d'une franchise de 500 €. Elle n'existe plus : tout dommage matériel réparable est indemnisable dès le premier euro.
• •Il n'y a pas de plafond d'indemnisation. Contrairement au Cyber Resilience Act ou à NIS2, qui prévoient des amendes barémées, il ne s'agit pas ici d'une sanction administrative mais d'une réparation intégrale du préjudice. Le montant, c'est le dommage.
• •L'exposition dure dix ans — vingt-cinq dans un cas. Les droits s'éteignent dix ans après la mise sur le marché du produit (article 17), délai porté à vingt-cinq ans lorsque la victime n'a pas pu agir plus tôt en raison d'un dommage corporel d'apparition lente. S'y ajoute une prescription de trois ans à compter du jour où la victime a connu le dommage, le défaut et la personne responsable (article 16). Dix ans, en logiciel, c'est trois refontes et deux équipes plus tard.
• •Vos clauses de limitation deviennent inopposables. L'article 15 est sans ambiguïté : la responsabilité d'un opérateur économique au titre de la directive ne peut être ni limitée ni exclue par une disposition contractuelle à l'égard de la personne lésée. Vos CGV, vos plafonds de responsabilité, vos exclusions de garantie : ils continuent de régir votre relation avec votre client, mais ils ne sont opposables ni à l'utilisateur blessé, ni à son assureur subrogé.

Une exonération reste ouverte, et il faut la connaître : le risque de développement (article 11). Vous pouvez vous exonérer si 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. Mais ne comptez pas dessus pour un bug ordinaire : cette défense a été pensée pour l'innovation de rupture, pas pour une injection SQL ou une dépendance non mise à jour.

Et surtout, notez ce que l'article 11 vous retire : vous ne pouvez plus vous exonérer en invoquant que le défaut n'existait pas à la mise sur le marché lorsqu'il résulte d'un service connexe, d'un logiciel ou d'une mise à jour restés sous votre contrôle. Si vous gardez la main sur les mises à jour — ce que le Cyber Resilience Act vous impose par ailleurs de faire pendant cinq ans — vous gardez la responsabilité qui va avec.

L'angle que personne ne vous vend : la qualité devient une pièce à conviction

Tout ce qui précède se lit comme une contrainte. Je crois que c'est une lecture courte.

Depuis dix ans, j'essaie d'expliquer à des dirigeants pourquoi il faut payer pour des tests automatisés, une revue de code, un suivi des dépendances, une traçabilité des versions. C'est l'argument le plus difficile à faire passer, parce que ces investissements n'ont aucune contrepartie visible : ils produisent des incidents qui n'arrivent pas.

L'article 9 change ce calcul. Le jour où un juge vous ordonne de produire vos éléments de preuve, votre ingénierie devient un dossier de défense. Une suite de tests avec son historique, un inventaire de vos composants — le fameux SBOM déjà exigé par le CRA —, un journal des correctifs de sécurité avec leurs dates, une documentation des choix de conception : ce sont désormais des pièces qui démontrent que votre produit offrait la sécurité à laquelle on pouvait légitimement s'attendre. À l'inverse, une équipe incapable de dire quelle version tournait chez le client au moment des faits est, procéduralement, dans une position très inconfortable.

C'est aussi ce qui rend la dette technique brutalement chiffrable. Un produit assemblé à la hâte, avec des dépendances que personne ne suit — le risque exact que j'avais décrit à propos du vibe coding et de la supply chain npm — n'est plus seulement une source de bugs. C'est une exposition juridique sur dix ans que vous ne pouvez plus refermer par une clause.

Enfin, il y a un effet de marché qu'il serait dommage de rater. À partir du 9 décembre, les acheteurs sérieux — donneurs d'ordre, assureurs, fonds — vont commencer à poser ces questions en due diligence. Être l'éditeur capable de répondre du premier coup, c'est un argument commercial pendant les dix-huit mois où vos concurrents découvriront le sujet.

Les quatre idées fausses qui vont coûter cher

1. « On est une société de services, pas un fabricant »

La distinction service / produit sur laquelle repose cette croyance est précisément celle que la directive supprime. L'article 4 qualifie le logiciel de produit indépendamment de sa modalité de fourniture. Et l'article 8 étend la qualité de responsable au fabricant de composant, à celui qui modifie substantiellement un produit, à l'importateur et au mandataire. La question n'est plus « suis-je un éditeur ou un prestataire ? » mais « mon code est-il fourni, mis en service, ou intégré quelque part ? ».

2. « Notre contrat plafonne notre responsabilité »

Il plafonne votre responsabilité contractuelle, envers votre cocontractant. La victime d'un dommage corporel n'a pas signé votre contrat : elle agit sur un fondement extracontractuel, et l'article 15 interdit qu'une clause lui soit opposée. Cela vaut aussi pour l'assureur qui, ayant indemnisé la victime, se retourne contre vous. Relire ses CGV est utile ; croire qu'elles constituent une protection ici ne l'est pas.

3. « La France n'a pas encore transposé, on a le temps »

C'est factuellement exact et stratégiquement faux. À ce jour, la loi française de transposition n'est pas publiée, et le débat porte notamment sur la question de savoir si elle sera intégrée à la réforme d'ensemble de la responsabilité civile, engagée depuis 2017 et jamais menée à terme. Le Conseil de l'Ordre du barreau de Paris a d'ailleurs adopté le 24 février 2026 une résolution sur le contenu du futur texte, notamment sur la réparation du préjudice psychologique et des données non professionnelles. Source : résolution du Barreau de Paris. Mais l'échéance, elle, est fixée : la directive est publiée au Journal officiel de l'Union européenne, son application vise les produits mis sur le marché à partir du 9 décembre 2026, et un retard de transposition n'a jamais protégé personne — il crée surtout de l'insécurité juridique pour celui qui n'a rien préparé.

4. « On fera un avenant avec notre prestataire »

Bonne idée, mais elle ne fait pas ce que vous croyez. Un avenant ne peut pas vous soustraire au régime : il organise seulement la répartition du risque entre vous et votre prestataire, par des garanties, des engagements de qualité et des recours. C'est utile, c'est même indispensable — mais c'est un mécanisme de recours interne, pas un bouclier envers la victime. Et il n'a de valeur que si votre prestataire est solvable et assuré dans dix ans.

Votre plan en 4 étapes d'ici au 9 décembre

Étape 1 — Inventoriez ce que vous mettez réellement sur le marché (semaine 1)

Listez tout ce que votre entreprise fournit sous forme de code : produits vendus, applications mobiles, SDK et API exposés, modules intégrés chez des clients, firmwares, systèmes d'IA. Pour chacun, notez trois informations : qui en est l'utilisateur final, quel dommage physique ou matériel une défaillance pourrait causer à une personne, et quelles données non professionnelles il manipule. Cette grille suffit à séparer ce qui relève du nouveau régime de ce qui n'en relève pas — et la plupart des dirigeants découvrent à cette étape deux ou trois composants qu'ils avaient oubliés.

Étape 2 — Faites qualifier votre rôle juridique (semaines 2-3)

Fabricant, fabricant de composant, importateur, mandataire, auteur d'une modification substantielle : ces qualifications emportent des obligations différentes et se cumulent. Faites trancher votre position par un avocat sur les deux ou trois produits que l'étape 1 aura identifiés comme sensibles, en particulier si vous développez sur mesure, si vous revendez sous votre marque ou si vous avez repris l'existant d'un tiers. C'est un travail court et bien délimité, pas un audit général.

Étape 3 — Constituez votre dossier de preuve (semaines 3-6)

Partez du principe qu'un juge pourra vous demander de tout produire. Mettez en place l'essentiel : un SBOM à jour pour chaque version livrée, un journal daté des correctifs de sécurité, une traçabilité des versions déployées chez chaque client, un registre des décisions de conception liées à la sécurité, et la conservation de ces éléments sur dix ans. Si vous avez déjà engagé le chantier du Cyber Resilience Act ou de la cybersécurité de votre PME, l'essentiel du matériel existe déjà : il s'agit de le rendre présentable et de le conserver.

Étape 4 — Revoyez vos contrats et appelez votre assureur (semaines 6-8)

Deux chantiers parallèles. Côté contrats : ajoutez à vos conventions de développement et à vos conditions fournisseurs des garanties explicites, des engagements de maintien des correctifs et des clauses de recours — en sachant qu'elles jouent entre professionnels, pas envers les victimes. Côté assurance : vérifiez que votre police de responsabilité civile professionnelle couvre bien la responsabilité du fait des produits pour un logiciel, sur une durée compatible avec une exposition de dix ans. Beaucoup de contrats actuels ont été rédigés à une époque où « produit » voulait dire « objet », et cette conversation avec votre courtier vaut la peine d'être eue avant décembre, pas après un sinistre.

Conclusion : ce n'est pas une conformité, c'est une exposition

Le Cyber Resilience Act, NIS2 ou l'AI Act partagent une même mécanique : une autorité, des obligations, un barème d'amendes. Vous pouvez les traiter comme des cases à cocher, et beaucoup le font.

La directive 2024/2853 ne fonctionne pas ainsi. Il n'y a pas d'autorité à qui se déclarer, pas de certificat à obtenir, pas d'amende à provisionner. Il y a une personne, un jour, qui aura subi un dommage — et un juge qui vous demandera de prouver que votre produit offrait la sécurité à laquelle elle pouvait légitimement s'attendre. Il n'y a rien à cocher : il n'y a que la qualité réelle de ce que vous avez construit, et votre capacité à en faire la démonstration dix ans plus tard.

C'est, je trouve, la réglementation la plus honnête de toute la vague en cours. Elle ne récompense pas le formalisme. Elle récompense le travail bien fait et documenté.

Vous vendez un logiciel, une application ou un produit connecté, et vous vous demandez si ce régime vous vise et ce qu'il faut préparer d'ici décembre ? Parlons-en : en 30 minutes, on fait le tour de ce que vous mettez sur le marché, de votre rôle exact au sens de la directive, et des deux ou trois chantiers à lancer en priorité.

Questions fréquentes

Mon logiciel est-il concerné par la directive (UE) 2024/2853 ?

L'article 4 de la directive qualifie le logiciel de « produit », y compris les systèmes d'intelligence artificielle, et cela quelle que soit sa modalité de fourniture : installé, embarqué, exécuté dans le cloud ou fourni en SaaS. La vraie question n'est donc pas de savoir si votre logiciel est un produit, mais quel dommage sa défaillance peut causer. Le régime ne joue que pour les préjudices subis par des personnes physiques : décès, lésions corporelles y compris psychologiques médicalement reconnues, dommages aux biens privés, destruction ou corruption de données non professionnelles. Un logiciel strictement B2B dont la panne ne provoque qu'une perte économique pour une entreprise reste en dehors, sur le terrain contractuel classique. Seule exclusion explicite du texte : les logiciels libres et open source développés ou fournis en dehors d'une activité commerciale.

Mes conditions générales peuvent-elles limiter cette responsabilité ?

Non, pas à l'égard de la victime. L'article 15 dispose que la responsabilité d'un opérateur économique au titre de la directive ne peut être ni limitée ni exclue par une disposition contractuelle à l'égard de la personne lésée. Vos plafonds de responsabilité, exclusions de garantie et clauses limitatives continuent de régir votre relation avec votre client professionnel, mais ils sont inopposables à l'utilisateur qui subit le dommage — et à son assureur qui, après l'avoir indemnisé, se retourne contre vous. C'est le changement le plus sous-estimé du texte : la protection contractuelle sur laquelle repose une grande partie de l'industrie logicielle cesse de fonctionner dans ce cas de figure.

Pendant combien de temps suis-je exposé après la livraison ?

Dix ans à compter de la mise sur le marché ou de la mise en service du produit, en vertu de l'article 17. Ce délai est porté à vingt-cinq ans lorsque la victime n'a pas pu engager d'action dans les dix ans en raison d'un dommage corporel d'apparition lente. À cela s'ajoute, à l'article 16, une prescription de trois ans courant du jour où la victime a eu connaissance du dommage, du défaut et de l'identité de la personne responsable. En pratique, cela signifie que vous devez être capable, dix ans après, de dire quelle version tournait chez quel client, avec quelles dépendances et quels correctifs appliqués — d'où l'importance de conserver un SBOM et un journal de correctifs versionnés.

C'est mon prestataire qui a développé le logiciel : est-il le responsable ?

Pas nécessairement, et probablement pas seul. L'article 8 désigne comme responsables le fabricant, mais aussi le fabricant d'un composant intégré sous le contrôle du fabricant du produit, l'importateur, le mandataire et le prestataire de services d'exécution. Si le produit porte votre nom ou votre marque, vous êtes en première ligne. Un avenant avec votre prestataire ne vous sort pas du régime : il organise la répartition du risque entre professionnels, par des garanties et des recours, ce qui reste utile — mais uniquement si votre prestataire est solvable et correctement assuré au moment où le sinistre survient, c'est-à-dire potentiellement dans dix ans.

Une faille de sécurité non corrigée peut-elle constituer un défaut ?

Oui, c'est l'un des apports les plus directs du texte. L'article 7, qui liste les critères d'appréciation de la défectuosité, mentionne expressément les exigences applicables en matière de cybersécurité, ainsi que l'effet des mises à jour et la capacité du produit à évoluer après sa mise sur le marché. L'article 11 verrouille la logique : vous ne pouvez pas vous exonérer en soutenant que le défaut n'existait pas lors de la mise sur le marché lorsqu'il résulte d'un service connexe, d'un logiciel ou d'une mise à jour restés sous votre contrôle. Autrement dit, l'obligation de maintenance de sécurité que vous impose déjà le Cyber Resilience Act devient, par ce texte, le support d'une responsabilité civile envers les victimes.

La France a-t-elle transposé la directive ?

Pas à ce jour. Les États membres ont jusqu'au 9 décembre 2026 pour transposer, et la loi française n'est pas encore publiée ; l'une des questions débattues est de savoir si cette transposition sera autonome ou intégrée à la réforme d'ensemble de la responsabilité civile engagée depuis 2017. Le régime actuel, issu de la directive de 1985, figure aux articles 1245 à 1245-17 du Code civil et continuera de s'appliquer aux produits mis sur le marché avant le 9 décembre 2026. Cette incertitude sur le véhicule législatif ne change rien à votre calendrier : la date d'application vise les produits mis sur le marché ou mis en service à partir du 9 décembre 2026, et les chantiers utiles — inventaire, traçabilité, contrats, assurance — ne dépendent pas du texte français.