Le 25 septembre 2026, le Conseil fédéral a mandaté le DDPS pour élaborer d’ici juin 2027 un avant-projet de loi fédérale sur la cybersécurité. Ce projet sera soumis à la consultation (voir le communiqué de presse). Ainsi, la Suisse disposerait d’une loi qui imposerait des règles de cybersécurité aux entreprises privées de manière transversale.

Le texte devra aborder trois volets requis par le Parlement : la sûreté des articles numériques (logiciels et matériel), la garde des informations numériques les plus précieuses du pays et le rôle des hébergeurs et des fournisseurs de cloud face aux assauts informatiques. Il intégrera également l’obligation (définie dans la loi fédérale sur la sécurité de l’information) de déclarer les attaques informatiques ciblant les infrastructures critiques, qui est entrée en vigueur le 1er avril 2025.

Je vais tenter de décrire les intentions du projet, son origine et les transformations qu’il apporterait. Je présenterai également brièvement la comparaison avec les deux grands textes européens dont il s’inspire ou qu’il côtoie (le Cyber Resilience Act, CRA ; la directive NIS2), et je terminerai par une opinion.

La décision du Conseil fédéral

Le Conseil fédéral a décidé de fusionner en un seul projet législatif trois initiatives que l’Office fédéral de la cybersécurité (OFCS) développait indépendamment. Chacune d’entre elles devait initialement faire l’objet d’une révision de la loi sur la sécurité de l’information (LSI). Le gouvernement estime qu’ils traitent de domaines connexes (produits, données, infrastructure numérique) et qu’une loi unique assurerait une harmonie globale.

Les rôles seraient répartis de la manière suivante :

  • La LSI resterait la loi qui régit la sécurité de l’information des autorités fédérales.
  • La future loi sur la cybersécurité régirait la cybersécurité chez les tiers (entreprises, exploitants d’infrastructures critiques) et reprendrait l’obligation de signaler les cyberattaques, aujourd’hui logée dans la LSI.
  • Les réglementations sectorielles (loi sur les télécommunications, ordonnance sur l’approvisionnement en électricité, ordonnance sur les installations de télécommunication) resteraient en vigueur. La nouvelle législation ne les renforcerait que pour les responsabilités partagées.

En substance, le communiqué déclare :

  1. des exigences contraignantes pour les fabricants, importateurs et commerçants de produits techniques (logiciels et matériel informatique), une base pour la surveillance du marché et l’interdiction de distribuer des produits peu sûrs ;
  2. une inspiration explicite du Cyber Resilience Act européen, avec l’objectif de maintenir une charge administrative faible ;
  3. des obligations particulières pour la protection des données numériques importantes ;
  4. des obligations pour les fournisseurs d’hébergement et d’informatique en nuage ;
  5. des obligations de collaboration et de défense face aux cybermenaces.

Le gouvernement fédéral avance deux principaux arguments. Premièrement, une éventuelle avancée technologique ou européenne n’exigerait la modification que d’une seule loi. Deuxièmement, les entreprises actives dans l’UE, déjà soumises au CRA, échapperaient à des coûts additionnels grâce à une harmonisation de la législation. Le communiqué mentionne également les logiciels open source comme un sujet qui serait plus facile à réglementer dans une loi unique.

Le DDPS doit présenter un avant-projet en vue d’une consultation d’ici juin 2027.

L’origine de la décision du gouvernement

Le projet répond à trois motions déposées par la Commission de la politique de sécurité (CPS) de chaque chambre. Le Conseil fédéral a proposé de les approuver toutes les trois.

