Installer WordPress, ce n’est pas seulement “mettre un fichier en ligne puis cliquer”. Quand on traite la sécurité comme une simple option activée après coup, on finit souvent par colmater des dégâts plutôt que de prévenir les mauvaises surprises. J’ai vu des sites qui tournaient parfaitement, puis qui ont été compromis à cause d’un détail minuscule au départ: un compte administrateur créé trop facilement, une configuration réseau trop ouverte, ou des plugins installés “par confort” sans revue.
L’objectif de ce guide est de vous aider à installer WordPress avec une configuration sécurisée dès le début. On va parler pratiques concrètes, de compromis raisonnables, et de ce que vous pouvez vérifier sans devenir spécialiste de la sécurité.
Commencer par le contexte: qui attaque un site WordPress, et pourquoi ?
WordPress est souvent la cible parce qu’il est populaire. La majorité des tentatives ne cherchent pas votre contenu. Elles cherchent une faille “générique” qui existe sur beaucoup de sites, ou un point faible humain. Très souvent, l’attaque ressemble à ça:
- des identifiants devinés ou “testés” en masse (mots de passe faibles, comptes mal choisis); des scripts automatisés qui parcourent des pages accessibles et tentent des requêtes répétées; des robots qui cherchent des portes ouvertes: formulaires d’administration accessibles sans limitation, exposition directe de fichiers, absence de durcissement de configuration; des plugins et thèmes non maintenus, ou ajoutés sans vérification.
Ce n’est pas pour vous faire peur. C’est pour orienter les décisions. En installation, vous pouvez réduire fortement la surface d’attaque sans compliquer la vie au quotidien.
Choisir un hébergement et une architecture raisonnables
Le “meilleur” niveau de protection WordPress ne vient pas uniquement de WordPress lui-même. Il dépend aussi du serveur.
Vous n’avez pas besoin d’un laboratoire de sécurité, mais il faut au minimum:
- un hébergeur sérieux (mises à jour côté serveur, gestion des patchs, bonnes pratiques); un accès administrateur de type cPanel, Plesk ou équivalent, ou au moins une maîtrise claire des paramètres réseau et DNS; la possibilité d’activer HTTPS, idéalement avec un certificat géré automatiquement; une configuration qui évite d’exposer des répertoires non nécessaires.
Si votre hébergement ne fournit pas de HTTPS simple, si les logs sont inaccessibles, ou si vous ne pouvez pas configurer des règles de base (limitation de requêtes, blocage de certains chemins, etc.), votre marge de manœuvre sera plus faible.
Un point que je vérifie systématiquement
Avant d’installer, je teste l’accès au domaine depuis l’extérieur: résolution DNS correcte, certificat HTTPS qui se charge sans avertissement, redirections HTTP vers HTTPS en place. Ça n’a l’air “que” de la technique, mais ça évite tout un lot de problèmes liés aux cookies et à la confiance côté navigateur.
Préparer le nom de domaine, le DNS et la redirection
Dès le départ, je conseille de viser une structure cohérente pour éviter les doubles versions. Par exemple, si votre site répond à la fois à http://exemple.com et https://exemple.com, puis aussi à http://www.exemple.com et https://www.exemple.com, vous multipliez les risques de mauvaises configurations et les cas où un cookie peut se retrouver mal associé.
Le bon réflexe consiste à décider d’une seule version “canonique”. Ensuite, vous forcez le reste vers elle. En pratique, si vous choisissez https://www.exemple.com, vous redirigez tout le reste vers ce format.
Selon votre hébergement, cette redirection se configure via l’interface du serveur ou via un fichier de configuration. L’essentiel est d’obtenir un comportement stable, sans boucle de redirection.
Télécharger WordPress proprement, et éviter les installations “au hasard”
Pour une installation sécurisée, je recommande de partir des sources officielles. Téléchargez WordPress depuis le site officiel, vérifiez si votre méthode de déploiement le permet (certaines plateformes offrent une vérification ou un flux plus sûr), puis procédez.
Pourquoi je le dis avec insistance? Parce que des environnements “prépackagés” existent, parfois avec des réglages modifiés, ou des versions peu claires. Si vous avez un pack d’installation automatique, c’est pratique, mais assurez-vous que vous comprenez ce qui est installé et comment.
Une fois WordPress téléchargé, évitez aussi de laisser en place des fichiers d’installation inutiles ou des archives qui traînent dans des répertoires accessibles. En cas de doute, faites simple: un déploiement propre, puis suppression des éléments temporaires.
Configurer les bases: base de données, utilisateur, privilèges
Le fichier de configuration (wp-config.php) est au cœur du système. La sécurité ici se joue sur des points très concrets:
- identifiants base de données uniques, avec un mot de passe fort; utilisateur de base de données avec un périmètre minimal; accès limité uniquement à ce que WordPress doit faire.
Dans la plupart des hébergements, l’interface vous permet de créer un utilisateur de base de données dédié. C’est préférable à utiliser un utilisateur partagé entre plusieurs projets.
“Mot de passe fort” veut dire quelque chose de précis
Je parle ici d’une vraie phrase aléatoire, plutôt que “un mot plus un chiffre”. Une approche simple consiste à utiliser une phrase de plusieurs mots, sans logique apparente, qui n’est pas réutilisée ailleurs. Si votre gestionnaire de mots de passe est configuré, il faut s’en servir.
En installation, c’est un des endroits où j’ai vu des failles venir. Pas de magie, juste une collision entre “c’était rapide” et “ça a été deviné”.
Sécuriser wp-config.php dès l’installation
Même si WordPress gère beaucoup de choses, vous pouvez renforcer la configuration.
1) Ajoutez et conservez les “clés et salages” (les constantes de sécurité). Elles servent à protéger le contenu des cookies et à rendre les attaques par relecture beaucoup plus difficiles. Utilisez bien la génération proposée par WordPress et évitez de les réutiliser entre environnements.
2) Vérifiez le préfixe des tables si votre méthode d’installation le permet. Un préfixe non standard ne fait pas tout, mais il ajoute un bruit utile contre certains scripts automatisés. Attention, ne cassez pas la cohérence, WordPress doit utiliser le préfixe attendu.
3) Contrôlez le mode de connexion à la base. En général, c’est géré par l’hébergement, mais assurez-vous que vous n’exposez pas des réglages inutiles.
4) Pensez à la protection du fichier lui-même. Selon votre serveur, on peut empêcher l’accès direct à wp-config.php via des règles. L’idée est simple: même si quelqu’un “devine” le chemin, il ne doit pas lire le contenu.
Pour ce dernier point, la meilleure option dépend de votre environnement (Nginx, Apache, configuration spécifique du panel). Si vous n’êtes pas à l’aise, commencez par ce que votre hébergeur recommande. Souvent, ils ont déjà une option.
Paramètres WordPress qui comptent avant de publier
Une fois WordPress installé, beaucoup de gens continuent sans revoir les réglages initiaux. Pourtant, les premières minutes sont celles où l’on peut réduire l’exposition rapidement.
Voici ce que je fais systématiquement:
- je crée un compte administrateur unique, avec un email que je contrôle vraiment; je m’assure que l’authentification n’est pas “à moitié configurée” (mauvais mot de passe, absence de mécanismes de défense supplémentaires); je décide des chemins d’administration et de l’accessibilité du contenu.
Définir l’accès au site avant de l’ouvrir
Si vous êtes en train de préparer un site, laissez-le en mode privé ou au minimum, évitez qu’il soit entièrement indexé et accessible. WordPress fournit des réglages de visibilité, et vos pages peuvent aussi être protégées via des réglages serveur. On cherche à éviter un scénario où un site “en construction” est exposé avec des thèmes incomplets, des plugins en test, et des formulaires ouverts.
Un détail qui m’a déjà évité des ennuis: j’ai déjà vu des gens publier des pages avec des formulaires de test, puis “changer ça plus tard”. Les bots n’attendent pas “plus tard”.
Choisir une stratégie de sécurité côté login (sans surcharger)
La protection WordPress au niveau de l’administration passe surtout par le contrôle de l’accès. Mais il y a un équilibre.
Ajouter une couche trop agressive peut vous bloquer vous-même si vous êtes sur une connexion mobile instable, ou si votre équipe a des IP variables. Une approche raisonnable commence souvent par:
- un mot de passe robuste et unique pour chaque compte ayant des privilèges; une limitation des tentatives de connexion côté serveur ou via un module de protection; une surveillance des tentatives inhabituelles dans les logs.
WordPress peut être renforcé avec des extensions de sécurité, mais je préfère raisonner par couches. La logique est: limiter l’attaque avant qu’elle n’atteigne l’application, puis renforcer ce que l’application fait, puis surveiller.
Si votre hébergeur propose une protection “WAF” ou anti-bot, activez-la si elle est fiable. Sinon, des solutions existent, mais la compatibilité et la maintenance comptent autant que la promesse marketing.
Activer le HTTPS et vérifier la configuration des redirections
Le HTTPS est souvent activé automatiquement. Mais “certificat présent” n’est pas la même chose que “configuration parfaite”.
Vérifiez notamment:
- la redirection de toutes les pages en HTTPS; le bon domaine pour les cookies (pas de mélange avec un autre sous-domaine); l’absence d’erreurs de certificat, même après renouvellement.
Je conseille aussi de contrôler rapidement avec un navigateur ou un outil de vérification. Rien de sophistiqué, juste être certain que tout se charge sans avertissements.
Une erreur fréquente: une redirection appliquée seulement à certaines routes. Résultat, une partie du site crée des sessions sur HTTP, puis WordPress doit gérer la transition. Ce genre de friction peut devenir une source de problèmes.
Règles simples sur les permissions de fichiers et le propriétaire
Sur le système de fichiers, l’objectif est de limiter ce que WordPress peut écrire, et de s’assurer que les fichiers sensibles ne deviennent pas modifiables à tort.
Dans un environnement d’hébergement standard, le plus important est d’éviter:
- que les fichiers critiques aient des permissions trop ouvertes; que le propriétaire des fichiers soit incohérent par rapport à l’utilisateur PHP.
Selon l’outil de déploiement, les permissions peuvent déjà être correctes. Si vous touchez au système, faites-le avec prudence. En sécurité, “je me suis trompé dans les permissions” ressemble souvent à “je viens de créer une nouvelle surface d’attaque”.
Si votre hébergeur recommande un réglage précis, respectez-le. Sinon, partez d’un état standard fourni par la plateforme.
Choisir les extensions dès le début: moins, mais mieux
C’est tentant d’installer un ensemble d’extensions de “sécurité” dès J1. Parfois ça aide. Souvent ça ajoute des couches, parfois incompatibles, et ça augmente la charge de maintenance.
Je préfère la règle suivante: installez seulement ce dont vous avez besoin, puis ajoutez des outils au fur et à mesure, en regardant l’impact.
En termes de sécurité WordPress, les catégories les plus utiles au départ sont souvent:
- une protection anti-intrusion et anti-bots (à condition qu’elle soit compatible); une solution de sauvegarde fiable, testée (sans sauvegarde testée, on n’a pas de plan); une gestion des mises à jour (automatiques si vous êtes à l’aise, sinon planifiées).
Je ne vous donne pas une liste universelle de plugins parce que la compatibilité varie énormément selon votre thème, vos modules et votre hébergeur. L’approche qui marche le mieux reste la même: choisissez des outils maintenus, avec des avis raisonnables, une documentation claire, et une logique de déploiement compréhensible.
Petit incident typique à anticiper
J’ai déjà vu un site bloqué à cause d’une règle trop stricte qui empêchait l’accès aux pages d’administration après un changement de certificat ou une rotation d’IP. Leçon: testez après activation. Un bon réflexe est de prévoir une fenêtre de test hors heures de production.
Mettre en place une routine de mises à jour, et savoir lesquelles sont urgentes
La sécurité dans le temps compte autant que la sécurité à l’instant T. WordPress et ses composants évoluent, et certaines mises à jour contiennent des corrections. Si vous attendez “le prochain week-end”, vous laissez des portes ouvertes plus longtemps que nécessaire.
Cela dit, il y a une différence entre “mise à jour WordPress” et “mise à jour de plugins” ou “thème”. Les plugins peuvent casser des fonctionnalités si leur version change un comportement. Votre stratégie dépend de votre niveau de contrôle et de votre capacité à tester.
Un compromis réaliste consiste à:
- mettre à jour WordPress lui-même rapidement quand c’est urgent; planifier les plugins et thèmes pour limiter les risques, sans trop prolonger le délai; surveiller les journaux et les éventuels problèmes après mise à jour.
Si vous avez une équipe, synchronisez les déploiements. Si vous êtes seul, réfléchissez à une procédure stable.
Sauvegardes: la protection WordPress la plus sous-estimée
Une sauvegarde n’empêche pas l’attaque, mais elle vous donne une sortie de secours. Et dans les faits, c’est souvent ce qui permet de retrouver la main rapidement.
Deux points font la différence entre une sauvegarde “théorique” et une sauvegarde utile:
1) La sauvegarde doit inclure à la fois fichiers et base de données. 2) Vous devez tester la restauration, au moins une fois, ou au minimum vérifier la logique de restauration offerte par votre outil.
J’ai déjà vu des sauvegardes qui “existaient” mais qui ne restaurent pas correctement parce qu’il manquait un élément (droits, chemin, ou compatibilité de version). Si vous ne testez jamais, vous découvrez le jour où vous en avez besoin.
Hardening réseau et indexation: réduire ce que les bots voient
Tous les bots ne sont pas malveillants, mais vous n’avez pas besoin de leur donner de la matière. Le hardening “réseau et accès” peut inclure:
- limiter l’accès à certains endpoints d’administration via des règles serveur; désactiver l’exposition inutile d’annuaires; éviter d’ouvrir des dossiers qui ne doivent pas être visibles.
Même sans aller dans des règles complexes, vous pouvez déjà améliorer les choses en vous assurant que votre serveur ne diffuse pas par défaut une liste de répertoires.
Concernant l’indexation, vos réglages de visibilité et votre stratégie SEO jouent un rôle. Un site en construction devrait être protégé, et un site ouvert ne devrait pas exposer des contenus temporaires.
Un mini plan de déploiement sécurisé, étape par étape
Vous voulez un cadre simple qui vous évite d’oublier un détail. Voici comment je procède, sans faire de “théâtre” ni de configuration illisible.
- Choisissez l’hébergement, vérifiez HTTPS et la redirection vers une version canonique du domaine. Déployez WordPress depuis une source officielle, puis supprimez les éléments temporaires et assurez des permissions cohérentes. Créez une base de données et un utilisateur dédiés, avec des identifiants uniques et un mot de passe solide. Complétez wp-config.php correctement (clés de sécurité, préfixe cohérent si applicable, protection du fichier selon votre serveur). Installez les réglages de visibilité et configurez l’accès admin avant de publier quoi que ce soit.
Ce plan n’est pas une garantie absolue, mais il couvre les points où les accidents ont le plus de chances de naître.
Ce que vous pouvez vérifier après l’installation (sans outils compliqués)
Après l’installation, je fais un contrôle rapide qui ressemble à une vérification avant départ. Cela prend peu de temps, mais ça évite des soucis plus tard.
Voici les points que je contrôle en premier:
1) Connexion admin: testez l’accès depuis un nouvel onglet, et vérifiez que vous êtes bien redirigé en HTTPS. 2) Cookies et sessions: ouvrez le site, connectez-vous, puis vérifiez que le navigateur ne signale pas de mélange HTTP/HTTPS. 3) wp-config.php: confirmez qu’il n’est pas accessible directement (si vous avez un doute, demandez une validation côté hébergeur). 4) Accès au contenu: assurez que vos pages “en construction” ou tests ne sont pas publiées publiquement par erreur. 5) Plugins: regardez la liste et assurez qu’aucun plugin “vide” ou obsolète n’est installé par défaut ou sans raison.
Ce contrôle ressemble à une routine, mais en sécurité les routines gagnent.
Cas particuliers et compromis que vous rencontrerez
Il y a des situations où “la configuration la plus sécurisée” devient inconfortable.
Utiliser des connexions partagées ou plusieurs comptes
Si vous gérez le https://gardewp.fr/securite-wordpress/ site en équipe, vous devez décider comment gérer les accès. Donner un compte admin à tout le monde, même par commodité, augmente fortement le risque. La solution la plus saine est de limiter les privilèges, et de créer des comptes distincts.
Besoin d’un panel d’administration accessible depuis partout
Certains métiers exigent un accès depuis des réseaux variables. Si vous mettez des limitations trop strictes, vous pouvez vous bloquer. Dans ce cas, vous privilégiez des règles plus intelligentes (par exemple, protection anti-bots, limitation raisonnable, mais pas un mur de briques).
Installer un gros plugin de sécurité “tout-en-un”
Ces plugins peuvent être utiles, mais ils peuvent aussi interagir avec le caching, les réglages de redirection, ou des fonctionnalités comme la mise en cache de pages. J’ai déjà vu des systèmes de sécurité qui “cassent” le site après un changement de thème, non pas parce qu’ils étaient mauvais, mais parce qu’ils ont une portée trop large.
Le compromis: commencez simple, comprenez l’impact, gardez la possibilité de désactiver proprement si besoin.
Où placer la vraie “protection WordPress” dans votre quotidien
La sécurité ne vit pas seulement au moment de l’installation. Elle vit dans votre quotidien, dans vos réflexes, et dans la discipline des vérifications.
Si vous ne retenez qu’une idée, ce serait celle-ci: la meilleure protection WordPress est celle que vous maintenez. Un réglage isolé, même excellent, ne sert pas s’il n’est jamais revu, jamais testé, et jamais restauré en cas de problème.
Quand vous installez WordPress avec une configuration sécurisée dès le départ, vous créez une base solide. Ensuite, vous la protégez avec trois gestes: mise à jour régulière, sauvegarde testée, limitation raisonnable de l’accès à l’administration.
Checklist finale avant de dire “c’est en ligne”
Avant de mettre le site public, j’aime bien repasser mentalement sur une dernière question: est-ce que je pourrais récupérer rapidement en cas de pépin, et est-ce que j’ai réduit les portes faciles ?
Si vous avez suivi les étapes principales, votre protection WordPress sera déjà bien mieux que la moyenne. Et surtout, vous aurez évité les scénarios classiques qui transforment une installation “standard” en projet de correction sous pression.
Le vrai confort vient de là: une installation propre, une surface d’attaque réduite, des accès maîtrisés, et un plan de restauration crédible.