Un changement de mot qui change tout
Pendant des années, j’ai eu la sensation que le logiciel vivait dans une sorte de bulle. Pas au sens romantique du terme, plutôt une zone grise confortable, presque protectrice. Si un produit physique blessait quelqu’un, la responsabilité était une question immédiate et concrète. Si c’était « juste » du logiciel, la conversation glissait souvent vers les bugs, les patchs, les workarounds, et vers ce sous-entendu un peu indulgent : « c’est normal, ça se met à jour ».
La directive 85/374/CEE sur la responsabilité du fait des produits défectueux parlait au fond de biens meubles, d’objets tangibles. Le logiciel, intangible par définition, y entrait mal. Et quand une norme tombe mal, souvent elle finit par ne pas tomber du tout.
À partir du 9 décembre 2026, avec la directive (UE) 2024/2853, cette ambiguïté se referme. La nouvelle Product Liability Directive (PLD) dit explicitement que le logiciel est un produit. Et pas seulement le logiciel « dans » un objet, mais tout : standalone, embedded, firmware, applications, cloud, SaaS, systèmes d’IA. Indépendamment d’où il tourne et de comment vous le distribuez.
Ce n’est pas une note de bas de page. C’est un changement de paradigme, et le plus intéressant peut-être, c’est qu’il ne concerne pas seulement qui écrit du code. Il concerne qui décide quoi construire, qui le vend, qui le release, qui le maintient et qui décide quand arrêter.
La responsabilité objective : le point où la perspective change
La PLD s’appuie sur un concept facile à sous-estimer dans le monde du logiciel jusqu’à ce qu’il vous tombe dessus : la responsabilité objective (strict liability).
En pratique, qui subit un dommage du fait d’un produit défectueux n’a pas à démontrer que vous avez été négligent. Pas besoin de reconstruire votre chaîne de décisions, pas besoin de prouver que « vous auriez pu faire mieux ». Il doit démontrer trois choses : que le produit était défectueux, qu’il y a eu un dommage, et qu’il y a un lien de causalité.
Pour qui a l’habitude de raisonner en termes de « nous avons fait le maximum », « c’était un edge case », « c’était une dépendance tierce », c’est un déplacement mental notable. La diligence continue de compter, certes, mais pas comme bouclier automatique.
Et il y a un autre morceau qui rend tout plus concret : la directive introduit des mécanismes de présomption.
Si pour la victime il est « excessivement difficile » de prouver le défaut ou le lien causal — ce qui est presque la norme avec un logiciel complexe ou un système d’IA — le tribunal peut présumer la défectuosité et la causalité. Il peut aussi ordonner au producteur de produire la documentation technique, qui doit être présentée de façon « accessible et compréhensible ». Si vous ne coopérez pas, ce manque de coopération peut devenir un élément à votre défaveur.
Sans détour : dans bien des cas, vous vous retrouverez à devoir démontrer que le logiciel n’était pas défectueux. Et pour ça, il faut des preuves. Des traces. Des choix motivés. Des données.
Qui fait du produit : la responsabilité commence bien avant le code
Quand on parle de responsabilité, l’instinct est de regarder le développement. Mais la PLD met aussi sous loupe ce qui vient avant, c’est-à-dire les décisions de produit.
La défectuosité s’apprécie selon les attentes raisonnables de sécurité. Un produit est défectueux s’il n’offre pas le niveau de sécurité qu’une personne est en droit d’attendre. Et ce jugement dépend de comment vous présentez le produit, de l’usage raisonnablement prévisible, du moment de la mise en service. Mais aussi d’éléments très modernes, comme l’interconnexion avec d’autres systèmes, la conformité aux exigences de cybersécurité, et même la capacité à apprendre.
Là, je pense à toutes ces fois où une roadmap naît de trade-offs qui semblent purement « business » : livrer plus tôt, couper une feature de sécurité, repousser la phase de hardening, intégrer un composant IA parce que « c’est cool » et parce que les concurrents l’ont déjà.
Avec la PLD, ce ne sont pas seulement des choix de produit. Ce sont des choix qui peuvent devenir pertinents en cas de contestation.
Si vous promettez dans les specs commerciales une certaine fiabilité ou un certain standard de sécurité, vous créez une attente. Si vous intégrez un composant IA qui change de comportement dans le temps, vous prenez la responsabilité aussi de ce comportement futur. Et l’imprévisibilité de l’IA, telle qu’est posée la directive, n’est pas une défense.
La conséquence la plus pratique, à mon sens : le risk assessment entre dans le product management. Pas comme un document fait une fois pour toutes, mais comme une habitude.
Et surtout, entre la documentation des décisions. Pas par bureaucratie, mais parce que dans quelques années il pourrait être nécessaire d’expliquer pourquoi un certain choix était raisonnable à ce moment-là. Les Architecture Decision Records, qu’aujourd’hui beaucoup d’équipes utilisent pour ne pas se perdre, commencent à ressembler à un morceau de votre défense.
Qui vend : le contrat n’est plus un bouclier
Il y a un réflexe conditionné répandu dans le logiciel : si le risque augmente, on ajoute une clause. Limitation de responsabilité, cap, indemnisation, disclaimers dans les conditions.
La PLD est ici plutôt brutale : la responsabilité prévue par la directive ne peut pas être exclue ou limitée contractuellement quand le dommage concerne une personne physique. Cela vaut en B2C, et en pratique cela vous touche aussi en B2B chaque fois qu’il existe des utilisateurs finaux personnes.
Cela ne veut pas dire que les contrats deviennent inutiles. Cela veut dire qu’ils doivent changer de fonction.
En particulier, dans les rapports B2B, il faut clarifier les responsabilités le long de la supply chain. Si vous développez pour un client qui met le produit sur le marché sous sa marque, qui est le « fabricant » au sens de la PLD ? Si votre logiciel est un composant d’un système plus grand, comment se gère le recours entre les parties ? Vous ne pouvez pas éliminer la responsabilité vers l’extérieur, mais vous pouvez et devez clarifier ce qui se passe entre vous.
Puis il y a un morceau souvent sous-estimé par les équipes sales et marketing : les promesses commerciales.
Démos, brochures, claims du genre « plus hauts standards de sécurité », slides avec « zero downtime », pages de pricing qui impliquent certaines garanties. Tout cela contribue à définir ce que l’utilisateur était en droit d’attendre. Et cela entre, indirectement, dans l’évaluation de la défectuosité.
Enfin, le sujet assurance et pricing. La RC pro classique couvre la négligence, pas nécessairement la strict liability. Il est probable que beaucoup d’entreprises doivent revoir couvertures et plafonds, en incluant cybersécurité, perte de données et dommages immatériels. Et ce coût finira dans le prix. Avec un effet collatéral intéressant : qui se positionne bien tôt peut transformer la compliance en argument compétitif crédible.
Qui release : chaque deploy devient un acte qui laisse des traces
Si vous travaillez sur les releases, le DevOps, la QA, ou si vous êtes la personne qui finit par dire « ok, on passe en prod », c’est peut-être la partie la plus concrète.
Dans le logiciel moderne, la release n’est pas la fin. C’est le début. Parce que presque toujours le producteur conserve le contrôle via des updates, l’accès distant, des feature flags, des patches, des mises à jour de sécurité.
La PLD, lue avec le contexte normatif, rend très risquée une approche « on release et on verra ». L’absence de fourniture de mises à jour de sécurité pour des vulnérabilités connues peut être considérée elle-même comme un défaut. Et une mise à jour qui introduit un problème peut être vue comme une modification substantielle, avec des effets sur les délais aussi.
La responsabilité de base dure 10 ans, et pour des lésions personnelles latentes elle peut atteindre 25. Quand je lis ces chiffres, je me demande toujours si nous avons vraiment la culture de conservation des preuves sur un horizon pareil. Parce qu’il ne suffit pas d’avoir bien fait les choses, il faut pouvoir le démontrer.
Là entre la traçabilité.
Savoir ce que contenait une certaine version à une certaine date. Quelles dépendances. Quelles vulnérabilités connues. Quels tests ont été exécutés. Qui a approuvé. Ce qui a été décidé et pourquoi.
Le SBOM (Software Bill of Materials) devient central. D’autant que le Cyber Resilience Act le rend obligatoire dans bien des cas, et la pipeline CI/CD devient de fait une infrastructure de compliance : génération automatique de SBOM (CycloneDX ou SPDX), scan de vulnérabilités, audit trail des deploys, conservation des artefacts.
Et il y a un détail qui paraît banal jusqu’à ce qu’on le vive : la décision de ne pas publier un patch est aussi une décision. Si aujourd’hui vous choisissez de repousser une correction pour des raisons sensées, c’est probablement OK. Mais dans cinq ans, vous pourriez devoir expliquer pourquoi c’était sensé. Mieux vaut avoir cette explication écrite quand la mémoire est fraîche.
Qui développe : documenter n’est pas de la bureaucratie, c’est de la mémoire défendable
Pour les développeurs, la PLD ne demande pas de magie. Elle ne dit pas « écris du code parfait », chose qui n’existe pas. Elle vous demande, en substance, de rendre le parcours reconstructible.
Tests automatiques qui démontrent le comportement attendu. Code reviews tracées. Scans de sécurité intégrés. Messages de commit qui ne soient pas « fix ». Tickets qui racontent le contexte.
Ce sont des choses que beaucoup d’équipes font déjà, parfois de façon irrégulière. La différence : de « bonne pratique », elles deviennent aussi un élément de protection.
Et ici la connexion avec le Cyber Resilience Act est directe : si vous n’êtes pas conforme à des exigences comme secure by design, gestion des vulnérabilités et SBOM, cette non-conformité peut renforcer une contestation de défectuosité au sens de la PLD. Les normes, en somme, ne vivent plus en compartiments étanches.
Le mythe du B2B comme zone franche
Je comprends la tentation : « nous vendons uniquement à des entreprises, donc ça ne nous concerne pas ».
Mais il suffit de regarder un instant les utilisateurs réels.
Logiciels pour l’administration : citoyens. Systèmes RH : employés. E-learning : étudiants. Parking : automobilistes. Santé : patients. Dans tous ces cas, le client est une organisation, mais l’impact retombe sur des personnes physiques.
En plus, la PLD raisonne aussi par composants. Si vous fournissez un module, une API, un microservice qui finit dans le produit d’un autre, vous pouvez être considéré comme fabricant du composant.
Et puis il y a l’extension des dommages indemnisables : la destruction ou la corruption de données non utilisées à des fins professionnelles, sans seuil minimum et sans plafond maximum. Un passage que beaucoup d’entreprises n’ont pas encore digéré.
Open source : protégé, mais pas une échappatoire
La directive exclut le logiciel open source développé ou fourni en dehors d’une activité commerciale. Mais s’il y a une contrepartie, même sous forme de données personnelles, le discours change.
Et surtout, si vous intégrez de l’open source dans un produit commercial, la responsabilité d’éventuels défauts retombe sur qui intègre et met sur le marché.
Cela déplace le centre de gravité : ce n’est plus seulement un sujet de compliance des licences. Cela devient gestion du risque technique et juridique. Choix des dépendances, processus de vetting, vulnerability management sérieux, et de nouveau SBOM.
La PLD n’est pas seule : un écosystème qui s’emboîte
Le sentiment, en regardant le tableau européen, c’est que l’UE est en train de construire une idée précise de « logiciel comme produit » et la soutient sur plusieurs flancs.
La PLD s’emboîte avec le Cyber Resilience Act (cybersécurité by design, SBOM, gestion vulnérabilités), avec l’AI Act (qui rend les fournisseurs IA fabricants aussi au sens PLD), avec le RGPD (data breach et dommages), avec NIS2, avec le GPSR, avec la Representative Actions Directive pour les actions collectives, et même avec l’European Accessibility Act.
Le point n’est pas de retenir tous les sigles. Le point est qu’une lacune dans un domaine peut se propager et renforcer un contentieux dans un autre. La compliance devient un système.
La transposition italienne : un choix à surveiller
L’Italie doit transposer la PLD avant le 9 décembre 2026. S’agissant d’une directive d’harmonisation maximale, il n’y a pas beaucoup de marge pour des « interprétations créatives ». Mais une marge importante existe : la défense de l’état de l’art.
En substance, l’État peut décider de maintenir l’idée selon laquelle le fabricant ne répond pas si le défaut n’était pas reconnaissable avec les connaissances disponibles au moment de la mise en service. Ou il peut l’éliminer.
Ce n’est pas un détail, et ça vaut la peine de le surveiller. Parce que cela change le profil de risque, en particulier sur le logiciel complexe et sur les scénarios IA.
Pas que des risques : la part qui peut devenir un avantage
Si vous la lisez en mode « catastrophe », la PLD ne ressemble qu’à un coût. Plus de documentation, plus de processus, plus d’assurances, plus de discussions internes.
Mais il y a une autre lecture, peut-être la plus utile si vous devez décider maintenant.
La PLD crée un terrain de jeu où qualité, sécurité et transparence de la supply chain deviennent des avantages compétitifs mesurables. Plus de « faites-nous confiance », mais « nous avons des processus et des preuves qui tiennent face à une demande formelle, et au besoin face à un tribunal ».
Pour les software houses, arriver compliant avant la deadline peut devenir un argument fort avec l’enterprise et l’administration. Pour le conseil et l’intégration de systèmes, s’ouvre une demande énorme de compétences qui aujourd’hui, au moins dans le tissu des PME italiennes, n’est pas si répandue. Pour qui fait du produit, c’est une incitation à investir dans des choses qui, à la longue, améliorent vraiment le logiciel.
Une conclusion sans triomphalisme
Pendant quarante ans, nous avons pu penser au logiciel comme à quelque chose de spécial. Plus flexible, plus actualisable, plus pardonnable.
La PLD dit que cette exception est terminée. Le logiciel est un produit, avec des responsabilités semblables à celles d’une machine, d’un dispositif médical, d’une voiture.
Cela ne concerne pas seulement qui écrit du code. Cela concerne la roadmap et les trade-offs. Cela concerne les contrats et les promesses commerciales. Cela concerne les releases et le support, et même la fin de vie.
La chose qui me semble la plus sensée, aujourd’hui, est de déplacer la question de « comment nous protéger » à « comment rendre notre façon de travailler démontrable ». Parce que se préparer ne se résume pas à mettre des rustines juridiques. C’est faire mieux son métier, avec plus de mémoire, plus de traçabilité et moins de confiance aveugle dans le « de toute façon, on rattrapera ».
La question n’est pas s’il faut se préparer. C’est à quelle vitesse.
Sources principales : directive (UE) 2024/2853 ; Cyber Resilience Act (règlement UE 2024/2847) ; analyses de Reed Smith, IBA, Fladgate, Taylor Wessing, Clyde & Co, DLA Piper, Hogan Lovells, ICLG, Covington.
Ce qu'il faut retenir
La PLD introduit une responsabilité objective sur le logiciel : le bug cesse d’être un désagrément opérationnel pour devenir potentiellement un défaut de produit.
Logging, audit et SBOM deviennent des exigences non négociables — si vous ne pouvez pas démontrer ce qui s’est passé, vous ne pouvez pas vous défendre.
L’open source n’est pas une échappatoire : qui intègre un composant répond du défaut même s’il vient de l’amont.
Trois clauses contractuelles à revoir tout de suite : garantie et SLA explicites sur la sécurité, procédure d’incident concertée, allocation claire des responsabilités vis-à-vis de l’utilisateur final.
Qui travaille avec des contrats pré-PLD accumule un risque juridique qui émergera au premier contentieux.
Questions & réponses
Qu'est-ce qui change pour le logiciel à partir du 9 décembre 2026 ?
La nouvelle Product Liability Directive (Directive UE 2024/2853) entre en vigueur et inclut explicitement le logiciel dans la catégorie « produit ». Cela signifie que le producteur répond des dommages dus à un défaut indépendamment de la négligence — responsabilité objective, comme pour l’électroménager ou les médicaments. Les bugs cessent d’être un désagrément opérationnel pour devenir potentiellement des défauts de produit avec des conséquences juridiques directes.
Comment la roadmap produit change-t-elle avec la PLD ?
Dans trois directions : (1) le logging et l’audit deviennent des exigences non optionnelles — sans preuve de ce qui s’est passé, pas de défense ; (2) la rétention des mises à jour de sécurité a une valeur juridique — la responsabilité ne s’arrête pas à la release mais à la fin du support déclaré ; (3) la gestion des vulnérabilités devient un processus produit, pas une activité ad hoc. La roadmap ne peut plus comporter que des « features » — elle doit aussi comporter de la maintenance.
Qu'est-ce qui change pour qui utilise des composants open source ?
Beaucoup. Le producteur du logiciel final répond des défauts même quand ils viennent de composants open source qu’il a intégrés. Il ne peut pas se décharger sur le projet open source (qui souvent n’a pas de personnalité juridique). Conséquence pratique : deux mouvements obligatoires — due diligence sur les projets intégrés (santé, gouvernance, historique de patchs) et SBOM permettant une réaction rapide aux vulnérabilités. Ce n’est pas anti-open-source — c’est de la responsabilité de chaîne.
Comment faut-il mettre à jour les contrats pour le logiciel B2B ?
Trois clauses à revoir : (1) garantie et service level explicite sur la sécurité, pas générique ; (2) procédure de gestion d’incident concertée (délais de notification, responsabilités de remédiation) ; (3) allocation contractuelle claire entre responsabilité vis-à-vis de l’utilisateur final et responsabilité entre fournisseur et client enterprise. Qui travaille aujourd’hui avec des modèles contractuels pré-PLD accumule un risque juridique qui émergera au premier contentieux.
L'auteur