MotionAuteurDépôt/transmissionCe qu’elle demande
23.3002 « Pour une meilleure sécurité des données numériques essentielles de la Suisse »CPS du Conseil des ÉtatsDéposée le 12.01.2023, adoptée par les deux Chambres en 2023Critères pour identifier les données à protéger, normes de gestion de la sécurité, recours si possible à des entreprises suisses pour le stockage
24.3810 « Réalisation de contrôles de cybersécurité urgents et nécessaires »CPS du Conseil des ÉtatsDéposée le 24.06.2024, transmise le 12.12.2024Cadre réglementaire et ressources financières nécessaires pour assurer la sécurité des produits, des applications et des infrastructures liées.
25.3011 « Renforcer le rôle des fournisseurs d’hébergement et d’informatique en nuage dans la lutte contre les cybermenaces »CPS du Conseil nationalDéposée le 27.01.2025, transmise le 09.12.2025Droits et obligations pour lutter contre l’utilisation abusive des hébergements et des infrastructures cloud

Voici, en bref, ce que contiennent ces motions.

Motion 23.3002 : les données essentielles

La motion vise les données numériques de la Confédération, des cantons, des communes et des exploitants d’infrastructures critiques. Toutefois, dans sa réponse du 15 février 2023, le Conseil fédéral a souligné que la LSI ne s’applique aux cantons que s’ils traitent des informations confidentielles de la Confédération ou utilisent ses ressources informatiques. De plus, elle ne couvre pas les exploitants d’infrastructures critiques qui ne dépendent pas de la Confédération. Il a donc déclaré qu’il est nécessaire de préciser quels domaines relèvent de la compétence législative de la Confédération.

Motion 24.3810 : les contrôles de cybersécurité

La commission part d’un constat alarmant : en Suisse, les produits numériques ne sont soumis à aucune norme obligatoire ni à aucune exigence minimale. De plus, aucune responsabilité légale n’est spécifiquement établie pour les logiciels. En réalité, l’application de la loi fédérale sur la responsabilité du fait des produits aux logiciels est un sujet de débat en droit. La commission énumère cinq raisons pour lesquelles les produits ne sont pas testés : l’absence d’incitation pour l’industrie privée ; une mauvaise définition des responsabilités ; l’absence de mandat de l’OFCS ; une réglementation trop tardive et d’origine étrangère ; et des capacités de contrôle insuffisantes.

Elle suggère que les éléments et matériaux essentiels, y compris les cadres de référence et les composants open source largement utilisés, soient constamment repérés et examinés par des entités impartiales. Le Conseil fédéral a approuvé la motion, en indiquant que le financement devrait être assuré par les parties intéressées, par exemple par le biais de redevances.

En août 2025, le Conseil fédéral a transformé cette résolution en un projet de loi sur la résilience numérique des produits, s’inspirant du CRA européen. Une consultation publique était prévue pour l’automne 2026 (communiqué du 20 août 2025).

Motion 25.3011 : hébergeurs et fournisseurs cloud

La commission a constaté que les fournisseurs d’accès à Internet relèvent de la loi sur les télécommunications, contrairement aux hébergeurs et aux fournisseurs de cloud. Par conséquent, il n’y a aucune base légale pour les contraindre à lutter contre l’utilisation abusive de leurs services ni pour leur accorder les droits nécessaires à cet effet. Or, l’OFCS remarque que des attaques contre des cibles suisses sont lancées à partir de points situés en Suisse.

L’obligation de signaler dans la LSI

À compter du 1er avril 2025, les responsables d’infrastructures critiques ont l’obligation légale de signaler toute cyberattaque détectée à l’Office fédéral de la cybersécurité (OFCS) dans les 24 heures suivant son dépistage. Cette exigence est régie par les articles 74a ss de la loi sur la sécurité de l’information (LSI) et précisée par l’ordonnance sur la cybersécurité (OCyS). Aujourd’hui, ce cadre est l’instrument principal de cybersécurité transversal applicable au secteur privé, en parallèle avec l’obligation légale d’annoncer les violations de la sécurité des données au Préposé fédéral à la protection des données et à la transparence (PFPDT), conformément à l’article 24 LPD.

