Le 28 octobre 2026, les documents budgétaires du gouvernement britannique ont annoncé une consultation, l’an prochain, sur les technologies non sécurisées dès leur conception, avec l’engagement d’examiner « where liability for cyber breaches should sit », autrement dit qui doit répondre des cyberattaques. The Record y voit le premier engagement formel d’un gouvernement britannique sur la responsabilité des éditeurs de logiciels. L’annonce tient en une ligne d’un document de 166 pages, mais elle intéresse tous les acheteurs de logiciels.
Ce que Londres met sur la table
Le contexte pèse lourd. L’attaque subie par Jaguar Land Rover en 2025 aurait coûté environ 1,9 milliard de livres à l’économie britannique. Depuis 2024, la loi PSTI (Product Security and Telecommunications Infrastructure Act) impose des exigences de sécurité de base aux fabricants d’objets connectés grand public, et son extension figure parmi les pistes les plus probables. Le gouvernement n’a pas encore dit quel ministère pilotera le dossier, ni s’il choisira la responsabilité civile, des obligations légales à la charge des éditeurs, ou une combinaison des deux.
Le travail s’appuiera sur la revue du droit de la responsabilité du fait des produits menée par la Law Commission. Sa consultation, ouverte le 8 octobre et close le 14 janvier, propose d’étendre la notion de produit du Consumer Protection Act 1987, pensée pour des biens physiques, aux logiciels et aux systèmes d’IA. En novembre 2025, une commission de la Chambre des communes avait déjà demandé que le code de bonnes pratiques du NCSC sur la sécurité des logiciels, aujourd’hui volontaire, devienne obligatoire et assorti de sanctions. Le projet de loi sur la cybersécurité et la résilience, en discussion à la Chambre des lords, vise de son côté les opérateurs d’infrastructures critiques et leurs fournisseurs, sans toucher directement les développeurs.
La responsabilité des éditeurs de logiciels dans l’Union européenne
Côté européen, deux textes couvrent déjà le terrain. Le Cyber Resilience Act (règlement 2024/2847) impose aux fabricants de produits comportant des éléments numériques, logiciels compris, des exigences de cybersécurité dès la conception, une gestion des vulnérabilités pendant la période de support et la fourniture de mises à jour de sécurité. Le signalement des vulnérabilités activement exploitées est exigé depuis le 11 septembre 2026, et la plupart des autres obligations s’appliqueront à partir du 11 décembre 2027. Les amendes peuvent atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial. Un service purement en ligne relève plutôt de NIS 2 et du contrat que du CRA.
La nouvelle directive sur la responsabilité du fait des produits défectueux (directive 2024/2853), à transposer d’ici le 9 décembre 2026, range expressément les logiciels parmi les produits. Un défaut peut résulter de l’absence d’une mise à jour de sécurité, et le dommage indemnisable comprend, pour les personnes physiques, la destruction ou la corruption de données qui ne servent pas à un usage professionnel. Il s’agit d’une responsabilité sans faute. Le Royaume-Uni discute donc aujourd’hui d’un principe que l’Union a adopté en 2024.
Ce que l’organisme qui achète un logiciel doit vérifier
Pour un responsable de traitement, rien ne déplace l’obligation de sécurité de l’article 32 du RGPD. Si un logiciel défaillant provoque une fuite, l’organisme reste tenu de notifier la violation, d’informer les personnes concernées et de répondre à la CNIL. Le CRA et la directive lui donnent en revanche des arguments face à l’éditeur, puisqu’il peut exiger dès maintenant des engagements qui deviendront des obligations légales. À l’occasion d’un renouvellement ou d’un nouvel achat, je recommande de regarder dans le contrat :
- la durée pendant laquelle l’éditeur fournit des mises à jour de sécurité, et le délai de correction des vulnérabilités critiques ;
- l’obligation de prévenir le client sans délai d’une vulnérabilité exploitée ou d’un incident, avec un délai compatible avec les 72 heures de l’article 33 ;
- la remise d’une nomenclature des composants logiciels (SBOM) et l’engagement de conformité au CRA à son entrée en application ;
- pour un service hébergé, un contrat conforme à l’article 28 avec droit d’audit, liste des sous-traitants ultérieurs et conditions de réversibilité ;
- les clauses de limitation de responsabilité, souvent rédigées pour exclure toute perte de données, à relire à la lumière des régimes qui arrivent ;
- les prérequis de sécurité laissés à la charge du client (configuration, comptes, sauvegardes), pour savoir précisément ce qui relève de chacun.
Pour un logiciel déjà en place, l’avenant de renouvellement est souvent le seul moment où l’éditeur accepte de discuter ces points. Ces vérifications gagnent à être tracées. Une fiche par éditeur, rattachée aux traitements concernés, permet de montrer à une autorité de contrôle que le fournisseur a été choisi en connaissance de cause et suivi dans la durée.
Les DPO du réseau DPO FRANCE relisent les contrats passés avec les éditeurs et accompagnent les organismes lors des audits de sous-traitants. DPO SUITE rassemble le registre, les fiches sous-traitants, les audits et les violations de données, ce qui permet de documenter la chaîne de responsabilité de chaque logiciel.
