Un décalage entre discours et pratique
La collecte de données effectuée sur les domaines publics des principaux acteurs de la sécurité numérique en France met en évidence une contradiction flagrante. Alors que la souveraineté technologique est omniprésente dans les discours, l’hygiène fondamentale des serveurs incluant les politiques CSP, le HSTS ou les politiques de référent reste trop souvent traitée comme un sujet accessoire. L’outil de Mozilla agit ici comme un révélateur sans détour, exposant ce que la communication institutionnelle laisse parfois dans l'ombre.
Trois leviers pour une souveraineté réelle
Réduire cet écart n’impose pas de réinventer la sécurité web. En pratique, trois leviers concrets se dégagent pour les organisations et, surtout, pour les acheteurs publics souhaitant relever le niveau d’exigence technique.
A. Gouvernance et Appels d’Offres
Une première étape structurante consisterait à intégrer un seuil minimal sur l'outil Mozilla Observatory au moins un score B, idéalement B+ au sein des cahiers des charges et des critères d'évaluation. Lorsqu’un acteur se positionne comme protecteur du patrimoine numérique, il est légitime d'attendre qu'il puisse documenter l'état de ses propres surfaces web par des analyses régulières. Si cette exigence ne garantit pas à elle seule la solidité globale d’un fournisseur, elle permet au moins d’écarter les négligences les plus manifestes sur des mécanismes désormais standards.
B. Industrialisation des en-têtes
La sécurité des en-têtes ne devrait plus dépendre d’un réglage manuel effectué au gré des projets. L’enjeu réside dans l’automatisation des protections essentielles CSP robuste, HSTS, X-Content-Type-Options, Referrer-Policy - directement au niveau des couches d’infrastructure (Nginx, Apache, Traefik ou réseaux de diffusion de contenu). En d'autres termes, la configuration sécurisée doit devenir le comportement par défaut, les exceptions devant rester limitées, documentées et techniquement justifiées.
C. Intégration dans les chaînes de déploiement
Le contrôle du score de sécurité doit sortir du registre du diagnostic ponctuel pour entrer dans celui de l’assurance qualité continue. À l'image des tests unitaires ou des contrôles de dépendances, ces analyses trouvent naturellement leur place dans les chaînes d’intégration et de déploiement (CI/CD). Cette approche permet de détecter immédiatement toute régression sur les politiques de sécurité côté navigateur. Dans cette logique, une mise en production pourrait être bloquée si le score descend sous un seuil prédéfini, évitant qu’une dégradation banalisée ne devienne la norme.
Ce que mesure réellement Mozilla Observatory
Pour éviter tout contresens, il convient de préciser la portée réelle d'une évaluation Mozilla Observatory. Cet outil ne remplace pas un audit d'intrusion approfondi, ne traque pas les vulnérabilités métier et ne prétend pas mesurer l'étanchéité globale d'une organisation. Son rôle est plus ciblé : il évalue la mise en œuvre de mécanismes de protection standardisés, interprétés directement par les navigateurs, tels que la Content Security Policy (CSP), le HSTS ou la gestion sécurisée des témoins de connexion (cookies).
Des protections simples, mais structurantes
Parmi les leviers les plus déterminants, la Content Security Policy (CSP) occupe une place centrale. Elle permet au serveur d’indiquer au navigateur quelles sources de scripts ou de styles sont autorisées, réduisant ainsi l'exposition aux injections de scripts côté client (XSS). Lorsqu’elle est absente ou configurée de manière trop permissive, elle perd sa fonction de barrière pour redevenir un simple indicateur décoratif sans utilité réelle.
L’en-tête Strict-Transport-Security (HSTS) joue un autre rôle essentiel : il impose au navigateur l’utilisation exclusive du protocole sécurisé HTTPS, neutralisant les risques de déclassement ou d’interception opportuniste. Enfin, la Referrer-Policy contrôle la quantité d’informations transmises lors des requêtes sortantes, limitant les fuites de contexte de navigation vers des domaines tiers.
Il faut donc percevoir Mozilla Observatory comme un révélateur de sérieux opérationnel plutôt que comme un juge final. Il expose instantanément si les protections sont pensées comme des standards industrialisés ou comme des réglages secondaires traités au fil de l'eau. Dans cette étude, c’est précisément ce qui en fait un outil de comparaison pertinent : il met en lumière le décalage entre l’exigence affichée par la filière et le soin réellement apporté à ses propres vitrines publiques.
Le panel : des écarts nets et des enseignements concrets
L’échantillon retenu pour cette analyse rassemble les acteurs les plus visibles de l'écosystème cyber français - éditeurs, prestataires, plateformes et grands groupes industriels. Sur les 30 domaines initialement sélectionnés, 26 ont fait l'objet d'une exploitation complète. Le constat global est sans appel : la filière manque d’homogénéité. Plutôt qu'un bloc cohérent de sites durcis, nous observons un paysage fragmenté où seuls quelques rares acteurs atteignent l'excellence, suivis d'une traîne importante de configurations défaillantes.
| ACTEUR_CIBLE | SCORE_OBSERVATORY | NOTE | OBSERVATION_CRITIQUE |
|---|---|---|---|
| Koperateur.com | 140/100 | A+ | Score maximal (10/10 tests), CSP durcie |
| YesWeHack.com | 105/100 | A+ | Configuration exemplaire (9/10 tests) |
| I-Tracing / Sekoia | 75/100 | B | Niveau correct, CSP perfectible |
| Eviden / Capgemini | 70-75/100 | B | Zone intermédiaire fonctionnelle |
| Tehtris / Scassi | 50-55/100 | C | Signaux de sécurité incomplets |
| Almond / HarfangLab | 30-35/100 | D | Absence ou faiblesse de la CSP |
| Orange Cyberdefense | 20/100 | F | Défaut de rigueur opérationnelle |
| Thales Group | 05/100 | F | En-têtes et cookies non sécurisés |
Un haut de tableau très restreint
Les résultats les plus probants du panel reviennent à Koperateur.com et YesWeHack, seuls acteurs à atteindre et dépasser la note maximale grâce à des bonus de durcissement (HSTS préchargé, CSP stricte). Ces scores démontrent qu'une structure française peut parfaitement s'aligner sur les standards les plus exigeants sans infrastructure complexe. Derrière ce peloton de tête, un groupe d'acteurs (I-Tracing, Sekoia, Eviden, Capgemini, etc.) se stabilise dans une zone intermédiaire. Pour eux, l'application des protections essentielles est une réalité, bien que la précision des politiques CSP puisse encore être optimisée.
La zone critique : là où le discours s'effrite
C’est dans la moitié basse du panel que le décalage entre l’image institutionnelle et l’exécution technique devient le plus flagrant. Des acteurs tels que Almond, HarfangLab ou Gatewatcher affichent des scores en catégorie D, révélant souvent l'absence totale de Content Security Policy.
Plus préoccupant encore, des noms emblématiques comme Orange Cyberdefense, Wallix, Stormshield ou Thales tombent en catégorie F. Avec des scores compris entre 5 et 20/100, ces sites souffrent de lacunes majeures : absence de CSP, politiques laissées en mode signalement uniquement (non bloquantes) ou cookies dépourvus de drapeaux de sécurité.
Pourquoi autant de sites échouent-ils sur les fondamentaux ?
Le point le plus frappant de cette analyse n’est pas seulement la fréquence des scores médiocres, mais leur répétition autour des mêmes lacunes. D’un domaine à l’autre, les causes sont identiques : une politique de sécurité de contenu (CSP) absente ou trop permissive, des témoins de connexion (cookies) mal encadrés et des protections activées en mode test plutôt qu'en mode restrictif.
La CSP : l’angle mort majeur
La Content Security Policy est le maillon faible le plus récurrent. Plusieurs acteurs (Stormshield, Wallix, Thales Group, Neowave ou Yogosha) sont lourdement sanctionnés pour l'absence totale de consignes envoyées au navigateur. Sans cette directive, le navigateur n'a aucun moyen de distinguer les scripts légitimes des injections malveillantes.
Dans d'autres cas (Sekoia, I-Tracing, Eviden ou Tehtris), la politique existe mais s'avère trop large. L'usage de directives permissives (comme unsafe-inline) ou de sources de données trop vastes améliore le score de façade, mais vide la protection de sa substance réelle.
Le piège du mode "signalement uniquement"
Une autre défaillance subtile concerne les politiques laissées en mode Report-Only. Si ce mode est utile en phase de développement pour tester les blocages sans perturber l'expérience utilisateur, il n'offre aucune protection effective tant qu'il n'est pas transformé en politique restrictive.
Le cas de ITrust est ici révélateur : la sécurité est surveillée mais jamais imposée. Pour un secteur dont la valeur ajoutée repose sur la maîtrise et le contrôle, rester durablement dans cette phase de test pose une question de rigueur opérationnelle.
Ce que ces défauts révèlent de la culture cyber
Pris isolément, chaque écart un cookie mal balisé, une politique CSP trop souple, un HSTS partiel peut sembler anecdotique. Pourtant, leur cumul suggère un défaut d’industrialisation profond. La sécurité des en-têtes n’est manifestement pas encore intégrée comme un invariant dans les modèles d’infrastructure, les chaînes de déploiement continu et les processus de recette.
Les mauvais scores ne trahissent pas une absence de compétence, mais une culture du "presque prêt" ou du "suffisamment bon pour la vitrine". Une approche qui entre en contradiction directe avec l'exigence technique radicale que ces acteurs vendent à leurs propres clients.
Ce que ces résultats disent de la souveraineté numérique
Pris isolément, ces scores pourraient passer pour de simples erreurs de configuration. Toutefois, leur analyse globale révèle une réalité plus profonde : en France, la souveraineté numérique est encore trop souvent perçue sous l'angle de l'offre, des labels ou de l'indépendance vis-à-vis des géants étrangers. Pourtant, elle repose tout autant sur une capacité d'exécution technique irréprochable sur les fondamentaux.
Dans ce contexte, constater que certains acteurs majeurs de la sécurité numérique française sont mal notés sur leurs propres vitrines n'est pas anecdotique. Bien que cela ne disqualifie pas tout un secteur, cela fragilise le récit d’exemplarité nécessaire au discours sur la souveraineté. Avant d’être un argument commercial ou politique, la souveraineté doit d'abord s'incarner dans la rigueur des déploiements les plus visibles.
Conclusion
Cette analyse ne prétend pas que la cybersécurité française serait globalement défaillante, ni qu’un score sur Mozilla Observatory suffirait à juger seul de la solidité réelle d’une organisation. En revanche, elle met en évidence un point aussi simple que préoccupant : sur des mécanismes de sécurité web éprouvés, documentés et relativement simples à industrialiser, une part significative du secteur reste en deçà du niveau d’exigence qu’elle préconise pour ses clients.
La leçon de fond est finalement assez sobre : la souveraineté ne se proclame pas uniquement dans des feuilles de route, des labels ou des discours commerciaux. Elle se vérifie dans les détails visibles, répétables et auditables - ces mêmes détails qu’un navigateur, lui, évalue sans aucune indulgence.
La souveraineté numérique n'est pas une destination, mais une discipline quotidienne. Elle commence par la maîtrise totale de sa propre infrastructure, une approche que nous appliquons rigoureusement pour chaque projet.
Outils & références
- Mozilla HTTP Observatory - Outil d’analyse des en-têtes HTTP et des mécanismes de sécurité visibles côté navigateur, utilisé ici pour établir le panel et comparer les scores observés.
- OWASP Secure Headers Project - Référentiel de bonnes pratiques sur les en-têtes de sécurité HTTP, utile pour interpréter les écarts de configuration et les recommandations de durcissement.
- MDN Web Docs - Documentation technique de référence sur les headers HTTP, la CSP, HSTS, Referrer-Policy et les attributs de cookies.
- Koperateur Consulting - Référence méthodologique complémentaire sur les enjeux de structuration, d’industrialisation et de standardisation des systèmes numériques.