Pour rappel les principaux éléments de ce devoir d’annonce sont les suivants :

  • Qui est visé par le devoir d’annonce : les exploitants d’infrastructures critiques énumérés à l’art. 74b LSI, notamment les établissements financiers, les assureurs et les prestataires de services cloud (cf. CDBF).
  • Quels événements déclenchent une annonce : les cyberattaques qui remplissent les critères de l’art. 74d LSI, à savoir notamment celles qui ont entraîné une manipulation ou une fuite d’informations ou qui n’ont pas été détectées pendant une période prolongée.
  • Dans quel délai procéder à l’annonce : 24 heures après la détection. Si toutes les informations ne sont pas connues, l’OFCS accorde 14 jours pour compléter (CDBF).
  • Quelles sanctions : l’OFCS contacte d’abord l’organisation, puis rend une décision ; il ne dépose une plainte pénale que si celle-ci reste sans effet (art. 74g et 74h LSI), avec à la clé une amende pouvant s’élever jusqu’à 100 000 CHF.

En six mois, 164 cyberattaques contre des infrastructures critiques ont été signalées, et l’OFCS s’est déclaré globalement satisfait du respect du délai de 24 heures (communiqué du 29 septembre 2025).

Le transfert de ce régime vers une future loi suit une certaine logique, car la LSI s’adresse à l’administration fédérale, mais l’obligation de signaler vise aussi d’autres organisations ainsi que des entreprises privées.

Ce qui changerait pour les autorités, les entreprises et le public

Comme aucun texte n’est publié, ce qui suit découle des informations fournies par le Conseil fédéral et des suppositions que je fais.

Pour les autorités

L’OFCS changerait de rôle. Aujourd’hui c’est un centre de compétences, d’alerte et de réception des signalements. Demain, il deviendrait un régulateur transversal du secteur privé, chargé au moins d’une partie de la surveillance du marché des produits numériques. D’ailleurs le Parlement a déjà relevé de 10 millions de francs le budget 2026 de l’office (rapport annuel OFCS 2025).

Le communiqué du gouvernement ne précise pas qui contrôlerait les produits sur le marché. En août 2025, le projet « produits » associait l’OFCS, l’OFCOM et le SECO. Il ne précise pas non plus comment les autorités sectorielles (FINMA, ElCom, OFCOM) s’articuleraient avec l’OFCS.

Pour les entreprises

Trois catégories d’entités seraient directement concernées :

  • Les fabricants, importateurs et distributeurs de produits numériques devraient respecter des exigences de sécurité inspirées du CRA. On peut donc supposer qu’on verra arriver la sécurité dès la conception, la gestion et la correction des vulnérabilités pendant une durée définie, la documentation technique et probablement le signalement des failles activement exploitées.
  • Quant aux hébergeurs et fournisseurs cloud, ils recevraient des obligations, mais aussi des droits, pour agir contre l’utilisation abusive de leurs services (par exemple, bloquer un serveur utilisé pour une attaque). Ceux qui sont déjà des infrastructures critiques au sens de l’art. 74b LSI doivent aujourd’hui signaler les attaques qu’ils subissent. La motion vise l’inverse : les attaques menées depuis leurs infrastructures par des clients ou des tiers, par exemple un serveur loué pour piloter un réseau de machines infectées ou héberger un site d’hameçonnage. Il s’agirait de les obliger à agir contre ces abus et de leur donner une base légale pour le faire.
  • Concernant les exploitants d’infrastructures critiques, ils devraient protéger leurs « données importantes » selon des critères et des normes encore à définir. Ils continueraient à signaler les cyberattaques, mais sur la base de la nouvelle loi.

Indirectement, toutes les entreprises qui achètent des logiciels et du matériel seraient touchées : elles devraient bénéficier de produits plus sûrs et d’informations plus claires sur leur durée de support.

Pour le public

Grâce à la future loi, on devrait avoir moins d’objets connectés vulnérables sur le marché suisse (caméras, routeurs, jouets connectés, etc.), des mises à jour de sécurité garanties et la possibilité d’interdire un produit dangereux. La lutte contre les infrastructures d’attaque hébergées en Suisse devrait aussi réduire certaines campagnes de fraude ou de rançongiciel.

