Comparatif sécurité
WordPress ou site statique :
dix critères de sécurité
Un comparatif honnête, critère par critère, y compris là où WordPress garde l’avantage. L’objectif n’est pas de disqualifier un outil, mais de montrer ce que change réellement la suppression du serveur d’exécution.
Le tableau
Dix critères, deux architectures
| Critère de sécurité | WordPress (CMS dynamique) | Site statique pré-généré |
|---|---|---|
| Surface d’attaque exposée | Serveur PHP, base MySQL, thème, et souvent 20 à 40 extensions tierces accessibles depuis Internet. | Des fichiers HTML, CSS et images sur un CDN. Aucun langage serveur ne s’exécute à la requête. |
| Origine des vulnérabilités | La très grande majorité des failles WordPress recensées proviennent des extensions et des thèmes, pas du cœur. | Pas d’extension exécutée en production : le risque disparaît avec le runtime. |
| Injection SQL | Risque permanent : chaque requête publique dialogue avec la base de données. | Structurellement impossible : il n’y a pas de base de données interrogée par le visiteur. |
| Back-office public (/wp-admin, /wp-login.php) | Exposé en permanence, cible de bourrage d’identifiants et de force brute automatisée. | L’édition passe par un CMS headless authentifié, hors du domaine public du site. |
| Charge de mise à jour | Cœur, thème et extensions à patcher en continu ; toute mise à jour peut casser le site en production. | Les dépendances sont mises à jour au moment du build, testées, puis publiées. Le site en ligne ne bouge pas. |
| Défiguration & injection de contenu | Une compromission écrit directement en base : le site est modifié instantanément. | Le contenu servi est un artefact figé, versionné en Git. Toute altération est détectable et réversible en une commande. |
| Résistance aux pics de trafic et au déni de service | Chaque visite consomme CPU et connexions SQL : saturation rapide. | Servi depuis le cache du CDN, en périphérie, sans calcul serveur. |
| Restauration après incident | Restauration base + fichiers, avec risque de porte dérobée résiduelle. | Redéploiement de la version précédente en quelques secondes, contenu bit à bit identique. |
| Fonctionnalités dynamiques | Natives : commentaires, comptes, recherche, formulaires. | Déportées vers des services dédiés et isolés (formulaires, recherche, authentification). |
| Coût d’infogérance annuel | Veille de sécurité, correctifs, sauvegardes, pare-feu applicatif, surveillance. | Hébergement statique souvent gratuit ou marginal, maintenance concentrée sur le build. |
Surface d’attaque exposée
WordPress (CMS dynamique)
Serveur PHP, base MySQL, thème, et souvent 20 à 40 extensions tierces accessibles depuis Internet.
Site statique pré-généré
Des fichiers HTML, CSS et images sur un CDN. Aucun langage serveur ne s’exécute à la requête.
Origine des vulnérabilités
WordPress (CMS dynamique)
La très grande majorité des failles WordPress recensées proviennent des extensions et des thèmes, pas du cœur.
Site statique pré-généré
Pas d’extension exécutée en production : le risque disparaît avec le runtime.
Injection SQL
WordPress (CMS dynamique)
Risque permanent : chaque requête publique dialogue avec la base de données.
Site statique pré-généré
Structurellement impossible : il n’y a pas de base de données interrogée par le visiteur.
Back-office public (/wp-admin, /wp-login.php)
WordPress (CMS dynamique)
Exposé en permanence, cible de bourrage d’identifiants et de force brute automatisée.
Site statique pré-généré
L’édition passe par un CMS headless authentifié, hors du domaine public du site.
Charge de mise à jour
WordPress (CMS dynamique)
Cœur, thème et extensions à patcher en continu ; toute mise à jour peut casser le site en production.
Site statique pré-généré
Les dépendances sont mises à jour au moment du build, testées, puis publiées. Le site en ligne ne bouge pas.
Défiguration & injection de contenu
WordPress (CMS dynamique)
Une compromission écrit directement en base : le site est modifié instantanément.
Site statique pré-généré
Le contenu servi est un artefact figé, versionné en Git. Toute altération est détectable et réversible en une commande.
Résistance aux pics de trafic et au déni de service
WordPress (CMS dynamique)
Chaque visite consomme CPU et connexions SQL : saturation rapide.
Site statique pré-généré
Servi depuis le cache du CDN, en périphérie, sans calcul serveur.
Restauration après incident
WordPress (CMS dynamique)
Restauration base + fichiers, avec risque de porte dérobée résiduelle.
Site statique pré-généré
Redéploiement de la version précédente en quelques secondes, contenu bit à bit identique.
Fonctionnalités dynamiques
WordPress (CMS dynamique)
Natives : commentaires, comptes, recherche, formulaires.
Site statique pré-généré
Déportées vers des services dédiés et isolés (formulaires, recherche, authentification).
Coût d’infogérance annuel
WordPress (CMS dynamique)
Veille de sécurité, correctifs, sauvegardes, pare-feu applicatif, surveillance.
Site statique pré-généré
Hébergement statique souvent gratuit ou marginal, maintenance concentrée sur le build.
Sur dix critères, neuf sont à l’avantage du statique. Le dixième — les fonctionnalités dynamiques natives — est celui que nous traitons en déportant chaque fonction vers un service isolé.
Vecteurs d’attaque
Six attaques classiques, et ce qu’elles deviennent
La différence n’est pas une question de degré de protection. Pour la plupart des vecteurs, la cible disparaît purement et simplement.
Injection SQL
Chaque requête publique dialogue avec MySQL. Un paramètre mal filtré dans une extension suffit.
Aucune base interrogée par le visiteur. Le vecteur n’existe pas.
Exécution de code à distance
PHP s’exécute à chaque requête. Un téléversement mal contrôlé peut déposer un webshell.
Aucun interpréteur côté serveur. Un fichier déposé reste un fichier inerte.
Force brute sur l’administration
/wp-login.php est public et connu de tous les robots. Le bourrage d’identifiants est permanent.
Pas d’administration sur le domaine public. Rien à forcer.
Chaîne d’approvisionnement
Une extension rachetée puis piégée met à jour automatiquement des milliers de sites.
Les dépendances sont figées, vérifiées et intégrées au build, jamais téléchargées en production.
Déni de service applicatif
Quelques requêtes coûteuses saturent CPU et connexions SQL.
Le CDN sert du cache en périphérie. Il n’y a pas de calcul à saturer.
Défiguration
Une écriture en base modifie instantanément les pages servies.
Le contenu est un artefact versionné. Toute altération est détectable et réversible.
Analyse
Ce que le tableau ne dit pas
Un comparatif tabulaire donne l’impression d’un verdict. La réalité mérite quelques nuances, et les poser honnêtement est ce qui distingue un prestataire d’un vendeur.
WordPress n’est pas un mauvais logiciel
Son cœur est audité, corrigé rapidement, et son équipe de sécurité est sérieuse. Le problème n’est pas WordPress : c’est le modèle d’exécution qu’il impose. Faire tourner du code tiers à chaque requête, sur une machine joignable depuis Internet, crée mécaniquement une surface d’attaque que la meilleure hygiène ne fera jamais disparaître — elle peut seulement la surveiller. Or la surveillance est un coût récurrent, et un coût récurrent finit toujours par être arbitré.
Le statique n’est pas magiquement sûr
Un site statique déplace le risque plutôt qu’il ne l’annule. Il faut être clair sur ce qui reste à sécuriser :
- Un site statique mal configuré reste vulnérable : en-têtes absents, secrets committés, dépendances non vérifiées.
- Les services externes appelés (formulaire, recherche, paiement) doivent être durcis individuellement.
- Le compte du fournisseur d’hébergement et le dépôt Git deviennent les nouveaux points sensibles : authentification forte obligatoire.
- Le statique protège la publication, pas votre messagerie ni vos postes de travail.
La bonne nouvelle, c’est que cette liste est courte, stable et auditable. Elle ne s’allonge pas à chaque extension installée par un stagiaire trois ans après la mise en ligne.
Le vrai argument : la charge mentale
Dans nos échanges avec des dirigeants de PME, l’argument qui emporte la décision n’est presque jamais technique. C’est celui-ci : avec un site statique, il n’y a plus rien à surveiller le dimanche soir. Pas d’alerte de mise à jour critique, pas de panique quand une faille d’extension fait le tour de la presse spécialisée, pas de facture de nettoyage après une infection.
C’est aussi un argument économique. Le budget consacré à l’infogérance de sécurité d’un WordPress — pare-feu applicatif, sauvegardes, supervision, interventions — est un coût annuel permanent. La migration est un coût unique.
Comment décider ?
Posez-vous trois questions. Votre site sert-il majoritairement le même contenu à tous les visiteurs ? Vos contenus changent-ils quelques fois par semaine plutôt que plusieurs fois par minute ? Vos fonctions réellement dynamiques tiennent-elles en une liste courte ? Si vous répondez oui trois fois, le statique est la bonne architecture, et la migration se rentabilise en général en moins de deux ans d’infogérance économisée.
Prochaine étape
Sur quel critère votre site est-il le plus exposé ?
L’audit gratuit reprend ces dix critères et les applique à votre site réel, avec la liste nominative des extensions à risque.
Réponse sous 24 h ouvrées · Aucune donnée stockée sur nos serveurs