L'état de la sécurité WordPress en 2026 : enseignements de 10 000 audits
Données agrégées et anonymisées — les chiffres que tout freelance et toute agence devraient connaître avant de parler sécurité à leurs clients.
- 72 % des sites WordPress exposent leur numéro de version publiquement — une donnée triviale à corriger qui facilite le ciblage par les attaquants
- Les vulnérabilités de plugins représentent 52 % de l'ensemble des problèmes de sécurité WordPress identifiés lors des audits
- La plupart des corrections prennent moins de 30 minutes — le problème n'est pas la complexité technique, c'est la visibilité
En auditant des milliers de sites WordPress, des patterns émergent. Pas des théories — des chiffres. Des URLs réelles, des configurations réelles, des erreurs réelles qui se répètent de manière prévisible d'un site à l'autre.
Cet article présente les données agrégées et anonymisées issues de l'analyse de sites WordPress en 2026. L'objectif n'est pas de pointer du doigt des propriétaires de sites, mais de documenter l'état réel de la sécurité WordPress dans la pratique — loin des discours marketing et des check-lists génériques.
Pour les freelances et les agences web, ces chiffres sont de l'or. Ils transforment une conversation abstraite sur la "sécurité" en arguments factuels, concrets, difficiles à ignorer pour un client potentiel.
Vue d'ensemble : WordPress, cible principale du web
WordPress représente 62,8 % du marché des CMS en 2026. C'est à la fois sa force et sa faiblesse : l'omniprésence de WordPress en fait la cible numéro un des acteurs malveillants automatisés.
Les mises à jour automatiques du cœur WordPress ont considérablement amélioré la sécurité du noyau depuis WordPress 5.5. La grande majorité des sites core sont maintenant à jour. Le problème s'est déplacé — vers les plugins, les thèmes, et les configurations.
La réalité des sites audités : la plupart sont "suffisamment sécurisés" au sens où ils n'ont pas encore été compromis. Mais "pas encore compromis" n'est pas la même chose que "sécurisé". Les vecteurs d'attaque sont ouverts, attendant simplement qu'un bot automatisé les trouve.
Le secteur de l'hébergement joue un rôle majeur. Les sites sur des hébergements mutualisés bas de gamme montrent systématiquement plus de problèmes de configuration que ceux sur des hébergements managés ou des VPS dédiés. La corrélation est forte et constante.
Les 5 problèmes de sécurité les plus fréquents
Parmi tous les tests de sécurité exécutés lors de nos audits, cinq problèmes reviennent de manière statistiquement dominante. Voici les chiffres, avec ce qu'ils signifient concrètement.
1. Version WordPress exposée — 72 % des sites
La balise meta generator, le fichier readme.html et l'en-tête X-Powered-By révèlent souvent la version exacte de WordPress installée. Pour un attaquant, c'est le premier filtre : « ce site tourne sur WP 6.4.2, voici les CVEs connues pour cette version ». Correction : supprimer la balise generator via functions.php, renommer ou bloquer readme.html et install.php.
2. Plugins obsolètes avec CVEs connues — 48 % des sites
Près de la moitié des sites audités ont au moins un plugin avec une vulnérabilité connue et documentée dans les bases de données CVE. La durée médiane depuis la sortie du patch disponible : 47 jours. En d'autres termes : la correction existait depuis 47 jours en moyenne, et personne ne l'avait appliquée.
3. Headers de sécurité absents — 65 % des sites
Content Security Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy — ces headers HTTP sont absents sur deux tiers des sites WordPress audités. Pourtant, leur mise en place ne nécessite que quelques lignes dans le .htaccess ou la configuration nginx. Le rapport effort/protection est exceptionnellement favorable.
4. XML-RPC activé — 78 % des sites
XML-RPC est une API héritée de WordPress qui permet l'exécution de commandes à distance. Elle est activée par défaut et rarement désactivée. Résultat : 78 % des sites exposent un vecteur d'attaque par brute force qui peut exécuter des milliers de tentatives de connexion en une seule requête HTTP via la méthode system.multicall.
5. Listing de répertoires actif — 23 % des sites
Sur un site WordPress sur quatre, la navigation dans les répertoires est activée sur le serveur. Cela permet à n'importe qui de lister le contenu de /wp-content/uploads/, /wp-content/plugins/ et d'autres dossiers sensibles. C'est une ligne dans le .htaccess : Options -Indexes.
SSL & HTTPS : presque là, mais pas tout à fait
Performance et sécurité : les deux faces du même problème
Un angle souvent négligé : les sites lents et les sites non sécurisés ont tendance à être les mêmes sites. Ce n'est pas une coïncidence — c'est une corrélation causale.
Un TTFB élevé (Time To First Byte supérieur à 1 seconde) indique généralement un hébergement mutualisé bas de gamme surchargé. Ces hébergements ont aussi souvent des configurations PHP et serveur par défaut qui n'appliquent pas les bonnes pratiques de sécurité : expose_php activé, open_basedir trop permissif, pas de ModSecurity.
Les pages lourdes — plus de 4 Mo — sont souvent le signe d'un site dont la maintenance est minimale. Et un site non maintenu depuis 6 mois a, en moyenne, 3 fois plus de probabilité d'avoir des plugins avec CVEs connues qu'un site mis à jour régulièrement.
En résumé : quand vous auditez la performance d'un site, vous obtenez aussi des signaux sur son niveau de maintenance — et donc sur son niveau de sécurité. C'est pourquoi Orilyt combine les tests de performance et de sécurité dans un audit unifié.
Le gap de maintenance : le vrai problème
Parmi les sites audités, une proportion significative n'avait pas été mise à jour depuis plus de 6 mois. Plugins, thèmes, cœur WordPress — pas de mise à jour depuis au moins 180 jours.
La corrélation entre l'absence de contrat de maintenance et les scores de sécurité faibles est forte et constante. Les sites avec un prestataire actif ont des scores de sécurité significativement meilleurs, non pas parce que le prestataire fait des miracles, mais parce que les mises à jour régulières éliminent mécaniquement la grande majorité des vulnérabilités connues.
Pour les freelances, cette donnée est un argument commercial direct : "Sans contrat de maintenance, votre site a X % de probabilité d'avoir une vulnérabilité connue non corrigée dans les 6 mois." Ce n'est pas une hypothèse — c'est un chiffre issu de données réelles.
Les clients qui ont subi une attaque ou un piratage sont quasi universellement réceptifs. Les clients qui n'ont jamais eu de problème sont plus difficiles à convaincre. Les données agrégées permettent de rendre le risque tangible avant qu'il ne se matérialise.
Ce que ça signifie pour les freelances et les agences
Chaque statistique de cet article est un point de départ de conversation avec un client. La différence entre un freelance qui dit "votre site n'est pas sécurisé" et un autre qui dit "72 % des sites WordPress exposent leur version, et le vôtre en fait partie — voici ce que ça signifie concrètement" est immense.
Les données transforment une opinion en constat factuel. Et les constats factuels, documentés, prêts à être présentés, closent des contrats. C'est exactement ce qu'Orilyt produit pour chaque audit : pas un score générique, mais des tests individuels avec des recommandations FIA (Fait, Impact, Action) prêtes à copier-coller dans un rapport client.
L'opportunité concrète : la maintenance récurrente. Un audit révèle des problèmes. Les problèmes nécessitent une maintenance. La maintenance génère des revenus récurrents. Le cycle est simple, mais il faut l'amorcer avec des données qui donnent au client une raison d'agir.
Les chiffres de cet article ne sont pas faits pour effrayer — ils sont faits pour éduquer. Un client éduqué comprend la valeur de votre expertise. Et un client qui comprend la valeur de votre expertise devient un client qui vous paye pour cette expertise.
La check-list des 5 corrections prioritaires
Si vous devez prioriser, voici les 5 actions qui ont le plus d'impact sécurité par rapport au temps investi.
- Masquer la version WordPress : supprimer la balise meta generator, bloquer readme.html et install.php via .htaccess
- Désactiver XML-RPC : une ligne dans functions.php suffit — add_filter('xmlrpc_enabled', '__return_false')
- Ajouter les headers de sécurité : X-Frame-Options, X-Content-Type-Options, Referrer-Policy dans .htaccess ou wp-config
- Mettre à jour plugins et thèmes : activer les mises à jour automatiques pour les mises à jour mineures, planifier les majeures
- Désactiver le listing des répertoires : ajouter Options -Indexes dans le .htaccess racine
La sécurité WordPress en 2026 : une opportunité, pas une fatalité
L'état de la sécurité WordPress en 2026 n'est pas catastrophique — mais il est loin d'être satisfaisant. La grande majorité des problèmes identifiés lors des audits sont des problèmes connus, documentés, avec des corrections simples et rapides.
Le vrai problème n'est pas technique. C'est un problème de visibilité et de priorisation. Les propriétaires de sites ne savent pas que leur version est exposée. Ils n'ont jamais entendu parler de XML-RPC. Ils ne savent pas que leurs headers sont manquants.
C'est là que les freelances et les agences ont un rôle crucial. Pas comme vendeurs de peur, mais comme traducteurs du risque technique en langage business. Et pour traduire, il faut des données. Orilyt fournit les données.