La transparence en matière de sécurité commence par un simple fichier.
Le security.txt (RFC 9116) permet à un site web d’indiquer publiquement un contact dédié pour signaler une faille de sécurité. Cette carte recense, commune par commune, la présence et la validité de ce fichier sur les sites officiels des ~2 100 communes du pays. Cliquez sur une commune pour voir son statut, son contact de sécurité et la date d’expiration déclarée.
Chargement de la carte…
Au 7 août 2026, 2110 sites évalués sur Communes suisses (security.txt) : 888 appliquent les bonnes pratiques (Point de contact publié pour signaler une faille de sécurité selon le standard RFC 9116).
- Solide 888 (42%)
- Partiel 64 (3%)
- Non évalué 1158 (55%)
| Région | Sites évalués | Bonnes pratiques | % |
|---|---|---|---|
| Canton d'Appenzell Rhodes-Extérieures | 20 | 16 | 80% |
| Canton d'Appenzell Rhodes-Intérieures | 5 | 2 | 40% |
| Canton d'Argovie | 196 | 128 | 65% |
| Canton d'Obwald | 7 | 7 | 100% |
| Canton d'Uri | 19 | 2 | 11% |
| Canton de Berne | 334 | 85 | 25% |
| Canton de Bâle-Campagne | 86 | 40 | 47% |
| Canton de Bâle-Ville | 3 | 0 | 0% |
| Canton de Fribourg | 119 | 25 | 21% |
| Canton de Genève | 45 | 11 | 24% |
| Canton de Glaris | 3 | 3 | 100% |
| Canton de Lucerne | 79 | 48 | 61% |
| Canton de Neuchâtel | 24 | 23 | 96% |
| Canton de Nidwald | 11 | 11 | 100% |
| Canton de Saint-Gall | 75 | 57 | 76% |
| Canton de Schaffhouse | 26 | 6 | 23% |
| Canton de Schwytz | 30 | 20 | 67% |
| Canton de Soleure | 104 | 62 | 60% |
| Canton de Thurgovie | 80 | 59 | 74% |
| Canton de Vaud | 300 | 83 | 28% |
| Canton de Zoug | 11 | 8 | 73% |
| Canton de Zurich | 160 | 140 | 88% |
| Canton des Grisons | 100 | 25 | 25% |
| Canton du Jura | 51 | 4 | 8% |
| Canton du Tessin | 100 | 0 | 0% |
| Canton du Valais | 122 | 23 | 19% |
Catalogue des contrôles security.txt
Le score affiché plus haut agrège quatre contrôles distincts, chacun avec sa propre gravité. Voici le détail de chacun : ce qu’il vérifie, pourquoi il compte, et comment le corriger s’il échoue — la même référence que celle citée dans la colonne « Contrôles à corriger » du tableau par canton.
security.txt
Point de contact publié pour signaler une faille de sécurité selon le standard RFC 9116.
STXT-PRESENTFichier security.txt publiéCritiqueSans point de contact publié, une personne qui découvre une faille ne sait pas à qui l'annoncer et renonce souvent.
Publier un fichier texte à l'adresse /.well-known/security.txt du site.
En savoir plus ↗STXT-CONTACTAdresse de contact valide (champ Contact)MajeurSeul champ obligatoire de la RFC 9116 : c'est lui qui porte l'adresse ou le formulaire de signalement.
Ajouter une ligne « Contact: mailto:security@exemple.ch » (répéter la ligne pour plusieurs contacts, ne pas la renommer).
En savoir plus ↗STXT-EXPIRESDate de validité renseignée (champ Expires)MajeurÉgalement obligatoire : il indique jusqu'à quand l'information de contact est considérée comme à jour.
Ajouter « Expires: » avec une date ISO 8601 future (par exemple dans un an) et penser à la renouveler.
En savoir plus ↗STXT-BOTH-VARIANTSFichier accessible avec et sans wwwMineurUn fichier servi par une seule des deux variantes reste invisible pour qui arrive par l'autre.
Servir le même fichier sur les deux variantes, ou rediriger l'une vers l'autre.
Historique des évolutions
| Période | Valide | Présent (incomplet) | Expiré | Partiel | Absent | Injoignable | Total |
|---|---|---|---|---|---|---|---|
| 2026-07 | 793 | 0 | 59 | 95 | 1143 | 20 | 2110 |
| 2026-08 | 799 | 0 | 57 | 96 | 1135 | 23 | 2110 |
Pour approfondir le sujet
Pourquoi adopter security.txt pour signaler les failles plus efficacement
Simplifiez la réception de rapports de vulnérabilités avec security.txt, un standard clair qui structure le contact entre chercheurs et équipes cybersécurité. Lire la suite
Questions fréquentes
Qu’est-ce qu’un fichier security.txt ?
C’est un fichier texte standardisé (RFC 9116), placé à l’adresse /.well-known/security.txt d’un site web, qui indique publiquement comment signaler une faille de sécurité : contact, politique de divulgation, langue, date d’expiration. Il facilite la divulgation responsable des vulnérabilités.
Comment cette carte est-elle construite ?
Chaque commune est associée au domaine de son site officiel, puis DCOD vérifie automatiquement et régulièrement la présence et la validité d’un fichier security.txt. Les correspondances commune–domaine proviennent du projet open source mxmap. Aucune donnée personnelle n’est collectée.
Que signifient les différents statuts ?
Valide : fichier conforme, avec un contact et une date d’expiration future.
Présent (incomplet) : fichier trouvé mais sans tous les champs requis.
Partiel : fichier trouvé sur une seule des deux adresses du site (avec ou sans « www »), absent sur l’autre.
Expiré : date d’expiration dépassée.
Absent : aucun fichier trouvé. Injoignable : site non accessible au moment de l’analyse.
À quelle fréquence les données sont-elles mises à jour ?
La carte est ré-analysée régulièrement ; la date de la dernière analyse est indiquée sur la carte et dans le fichier de données.
Ces données sont-elles réutilisables ?
Oui. Les résultats agrégés sont publiés en JSON ouvert. Les adresses de contact ne figurent pas dans le fichier public, afin d’éviter leur collecte automatisée à des fins de spam.