Infrastructures critiques suisses : chiffres clés de cybersécurité, comparaisons et priorités de correction pour cantons, communes, finance et hôpitaux.
Cette analyse consolide les résultats des scans de cybersécurité menés sur les infrastructures critiques suisses. Trois axes mesurés : security.txt (point de contact pour signaler une faille), en-têtes de sécurité, et sécurité e-mail (SPF, DMARC, DNSSEC).
dcod.ch
Cybersécurité • IA • Tech
Observatoire de la cybersécurité des infrastructures critiques suisses
Périmètre
Contrôle
État au 22 septembre 2026 Source : Sites officiels des 26 cantons suisses (curation DCOD).
Entités recensées
26
26 mesurées · 0 inatteignables
Type d'infrastructure critique
Autorités
Parlement, gouvernement, justice, administration
Résultats
Niveau de conformité
Sur l'ensemble des entités mesurées, y compris celles qui ne publient rien.
- Solide 6
- Partiel 15
- À renforcer 5
| Résultat | Entités | % |
|---|---|---|
| Solide | 6 | 23 % |
| Partiel | 15 | 58 % |
| À renforcer | 5 | 19 % |
Comparaison entre domaines
Tous les domaines d'infrastructure critique comparés entre eux, au niveau suisse.
Cantons suisses
Communes suisses
Établissements financiers suisses
Hôpitaux suisses
- Solide
- Partiel
- À renforcer
Comparaison entre cantons
Résultat de chaque canton pour chaque analyse, du meilleur au moins bon sur l'analyse affichée. Seule la bande est affichée, jamais un score ni le détail des contrôles, qui restent réservés au canton concerné.
| Rang | Canton | Score global | security.txt | Entêtes de sécurité | Sécurité e-mail |
|---|---|---|---|---|---|
| 1 | Zoug | Solide | Solide | Partiel | Solide |
| 2 | Genève | Solide | Partiel | Solide | Solide |
| 3 | Berne | Solide | Solide | Solide | Partiel |
| 4 | Vaud | Solide | Solide | Solide | Partiel |
| 5 | Lucerne | Solide | Solide | Solide | Partiel |
| 6 | Glaris | Solide | Solide | Solide | Partiel |
| 7 | Fribourg | Partiel | Solide | Solide | À renforcer |
| 8 | Uri | Partiel | Solide | Partiel | Partiel |
| 9 | Valais | Partiel | Solide | Partiel | À renforcer |
| 10 | Bâle-Campagne | Partiel | Solide | Partiel | À renforcer |
| 11 | Bâle-Ville | Partiel | Partiel | Solide | Partiel |
| 12 | Schwytz | Partiel | Solide | Solide | À renforcer |
| 13 | Argovie | Partiel | Solide | Partiel | Partiel |
| 14 | Saint-Gall | Partiel | Partiel | Partiel | Partiel |
| 15 | Nidwald | Partiel | Solide | Partiel | À renforcer |
| 16 | Tessin | Partiel | Solide | Partiel | Partiel |
| 17 | Neuchâtel | Partiel | Solide | Partiel | À renforcer |
| 18 | Jura | Partiel | Solide | Solide | À renforcer |
| 19 | Obwald | Partiel | Solide | Partiel | À renforcer |
| 20 | Appenzell Rhodes-Extérieures | Partiel | À renforcer | Solide | Partiel |
| 21 | Thurgovie | Partiel | Solide | Partiel | À renforcer |
| 22 | Zurich | À renforcer | Partiel | Partiel | À renforcer |
| 23 | Appenzell Rhodes-Intérieures | À renforcer | À renforcer | Solide | À renforcer |
| 24 | Soleure | À renforcer | À renforcer | Solide | À renforcer |
| 25 | Grisons | À renforcer | Solide | À renforcer | À renforcer |
| 26 | Schaffhouse | À renforcer | À renforcer | Partiel | Partiel |
- Solide
- Partiel
- À renforcer
Comparaison des communes par canton
Part des communes en conformité, par canton – les 26 cantons, du meilleur au moins bon.
1Appenzell Rhodes-Extérieures
2Zoug
3Berne
4Argovie
5Bâle-Campagne
6Saint-Gall
7Lucerne
8Zurich
9Soleure
10Thurgovie
11Vaud
12Grisons
13Glaris
13Nidwald
13Obwald
16Neuchâtel
17Bâle-Ville
17Schwytz
19Appenzell Rhodes-Intérieures
20Genève
20Jura
22Fribourg
22Schaffhouse
24Valais
25Uri
26Tessin
- Solide
- Partiel
- À renforcer
Problèmes à corriger
Types d'erreurs rencontrés, classés par gravité et non par fréquence. La part indique combien d'entités mesurées sont touchées.
| Gravité | Contrôle | Entités | Correction recommandée |
|---|---|---|---|
| Critique | Fichier security.txt publié STXT-PRESENT | Publier un fichier texte à l'adresse /.well-known/security.txt du site, portant une adresse de signalement – de préférence une boîte générique relevée par plusieurs personnes, jamais celle d'une seule. | |
| Critique | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC | Publier, dans la zone DNS du domaine (chez l'hébergeur qui la gère), un enregistrement TXT sur _dmarc.<domaine>, en commençant par « v=DMARC1; p=none; rua=mailto:… » puis en durcissant vers p=reject. | |
| Critique | Expéditeurs de courrier autorisés (SPF) EMAIL-SPF | Publier, dans la zone DNS du domaine (chez l'hébergeur qui la gère), un enregistrement TXT « v=spf1 … -all » listant les serveurs autorisés, terminé par -all. | |
| Critique | Connexion chiffrée disponible (HTTPS) HEAD-HTTPS | Installer un certificat (Let's Encrypt est gratuit et automatisable) et servir le site en HTTPS. | |
| Majeur | Chiffrement SMTP forcé en transit (MTA-STS) EMAIL-MTA-STS | Publier un enregistrement TXT sur _mta-sts.<domaine> (« v=STSv1; id=… »), puis publier le fichier de politique sur https://mta-sts.<domaine>/.well-known/mta-sts.txt avec « mode: enforce » une fois vérifié. | |
| Majeur | Réponses DNS signées et vérifiables (DNSSEC) EMAIL-DNSSEC | Activer DNSSEC chez l'hébergeur de la zone DNS (souvent une simple case à cocher), puis publier l'enregistrement DS chez le registraire. | |
| Majeur | Navigateur forcé à rester en HTTPS (HSTS) HEAD-HSTS | Ajouter l'en-tête « Strict-Transport-Security: max-age=31536000 » (1 an ; 6 mois minimum acceptés). | |
| Majeur | Date de validité renseignée (champ Expires) STXT-EXPIRES date de validité dépassée | Renouveler la date du champ « Expires: » (ISO 8601, par exemple dans un an) et prévoir un rappel avant la prochaine échéance. | |
| Majeur | Date de validité renseignée (champ Expires) STXT-EXPIRES | Ajouter « Expires: » avec une date ISO 8601 future (par exemple dans un an) et penser à la renouveler. | |
| Majeur | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC partiellement configuré « p=none » (surveillance seule) | Passer de « p=none » à « p=quarantine » (mise en quarantaine), puis à terme « p=reject » (rejet) une fois les rapports rua= vérifiés. | |
| Majeur | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC partiellement configuré « p=none » sans « rua= » | Ajouter « rua=mailto:… » à l'enregistrement pour recevoir les rapports d'agrégation : sans eux, impossible de savoir quand durcir vers « p=quarantine » ou « p=reject » sans risquer de bloquer des courriels légitimes. | |
| Majeur | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC partiellement configuré « p=quarantine » | Passer de « p=quarantine » à « p=reject » (rejet) une fois les rapports rua= vérifiés et les faux positifs écartés. | |
| Majeur | Expéditeurs de courrier autorisés (SPF) EMAIL-SPF partiellement configuré se termine par « ~all » | Remplacer « ~all » par « -all » en fin d'enregistrement, une fois les expéditeurs légitimes bien listés (le marquage « ~all » n'est censé être qu'une étape de test). | |
| Majeur | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC partiellement configuré sous-domaines moins protégés | Ajouter ou durcir « sp=reject » pour aligner la politique des sous-domaines sur celle du domaine principal – ou « sp=quarantine » a minima. | |
| Mineur | Rapports d'échec de chiffrement SMTP (TLS-RPT) EMAIL-TLSRPT | Publier un enregistrement TXT sur _smtp._tls.<domaine> (« v=TLSRPTv1; rua=mailto:… »). | |
| Mineur | Autorités de certification restreintes (CAA) EMAIL-CAA | Publier, dans la zone DNS du domaine, un enregistrement CAA listant la ou les autorités autorisées (ex. « 0 issue "letsencrypt.org" »). | |
| Mineur | Clé de chiffrement publiée (champ Encryption) STXT-ENCRYPTION | Ajouter une ligne « Encryption: https://exemple.ch/cle-pgp.asc » pointant vers la clé publique de l'équipe de sécurité. | |
| Mineur | Accès aux fonctions du navigateur limité (Permissions-Policy) HEAD-PERMISSIONS | Ajouter une politique fermant ce qui n'est pas utilisé, par exemple « Permissions-Policy: camera=(), microphone=(), geolocation=() ». | |
| Mineur | Liste des scripts et ressources autorisés (CSP) HEAD-CSP | Définir une politique, en commençant en mode rapport (Content-Security-Policy-Report-Only) pour vérifier qu'elle ne casse rien. | |
| Mineur | Informations limitées vers les liens sortants (Referrer-Policy) HEAD-REFERRER | Ajouter « Referrer-Policy: strict-origin-when-cross-origin ». | |
| Mineur | Cookies protégés (Secure, HttpOnly, SameSite) HEAD-COOKIES | Ajouter les attributs Secure, HttpOnly et SameSite (Lax au minimum) à chaque cookie posé par le site. | |
| Mineur | Fichier accessible avec et sans www STXT-BOTH-VARIANTS | Servir le même fichier sur les deux variantes, ou rediriger l'une vers l'autre. | |
| Mineur | Protection contre l'affichage dans un cadre invisible (anti-clickjacking) HEAD-FRAME | Ajouter « X-Frame-Options: SAMEORIGIN », ou la directive frame-ancestors dans la politique CSP. | |
| Mineur | Type de fichier non réinterprété par le navigateur (nosniff) HEAD-NOSNIFF | Ajouter l'en-tête « X-Content-Type-Options: nosniff ». | |
| Mineur | Langues de contact indiquées (champ Preferred-Languages) STXT-LANGUAGES | Ajouter une ligne « Preferred-Languages: fr, de, it, en » listant les langues acceptées pour le signalement. | |
| Mineur | Numéro de version du logiciel non divulgué HEAD-VERSION | Configurer le serveur pour masquer le numéro de version dans les en-têtes Server et X-Powered-By (souvent ServerTokens Prod et ServerSignature Off sous Apache, expose_php = Off sous PHP). | |
| Mineur | Navigateur forcé à rester en HTTPS (HSTS) HEAD-HSTS partiellement configuré durée (max-age) trop courte | Augmenter max-age à au moins 15552000 (6 mois) – idéalement 31536000 (1 an) avec includeSubDomains. | |
| Mineur | Cookies protégés (Secure, HttpOnly, SameSite) HEAD-COOKIES partiellement configuré | Ajouter les attributs Secure, HttpOnly et SameSite (Lax au minimum) à chaque cookie posé par le site. |
Évolution
Tendance mensuelle de l'ensemble du registre, toutes entités confondues.
| Mois | Solide | Partiel | À renforcer | Entités évaluées |
|---|---|---|---|---|
| 2026-08 | 23 % | 73 % | 4 % | 26 |
| 2026-09 | 23 % | 58 % | 19 % | 26 |
Méthodologie et limites
Les évaluations sont établies à la date d'observation, sur la seule base d'informations publiquement accessibles, collectées de manière passive et sans authentification. Elles ne constituent ni un audit de sécurité, ni un test d'intrusion, ni une certification. Un résultat « solide » ne garantit pas l'absence de vulnérabilité ; un point « à renforcer » n'implique ni compromission, ni manquement à une obligation légale ou contractuelle.