Le revers possible porte sur les coûts. Lors de la préparation du CRA, la Commission européenne estimait les coûts pour l’industrie à environ 29 milliards d’euros, soit un dixième des 290 milliards de pertes annuelles attribuées aux cyberincidents. Elle mentionnait aussi une possible hausse des prix pour les utilisateurs. L’association allemande Bitkom craint que les coûts de certification pèsent surtout sur les petits fabricants et les nouveaux entrants.

Ces effets restent des projections : les exigences de fond du CRA ne s’appliqueront qu’en décembre 2027, et aucun retrait de produits du marché européen lié au CRA n’est documenté à ce jour. Si la Suisse reprend ces exigences, des effets comparables sont possibles, et certains fabricants pourraient juger le marché suisse trop petit pour justifier une conformité spécifique, si elle diverge du CRA.

Comparatif avec le CRA et NIS2

Le texte légal suisse emprunterait de la matière aux deux textes européens à la fois. Le volet « produits » s’inspirerait explicitement du CRA (règlement (UE) 2024/2847). Les volets « données essentielles », « cloud » et « signalement » visent des exploitants et des prestataires, soit le terrain de la directive NIS2 (UE) 2022/2555.

Avec l’aide de l’IA, j’ai créé ce tableau comparatif.

CritèreProjet suisse (annoncé)CRANIS2
NatureLoi fédérale, avant-projet attendu en juin 2027Règlement directement applicableDirective à transposer par les États membres
ObjetUne seule loi pour les produits, les données importantes, le cloud et le signalementSécurité des produits mis sur le marché intérieurSécurité des réseaux et systèmes d’information des entités
DestinatairesFabricants, importateurs et commerçants de logiciels et de matériel ; hébergeurs et fournisseurs cloud ; exploitants d’infrastructures critiques (art. 74b LSI)Fabricants, mandataires, importateurs et distributeurs de produits comportant des éléments numériques ; régime allégé pour les stewards de logiciels open sourceEntités essentielles et importantes de 18 secteurs, en principe les moyennes et grandes entreprises
Obligations de fondAnnoncées sans détail : exigences pour les produits et interdiction des produits peu sûrs, protection des données importantes, mesures contre l’utilisation abusive du cloudExigences essentielles (annexe I), gestion des vulnérabilités pendant une période de support en principe d’au moins cinq ans, évaluation de la conformité, marquage CEMesures de gestion des risques (art. 21), approbation et formation des organes de direction (art. 20)
SignalementRégime LSI repris : cyberattaques contre les infrastructures critiques, 24 h, complément dans les 14 joursVulnérabilités activement exploitées et incidents graves : alerte en 24 h, notification en 72 h, rapport final 14 jours après le correctif (un mois pour un incident)Incidents importants : alerte en 24 h, notification en 72 h, rapport final en un mois
Destinataire du signalementOFCSENISA et CSIRT coordinateur, via la plateforme unique (SRP)CSIRT ou autorité nationale compétente
SanctionsNon annoncées ; régime LSI actuel : amende de 100 000 francs au plus, après une décision de l’OFCS restée sans effetJusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial (exigences essentielles, art. 13 et 14) ; plafonds inférieurs pour les autres manquementsPlafond fixé par chaque État, d’au moins 10 millions d’euros ou 2 % (entités essentielles) et 7 millions ou 1,4 % (entités importantes)
CalendrierConsultation d’ici juin 2027, entrée en vigueur non fixéeSignalement depuis le 11.09.2026, application complète le 11.12.2027Transposition due depuis le 17.10.2024

