Points clés
- security.txt (RFC 9116) est un fichier standardisé qui indique publiquement un contact et une procédure pour signaler une vulnérabilité.
- DCOD a analysé les 2110 communes et les 26 cantons suisses pour mesurer son adoption.
- 831 communes sur 2110 (39%) publient un security.txt valide ; 39% ont au moins tenté la démarche.
- Les cantons font mieux : 12 sur 26 (46%) ont un fichier valide, 65% en ont publié un sous une forme ou une autre.
- L’adoption semble largement portée par les hébergeurs web plutôt que par une démarche propre de chaque commune.
- Deux cartes interactives, mises à jour régulièrement, sont publiées librement sur dcod.ch, sans exposer les contacts récupérés.
DCOD a analysé les sites officiels de 2110 communes et des 26 cantons suisses pour mesurer l’adoption du security.txt, le standard qui indique comment signaler une faille de sécurité à une organisation. Résultat : seulement 39% des communes en publient un valide, contre 46% des cantons.
Le security.txt, en clair
Concrètement, ce fichier répond à une question simple : si quelqu’un découvre une faille de sécurité sur ce site, à qui le dire, et comment ? Sans lui, un chercheur en sécurité qui tombe sur une vulnérabilité doit deviner un contact – une adresse générique noyée dans un formulaire, ou personne du tout.
Avec lui, la réponse est écrite noir sur blanc, à un endroit standard que n’importe quel outil ou humain peut consulter en quelques secondes : /.well-known/security.txt.
L'essentiel Cybersécurité, IA & Tech
Rejoignez la communauté. 3 fois par semaine, recevez l'analyse des tendances par Marc Barbezat. Pas de spam, juste de l'info.
Un security.txt minimal tient en deux lignes :
Contact: mailto:securite@commune.ch
Expires: 2027-01-01T00:00:00zLa RFC 9116, qui définit ce format depuis 2022, n’impose que ces deux champs : un contact (Contact) et une date d’expiration (Expires), qui oblige à revalider le fichier régulièrement plutôt que de le laisser pourrir avec un contact obsolète. D’autres champs restent possibles – clé de chiffrement, politique de divulgation, langues acceptées – mais demeurent facultatifs.
DCOD détaillait déjà les bénéfices et les limites de cette pratique en 2025, dans Pourquoi adopter security.txt pour signaler les failles plus efficacement – notamment le risque de surcharge par des rapports non sollicités une fois le contact rendu public, et la recommandation de l’OFCS en faveur de cet usage.
Pour objectiver son adoption en Suisse, DCOD a développé deux cartes interactives qui scannent régulièrement les sites officiels des communes et des cantons, et affichent leur statut : valide, présent mais incomplet, expiré, absent, ou injoignable.
46% des cantons suisses savent dire à qui signaler une faille de sécurité. Seulement 39% des communes en font autant.
Les cantons font mieux que les communes
Avec 46% de cantons disposant d’un security.txt valide (12 sur 26), et 65% en ayant publié un sous une forme ou une autre, les cantons suisses font sensiblement mieux que les communes. Un écart logique : les cantons disposent généralement d’équipes IT et sécurité dédiées, quand une petite commune dépend souvent entièrement de son hébergeur web.
Ce dernier point n’est pas anodin. Dans l’échantillon analysé, l’adoption du security.txt semble largement portée par les prestataires d’hébergement plutôt que par une démarche propre de chaque commune : lorsqu’un hébergeur déploie systématiquement un security.txt sur tous les sites qu’il gère, l’ensemble de ses communes clientes en héritent d’un coup. À l’inverse, une commune hébergée ailleurs, sans initiative de son prestataire, reste dépourvue.
831 communes suisses sur 2110
Au global, 831 communes suisses (39%) publient un security.txt valide selon la RFC 9116, avec un contact et une date d’expiration future. En ajoutant les fichiers présents mais incomplets ou expirés, ce sont 44% des communes qui ont au moins tenté la démarche.
Voir si sa commune ou son canton est concerné
Les deux cartes sont librement consultables sur dcod.ch, avec le statut détaillé de chaque commune et canton, sans exposer publiquement les adresses de contact récupérées – une précaution volontaire pour ne pas faciliter leur collecte à des fins de spam.
Les données de correspondance commune-domaine s’appuient sur mxmap, le projet open source de David Huser (licence MIT) qui cartographie déjà les hébergeurs de messagerie des communes suisses. Un grand merci à lui pour cet excellent travail de base, sur lequel DCOD s’est appuyé pour décliner cette cartographie appliquée au security.txt.
Carte des communes suisses : https://dcod.ch/carte-securite-communes-suisses/
Carte des cantons suisses : https://dcod.ch/carte-securite-cantons-suisses/
D’autres outils gratuits de DCOD, dont l’évaluation de maturité Cyber Resilience Act pour les PME, sont disponibles sur https://dcod.ch/outils/
FAQ
Le security.txt est-il obligatoire pour une commune ou un canton suisse ?
Non. Ni la Confédération ni les cantons n’imposent aujourd’hui sa publication. Son adoption progresse par bonne pratique, portée notamment par les hébergeurs qui l’incluent par défaut sur les sites qu’ils gèrent.
Comment savoir si mon propre site en dispose ?
Il suffit d’ajouter /.well-known/security.txt à l’adresse du site dans un navigateur. Si un fichier texte s’affiche avec un champ Contact et un champ Expires en date future, il est valide.
Que signifient « incomplet » et « expiré » sur les cartes DCOD ?
« Incomplet » signale un fichier présent auquel il manque un champ obligatoire, généralement Expires ou Contact. « Expiré » signale un fichier dont la date indiquée dans Expires est déjà passée : la RFC 9116 considère alors qu’il ne doit plus être pris en compte tel quel.
Publier un security.txt comporte-t-il un risque ?
La RFC elle-même le signale : un contact exposé publiquement peut devenir la cible de sollicitations automatisées. C’est pour cette raison que DCOD ne publie pas les adresses de contact qu’il a récupérées sur ses cartes.
Combien de temps faut-il pour en mettre un en place ?
Le dépôt du fichier lui-même se compte en minutes pour une équipe qui gère déjà son hébergement web. Ce qui prend du temps, c’est ce qu’il y a derrière : désigner un contact de sécurité et définir un processus pour traiter les signalements qui arrivent.
Quel est le lien avec le Cyber Resilience Act (CRA) ?
Le CRA européen impose aux fabricants de produits comportant des éléments numériques un canal de signalement des vulnérabilités – une exigence que security.txt permet de formaliser simplement. Les communes et cantons suisses ne sont pas soumis au CRA, mais l’usage du standard progresse dans son sillage.
Serveurs, API, temps de veille...
DCOD est indépendant et sans revenus. Soutenez le site pour l'aider à couvrir ses frais techniques.
