La directive du 23 octobre 2024 remplace le régime de 1985 et inscrit le logiciel dans la définition du produit. Applications, micrologiciels, systèmes d’exploitation et systèmes d’intelligence artificielle peuvent relever d’une responsabilité sans faute, que le logiciel soit installé, accessible en nuage ou fourni en mode software as a service.
La qualification n’est pourtant qu’un point de départ. Le régime suppose toujours une défectuosité, un dommage réparable et un lien de causalité — et il ne couvre ni tous les dommages, ni toutes les personnes.
La directive s’applique aux produits mis sur le marché ou mis en service après le 9 décembre 2026. La France ne l’a pas encore transposée : les articles 1245 à 1245-17 du code civil régissent toujours la matière. Le calendrier français reste à confirmer ; le calendrier européen, lui, est fixé.
01 — Situer Le logiciel est un produit — mais l’information ne l’est pas
La définition du produit comprend désormais expressément les logiciels, aux côtés de l’électricité, des matières premières et des fichiers de fabrication numériques. Le support est indifférent : un logiciel stocké sur un appareil, accessible par un réseau ou une technologie en nuage, ou fourni en mode software as a service, entre dans la définition.
Le développeur ou producteur de logiciel, y compris le fournisseur d’un système d’intelligence artificielle au sens du règlement du 13 juin 2024, est considéré comme un fabricant.
Les informations ne sont pas des produits : le contenu des fichiers numériques — fichiers médias, livres électroniques — et le simple code source des logiciels restent hors du régime.
Les logiciels libres et ouverts développés ou fournis en dehors du cadre d’une activité commerciale sont exclus par le texte lui-même. La condition est commerciale, non licencielle : intégrer un composant libre dans une offre commerciale ne fait pas jouer l’exclusion.
02 — Étendre Composants, services connexes et mises à jour
Un composant peut être immatériel : un logiciel embarqué, une application pilotant un objet connecté, un système d’IA intégré à un dispositif. Le fabricant d’un composant défectueux répond du dommage lorsque ce composant a été intégré ou interconnecté sous le contrôle du fabricant du produit et a causé le défaut.
La directive introduit également le service connexe : un service numérique intégré ou interconnecté au produit de telle sorte que son absence empêcherait celui-ci d’exécuter une ou plusieurs de ses fonctions.
La règle la plus structurante pour un éditeur
Un opérateur ne peut plus se prévaloir de ce que la défectuosité est apparue après la mise sur le marché lorsqu’elle est due, sous le contrôle du fabricant, à un service connexe, à un logiciel — mises à jour et mises à niveau comprises — ou à l’absence d’une mise à jour nécessaire au maintien de la sécurité.
La sécurité du produit ne s’apprécie donc plus au seul jour de sa commercialisation. La gouvernance des mises à jour devient une question de responsabilité, non de simple maintenance.
03 — Qualifier Quand un logiciel est-il défectueux ?
Un produit est défectueux lorsqu’il n’offre pas la sécurité à laquelle une personne peut légitimement s’attendre ou qui est requise par le droit de l’Union ou le droit national. Tout dysfonctionnement n’est donc pas une défectuosité.
- la présentation, la conception, les caractéristiques techniques et les instructions ;
- l’utilisation raisonnablement prévisible ;
- l’effet de toute capacité du produit à poursuivre son apprentissage ou à acquérir de nouvelles caractéristiques après sa mise sur le marché ;
- l’effet raisonnablement prévisible d’autres produits avec lesquels il est destiné à être utilisé ;
- le moment où le produit a quitté le contrôle du fabricant, lorsque celui-ci conserve ce contrôle après la mise sur le marché ;
- les exigences de sécurité applicables, y compris les exigences de cybersécurité pertinentes pour la sécurité.
Le texte l’énonce sans détour dans ses motifs : un produit peut être considéré comme défectueux en raison d’une vulnérabilité de cybersécurité, notamment s’il ne satisfait pas aux exigences de cybersécurité pertinentes pour la sécurité.
Un produit n’est pas défectueux au seul motif qu’un produit plus perfectionné, mises à jour comprises, a été mis sur le marché par la suite.
04 — Mesurer Quels dommages, et au bénéfice de qui
C’est la limite la moins commentée du régime, et la plus utile à connaître. Le droit à réparation bénéficie à toute personne physique qui subit un dommage causé par un produit défectueux. Une entreprise ne peut pas s’en prévaloir pour ses propres pertes.
- la mort et les lésions corporelles, y compris l’atteinte médicalement reconnue à la santé psychologique ;
- les dommages aux biens, à l’exclusion des biens utilisés exclusivement à des fins professionnelles ;
- la destruction ou la corruption de données qui ne sont pas utilisées à des fins professionnelles.
Pour un éditeur, la lecture est asymétrique : l’exposition en défense s’élargit, tandis que le régime reste fermé à ses propres préjudices professionnels, qui relèvent du contrat et du droit commun de la responsabilité — que la directive laisse expressément subsister.
05 — Identifier Qui répond, et contre qui se retourner
Répondent du dommage le fabricant du produit, le fabricant d’un composant défectueux et, lorsque le fabricant est établi hors de l’Union, l’importateur, le mandataire ou, à défaut, le prestataire de services d’exécution des commandes. Plusieurs opérateurs responsables du même dommage peuvent l’être solidairement.
Une clause contractuelle ne limite ni n’exclut la responsabilité à l’égard de la personne lésée. Elle ne règle que les rapports entre opérateurs.
Deux règles méritent une attention particulière dans les chaînes logicielles.
D’abord, l’acte ou l’omission d’un tiers ne réduit ni ne supprime la responsabilité de l’opérateur lorsque le dommage est causé à la fois par la défectuosité du produit et par ce tiers — l’hypothèse expressément visée étant celle d’un tiers exploitant une vulnérabilité de cybersécurité. La faute de la personne lésée, elle, peut réduire ou supprimer la responsabilité.
Ensuite, le fabricant qui intègre un composant logiciel n’a pas de recours contre le fabricant de ce composant lorsque celui-ci était, à la mise sur le marché du composant, une microentreprise ou une petite entreprise, dans les conditions prévues par le texte. L’intégrateur supporte alors la charge finale.
06 — Prouver Ce que la directive change à la charge de la preuve
Le demandeur reste tenu de prouver la défectuosité, le dommage et le lien de causalité. Le texte n’efface pas ces conditions ; il en aménage la démonstration.
Une juridiction peut ordonner au défendeur de divulguer les éléments de preuve pertinents dont il dispose. Le refus de divulguer emporte présomption de défectuosité.
- le défendeur ne divulgue pas les éléments de preuve pertinents ;
- le demandeur démontre que le produit n’est pas conforme à des exigences obligatoires de sécurité prévues par le droit de l’Union ou national, destinées à protéger contre le risque à l’origine du dommage ;
- le demandeur démontre que le dommage a été causé par un dysfonctionnement manifeste lors d’une utilisation raisonnablement prévisible ou dans des circonstances ordinaires.
Le lien de causalité peut lui aussi être présumé dans les cas prévus, et des mécanismes spécifiques jouent lorsque la complexité technique ou scientifique rend excessivement difficile la démonstration.
La conséquence pratique est nette : la documentation technique, la traçabilité des versions et la conservation des éléments de preuve deviennent des actifs de défense. Leur absence se retourne contre celui qui les détenait.
07 — Dater Le calendrier, et son articulation avec le Cyber Resilience Act
La directive s’applique aux produits mis sur le marché ou mis en service après le 9 décembre 2026, date à laquelle les États membres doivent avoir transposé. La date de mise sur le marché commande donc le régime applicable, ce qui rend la question du champ temporel délicate pour des produits évolutifs.
Le règlement sur la cyberrésilience, adopté le même jour, suit un calendrier propre.
- 11 juin 2026 : chapitre IV (articles 35 à 51), relatif notamment à la notification des organismes d’évaluation de la conformité ;
- 11 septembre 2026 : article 14, obligations de communication des fabricants — alerte précoce dans les 24 heures suivant la connaissance d’une vulnérabilité activement exploitée, notification dans les 72 heures, rapport final dans les 14 jours suivant la mise à disposition d’une mesure corrective ;
- 11 décembre 2027 : application du règlement pour le reste.
Présenter aujourd’hui l’ensemble des exigences substantielles du règlement comme applicables serait inexact. Les obligations de signalement, en revanche, entrent en jeu dès le 11 septembre 2026.
Les deux textes ne poursuivent pas la même fonction — prévenir le risque, réparer le dommage — mais ils communiquent : la non-conformité à une exigence obligatoire de sécurité destinée à protéger contre le risque réalisé fait présumer la défectuosité.
08 — Anticiper Où en est la France, et ce qui reste incertain
Interrogé sur les modalités de transposition, le ministère de la Justice a répondu, au Journal officiel du 12 mai 2026, que les articles 1245 à 1245-17 du code civil devront être modifiés, la directive étant d’harmonisation maximale. Les travaux ont été engagés dès la publication du texte, pilotés par la direction des affaires civiles et du sceau dans un groupe de travail interministériel, la France participant au groupe d’experts de la Commission.
Compte tenu de l’échéance, de l’harmonisation maximale et du caractère de régime de responsabilité sans faute autonome, le ministère indique qu’un texte dédié est envisagé à ce stade. La formule est prudente : ni le véhicule, ni la date de publication ne sont acquis.
Trois réserves méritent d’être posées avant de tirer des conclusions.
D’abord, la qualification du logiciel comme produit n’emporte aucune responsabilité par elle-même. Elle ouvre un régime dont les conditions restent à réunir, et dont l’exonération pour risque de développement — l’état objectif des connaissances scientifiques et techniques ne permettant pas de déceler la défectuosité — subsiste, sous réserve du contrôle conservé par le fabricant.
Ensuite, l’harmonisation maximale limite la marge du législateur français, mais l’articulation avec le droit commun de la responsabilité civile reste à écrire : la directive laisse subsister les régimes contractuel et extracontractuel nationaux.
Enfin, présenter le 9 décembre 2026 comme la date à laquelle le logiciel deviendrait un produit serait inexact. La directive le qualifie déjà ainsi ; cette date est celle de la transposition et du champ temporel d’application.
Quels produits et composants logiciels sont concernés, et qui en contrôle les mises à jour ? Quelles exigences obligatoires de sécurité, cybersécurité comprise, leur sont applicables — leur non-conformité faisant présumer la défectuosité ? Quelle documentation technique serait produite si une divulgation était ordonnée ? Et que prévoient les contrats avec les développeurs, intégrateurs et fournisseurs, sachant qu’une clause ne joue pas à l’égard de la personne lésée ?
Références
- Union européenne — directive (UE) 2024/2853 du 23 octobre 2024 relative à la responsabilité du fait des produits défectueux, abrogeant la directive 85/374/CEE : articles 2, 4, 5 à 14 et 22 ; considérants 13, 14, 32 et 55.
- Union européenne — règlement (UE) 2024/2847 du 23 octobre 2024 sur la cyberrésilience : articles 14 et 71.
- France — question écrite n° 11448 de M. Sacha Houlié, publiée au Journal officiel du 9 décembre 2025, réponse du ministère de la Justice publiée le 12 mai 2026.
- France — code civil, articles 1245 à 1245-17, régime issu de la directive 85/374/CEE, toujours applicable à la date de publication de cet article.
- Pour approfondir — Cybersécurité et cybercriminalité et Intelligence artificielle.
Un produit numérique à préparer à ce nouveau régime ?
Un échange permet d’examiner votre chaîne de conception et de distribution, d’identifier les règles applicables et de déterminer les démarches susceptibles d’être engagées.
Prendre rendez-vousÀ lire aussi