Amendement CS178 : un tournant pour la responsabilité des éditeurs de logiciels

L’amendement n° CS178, déposé à l’Assemblée nationale le 5 septembre 2025 par Mme Véronique Riotton, vise à compléter le projet de loi pour la résilience des infrastructures critiques et le renforcement de la cybersécurité. L’objet : ajouter dans l’article 8 (alinéa 7) les mots « et les éditeurs de logiciels ».

L’amendement a bien été adopté en commission à l’Assemblée nationale, mais il ne produit pas encore d’effet juridique. Il faudra attendre :

• le vote définitif de l’ensemble du projet de loi (Assemblée + Sénat),

• sa promulgation,

• puis la publication au Journal officiel (et souvent des décrets d’application).

Tant que ces étapes ne sont pas franchies, l’amendement est intégré au projet de loi, mais il n’est pas encore en vigueur.

Pourquoi cet amendement ?

• Aujourd’hui, les éditeurs de logiciels ne sont pas explicitement soumis aux obligations de sécurité — ni aux autorités de contrôle — prévues dans le cadre de la transposition nationale de la directive NIS 2.

• Cela crée une faille structurelle : lorsqu’un logiciel utilisé par un hôpital, une collectivité, ou une infrastructure essentielle présente une vulnérabilité, rien dans la loi actuelle ne force l’éditeur à la corriger dans un délai défini ou sous contrôle.

• Le considérant 85 de la directive NIS 2 identifie clairement les éditeurs de logiciels comme un maillon essentiel dans la chaîne d’approvisionnement numérique, souvent ciblé par des cyberattaquants pour infiltrer des systèmes en amont.

Que propose l’amendement ?

• Étendre le champ de la directive NIS 2 (via sa transposition nationale) aux éditeurs de logiciels, les soumettant aux obligations minimales de sécurité dès la conception et le développement des logiciels.

• Permettre à l’ANSSI (ou autre autorité compétente) d’intervenir, de contrôler, voire d’imposer des mesures, pour garantir que les éditeurs respectent les obligations.

La directive NIS 2 un rapide bref rappel

Avant d’explorer les conséquences, il est utile de resituer ce que fait la directive NIS 2.

• Adoptée au niveau européen en décembre 2022, la directive vise à garantir un niveau élevé de sécurité des réseaux et des systèmes d’information dans l’Union européenne.

• Elle élargit le champ d’application par rapport à NIS 1 : plus de secteurs, plus d’acteurs (essentiels ou importants), plus d’exigences techniques et organisationnelles.

• Elle instaure des obligations de gouvernance, de gestion des risques, de continuité des activités, de signalement des incidents, de supervision et d’audit.

Ce que changerait l’amendement — conséquences

L’extension du champ aux éditeurs de logiciels entraînerait plusieurs impacts — à la fois des obligations nouvelles pour eux, des effets de levier de sécurité pour les utilisateurs, et des défis opérationnels et juridiques.

Notre application DPO FRANCE propose des audit DORA, NIS2, ia act…

Liens avec d’autres cadres juridiques / législatifs

L’amendement ne se développe pas dans un vide : il s’interagit avec d’autres normes, directives ou règlements :

• Cyber Resilience Act (CRA) : règlement européen en cours (et adopté dans certains États) qui impose des exigences de sécurité pour les produits numériques, y compris le logiciel. L’amendement CS178 semble converger avec l’esprit du CRA, en ce qu’il impose une meilleure sécurité dès la conception.

• DORA (Digital Operational Resilience Act) dans le secteur financier : NIS 2 et DORA se chevauchent pour les entités financières, mais DORA joue un rôle de « lex-specialis » dans certains cas. L’harmonisation des obligations sera importante pour éviter les contradictions.

• Législation nationale française : le projet de loi relatif à la résilience des infrastructures critiques doit transposer NIS 2, mais aussi d’autres directives, et prévoit des sanctions en cas de manquement, des plans de résilience, etc. vie-

Risques, limites et incertitudes

Aucune mesure ne va sans compromis, ni sans zone d’ombre. Voici les principaux risques ou incertitudes liés à l’amendement CS178.

1. Proportionnalité et adaptation aux petites structures
   Les obligations fortes pèsent plus lourd sur des éditeurs petits ou moyens, qui n’ont pas forcément les ressources internes ni l’organisation pour répondre rapidement aux exigences techniques, aux audits, aux correctifs. Il faudra prévoir des seuils, des délais progressifs, des financements/ressources accompagnatrices.

2. Définition précise des obligations et des délais
   La loi devra préciser les délais dans lesquels l’éditeur doit corriger une vulnérabilité, les responsabilités contractuelles, le niveau de sécurité attendu, les mesures de contrôle de l’autorité. Sans cela, la jurisprudence ou les interprétations divergentes peuvent créer des incertitudes, voire des abus.