Ce tableau permet de faire plusieurs constats.

  • L’UE traite la sécurité des produits (CRA, marquage CE) et celle des entités (NIS2) dans deux textes distincts, avec des autorités et des logiques différentes (règlement vs directive). Le projet suisse les rassemble dans une seule loi et y ajoute un volet « données importantes » sans équivalent direct dans ces deux textes.
  • Pour les entités, le communiqué n’annonce aucune obligation générale de gestion des risques comparable à l’art. 21 NIS2. La Suisse conserverait son approche sectorielle (finance, électricité, télécommunications), complétée par l’obligation de signaler. Les groupes suisses actifs dans l’UE restent soumis à NIS2 pour leurs entités européennes.
  • Les plafonds des sanctions européennes se comptent en millions d’euros et en pourcentage du chiffre d’affaires mondial, alors que le régime suisse actuel prévoit au plus 100 000 CHF. Le niveau des sanctions déterminera la crédibilité de la surveillance du marché.
  • NIS2 devait être transposée en 2024 et le CRA s’applique déjà en partie, alors que le projet suisse n’est qu’au stade du mandat d’élaboration. Comme pour la LPD et de nombreux cadres législatifs, la Suisse est à la traine.

Ce qui semble positif avec le projet

Le projet comble une lacune réelle et reconnue par le Conseil fédéral lui-même : en août 2025, il constatait qu’il n’existe en Suisse pratiquement aucune disposition sur la cyberrésilience des produits numériques (communiqué du 20 août 2025). Mais le projet a d’autres effets intéressants.

Le projet amènerait donc une base légale claire pour la sécurité des produits. Les failles dans les logiciels et le matériel sont l’une des principales portes d’entrée des attaques. Imposer des exigences au moment de la mise sur le marché agit en amont, avant que le produit ne soit déployé chez des milliers d’utilisateurs, protège les consommateurs. La possibilité d’interdire un produit peu sûr donne enfin aux autorités un levier dont elles ne disposent pas aujourd’hui.

Une loi unique me semble préférable à une LSI surchargée. Loger des obligations pour le secteur privé dans une loi conçue pour l’administration fédérale aurait probablement brouillé sa lecture. À l’inverse, une loi dédiée rend le droit plus lisible pour les entreprises et plus facile à concrétiser opérationnellement.

Les entreprises suisses qui exportent dans l’UE doivent de toute façon respecter le CRA. Des règles suisses équivalentes leur évitent de construire deux programmes de conformité distincts (CH/UE), et protègent les acheteurs suisses contre les produits refusés ailleurs.

En outre, donner aux hébergeurs des droits et des obligations clairs leur permet d’agir rapidement contre un serveur compromis ou loué par des attaquants, sans craindre de violer leurs engagements contractuels envers le client et d’engager leur responsabilité.

L’obligation de signaler fonctionne bien selon l’OFCS et bénéficie d’une relation de confiance entre l’OFCS et les exploitants. La reprendre telle quelle, plutôt que de la réinventer, préserve cet acquis.

Enfin, le communiqué mentionne expressément les logiciels libres. C’est un sujet délicat (qui est responsable d’un composant maintenu par des bénévoles ?) que le CRA a traité avec la notion de « stewards » (art. 24 CRA). Une loi unique permettrait de faire de même en droit suisse, et une seule fois.

Points d’attention et critiques

Les points ci-dessous ne remettent pas en question l’objectif. Cependant, je souhaiterais évoquer les décisions que la consultation de 2027 devra prendre pour que la loi tienne ses promesses.

Le calendrier

Le projet « produits » devait initialement être soumis à la consultation en automne 2026. Cependant, en raison de sa fusion avec le projet de loi sur la cybersécurité, il a été reporté à juin 2027. Pendant ce temps, le CRA remplit ses obligations de signalement depuis le 11 septembre 2026 et les appliquera entièrement à compter du 11 décembre 2027.

Compte tenu du temps requis pour une procédure législative fédérale (consultation, message, débats dans les deux chambres, ordonnances), l’entrée en vigueur d’une nouvelle loi ne serait pas avant 2029 ou 2030. Durant cette période, le marché suisse pourrait être ouvert à l’importation de produits qui ne sont plus en vente dans l’UE, ou en plus grande quantité qu’actuellement.

Il est possible que les autorités ne suivent pas ce chemin, mais il serait judicieux d’aborder la question des produits en premier ou de prévoir dès l’étape de l’avant-projet une réintégration rapide des exigences du CRA par renvoi.

L’esprit de la motion 24.3810

