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).
État au 11 octobre 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 2
- Partiel 11
- À renforcer 13
| Résultat | Entités | % |
|---|---|---|
| Solide | 2 | 8 % |
| Partiel | 11 | 42 % |
| À renforcer | 13 | 50 % |
Détail du contrôle SPF
Qui est autorisé à envoyer du courrier au nom du domaine, indépendamment du reste du résultat.
- Solide 23
- Partiel 2
- À renforcer 1
| Résultat | Entités | % |
|---|---|---|
| Solide | 23 | 88 % |
| Partiel | 2 | 8 % |
| À renforcer | 1 | 4 % |
Détail du contrôle DMARC
Comment le domaine traite le courrier qui échoue aux vérifications SPF/DKIM, indépendamment du reste du résultat.
- Solide 6
- Partiel 18
- À renforcer 2
| Résultat | Entités | % |
|---|---|---|
| Solide | 6 | 23 % |
| Partiel | 18 | 69 % |
| À renforcer | 2 | 8 % |
Comparaison entre domaines
Tous les domaines d'infrastructure critique comparés entre eux, au niveau suisse.
- Solide
- Partiel
- À renforcer
Comparaison des communes par canton
Part des communes en conformité, par canton. Cette vue regroupe l'ensemble des communes de chaque canton : elle ne reflète pas le résultat du site du canton lui-même, dont le score reste réservé aux responsables sécurité concernés.
- 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 | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC | Publier un enregistrement TXT sur _dmarc.<domaine> : commencer par « v=DMARC1; p=none; rua=mailto:dmarc@exemple.ch », analyser les rapports quelques semaines, puis durcir vers « p=quarantine » et enfin « p=reject ». | |
| Critique | Expéditeurs de courrier autorisés (SPF) EMAIL-SPF | Dans la zone DNS du domaine (chez l'hébergeur ou le registraire qui la gère), publier un seul enregistrement TXT commençant par « v=spf1 », qui liste tous les services d'envoi légitimes et se termine par « -all ». Le temps de vérifier que tous les envois légitimes sont bien listés, « ~all » peut servir d'étape. | |
| Majeur | Chiffrement SMTP forcé en transit (MTA-STS) EMAIL-MTA-STS | Publier un enregistrement TXT sur _mta-sts.<domaine> (« v=STSv1; id=… »), puis le fichier de politique sur https://mta-sts.<domaine>/.well-known/mta-sts.txt, d'abord en « mode: testing », puis en « 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 option), puis faire publier l'enregistrement DS chez le registraire du domaine – beaucoup le font automatiquement. | |
| 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:tls-rapports@exemple.ch »). | |
| Mineur | Autorités de certification restreintes (CAA) EMAIL-CAA | Publier dans la zone DNS du domaine un enregistrement CAA qui nomme la ou les autorités utilisées, par exemple « 0 issue "letsencrypt.org" ». |
Pour corriger pas à pas, le guide complet : SPF, DKIM, DMARC : le guide complet de la sécurité des emails
Évolution
Tendance mensuelle de l'ensemble du registre, toutes entités confondues.
| Mois | Solide | Partiel | À renforcer | Entités évaluées |
|---|---|---|---|---|
| 2026-08 | 8 % | 73 % | 19 % | 26 |
| 2026-09 | 8 % | 42 % | 50 % | 26 |
| 2026-10 | 8 % | 42 % | 50 % | 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.