La loi Résilience, qui transpose en droit français la directive NIS2, le règlement DORA et la directive CER, n'est pas encore promulguée. Son examen en séance publique à l'Assemblée nationale est attendu à l'automne 2026. Mais son article 16bis, adopté par le Sénat dès mars 2025, concentre déjà l'essentiel du débat entre experts cyber et services de renseignement. Pour votre organisation, comprendre ce que ce texte dit — et ce qu'il ne dit pas — est une décision d'architecture, pas seulement une question juridique.
Ce que la loi Résilience impose
Environ 15 000 entités françaises seront soumises à ses obligations : gestion des risques cyber, enregistrement auprès de l'ANSSI, notification d'incidents dans des délais stricts, et audits périodiques. Les sanctions peuvent atteindre 10 millions d'euros ou 2 % du chiffre d'affaires mondial, selon le montant le plus élevé.
L'ANSSI, autorité nationale compétente pour NIS2, ne chôme pas. En 2026, l'agence traite plus de 2 500 signalements d'incidents significatifs chaque mois, soit une hausse de 67 % par rapport à 2024. Ce contexte d'intensification des menaces donne tout son poids aux dispositions techniques du projet de loi.
Article 16bis : ce qu'il dit exactement
L'article 16bis, introduit par amendement sénatorial à l'initiative du sénateur Olivier Cadic, pose une règle simple : aucune autorité publique ne peut contraindre un fournisseur de services de chiffrement à intégrer une porte dérobée dans son produit. Ce verrou s'applique aux fournisseurs établis en France ou dont les services sont utilisés par des entités soumises à NIS2.
La disposition repose sur une conviction partagée par la majorité des experts cyber : un chiffrement affaibli le reste pour tout le monde. Un backdoor accessible aux services de renseignement français l'est aussi, tôt ou tard, pour un État étranger ou un acteur malveillant. La logique est celle du tout ou rien. Soit un canal chiffré est intègre, soit il ne l'est pas.
La fracture avec les services de renseignement
La Direction générale de la Sécurité intérieure (DGSI) et certains parlementaires voient les choses autrement. Ils soutiennent que l'article 16bis, s'il est maintenu, réduira durablement les capacités d'interception légale sur le territoire national.
Le débat rejoint la controverse mondiale sur le chiffrement de bout en bout. Plusieurs pays ont tenté, avec un succès limité, d'imposer des accès réservés aux autorités : le Royaume-Uni avec l'Online Safety Act, l'Australie avec l'Assistance and Access Act. En France, la position de l'ANSSI a historiquement été favorable à un chiffrement fort, sans affaiblissement réglementaire. Cette cohérence de doctrine se retrouve dans l'article 16bis.
Ce que ce texte ne fait pas
L'article 16bis ne couvre pas vos fournisseurs américains. Si vos données transitent par des services cloud soumis au CLOUD Act américain — adopté en 2018 et toujours en vigueur —, la législation américaine prévaut sur la loi française. Un fournisseur américain peut être contraint, via une ordonnance d'un tribunal fédéral, de livrer des données ou de faciliter un accès, indépendamment de ce que dit la loi Résilience.
Ce point est essentiel. Croire que l'article 16bis vous protège parce que votre équipe utilise un service américain chiffré de bout en bout est une illusion juridique. La protection s'arrête aux frontières de la juridiction française. Elle vaut pour les fournisseurs établis en France ou dans l'Union européenne, non pour ceux dont le siège est aux États-Unis, en Chine ou hors de l'UE.
Ce que cela change concrètement pour votre RSSI
Première implication : vos choix d'architecture de chiffrement disposent d'un ancrage législatif explicite. Si un fournisseur de solution de chiffrement souhaite répondre au marché français des entités NIS2, il ne peut légalement pas être contraint d'affaiblir son produit. C'est un argument solide dans vos discussions avec les prestataires, notamment pour négocier des clauses contractuelles portant sur l'intégrité cryptographique du service.
Deuxième implication : la distinction juridiction française et juridiction étrangère doit entrer dans votre cartographie des risques de traitement. Pour chaque service de chiffrement que vous utilisez, il convient d'identifier la loi applicable au fournisseur. Un service SaaS européen hébergé en Irlande n'est pas soumis aux mêmes contraintes qu'un service américain hébergé en Virginie, même si les deux affichent « chiffrement de bout en bout » dans leur documentation commerciale.
Troisième implication : l'article 16bis renforce l'argument pour une architecture de type Zero Knowledge dans vos environnements critiques. Si vos données les plus sensibles ne peuvent être déchiffrées que par vous, le fournisseur ne peut rien livrer, même sous contrainte légale. Les solutions qui séparent gestion des clés et hébergement des données permettent de réduire cette dépendance à la juridiction du prestataire.
Un exemple concret
Une collectivité territoriale soumise à NIS2 utilise un service de messagerie sécurisée opéré par un éditeur français. En vertu de l'article 16bis, cet éditeur ne pourra pas être contraint d'intégrer un accès exceptionnel. La collectivité dispose d'une garantie légale sur l'intégrité du canal chiffré.
La même collectivité utilise par ailleurs une suite collaborative américaine, même chiffrée de bout en bout. Cette solution reste potentiellement accessible via le CLOUD Act, quelle que soit l'architecture déclarée. Le niveau de protection n'est pas équivalent, même si les deux produits annoncent les mêmes fonctionnalités dans leur fiche commerciale.
Cette distinction — fournisseur français ou européen contre fournisseur américain, même promesse, garanties différentes — doit figurer dans votre analyse de risque et dans votre politique de classification des données.
Ce qui reste à construire
L'article 16bis ne règle pas seul la question de la souveraineté numérique. Il pose un interdit légal, mais la mise en oeuvre dépend de vos choix d'architecture. Un interdit légal ne remplace pas une clé de chiffrement bien gérée ni une politique de délivrance et de rotation robuste.
La cryptographie post-quantique, que l'ANSSI recommande d'anticiper dès maintenant dans vos projets pluriannuels, apporte une couche supplémentaire : un algorithme résistant aux calculateurs quantiques protège vos données contre les attaques futures, qu'un backdoor réglementaire existe ou non. Ces deux sujets sont liés, et votre feuille de route de sécurité devrait les adresser conjointement. Pour comprendre les migrations concrètes à envisager, l'article Cryptographie post-quantique : ce que les organisations doivent faire maintenant détaille les délais et les priorités par type de cryptosystème.
Ce qu'il faut retenir
Si l'article 16bis est maintenu lors de la promulgation de la loi Résilience, vos RSSI disposent d'un levier légal pour résister aux demandes d'affaiblissement du chiffrement adressées à vos fournisseurs français. Ce texte ne résout pas la question des fournisseurs extra-européens. Il ne dispense pas d'une cartographie précise de vos flux de données chiffrées. Il ne protège pas contre les menaces qui n'ont pas besoin de backdoor pour compromettre un système.
Ce qu'il faut engager avant la promulgation : auditer quels fournisseurs de chiffrement entrent dans le périmètre de l'article 16bis, identifier ceux qui n'y entrent pas, et documenter le niveau de garantie réel pour chaque service critique. C'est un travail de cartographie. Il peut commencer maintenant, sans attendre le texte définitif.