Launch is day one. Pour la sécurité aussi.

Le code que vous n’avez pas écrit

Un site d’entreprise moderne est rarement écrit de zéro. Il repose sur un CMS, des extensions, des bibliothèques JavaScript, des paquets PHP, des services tiers pour les formulaires, l’analytics ou les cartes. Une installation courante mobilise des centaines de dépendances, dont la plupart ne sont jamais lues par l’équipe qui les déploie.

L’OWASP, la fondation de référence en sécurité applicative, a pris acte de cette réalité. Dans son Top 10 présenté en novembre 2025, la catégorie « Software Supply Chain Failures » apparaît en troisième position. Elle élargit l’ancienne catégorie des composants vulnérables ou obsolètes à l’ensemble de la chaîne : dépendances, systèmes de build, pipelines d’intégration et de déploiement, mécanismes de mise à jour. Autre signal, la mauvaise configuration de sécurité monte à la deuxième place, juste derrière les défauts de contrôle d’accès.

Ces deux catégories ont un point commun. Elles relèvent moins d’une ligne de code mal écrite que de la manière dont un système est assemblé, configuré et maintenu.

Quand une dépendance devient un vecteur

Septembre 2025 en a fourni une démonstration à grande échelle. Un ver baptisé Shai-Hulud s’est propagé dans npm, le registre de paquets JavaScript. Après avoir compromis le compte d’un mainteneur, il publiait des versions piégées de ses paquets, récupérait les jetons d’accès et les clés présents sur les postes des développeurs et dans les pipelines, puis utilisait ces accès pour infecter d’autres paquets. L’agence américaine de cybersécurité CISA a fait état de plus de 500 paquets compromis. Plusieurs éditeurs de sécurité ont ensuite documenté une seconde vague, fin novembre.

La leçon dépasse l’écosystème JavaScript. Toute plateforme qui installe automatiquement la dernière version d’un composant fait implicitement confiance à la sécurité du compte de chaque mainteneur de la chaîne. Les mesures de protection sont connues et peu spectaculaires : verrouiller les versions, examiner les mises à jour avant de les déployer, limiter les secrets accessibles aux pipelines, imposer l’authentification forte sur les comptes de publication et de déploiement.

Ce que la loi exige déjà en Suisse

Depuis le 1er avril 2025, la loi sur la sécurité de l’information impose aux exploitants d’infrastructures critiques de signaler les cyberattaques à l’Office fédéral de la cybersécurité (OFCS) dans les 24 heures suivant leur découverte. Le périmètre est large : énergie, eau potable, transports, santé, finance, mais aussi autorités cantonales et communales. Les informations manquantes peuvent être complétées dans un délai de 14 jours. Depuis le 1er octobre 2025, l’absence de signalement est passible d’une amende pouvant atteindre CHF 100’000. Après six mois, l’OFCS avait reçu 164 signalements.

La loi sur la protection des données, révisée et en vigueur depuis septembre 2023, impose de son côté d’annoncer au Préposé fédéral (PFPDT), dans les meilleurs délais, toute violation de la sécurité des données susceptible d’entraîner un risque élevé pour les personnes concernées.

Concrètement, une organisation doit pouvoir répondre vite à trois questions après un incident : que s’est-il passé, quelles données sont touchées, qui doit être informé. Sans journalisation exploitable ni procédure écrite, 24 heures passent très vite.

Le Cyber Resilience Act, ou le logiciel traité comme un produit

Dans l’Union européenne, le Cyber Resilience Act (règlement (UE) 2024/2847) a franchi une première étape. Depuis le 11 septembre 2026, les fabricants de produits comportant des éléments numériques doivent signaler les vulnérabilités activement exploitées et les incidents graves via la plateforme unique de l’ENISA, ouverte le même jour. Les délais sont serrés : une alerte précoce sous 24 heures, une notification complète sous 72 heures, puis un rapport final.

Le règlement vise les logiciels et matériels mis sur le marché européen : applications, logiciels téléchargeables, objets connectés, composants commercialisés. Un site web exploité comme un service n’est en principe pas un « produit » au sens du texte. En revanche, une application mobile, une extension vendue ou un logiciel livré à des clients européens peuvent l’être. Les fabricants suisses qui vendent dans l’UE portent les mêmes obligations que leurs concurrents européens. L’application complète du règlement, avec le marquage CE, interviendra le 11 décembre 2027.

Pour les éditeurs et les agences qui développent des produits numériques, la question devient très pratique : pour chaque produit, qui porte le rôle de fabricant, et qui assure le suivi des vulnérabilités pendant toute la durée de support ?

Ce que cela change pour une plateforme web

Même hors du champ du Cyber Resilience Act, ces textes dessinent une norme de fait. On attend d’une plateforme sérieuse qu’elle connaisse ses composants, qu’elle les maintienne et qu’elle sache réagir. En pratique, cela se traduit par quelques livrables concrets.

• Un inventaire à jour des composants et de leurs versions, idéalement sous forme de SBOM (software bill of materials) généré à chaque build.

• Une politique de mises à jour planifiée, avec un délai défini pour les correctifs de sécurité et un environnement de test pour les valider.

• Une configuration durcie et vérifiée : en-têtes de sécurité, droits minimaux, comptes d’administration nominatifs protégés par une authentification forte.

• Une journalisation et une surveillance qui permettent de reconstituer un incident.

• Une procédure d’incident écrite, avec les contacts, les rôles et les obligations de signalement applicables.

• Des sauvegardes dont la restauration est réellement testée.

Aucune de ces mesures n’est nouvelle. Ce qui change, c’est qu’elles ne peuvent plus être reportées à « après le lancement ». Une plateforme publique est exposée dès sa mise en ligne, et le cadre légal suppose désormais que ces réflexes existent.

Cet article présente un cadre général et ne constitue pas un avis juridique.

Questions fréquentes

Mon site d’entreprise est-il concerné par le Cyber Resilience Act ?

Un site exploité comme un service n’est en principe pas un produit au sens du règlement. Les applications, logiciels ou extensions mis sur le marché de l’UE peuvent l’être, y compris lorsqu’ils sont développés en Suisse. Une analyse au cas par cas reste nécessaire.

Qui doit signaler une cyberattaque à l’OFCS ?

Les exploitants d’infrastructures critiques définis par la loi sur la sécurité de l’information, dont les autorités cantonales et communales, dans un délai de 24 heures. Les autres organisations peuvent signaler un incident de manière volontaire.

Qu’est-ce qu’un SBOM ?

Une nomenclature logicielle : la liste des composants, bibliothèques et versions qui constituent une application. Elle permet de savoir rapidement si une vulnérabilité nouvellement publiée vous concerne.