À partir du 9 décembre 2026, le régime européen de responsabilité du fait des produits défectueux couvrira explicitement les logiciels mis sur le marché ou mis en service dans son champ. Pour un éditeur, la difficulté ne consiste pas seulement à démontrer qu’un correctif a été publié. Elle consiste à retrouver la version effectivement fournie, la sécurité attendue à cette date, les usages raisonnablement prévisibles, les décisions prises et les éléments susceptibles d’expliquer un dommage.
La nouvelle directive organise aussi la divulgation d’éléments de preuve. Le défaut de divulguer les éléments pertinents conformément à cette procédure est l’un des cas dans lesquels l’article 10 prévoit une présomption de défectuosité. À l’inverse, accumuler tous les journaux, contenus clients et données personnelles « au cas où » ne garantit ni leur pertinence ni leur licéité.
Conclusion courte : un dossier probatoire utile relie une version déterminée à ses exigences de sécurité, à ses tests, à ses avertissements, à ses mises à jour et aux décisions prises. Il ne constitue ni une auto-exonération, ni une autorisation de surveiller les utilisateurs.
Le 9 décembre 2026 sépare deux régimes
La directive (UE) 2024/2853 consolidée s’applique aux produits mis sur le marché ou mis en service après le 8 décembre 2026. Cette formulation résulte du rectificatif publié le 7 mai 2026, qui a remplacé la date du 9 décembre dans l’article 2, paragraphe 1. En pratique, le nouveau champ commence donc le 9 décembre 2026.
La distinction est importante. L’article 21 maintient l’ancienne directive pour les produits mis sur le marché ou mis en service avant cette date. Une organisation qui exploite plusieurs générations d’un même logiciel devra pouvoir distinguer leur première mise à disposition, leur mise en service lorsqu’elle est pertinente et les modifications substantielles ultérieures. Un numéro commercial unique ne suffit pas toujours à identifier le régime applicable.
Les États membres doivent transposer la directive au plus tard le 9 décembre 2026. En France, les articles 1245 à 1245-17 du Code civil constituent encore le cadre national publié. Dans une réponse parue le 12 mai 2026, le ministère de la Justice indique que ces dispositions devront être modifiées, que les travaux de transposition sont engagés et qu’un texte dédié est envisagé à ce stade.
Cette réponse gouvernementale établit une direction, pas le contenu définitif de la loi française. Les modalités procédurales de divulgation, l’articulation avec le droit judiciaire national et les éventuelles options laissées à la France doivent rester identifiées comme des inconnues jusqu’à la publication des textes.
Le logiciel entre dans le produit, pas chaque incident dans la responsabilité
L’article 4 inclut les logiciels dans la définition du produit. Le considérant 13 précise que le mode de fourniture ne change pas à lui seul cette qualification : logiciel installé, accessible par un réseau ou dans le cloud, y compris selon un modèle SaaS. Les systèmes d’exploitation, micrologiciels, applications et systèmes d’intelligence artificielle sont cités comme exemples.
Deux limites évitent une lecture trop large :
- le logiciel libre et ouvert développé ou fourni hors d’une activité commerciale est exclu par l’article 2, paragraphe 2 ;
- le considérant 13 distingue le logiciel du simple contenu d’un fichier numérique et du simple code source considéré comme information.
L’exclusion liée au logiciel libre ne doit donc pas être déduite de la seule licence. L’article 2 vise les conditions de développement ou de fourniture et leur inscription dans une activité commerciale.
La directive ne transforme pas non plus chaque bug, indisponibilité ou perte financière en dommage indemnisable selon ce régime. Son article 6 couvre la mort ou les lésions corporelles, certaines atteintes aux biens et la destruction ou la corruption de données qui ne sont pas utilisées à des fins professionnelles. Les biens utilisés exclusivement à des fins professionnelles sont exclus de cette catégorie de dommage. D’autres fondements contractuels, extracontractuels, sectoriels ou liés aux données personnelles peuvent rester applicables séparément.
Pour qualifier un dossier, il faut donc poser au moins quatre questions distinctes :
| Question | Élément à établir | Conclusion à ne pas tirer trop vite |
|---|---|---|
| Produit | Logiciel, composant, service connexe et activité de fourniture | Tout fichier numérique n’est pas un produit |
| Opérateur | Fabricant, fabricant d’un composant, importateur ou autre acteur visé | L’hébergeur ou le sous-traitant n’est pas automatiquement le fabricant |
| Défectuosité | Sécurité légitimement attendue ou exigée par le droit | Un bug fonctionnel ne prouve pas seul un défaut de sécurité |
| Dommage | Catégorie visée par l’article 6 et lien avec la défectuosité | Une perte économique ou une interruption ne suffit pas toujours |
La sécurité attendue se lit dans une chronologie
L’article 7 ne définit pas la défectuosité par la seule non-conformité à une spécification. 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.
L’évaluation doit tenir compte de toutes les circonstances. Le texte cite notamment :
- la présentation, l’étiquetage, la conception, les caractéristiques techniques et les instructions ;
- l’utilisation raisonnablement prévisible ;
- la capacité du produit à poursuivre son apprentissage ou à acquérir de nouvelles caractéristiques ;
- les effets raisonnablement prévisibles d’autres produits interconnectés ;
- le moment de la mise sur le marché ou de la mise en service et, lorsque le fabricant conserve le contrôle, le moment où ce contrôle prend fin ;
- les exigences pertinentes de sécurité, y compris de cybersécurité ;
- les rappels ou autres interventions de sécurité ;
- les besoins spécifiques du groupe d’utilisateurs ciblé ;
- l’échec d’un produit dont la finalité est précisément de prévenir un dommage.
Le considérant 31 apporte une limite majeure à la stratégie documentaire : une longue liste d’avertissements ne suffit pas à rendre sûr un produit défectueux. Les instructions restent pertinentes dans l’évaluation, mais elles ne permettent pas de transférer artificiellement tous les risques à l’utilisateur.
La charge de la preuve demeure, les présomptions modifient le risque
L’article 10 conserve le principe central : le demandeur doit prouver la défectuosité, le dommage et le lien de causalité. La nouvelle directive ne crée donc pas une responsabilité automatique dès qu’un logiciel dysfonctionne.
Elle prévoit cependant plusieurs présomptions réfragables :
| Situation établie dans la procédure | Effet prévu par l’article 10 | Limite |
|---|---|---|
| Le défendeur ne divulgue pas les preuves pertinentes ordonnées selon l’article 9 | La défectuosité est présumée | Le défendeur peut renverser la présomption |
| Le produit enfreint une exigence obligatoire de sécurité destinée à protéger contre le risque réalisé | La défectuosité est présumée | L’exigence et le risque doivent correspondre |
| Un dommage résulte d’un dysfonctionnement manifeste lors d’un usage raisonnablement prévisible ou dans des circonstances ordinaires | La défectuosité est présumée | Le dommage et les circonstances doivent être démontrés |
| Le produit est établi comme défectueux et le dommage est d’une nature généralement compatible avec ce défaut | Le lien de causalité est présumé | La défectuosité doit d’abord être établie |
| La complexité technique ou scientifique rend la preuve excessivement difficile et le demandeur montre une probabilité suffisante | Défectuosité, causalité ou les deux peuvent être présumées | Le juge apprécie toutes les circonstances |
L’absence d’un dossier interne n’entraîne pas, à elle seule et hors de ces conditions, une condamnation. Le risque opérationnel apparaît lorsqu’une preuve pertinente existe mais ne peut pas être localisée, expliquée ou produite, ou lorsque son absence empêche de répondre à une affirmation techniquement complexe.
Cette nuance doit rester visible dans les politiques internes. Écrire « conserver pour éviter une présomption de responsabilité » serait trop général. La formulation défendable est plus étroite : conserver de manière proportionnée les éléments qui permettent d’expliquer les décisions de sécurité et de répondre à une demande de preuve pertinente.
La divulgation n’ouvre pas un accès illimité au système d’information
L’article 9 encadre la divulgation dans une procédure devant une juridiction nationale. Le demandeur doit d’abord présenter suffisamment de faits et de preuves pour rendre sa demande plausible. Le défendeur peut lui aussi obtenir des preuves du demandeur lorsqu’il démontre en avoir besoin pour s’opposer à la demande.
La divulgation doit être nécessaire et proportionnée. Le juge doit tenir compte des intérêts légitimes des parties et des tiers, notamment de la protection des informations confidentielles et des secrets d’affaires. Lorsqu’un secret d’affaires doit être produit, la juridiction doit pouvoir prendre des mesures spécifiques pour en préserver la confidentialité.
Enfin, une juridiction peut demander une présentation facilement accessible et compréhensible lorsque le coût et l’effort restent proportionnés. Un export de plusieurs téraoctets sans dictionnaire, horodatage fiable ni lien avec la version concernée peut donc être techniquement massif et probatoirement faible.
La préparation doit séparer trois fonctions :
- Localiser les sources et leurs responsables sans copier tout leur contenu.
- Préserver un périmètre ciblé lorsqu’un incident ou un litige le justifie.
- Présenter un extrait compréhensible, avec sa provenance, son intégrité et ses limites.
Cette séparation protège aussi les secrets d’affaires. Un dossier probatoire n’a pas à rendre le code source ou les architectures sensibles accessibles à toute l’organisation. Il doit documenter où ils se trouvent, qui peut autoriser leur extraction et comment construire, si nécessaire, une annexe confidentielle distincte.
Le dossier de version répond à des affirmations précises
Le tableau suivant constitue une proposition opérationnelle BLACKPROOF, pas une liste d’obligations créée par la directive. Chaque bloc part d’une affirmation susceptible d’être discutée et conserve la preuve minimale qui permet de la tester.
| Affirmation à pouvoir examiner | Noyau probatoire | Données à éviter par défaut |
|---|---|---|
| « Cette version était celle fournie » | Identifiant de version, empreinte de l’artefact, manifeste de composants, date, canal et périmètre de mise à disposition | Copie intégrale des environnements clients |
| « Cette fonction avait cette destination » | Documentation publiée, exigences, configuration par défaut, profils d’utilisateurs et limites annoncées | Historique nominatif complet des consultations |
| « Cet usage était raisonnablement prévisible » | Cas d’usage, mésusages analysés, tickets agrégés, retours de support pertinents et décisions associées | Conversations clients sans rapport avec le risque |
| « La sécurité a été évaluée » | Modèle de menace daté, exigences applicables, plan de tests, résultats, écarts acceptés et responsable de l’acceptation | Captures de données réelles lorsque des données synthétiques suffisent |
| « Le fabricant contrôlait ou ne contrôlait plus cette évolution » | Architecture des mises à jour, responsabilités, contrats techniques, dates de fin de support et capacité réelle de déploiement | Formules contractuelles non reliées au fonctionnement réel |
| « Ce correctif répondait à ce risque » | Avis de vulnérabilité, analyse, changement, tests de non-régression, versions ciblées et preuve de disponibilité | Télémétrie générale sans lien avec le correctif |
| « L’utilisateur disposait de cette information » | Version du message, canal, date, population visée et état de publication | Suivi individuel permanent de la lecture |
| « Cet événement présente ces caractéristiques » | Sources originales, chronologie, configuration pertinente, faits établis, hypothèses et inconnues | Aspiration de tous les journaux avant qualification |
Une empreinte cryptographique aide à contrôler l’intégrité d’un artefact, mais elle ne prouve pas seule qui l’a produit, pourquoi il a été accepté ni s’il était sûr. Notre analyse sur les preuves numériques vérifiables à dix ans distingue ces propriétés et les dépendances nécessaires à une vérification différée.
Le manifeste de composants ne remplace pas non plus l’analyse de risque. Il indique ce qui était intégré, pas si une vulnérabilité était exploitable dans la configuration livrée ni si le dommage allégué en découle. La méthode utilisée pour les signalements du Cyber Resilience Act permet de séparer présence d’un composant, exploitation, gravité et décision de correction.
Conserver un noyau stable, déclencher un gel ciblé
Le dossier permanent doit rester compact. Il décrit le produit et ses décisions de sécurité sans reproduire toutes les données d’exploitation. Les éléments volatils ou sensibles sont référencés avec leur système source, leur propriétaire, leur durée normale et leur procédure d’extraction.
Lorsqu’un événement plausible apparaît, un gel ciblé peut préserver le périmètre pertinent avant l’expiration ou la rotation normale des sources. Ce gel doit être autorisé, journalisé, limité à une affaire et réexaminé. Il ne transforme pas une hypothèse initiale en fait établi.
Les mises à jour prolongent la chronologie sous contrôle
La directive définit le contrôle du fabricant par sa capacité à intégrer, autoriser ou fournir des composants, y compris des mises à jour, ainsi que par sa capacité à fournir lui-même ou par un tiers des mises à jour ou mises à niveau.
L’article 11 permet en principe à un opérateur de démontrer que le défaut n’existait pas au moment de la mise sur le marché ou qu’il est apparu ensuite. Cette exonération ne joue toutefois pas de la même manière lorsque la défectuosité provient, sous le contrôle du fabricant, d’un service connexe, d’un logiciel, d’une mise à jour ou de l’absence d’une mise à jour nécessaire au maintien de la sécurité.
Le considérant 51 précise en même temps que la directive ne crée pas, à elle seule, une obligation générale de fournir des mises à jour. Elle encadre la responsabilité lorsque la sécurité exige une mise à jour et que celle-ci relève du contrôle du fabricant. L’existence d’une obligation de support, sa durée et son contenu peuvent découler d’autres textes, du contrat, de la présentation du produit ou du droit sectoriel.
Le dossier doit donc documenter la réalité du contrôle plutôt qu’une formule abstraite :
- qui pouvait décider, construire, signer et déployer une mise à jour ;
- quelles versions et configurations pouvaient la recevoir ;
- à quelle date elle a été rendue disponible ;
- quels utilisateurs ou exploitants devaient encore agir ;
- quelles incompatibilités ou limites empêchaient son installation ;
- à quel moment le support ou le contrôle a effectivement pris fin.
Une preuve d’envoi n’est pas une preuve d’installation. Une télémétrie d’installation n’est pas toujours nécessaire. Selon le produit, un registre de publication, des paquets vérifiables et une documentation claire peuvent suffire à établir ce qui relevait de l’éditeur, tandis qu’un constat ciblé sera nécessaire pour un incident déterminé.
Dix ans ne constituent pas une durée universelle de conservation
L’article 17 prévoit en principe un délai de forclusion de dix ans à compter de la mise sur le marché ou de la mise en service du produit ayant causé le dommage. Un nouveau point de départ s’applique à un produit substantiellement modifié. Le délai peut atteindre vingt-cinq ans lorsque la latence de lésions corporelles a empêché l’engagement d’une procédure dans les dix ans.
Ces délais bornent le droit à réparation selon la directive. Ils ne prescrivent pas de conserver pendant dix ou vingt-cinq ans tous les journaux techniques, comptes utilisateurs et contenus traités par le logiciel. Convertir mécaniquement le délai de responsabilité en durée de conservation générale produirait une surcollecte difficile à défendre.
La directive prévoit explicitement qu’elle n’affecte pas le droit de l’Union relatif à la protection des données. Le RGPD impose notamment finalité, minimisation, limitation de la conservation, intégrité et confidentialité. Le Comité européen de la protection des données rappelle qu’une organisation ne peut traiter que les données nécessaires et proportionnées à l’objectif poursuivi, et qu’elle doit définir des durées par finalité.
Une politique défendable associe donc chaque catégorie à quatre paramètres :
| Paramètre | Question |
|---|---|
| Finalité | Quelle affirmation ou quel risque cette donnée permet-elle réellement d’examiner ? |
| Périmètre | Une métadonnée, un agrégat ou une preuve synthétique suffit-il ? |
| Durée | Quel événement déclenche la suppression, le réexamen ou un gel ciblé ? |
| Accès | Qui peut consulter, extraire et autoriser la divulgation ? |
L’empreinte d’une donnée personnelle peut elle-même rester une donnée personnelle lorsqu’elle permet un rattachement. Notre analyse sur la preuve EUDI Wallet sans surcollecte détaille cette limite entre reçu minimal, référence et copie de l’attestation.
Un protocole de préparation en quatre semaines
Semaine 1 : définir le produit et ses frontières
Inventorier les logiciels fournis, leurs composants, services connexes et modes de distribution. Identifier la personne morale présentée comme fabricant, les tiers qui contrôlent des composants et les produits susceptibles d’être mis sur le marché ou en service à partir du 9 décembre 2026.
Le livrable n’est pas une liste de dépôts. C’est une carte qui relie produit commercial, versions, artefacts, canaux, responsables et capacités de mise à jour.
Semaine 2 : construire un dossier sur une version réelle
Choisir une version représentative et rassembler son manifeste, sa documentation publiée, ses exigences de sécurité, son modèle de menace, ses tests, ses écarts acceptés et ses avertissements. Toute pièce doit être datée et attribuée.
Rechercher ensuite les lacunes : document reconstruit après coup, test non relié à l’artefact, décision sans responsable, date de publication inconnue, dépendance dont la version réelle ne correspond pas au manifeste.
Semaine 3 : simuler une demande de preuve
Partir d’une allégation falsifiable, par exemple : « la version disponible ce jour ne protégeait pas contre le risque annoncé ». Demander à une équipe indépendante de retrouver le produit, la règle de sécurité, les tests, les changements et les limites sans accès informel aux auteurs.
Mesurer le temps de localisation, le nombre de systèmes traversés, les droits nécessaires, les données personnelles exposées et la capacité à produire un extrait compréhensible. Un succès de recherche ne prouve pas le fond, mais révèle si l’organisation peut constituer un dossier.
Semaine 4 : tester le gel et la confidentialité
Déclencher un gel fictif sur un périmètre étroit. Vérifier l’autorisation, l’intégrité, la traçabilité des accès, la date de réexamen et la levée du gel. Préparer deux sorties : une note lisible sur les faits et une annexe confidentielle pour les secrets techniques.
Le test doit aussi démontrer la suppression normale des données hors périmètre. Une procédure qui sait geler mais ne sait plus effacer n’est pas maîtrisée.
Inconnues au 29 juillet 2026
Plusieurs éléments ne peuvent pas être présentés comme définitivement établis :
- le texte français de transposition et ses modalités procédurales n’étaient pas publiés dans les sources officielles consultées pour cette analyse ;
- la qualification d’un logiciel, d’un service connexe, d’un fabricant ou d’une modification substantielle dépendra des faits et des règles sectorielles applicables ;
- la preuve pertinente au sens de l’article 9 sera déterminée par la juridiction dans chaque affaire ;
- aucune architecture technique ne garantit à elle seule la recevabilité, la force probante ou l’issue d’un litige ;
- les durées de conservation doivent articuler plusieurs régimes et finalités, pas seulement la directive 2024/2853.
Le croisement avec le Cyber Resilience Act, l’AI Act, le RGPD, les obligations contractuelles et les règles sectorielles doit être traité comme plusieurs analyses reliées, pas comme une conformité unique. Pour un système d’IA, notre analyse de l’AI Act au 2 août 2026 permet de distinguer les exigences de transparence du dossier de responsabilité étudié ici.
Décision
La priorité avant décembre 2026 n’est pas de prolonger indistinctement la conservation des journaux. Elle est de rendre chaque version importante identifiable, de relier ses décisions de sécurité aux éléments disponibles à l’époque et de savoir préserver un périmètre ciblé lorsqu’un événement le justifie.
Un éditeur prêt à répondre dispose de trois capacités vérifiables :
- retrouver la version, les exigences, les tests et les décisions sans reconstruction opportuniste ;
- isoler les preuves pertinentes sans exposer tout son système d’information ni tous ses utilisateurs ;
- présenter une chronologie compréhensible qui distingue faits, hypothèses, inconnues et limites.
Ce dossier ne supprime pas le risque juridique. Il évite qu’une organisation découvre, au moment du litige, que ses affirmations de sécurité ne sont reliées à aucune version vérifiable.
Limites de l’analyse
Cette publication propose une méthode de préparation technique et documentaire à partir des textes officiels disponibles au 29 juillet 2026. Elle ne constitue pas un avis juridique, ne qualifie aucun produit particulier et ne préjuge pas de la transposition française, de la preuve admise par une juridiction ni de l’application d’un régime sectoriel.