TL;DR Cet article s’inscrit dans la continuité de nos travaux avec Me Marc-Antoine Ledieu sur le droit de pentester l’hébergeur du pentesté. Nous transposons ici le raisonnement juridique aux éditeurs de logiciels dont les produits, déployés dans le LAN de nos clients, introduisent des vulnérabilités structurelles.
Le constat qui revient à chaque mission
Chez BZHunt, nous réalisons des pentests d’infrastructures internes pour des entreprises de toutes tailles et de tous secteurs. Et le constat est récurrent, presque systématique : une part significative des vulnérabilités critiques que nous identifions ne provient pas d’erreurs de configuration du client, mais de défauts structurels introduits par les logiciels déployés dans son LAN.
Ce ne sont pas des cas isolés. Ce sont des schémas que l’on retrouve mission après mission, éditeur après éditeur :
Identifiants par défaut jamais modifiés — et parfois non modifiables. Des consoles d’administration de serveurs applicatifs (GlassFish, Tomcat, et bien d’autres) livrées avec des credentials par défaut documentés publiquement (
admin/admin,tomcat/tomcat…). Certains éditeurs livrent même des appliances dont le mot de passe administrateur est codé en dur dans le firmware, sans possibilité de le changer.Protocoles obsolètes activés par défaut. Des services qui communiquent encore en LLMNR, NBT-NS, en SMBv1, en Telnet ou en FTP non chiffré, parce que l’éditeur n’a jamais pris la peine de désactiver ces protocoles dans sa configuration d’usine. Des interfaces web d’administration accessibles en HTTP clair sur le réseau interne. Des communications inter-applicatives en texte brut, permettant l’interception triviale de credentials sur le réseau.
CVE connues, non patchées, parfois depuis des années. Des composants embarqués (bibliothèques Java, serveurs web intégrés, bases de données embarquées) dont les vulnérabilités sont publiques et activement exploitées, mais que l’éditeur ne met pas à jour. Dans certains cas, l’éditeur interdit contractuellement au client d’appliquer lui-même les correctifs de sécurité, sous peine de perdre le support.
Absence totale de durcissement (hardening). Des services exposés avec des configurations permissives par défaut : pages d’administration accessibles sans restriction réseau, modes debug activés en production, logs verbeux exposant des données sensibles, clés cryptographiques par défaut partagées entre toutes les installations…
Architectures intrinsèquement vulnérables. Des logiciels métier qui exigent des comptes de service avec des privilèges Domain Admin, des agents qui désactivent l’antivirus, l’EDR ou le pare-feu local pour fonctionner, des composants qui ouvrent des ports d’écoute non documentés et non sécurisés.
En résumé : le RSSI a beau appliquer scrupuleusement les bonnes pratiques d’hygiène numérique de l’ANSSI, il se retrouve avec des trous béants dans son SI parce que l’éditeur du logiciel métier n’a pas fait son travail.
Et quand le rapport de pentest tombe, c’est le RSSI qui doit expliquer à sa direction pourquoi le SI est vulnérable. Rarement l’éditeur.
Le parallèle avec l’hébergeur : même logique, mêmes travers
Dans notre article co-écrit avec Me Ledieu en janvier 2023, nous avions démontré que les données et infrastructures du client stockées chez un hébergeur font juridiquement partie du système d’information du client (au sens de la Directive NIS et de sa transposition française). Et que les restrictions imposées par les hébergeurs aux pentests — whitelisting d’IP, horaires imposés, conventions tripartites contraignantes — visaient trop souvent à masquer leurs propres défaillances en matière de cybersécurité.
La transposition aux éditeurs est directe. Le logiciel de l’éditeur, une fois déployé dans le LAN du client, fait partie intégrante du système d’information du client. C’est la définition même de « système d’information » posée par la Directive NIS 2 (n°2022/2555) : tout dispositif — c’est-à-dire tout ensemble matériel + logiciel — utilisé pour le traitement de données.
Et comme pour les hébergeurs, les éditeurs déploient tout un arsenal pour empêcher que leurs failles soient mises en lumière : clauses contractuelles interdisant le reverse engineering, interdiction d’appliquer des patchs tiers, exigence de passer par le support éditeur pour toute modification de configuration sécurité, refus de communiquer les résultats de leurs propres audits…
L’analogie avec l’immeuble que nous utilisions dans l’article de 2023 fonctionne toujours. Imaginez un propriétaire qui installe une serrure défectueuse sur la porte de votre appartement, vous interdit de la changer, et refuse que votre serrurier la teste — mais vous tient pour responsable en cas de cambriolage. C’est exactement ce que font certains éditeurs.
Les armes juridiques du RSSI face à l’éditeur défaillant
Le RSSI n’est pas démuni. Il dispose de plusieurs leviers juridiques pour exiger de l’éditeur qu’il corrige les vulnérabilités structurelles de ses produits, et pour engager sa responsabilité s’il refuse.
1. L’obligation de délivrance conforme (Code civil, art. 1604 et suivants)
L’éditeur qui vend ou met à disposition un logiciel s’engage à délivrer un produit conforme à ce qui est convenu contractuellement. Un logiciel qui introduit des vulnérabilités critiques dans le SI du client n’est pas conforme à l’usage auquel il est destiné. L’éditeur manque à son obligation de délivrance. Le client est en droit d’exiger la correction du défaut, une réduction du prix, voire la résolution du contrat.
2. La garantie des vices cachés (Code civil, art. 1641 et suivants)
Le vendeur est tenu de garantir l’acheteur contre les défauts cachés de la chose vendue qui la rendent impropre à l’usage auquel on la destine. Une vulnérabilité structurelle — credentials codés en dur, protocole obsolète activé par défaut, CVE non corrigée depuis des années — constitue un défaut caché au sens de l’article 1641 du Code civil. Le client ne pouvait pas raisonnablement le déceler au moment de l’achat.
Point crucial : le vendeur professionnel est présumé connaître les vices de la chose qu’il vend. L’éditeur ne peut pas se retrancher derrière son ignorance. Et s’il connaissait les vices (ce qui est souvent le cas quand les CVE sont publiques depuis des mois), il doit non seulement restituer le prix mais aussi tous les dommages-intérêts (art. 1645 du Code civil).
Le RSSI dispose de deux ans à compter de la découverte du vice pour agir. Et le rapport de pentest constitue un excellent élément de preuve pour dater cette découverte et caractériser le vice.
3. L’obligation de sécurité à l’état de l’art
Comme nous l’avions rappelé dans l’article avec Me Ledieu : en France, l’état de l’art en matière de cybersécurité est défini par les référentiels de l’ANSSI et par les décisions de la CNIL.
L’ANSSI définit l’état de l’art comme l’ensemble des bonnes pratiques, des normes et des techniques de sécurité reconnues à un instant donné. Un éditeur qui livre un produit avec des identifiants par défaut, des protocoles obsolètes ou des CVE non corrigées n’est manifestement pas à l’état de l’art.
Cette notion prend une force nouvelle avec le référentiel ReCyF (Référentiel Cyber France) publié par l’ANSSI le 17 mars 2026 dans le cadre de la transposition de NIS 2. Ce référentiel liste les mesures de sécurité attendues et peut servir de grille de lecture pour évaluer — et contester — la conformité d’un produit éditeur.
4. Le Cyber Resilience Act (Règlement UE 2024/2847) — le changement de paradigme
Le CRA est entré en vigueur le 10 décembre 2024. Les obligations de signalement des vulnérabilités s’appliqueront à partir du 11 septembre 2026. L’ensemble des exigences sera pleinement obligatoire le 11 décembre 2027.
Ce règlement change fondamentalement la donne pour les RSSI face aux éditeurs. Il impose aux fabricants de produits numériques — et les éditeurs de logiciels en sont explicitement — des obligations claires et sanctionnables :
Sécurité dès la conception (security by design et by default). Plus question de livrer un produit avec des configurations non sécurisées par défaut. Les identifiants par défaut, les protocoles obsolètes, l’absence de chiffrement — tout cela sera non-conforme.
Gestion structurée des vulnérabilités tout au long du cycle de vie du produit. L’éditeur devra détecter, corriger et notifier les failles selon des délais stricts : 24 heures pour l’alerte initiale, 72 heures pour la notification détaillée, 14 jours pour la correction.
Obligation de fournir des mises à jour de sécurité pendant au minimum 5 ans. Terminé les produits livrés puis abandonnés. L’éditeur devra maintenir la sécurité de son produit dans la durée.
Documentation obligatoire (SBOM). L’éditeur devra documenter les composants intégrés dans son produit, permettant aux clients d’évaluer leur exposition.
Les sanctions sont dissuasives : jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial. L’ANSSI sera l’autorité notifiante pour la France, et l’ANFR assurera la surveillance de marché.
Concrètement, dès septembre 2026, le RSSI pourra exiger de l’éditeur qu’il lui communique sa politique de gestion des vulnérabilités et se rapprocher de l’ENISA/ANSSI si l’éditeur ne notifie pas les vulnérabilités activement exploitées dans ses produits.
5. NIS 2 et la sécurité de la chaîne d’approvisionnement
La Directive NIS 2 (n°2022/2555 du 14 décembre 2022), en cours de transposition en droit français via le projet de loi « Résilience », impose aux entités essentielles et importantes de prendre en compte la sécurité de leur chaîne d’approvisionnement — y compris les produits logiciels qu’elles déploient.
La transposition française, attendue courant 2026, donnera au RSSI un argument réglementaire supplémentaire : l’entité assujettie à NIS 2 a l’obligation de s’assurer que les logiciels déployés dans son SI ne compromettent pas sa cybersécurité. Si l’éditeur refuse de corriger des vulnérabilités structurelles, le RSSI peut et doit en tirer les conséquences — y compris contractuelles.
6. DORA pour le secteur financier (Règlement UE 2022/2554)
Pour les entités du secteur financier (banques, assurances, courtiers), le Règlement DORA va encore plus loin : il impose des tests de pénétration réguliers par des prestataires qualifiés, y compris sur les systèmes fournis par des prestataires tiers (éditeurs compris). Et il exige de ces prestataires qu’ils soient couverts par une assurance de responsabilité civile professionnelle.
Le RSSI d’un établissement financier dispose donc d’un levier réglementaire direct pour exiger de l’éditeur qu’il corrige les vulnérabilités identifiées lors des tests de résilience opérationnelle.
Ce que le RSSI devrait faire concrètement
Avant le pentest
- Inventorier les logiciels éditeur déployés dans le LAN et les conditions contractuelles associées (clauses de limitation, interdictions de tests, conditions de maintenance).
- Vérifier si le contrat éditeur contient des clauses limitant le droit d’audit de sécurité et les contester si elles sont abusives.
- Anticiper le CRA en exigeant dès maintenant de l’éditeur un engagement écrit sur sa politique de gestion des vulnérabilités et de mise à jour.
Pendant le pentest
- Demander au pentesteur de tracer systématiquement l’origine des vulnérabilités : est-ce une erreur de configuration du client, ou un défaut structurel du produit éditeur ?
- Documenter précisément les vulnérabilités imputables à l’éditeur avec preuves techniques (versions, configurations par défaut, CVE associées).
Après le pentest
- Notifier formellement l’éditeur des vulnérabilités identifiées dans son produit, par courrier recommandé, en lui fixant un délai raisonnable de correction.
- Conserver le rapport de pentest : c’est la preuve de la découverte du vice au sens de l’article 1648 du Code civil (point de départ du délai de 2 ans pour agir en garantie des vices cachés).
- Négocier un avenant contractuel imposant à l’éditeur des engagements de correction et de maintien en condition de sécurité, adossés à des pénalités.
- Si l’éditeur refuse de corriger : évaluer les options juridiques (mise en demeure, résolution du contrat, action en garantie, signalement aux autorités compétentes si applicable).
- Documenter la décision : que le RSSI décide de maintenir ou de remplacer le produit, il doit documenter son analyse de risque et les mesures compensatoires mises en place. C’est une exigence qui sera renforcée par NIS 2.
Un mot pour les éditeurs
La logique est la même que pour les hébergeurs dans notre article de 2023 : quand un pentest bien fait montre que votre produit présente des failles de sécurité, c’est votre client qui paie pour vous permettre d’améliorer votre produit. Il ne vous reste plus qu’à corriger les problèmes identifiés — que vous n’avez pas payés pour identifier.
Le Cyber Resilience Act n’est pas une menace, c’est une opportunité de professionnaliser vos pratiques de développement. Les éditeurs qui anticiperont ces obligations en feront un avantage concurrentiel. Les autres s’exposeront à des sanctions réglementaires, à des actions en responsabilité de leurs clients, et in fine à la perte de leur marché européen.
Comme le rappelait Me Ledieu : le temps où l’on pouvait vendre un logiciel truffé de failles sans conséquences juridiques touche à sa fin.
Conclusion : le rapport de pentest comme outil juridique
Le rapport de pentest n’est pas seulement un livrable technique. C’est un élément de preuve à valeur juridique qui documente :
- la date de découverte des vulnérabilités (point de départ de la prescription),
- la nature et la gravité des défauts (caractérisation du vice caché),
- l’imputabilité au produit éditeur (et non à une erreur de configuration du client),
- le caractère « caché » du défaut (le client ne pouvait pas le déceler sans expertise spécialisée).
Le RSSI qui fait réaliser un pentest professionnel et qui exploite correctement les résultats dispose d’un arsenal juridique complet pour exiger des éditeurs qu’ils assument leurs responsabilités en matière de cybersécurité.
Et cet arsenal ne fera que se renforcer avec l’entrée en application du CRA en septembre 2026 et la transposition de NIS 2 en droit français.
Il est temps que les éditeurs cessent de considérer la sécurité comme un coût et commencent à la traiter comme une obligation, parce que c’est exactement ce qu’elle est en train de devenir.
Cet article ne constitue pas un avis juridique. Pour toute action contentieuse, nous recommandons de consulter un avocat spécialisé en droit du numérique. Les références réglementaires citées sont à jour au 27 mars 2026.
Article rédigé par Brice AUGRAS, Fondateur et président — BZHunt — en continuité de l’article co-écrit avec Me Marc-Antoine LEDIEU, Avocat et RSSI — Ledieu-Avocats.