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é. Elles ne remplacent aucune mesure interne, mais réduisent l’impact d’une faille sur le site public d’un hôpital — souvent le premier point de contact numérique pour un patient ou un proche.
Analyses cybersécurité passives : Aucun scan de vulnérabilités, aucune tentative d’accès ni d’exploitation. Les contrôles se limitent à la lecture d’informations publiques que tout navigateur ou serveur de messagerie reçoit lors d’une connexion ordinaire au site.
Chargement de la carte…
Au 1er octobre 2026, 47 sites des hôpitaux suisses évalués (Entêtes de sécurité) : 25 appliquent les bonnes pratiques (Mesures de durcissement annoncées par le site à chaque visite, qui protègent l'internaute dans son navigateur).
- Solide25(53%)
- Partiel16(34%)
- À renforcer6(13%)
Ces chiffres disent où en est le périmètre aujourd'hui. L'analyse consolidée montre leur évolution mois après mois et le plan d'action classé par gravité : voir l'analyse consolidée
Historique des évolutions
| Période | Solide | Partiel | À renforcer | Non évalué | Total |
|---|---|---|---|---|---|
| août 2026 | 25 | 16 | 6 | 0 | 47 |
| septembre 2026 | 25 | 16 | 6 | 0 | 47 |
| octobre 2026 | 25 | 16 | 6 | 0 | 47 |
Catalogue des contrôles
Voici le détail de chaque contrôle, regroupé par famille : fichier security.txt, en-têtes HTTP, enregistrements DNS. Une question, ou besoin d'exclure un domaine ? Passez par le formulaire de contact.
Entêtes de sécurité
Mesures de durcissement annoncées par le site à chaque visite, qui protègent l'internaute dans son navigateur.
Guide complet : En-têtes de sécurité HTTP : le guide complet (HSTS, CSP, cookies)
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.
- Le certificat est servi sans ses certificats intermédiaires (chaîne incomplète). Un navigateur de bureau complète souvent la chaîne de lui-même et affiche le site normalement, mais d'autres clients – applications, outils de sécurité, certains mobiles, services automatisés – refusent la connexion.
- Le certificat a expiré : les navigateurs affichent un avertissement de sécurité et la plupart des visiteurs renoncent.
- Le certificat ne couvre pas ce nom de domaine (par exemple certificat émis pour www. seulement, ou certificat générique de l'hébergeur) : les navigateurs affichent un avertissement.
- Le certificat est auto-signé, donc émis par aucune autorité reconnue : les navigateurs affichent un avertissement.
- Le certificat est refusé (non encore valide, révoqué ou non vérifiable) : les clients qui vérifient le certificat refusent la connexion.
- La négociation TLS échoue : le serveur n'accepte probablement que des protocoles ou des chiffrements obsolètes que les clients actuels refusent.
- Aucun service ne répond sur le port HTTPS (443) : le site n'est pas proposé en connexion chiffrée.
- Le serveur interrompt la connexion HTTPS avant de répondre (configuration TLS défaillante, ou pare-feu qui bloque).
- Le site n'est servi qu'en clair (http://) : aucune connexion chiffrée n'est proposée.
- La connexion HTTPS échoue pour une raison technique non classée (message technique conservé dans le détail).
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 de manière permanente (301 ou 308) toute requête HTTP vers l'adresse HTTPS équivalente, dès le premier saut – éviter 302 (temporaire), qui incite le navigateur à retenter en clair lors d'une prochaine visite.
- 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 » (1 an ; 6 mois minimum accepté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 ».
Guide MDN – X-Content-Type-OptionsHEAD-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. Dans les navigateurs récents, la directive CSP « frame-ancestors » prévaut sur X-Frame-Options si les deux sont présentes – le cumul des deux reste recommandé pour couvrir aussi les navigateurs plus anciens.
Ajouter « X-Frame-Options: SAMEORIGIN », ou la directive frame-ancestors dans la politique CSP.
Guide MDN – X-Frame-OptionsHEAD-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=() ».
Guide MDN – Permissions-PolicyHEAD-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 Prod et ServerSignature Off sous Apache, expose_php = Off sous PHP).
Projet OWASP – En-têtes de sécurité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. Analyse passive : seuls les attributs de l'en-tête Set-Cookie renvoyé par la réponse HTTP initiale de la page d'accueil sont examinés, jamais un cookie posé plus tard par du JavaScript ou sur une autre page.
Ajouter les attributs Secure, HttpOnly et SameSite (Lax au minimum) à chaque cookie posé par le site.
Guide MDN – Set-CookieQuestions fréquentes
Ces analyses de cybersécurité sont-elles intrusives ?
Non. Tout ce qui est mesuré ici est public et déjà lu par n’importe quel visiteur ou serveur de messagerie : les en-têtes renvoyés par la page d’accueil, des enregistrements DNS interrogés à chaque courriel reçu, et le fichier security.txt là où il est publié. Aucun test d’intrusion, aucune recherche de vulnérabilité, aucune tentative d’authentification, aucun formulaire soumis. Une seule requête par domaine et par passage sert toutes les familles de contrôles à la fois, et le User-Agent des sondes désigne cette page, pour qu’un exploitant qui inspecte ses journaux sache d’où vient le trafic.
Pourquoi le résultat détaillé des entités n’est-il pas public ?
Publier « tel site n’applique pas telle protection » revient à dresser une liste de cibles, ce qui n’aide personne à corriger. Cette page publie donc des agrégats : combien d’entités appliquent les bonnes pratiques, dans quelles proportions, et comment la situation évolue. La carte montre le verdict de chaque entité, jamais la liste de ses manques. Le fichier security.txt fait exception et reste public car il permet de désigner à qui signaler une faille.
Qui peut consulter le résultat détaillé d’une entité ?
Le responsable de la sécurité des systèmes d’information (CISO) de l’entité concernée, ou de la collectivité dont elle dépend : un CISO cantonal voit son canton et l’ensemble des communes de ce canton, un CISO communal voit sa commune. Des portées sectorielle et nationale existent pour les organisations qui coordonnent plusieurs établissements.
Qui peut obtenir un accès, que voit-il de plus, et comment le demander ?
L’accès est ouvert aux responsables sécurité des entités suivies, sur demande et après vérification. Dans sa portée, un accès approuvé donne le détail contrôle par contrôle, la liste de ce qui reste à corriger, l’historique de chaque entité, une fiche PDF et l’analyse consolidée avec son plan d’action. La demande se fait sur cette page : demander un accès.
Que mesure le score de sécurité et comment est-il construit ?
Chaque contrôle porte un poids et une gravité. Le résultat d’une famille de contrôles est évalué selon trois niveaux : « Solide » à partir de 80 % des points, « Partiel » à partir de 40 %, « À renforcer » en dessous. Deux plafonds s’appliquent ensuite, quel que soit le total : un contrôle critique en échec ramène à « À renforcer », un contrôle critique partiel ou un contrôle majeur en échec interdit de dépasser « Partiel ». Le score global est la moyenne des sondes ayant produit un verdict, sur la même échelle. Ce qui n’a pas pu être mesuré reste « Non évalué » et n’entre pas dans cette moyenne. Pour en savoir plus : le détail des poids et des gravités, contrôle par contrôle.
À quelle fréquence ces données sont-elles mises à jour ?
Chaque périmètre est analysé sur une base mensuelle. La date exacte de la mesure affichée figure en tête des statistiques, plus haut sur cette page, et l’historique en conserve la trace mois après mois. Une correction apportée par une entité apparaît donc au passage suivant, pas le jour même.
Qu’est-ce qu’un en-tête de sécurité HTTP ?
Une consigne que le serveur envoie au navigateur avec chaque page, et que le navigateur applique ensuite pour le compte du visiteur : rester en HTTPS (HSTS), n’exécuter que les scripts d’une liste déclarée (CSP), ne pas réinterpréter le type d’un fichier (nosniff), refuser l’affichage du site dans un cadre invisible (anti-clickjacking), limiter ce qui fuit vers les liens sortants (Referrer-Policy) ou l’accès aux fonctions du navigateur (Permissions-Policy). Ces consignes se règlent sur le serveur web, sans toucher au contenu du site. Rôle de chaque en-tête, priorités et déploiement sans casser le site : le guide complet des en-têtes de sécurité HTTP.
Comment un problème de certificat TLS est-il pris en compte ?
Le contrôle « Connexion chiffrée (HTTPS) » vérifie que le site répond en HTTPS avec un certificat accepté. Quand le certificat est refusé, la cause précise est indiquée avec la correction à apporter, et les autres en-têtes (HSTS, CSP, etc.) sont tout de même mesurés. Une chaîne de certificats incomplète compte comme « Partiel » : un navigateur de bureau complète souvent la chaîne de lui-même et affiche le site, mais d’autres clients (applications, outils de sécurité, certains mobiles) refusent la connexion. Un certificat expiré, émis pour un autre nom ou auto-signé compte comme un échec, car tous les navigateurs affichent alors un avertissement. Le détail de la négociation TLS (version du protocole, émetteur, date d’expiration à venir) n’est pas noté : un certificat se renouvelle aujourd’hui automatiquement toutes les quelques semaines, et surveiller son échéance produirait surtout des alertes qui se corrigent d’elles-mêmes. Un site qui ne répond pas du tout (nom introuvable, délai dépassé) reste « Non évalué » : une panne passagère ne se reproche pas. HTTPS, redirection et HSTS en détail : le guide des en-têtes de sécurité HTTP.