La proposition exigeait des inspections de sécurité impartiales pour les articles et pièces essentiels, y compris l’open source, grâce à des fonds publics. Le Conseil fédéral l’a traduite en une réglementation de mise sur le marché, financée par des émoluments.

Les deux méthodes sont complémentaires, mais ne sont pas interchangeables. Une réglementation pour la mise sur le marché ne finance pas l’analyse des bibliothèques libres utilisées partout, sans que les fabricants en soient responsables. Il serait donc bénéfique que le gouvernement inclue dans le projet de loi une base pour des programmes de tests ou de recherche sur les vulnérabilités menés ou mandatés par l’OFCS, comme le recommandait la commission.

La compétence constitutionnelle

Le Conseil fédéral l’a lui-même souligné en répondant aux motions 23.3002 et 24.3810 : il est nécessaire d’évaluer dans quelle mesure la Confédération peut établir des règles pour des tiers, y compris les cantons et les communes. En ce qui concerne les produits, il semble justifié de s’appuyer sur les compétences fédérales en matière économique (art. 95 Cst.). Toutefois, imposer des normes de sécurité aux données des cantons et des communes, c’est beaucoup moins évident. Le volet « données essentielles » pourrait être réservé aux autorités fédérales et aux exploitants privés. Les cantons et les communes auraient ainsi la responsabilité d’adapter leurs propres règles, à l’instar de la LPD et des 26 lois cantonales sur la protection des données.

L’accès au marché européen

En reproduisant le CRA, les exportateurs suisses échappent aux règles contradictoires, mais ne sont pas exemptés de se conformer aux exigences européennes. Il serait judicieux d’envisager une harmonisation des évaluations de conformité pour accroître les avantages pour ces exportateurs. L’accord de reconnaissance mutuelle (ARM) entre la Suisse et l’UE concerne actuellement vingt secteurs de produits (voir la fiche d’information). Aucune ressource publique consultée ne suggère que les articles relevant du CRA seront inclus. Cependant, cela pourrait être une option bénéfique à explorer.

Le signalement unique

Une même cyberattaque peut aujourd’hui devoir être annoncée à plusieurs autorités. Par exemple, pour une institution financière suisse, il faudrait informer la FINMA, le PFPDT et l’OFCS, chacun selon des procédures spécifiques. Un fabricant actif dans l’UE ajoutera l’ENISA à la liste, via le CRA. Le communiqué du Conseil fédéral ne mentionne pas l’idée d’un guichet unique, qui serait pourtant très appropriée pour harmoniser les procédures et accélérer les délais en alignant la Suisse sur le modèle européen. Cela pourrait être réalisé en créant un formulaire et un point d’entrée uniques, avec une transmission automatique aux autorités compétentes.

La gouvernance

Selon les données du Parlement, la motion 25.3011 relève du DETEC. Or, le communiqué place le projet sous la direction de l’OFCS (DDPS). Il sera nécessaire de clarifier qui est responsable du contrôle du marché des produits et comment la nouvelle loi s’harmonise avec les régimes existants de la LTC, de la FINMA et de l’ElCom. La définition claire des responsabilités pourrait s’avérer complexe.

Conclusion

La Suisse passerait d’une cybersécurité réglementée principalement pour l’administration fédérale et certains secteurs à une loi transversale qui toucherait les fabricants, les prestataires de services numériques et les exploitants d’infrastructures critiques. Cette approche me semble appropriée : elle comble un manque reconnu, s’appuie sur un système de signalement éprouvé et se conforme au modèle européen. La réussite de cette démarche dépendra de plusieurs décisions à inclure dans l’ébauche initiale : une mise en œuvre rapide par rapport au CRA, une base constitutionnelle solide, une clarification des relations avec les autorités sectorielles, et la préservation de l’ambition initiale des résolutions, en particulier la volonté de contrôles indépendants énoncée dans la motion 24.3810.

En 2027, la consultation sera l’occasion pour les entreprises et les spécialistes de donner leur avis sur ces décisions.