Avant qu’une page ne s’affiche, le serveur qui l’héberge envoie au navigateur une série d’instructions invisibles : les entêtes de sécurité HTTP. Ils décident du niveau de méfiance que le navigateur appliquera au site — chiffrement obligatoire, scripts autorisés, cadres interdits. Cette page mesure ceux que les sites officiels des communes suisses envoient réellement, sur plus de 2 100 sites analysés.
Aucun scan de vulnérabilités, aucune tentative d’exploitation. Ces contrôles se limitent à lire des informations déjà publiques — les mêmes qu’un navigateur ou un serveur de messagerie reçoit de toute façon en se connectant normalement à ce site.
Chargement de la carte…
Au 6 septembre 2026, 2110 sites évalués sur Communes suisses (Entêtes de sécurité) : 586 appliquent les bonnes pratiques (Mesures de durcissement annoncées par le site à chaque visite, qui protègent l'internaute dans son navigateur).
- Solide586(28%)
- Partiel1254(59%)
- À renforcer258(12%)
- Non évalué12(1%)
Catalogue des contrôles
Détail technique de chaque contrôle ci-dessous. Sources : en-têtes HTTP, enregistrements DNS, fichier security.txt. Vérification automatique et périodique (hebdomadaire ou mensuelle selon le jeu de données) par DCOD, dans le cadre d'un observatoire public de la sécurité des sites suisses. Une question, ou besoin d'exclure un domaine ? hello@dcod.ch
Entêtes de sécurité
Mesures de durcissement annoncées par le site à chaque visite, qui protègent l'internaute dans son navigateur.
HEAD-HTTPSConnexion chiffrée disponible (HTTPS)CritiqueSans HTTPS, tout ce qui circule entre le visiteur et le site peut être lu ou modifié en chemin. Ce contrôle vérifie que le site répond correctement en HTTPS, pas la redirection depuis l'ancienne adresse en http://.
Installer un certificat (Let's Encrypt est gratuit et automatisable) et servir le site en HTTPS.
En savoir plus ↗HEAD-REDIRECTRedirection automatique vers HTTPSMajeurSans redirection, un visiteur qui tape l'adresse sans https:// reçoit d'abord une réponse en clair : HSTS, qui suppose déjà une première visite réussie en HTTPS, ne peut s'appliquer qu'après.
Configurer le serveur pour rediriger (301 ou 302) toute requête HTTP vers l'adresse HTTPS équivalente, dès le premier saut.
- Le port 80 répond directement (le contenu est servi en clair) au lieu de rediriger vers l'adresse HTTPS.
- Une redirection a bien lieu, mais pas vers une adresse en https:// (ou sans indiquer de destination) : le premier échange reste en clair malgré tout.
HEAD-HSTSNavigateur forcé à rester en HTTPS (HSTS)MajeurIndique au navigateur de n'utiliser que HTTPS pour ce site, y compris si le visiteur tape l'adresse sans https://.
Ajouter l'en-tête « Strict-Transport-Security: max-age=31536000 » (6 mois minimum recommandés).
- Aucun en-tête Strict-Transport-Security n'est envoyé : le navigateur n'est jamais forcé à rester en HTTPS pour ce site.
- L'en-tête est présent mais sans durée (max-age) exploitable : le navigateur ne peut pas retenir la consigne.
- La durée annoncée (max-age) est inférieure à 6 mois : la mesure existe, mais une visite un peu espacée suffit à la faire expirer.
HEAD-CSPListe des scripts et ressources autorisés (CSP)MineurLimite les scripts et ressources que la page a le droit de charger, ce qui réduit fortement l'impact d'une injection de code.
Définir une politique, en commençant en mode rapport (Content-Security-Policy-Report-Only) pour vérifier qu'elle ne casse rien.
- Aucune politique de sécurité de contenu n'est envoyée, ni en mode appliqué ni en mode rapport.
- La politique publiée est en mode « rapport seul » (Content-Security-Policy-Report-Only) : elle observe les violations sans encore en bloquer aucune.
HEAD-NOSNIFFType de fichier non réinterprété par le navigateur (nosniff)MineurEmpêche le navigateur de deviner le type d'un fichier, et donc d'exécuter comme script un contenu qui n'en est pas un.
Ajouter l'en-tête « X-Content-Type-Options: nosniff ».
En savoir plus ↗HEAD-FRAMEProtection contre l'affichage dans un cadre invisible (anti-clickjacking)MineurEmpêche un site tiers d'afficher les pages du site dans un cadre invisible pour faire cliquer l'internaute à son insu.
Ajouter « X-Frame-Options: SAMEORIGIN », ou la directive frame-ancestors dans la politique CSP.
En savoir plus ↗HEAD-REFERRERInformations limitées vers les liens sortants (Referrer-Policy)MineurContrôle les informations d'origine transmises aux sites tiers lorsqu'un visiteur suit un lien sortant.
Ajouter « Referrer-Policy: strict-origin-when-cross-origin ».
- Aucun en-tête Referrer-Policy n'est envoyé : le navigateur applique son comportement par défaut, qui varie d'un navigateur à l'autre.
- La politique publiée est « unsafe-url » : l'adresse complète (chemin compris) est transmise à chaque site tiers lié, y compris depuis une page en HTTPS vers un lien en HTTP.
HEAD-PERMISSIONSAccès aux fonctions du navigateur limité (Permissions-Policy)MineurDéclare quelles fonctionnalités du navigateur (caméra, micro, géolocalisation) la page peut solliciter.
Ajouter une politique fermant ce qui n'est pas utilisé, par exemple « Permissions-Policy: camera=(), microphone=(), geolocation=() ».
En savoir plus ↗HEAD-VERSIONNuméro de version du logiciel non divulguéMineurUn numéro de version précis (Apache/2.4.41, PHP/7.4.3…) permet à un attaquant de cibler directement les failles connues de cette version, sans avoir à les chercher.
Configurer le serveur pour masquer le numéro de version dans les en-têtes Server et X-Powered-By (souvent ServerTokens/ServerSignature sous Apache, expose_php sous PHP).
En savoir plus ↗HEAD-COOKIESCookies protégés (Secure, HttpOnly, SameSite)MineurSans l'attribut Secure, un cookie peut être intercepté si le site est un jour accédé en clair. Sans HttpOnly, un script injecté peut le lire. Sans SameSite, il est envoyé vers des sites tiers qui n'en ont pas besoin.
Ajouter les attributs Secure, HttpOnly et SameSite (Lax au minimum) à chaque cookie posé par le site.
En savoir plus ↗Comment la situation évolue-t-elle ?
| Période | Solide | Partiel | À renforcer | Non évalué | Total |
|---|---|---|---|---|---|
| 2026-07 | 0 | 0 | 0 | 0 | 0 |
| 2026-08 | 578 | 1267 | 257 | 8 | 2110 |
| 2026-09 | 586 | 1254 | 258 | 12 | 2110 |
Questions fréquentes
Ma commune a un site récent : est-il forcément bien configuré ?
Pas nécessairement. Les entêtes de sécurité ne sont presque jamais activés par défaut, y compris sur les hébergements et les systèmes de gestion de contenu récents. Un site refait l’an dernier peut n’en envoyer aucun, sans que cela se voie ni ne gêne son fonctionnement.
Qui doit s’en occuper dans une commune ?
La personne ou l’entreprise qui administre le serveur web, pas celle qui rédige le contenu. C’est une modification de configuration technique, indépendante du travail éditorial et sans conséquence sur l’apparence du site.
Combien de temps cela représente-t-il ?
Pour les entêtes sans risque, quelques minutes de configuration valables pour tout le site. La Content-Security-Policy demande davantage : plusieurs jours d’observation en mode rapport avant de l’appliquer, afin de vérifier qu’elle ne bloque rien de légitime.
Faut-il payer pour cela ?
Non. Ces entêtes sont des paramètres de configuration standards, disponibles sur tous les serveurs web courants. Ils ne nécessitent ni licence, ni logiciel, ni service supplémentaire.
Pourquoi certains sites communaux sont-ils « non évalués » ?
Parce que le site n’a pas répondu au moment de l’analyse — nom de domaine qui ne résout plus, hébergement indisponible, délai dépassé. Aucun entête ne peut alors être observé, et la commune n’est pas pénalisée pour autant. À ne pas confondre avec une commune dont le résultat est simplement réservé : la carte distingue les deux au clic.
Qui peut consulter le résultat d’une commune en particulier ?
Les chiffres d’ensemble de cette page sont publics, canton par canton : combien de communes appliquent les bonnes pratiques, et comment la situation évolue. Le résultat détaillé d’une commune donnée, en revanche, est réservé aux responsables de la sécurité des systèmes d’information (CISO) des cantons et des communes.
Un CISO qui obtient un accès voit en clair son canton et l’ensemble des communes de ce canton — la maille à laquelle l’action collective se décide — et les autres cantons en vue agrégée. Le fichier security.txt fait exception et reste public sans condition : son objet même est d’être trouvé par qui cherche à signaler une faille.
Pourquoi le résultat détaillé d’une commune n’est-il pas public ?
Le résultat individuel de chaque entité est réservé aux responsables de sécurité (CISO) des cantons et des communes.
Qui peut obtenir un accès, et que voit-il de plus ?
Les responsables de sécurité des cantons et des communes suisses, sur demande et après validation manuelle. Un accès couvre tout un canton : le CISO cantonal et celui d’une commune de ce canton voient exactement la même chose, à savoir le détail du canton et de toutes ses communes. Les autres cantons restent en vue agrégée, ce qui permet la comparaison sans exposer personne.
Une zone grise sur la carte signifie-t-elle que la commune n’est pas évaluée ?
Pas nécessairement. Le gris couvre deux situations, que la carte distingue au clic : soit la mesure n’a pas pu se faire — site injoignable, domaine qui ne résout plus — soit la commune est bien évaluée mais son résultat individuel est réservé. Dans ce second cas, la carte affiche à la place le résultat agrégé du canton auquel elle appartient.