3. Charge pour les éditeurs et coûts de mises à jour
   Pour les éditeurs, ces nouvelles obligations signifient des investissements pour la sécurité (audit, test, correction, surveillance), mais aussi des pertes potentielles si le produit est retiré du marché ou sanctionné pour non-conformité.

4. Impact sur l’innovation et les délais de commercialisation
   Imposer des obligations de sécurité plus strictes dès la conception peut ralentir le cycle de développement, rendre plus coûteuse l’innovation ou les mises à jour, en particulier dans les startups ou éditeurs agiles. Il faut trouver un équilibre pour ne pas étouffer l’innovation.

5. Capacité de contrôle de l’autorité nationale
   L’ANSSI devra disposer de moyens suffisants (effectifs, compétences, budget) pour surveiller les éditeurs, faire des audits, imposer des sanctions. Sinon, les obligations resteront lettre morte. Si l’autorité est débordée ou mal dotée, le risque de non application augmente.

6. Risques de contentieux / responsabilité
   Les éditeurs pourraient être exposés à des actions en responsabilité (contractuelles, voire extra-contractuelles) si une vulnérabilité de leur logiciel cause un dommage. Cela soulève des questions d’assurance, de régime de responsabilité applicable, de preuve, etc.

7. Coordination européenne nécessaire
   Si la France adopte des règles divergentes ou plus strictes sur certains points, cela pourrait créer des frictions avec le marché européen, des coûts de conformité multiples, voire des obstacles à l’export pour les éditeurs. Une harmonisation au moins minimale avec le CRA, la directive NIS 2 européenne, et d’autres cadres est souhaitable.

Recommandations pour les entreprises utilisatrices (DPO, RSSI, direction)

Pour minimiser les risques et tirer profit de cette évolution, voici quelques bonnes pratiques à anticiper :

• Audit du portefeuille logiciel : recenser les logiciels critiques utilisés, identifier les éditeurs, les versions, les vulnérabilités connues, les droits de correction, les contrats existants.

• Renégociation ou insertion de clauses contractuelles : prévoir des SLA de correction de vulnérabilité, des obligations de documentation de sécurité, des droits d’audit, des garanties de conformité, des pénalités en cas de non respect.

• Exiger des certificats ou labels de sécurité : utiliser des logiciels ou modules certifiés, ou respectant des normes reconnues (ex. ISO 27001, ENISA secure software, etc.).

• Veille technologique et vulnérabilité : maintenir une surveillance des alertes de sécurité, des CVE, etc., pour tous les logiciels utilisés, même ceux tiers ou open source.

• Formation et gouvernance interne : sensibiliser les équipes métiers, la direction, le DPO, le RSSI aux nouvelles obligations, aux risques logiciels, à la responsabilité, etc.

• Plan de résilience / gestion de crise : prévoir ce qui se passe si un logiciel tierce présente une faille critique — scénario de substitution, de mitigation, de reprise, etc.

Ce qu’il faut surveiller dans l’évolution du cadre législatif

• Le texte final de la transposition en droit français : quelles versions des obligations seront retenues, s’il y aura des assouplissements pour certaines catégories (PME, éditeurs de niche, open source…), les seuils, les délais, les sanctions.

• L’articulation avec le Cyber Resilience Act (CRA) — quelles obligations s’appliquent selon que le logiciel est mis sur le marché, fourni en service, localement installé, etc.

• L’évolution des référentiels techniques de sécurité : l’ANSSI devra probablement définir des guides, des normes, ou référentiels applicables aux logiciels, avec des pratiques de référence.

• La capacité financière et opérationnelle des éditeurs à s’adapter, et la mise en place de dispositifs d’accompagnement (subventions, aides, financements, formation).

• L’intensité des contrôles et des sanctions : c’est un facteur clé pour que les obligations soient respectées — si les sanctions sont peu dissuasives ou appliquées de façon limitée, l’effet sera faible.

L’amendement n° CS178 représente une évolution majeure du cadre de cybersécurité en France. En rendant les éditeurs de logiciels pleinement responsables, dès la conception, de la sécurité de leurs produits, il comble une lacune importante du dispositif actuel.

Pour autant, la traduction concrète de cet amendement — dans le droit français final, dans les contrats, dans les pratiques — sera déterminante. Les bénéfices peuvent être substantiels, mais les coûts et les risques sont aussi réels, surtout pour les petits éditeurs ou les utilisateurs avec des ressources limitées.

Il est souhaitable que ce renforcement soit accompagné d’une responsabilisation mesurée, d’un accompagnement clair, et d’un dialogue avec toutes les parties concernées (éditeurs, utilisateurs, autorités). Une mise en œuvre progressive, transparente, proportionnée, pourra permettre d’atteindre un équilibre entre sécurité accrue et innovation.