Dans la plupart des audits et des sécurisation WordPress, le point qui revient le plus souvent n’est pas un plugin exotique, ni une faille médiatisée. C’est la même faiblesse, répétée à l’échelle: des identifiants trop simples, des réutilisations entre sites, et une politique de mots de passe qui ne force rien, ou presque. Le résultat est connu, même quand on a “tout mis à jour”: un compte devient une porte d’entrée, parfois depuis plusieurs mois avant que quelqu’un ne s’en aperçoive.
Renforcer la politique de mots de passe, ce n’est pas uniquement imposer des mots “plus compliqués”. Il faut surtout rendre les choix raisonnables pour les humains, et rendre les attaques difficiles pour les machines. Un bon réglage de WordPress et de l’écosystème autour du login peut réduire drastiquement le risque, sans transformer la gestion du site en parcours administratif.
Partir de ce que l’attaque cherche vraiment
Quand on parle de mots de passe, on pense brute force. Oui, il y en a. Mais dans les incidents réels, le scénario le plus fréquent ressemble plus à une combinaison de trois choses:
- des mots de passe déjà trouvés ailleurs (fuites d’identifiants, listes volées, attaques par rebond), un accès réseau qui n’est pas assez freiné (tentatives illimitées, absence de contrôle), et des comptes privilégiés qui restent trop exposés (administrateurs peu nombreux, mais très ciblés).
Un audit utile commence donc par une question simple: vos mots de passe, et leur usage, résistent-ils aux attaques automatiques et aux identifiants déjà compromis?
Si votre site est petit, l’impact n’est pas nul. Sur un site de moyenne taille, on voit souvent plus de candidats “probables” côté mots de passe, car l’administrateur utilise le même schéma sur plusieurs services. Sur un site très actif, le risque change: ce sont davantage les comptes collaborateurs, contributeurs, et parfois des rôles oubliés (anciens freelances, prestataires, comptes créés pour un moment et conservés).
Dans ce contexte, la politique de mots de passe ne doit pas être un texte dans un doc interne. Elle doit se refléter dans le comportement réel du site: validation à la création, règles au changement, et surtout contrôle au moment des connexions.
Ce que WordPress fait, et ce qu’il ne fait pas
WordPress propose des contrôles, mais il laisse beaucoup de liberté. Selon la configuration, vous pouvez obtenir:
- un minimum de longueur (via des filtres et fonctions), la possibilité de refuser des mots de passe “trop proches” (parfois configuré via des mécanismes additionnels), et un comportement de login géré par le noyau.
En revanche, WordPress n’impose pas par défaut une politique complète comme le ferait une solution d’annuaire d’entreprise. Il ne va pas automatiquement exiger un historique, imposer une rotation stricte, ou vérifier systématiquement des critères “zéro réutilisation” sans passer par des composants externes.
C’est là que l’audit devient concret: vous devez décider quelles règles vous voulez, et surtout lesquelles sont réalistes pour vos utilisateurs. Une politique trop stricte entraîne souvent des contournements. Une politique trop souple donne aux attaquants un terrain favorable.
J’ai vu des sites où l’on imposait un renouvellement très fréquent, “tous les 30 jours”, avec un minimum de complexité faible. Les utilisateurs finissaient par ajouter un chiffre à la fin, par exemple Mars2024!, puis Mars2025!. Ce n’est pas une amélioration, c’est une prévisibilité.
À l’inverse, un site qui impose une longueur correcte, exige une vraie phrase de passe, et limite les tentatives via des contrôles de connexion, obtient un gain net, sans casser l’usage.
Construire une politique de mots de passe qui tient dans le temps
Une politique efficace combine trois axes. Le premier, c’est la qualité des mots de passe au moment où ils sont choisis ou changés. Le deuxième, c’est la façon dont WordPress et votre couche de sécurité réagissent aux tentatives de connexion. Le troisième, c’est l’hygiène côté comptes.
Pour l’axe “qualité”, la meilleure approche consiste généralement à favoriser des phrases de passe longues plutôt que des mots isolés. Une phrase de passe de bonne longueur, même sans symboles extravagants, résiste mieux que des mots courts ajoutés de chiffres. Les attaques par dictionnaire et par listes de fuites pénalisent surtout les mots trop courants, et la longueur est un rempart direct.
Pour l’axe “connexion”, il faut réduire la probabilité de réussite d’une attaque automatisée. Même une bonne politique de mots de passe perd de sa valeur si un attaquant peut tenter des milliers de combinaisons sans friction.
Enfin, pour l’hygiène, l’audit doit lier mots de passe et gestion des rôles. Un compte administrateur ou éditeur qui n’est plus utilisé, mais qui reste actif, est un risque latent. Une politique de rotation peut donner une illusion de sécurité tant que ces comptes fantômes existent.
Règles de base à imposer (sans tomber dans l’arbitraire)
Quand on renforce une politique, on rencontre vite un dilemme: les critères doivent être suffisamment clairs pour être appliqués, mais assez souples pour ne pas créer de contournements.
Un bon point de départ, c’est de définir des règles qui renforcent la difficulté de deviner un mot de passe sans exiger des “acrobaties” impossibles. Par expérience, les critères suivants fonctionnent bien parce qu’ils améliorent la résistance réelle:
- exiger une longueur minimale suffisamment élevée, éviter les mots trop courts ou trop proches du nom de l’utilisateur, favoriser des phrases de passe, et interdire la réutilisation immédiate lors d’un changement.
WordPress seul ne garantit pas toujours ces points sans assistance. C’est pour cela qu’on parle d’audit de sécurisation: on regarde l’existant, on identifie les gaps, puis on comble avec une configuration, un module de validation, ou une gestion des changements via un mécanisme central.
Voici une trame de vérification qui aide à cadrer l’effort, sans se perdre dans des options abstraites.
- Vérifier la méthode actuelle de création et de changement des mots de passe (qui change, quand, sur quels rôles). Contrôler la politique de complexité réellement appliquée (minimum de longueur, règles de proximité, refus de valeurs faibles). Examiner les paramètres de connexion qui limitent les tentatives (limitation, délais, blocage temporaire). Évaluer l’exposition des comptes (comptes inutilisés, rôles trop larges, administrateurs partagés).
Cette mini-vérification donne une photographie immédiate de ce qui protège, et de ce qui ne protège pas.
La longueur bat la complexité “décorative”
Une tentation fréquente lors de la rédaction d’une politique de mots de passe est d’insister sur les symboles et la complexité, par exemple mélanges majuscules, minuscules, chiffres et caractères spéciaux. Cela peut aider dans certains cas, mais ça n’apporte pas le même niveau de protection que la longueur.
Un mot de passe de 10 caractères “complexe” reste attaquable si l’attaquant dispose d’une liste de mots probables, ou si le mot de passe est dérivé d’un schéma connu (nom du site, année, nom de la ville, variations prévisibles). Au contraire, une phrase de passe de 4 à 6 mots, sans dictionnaire immédiat, rend les attaques basées sur des listes de candidats beaucoup moins efficaces.
Dans un audit que j’ai mené sur un site associatif, l’équipe avait “standardisé” des mots de passe avec le même format, du type NomAsso!2024. La complexité était là, mais tout le monde savait le motif. Le correctif a été moins spectaculaire qu’il n’y paraît: on a changé la règle pour viser des phrases de passe longues et on a formé l’équipe à l’idée qu’un mot unique n’est pas une phrase. Résultat: moins de rééchecs, moins d’oublis, et une réduction nette des risques sur les schémas évidents.
La clé est de transformer la règle en comportement. Il ne suffit pas de “dire” aux gens d’utiliser des caractères spéciaux. Il faut leur donner une méthode.
Valider au moment du changement, pas uniquement à la création
Beaucoup de sites appliquent des règles à la création, puis ne revalident rien au changement. Or, un changement de mot de passe est un moment où l’utilisateur peut adopter un schéma: remplacer l’année, ajouter un chiffre, ou remplacer un caractère. Une politique efficace doit empêcher les changements qui conduisent à un mot de passe “pratiquement identique”.
On peut aussi tomber dans l’erreur inverse. En imposant une rotation trop fréquente et sans garde-fous, on pousse des utilisateurs à modifier en surface. C’est le cas typique d’une règle annuelle ou mensuelle qui n’est pas associée à une interdiction de réutilisation, ou à un contrôle de similarité.
La bonne question, pour votre audit et sécurisation WordPress, est donc: vos règles de changement détectent-elles les dérives? Si vous choisissez une politique de rotation, elle doit s’accompagner de critères qui rendent les changements réellement différents, et pas simplement “plus récents”.
En pratique, la rotation systématique n’est pas toujours nécessaire si vous combinez une excellente hygiène de comptes, une limitation de tentatives, et une authentification forte. Mais si vous vivez avec des contraintes organisationnelles (contrat, conformité, habitudes internes), alors il faut que la rotation soit réaliste et encadrée.
Le frein côté connexion: souvent le gain le plus immédiat
Même avec de “bons” mots de passe, un site reste une surface de login. Un attaquant automate peut tester beaucoup plus vite que l’humain. Donc, si votre politique de mots de passe est renforcée mais que vos connexions restent trop permissives, vous n’avez pas tout réglé.
C’est ici que les mesures autour du login prennent une place énorme: limitation des tentatives, gestion des retours de code, délais progressifs, et verrouillage temporaire en cas d’anomalies. La partie délicate, c’est le risque de pénaliser les utilisateurs légitimes, par exemple ceux qui saisissent plusieurs fois par erreur, ou qui ont des lenteurs réseau.
Dans un audit, je recommande de mesurer et d’observer. Les réglages doivent être testés sur un scénario d’utilisateur réel: un mot de passe oublié, un membre de l’équipe qui se trompe une fois, un mobile qui décroche. Ensuite seulement, vous bloquez plus fermement.
Pour être efficace, le frein doit s’appliquer de façon cohérente à toutes les tentatives. S’il existe des points d’accès alternatifs, comme une URL de connexion via un autre chemin, ou un formulaire intégré ailleurs, l’attaquant peut contourner vos restrictions si elles sont mal ciblées.
Gérer les comptes: le point souvent sous-estimé
Les mots de passe ne vivent pas seuls. Ils vivent dans un parc de comptes, et ce parc évolue. Un audit doit donc lister ce qui suit, même si ce n’est pas “technique” au sens strict:
- Les comptes créés pour des prestataires, puis oubliés. Les comptes dont le rôle a été élargi “pour dépanner”. Les comptes administrateur qui ne sont pas partagés par erreur, mais qui sont trop nombreux. Les comptes avec des utilisateurs inactifs depuis longtemps.
Un mot de passe fort ne sert à rien si le compte n’est plus surveillé, ou si l’accès reste disponible après départ. Dans la pratique, un compte abandonné ressemble à un mot de passe faible, même si le mot de passe initial était solide, car il reste potentiellement accessible trop longtemps.
À ce stade, l’amélioration peut être aussi simple que supprimer les droits inutiles, puis forcer un changement du mot de passe pour les comptes restants, avec une validation renforcée.
C’est souvent le meilleur compromis, parce que vous réduisez la surface d’attaque sans augmenter la charge de manière disproportionnée.
Deux erreurs qui reviennent tout le temps
On peut renforcer une politique de mots de passe et pourtant rater le résultat. Voici deux écueils fréquents, que j’ai vus sur des environnements très différents.
- Imposer une complexité “symboles obligatoires” sans augmenter la longueur, ce qui produit des mots dérivés facilement. Forcer une rotation trop fréquente sans empêcher les changements “identiques à l’ancienne version”.
Ces deux erreurs créent, respectivement, des mots de passe prévisibles et des utilisateurs qui contournent la règle par fatigue. Dans les deux cas, l’audit finit avec une politique qui a l’air stricte, mais qui ne protège pas vraiment.
Comment déployer sans casser l’usage
Renforcer une politique n’est pas un bouton “sécurité activée”. Il y a une phase de transition, sinon vous provoquez des blocages le jour où l’équipe doit livrer un contenu, migrer un site, ou publier un article.
Le déploiement doit respecter trois principes.
Premier principe: communiquer la méthode, pas seulement la règle. Si vous exigez des phrases de passe, expliquez ce que cela https://gardewp.fr/securite-wordpress/ veut dire dans la vie réelle, et proposez un exemple de schéma non réutilisable. Si vous imposez une longueur minimale, indiquez ce que vous entendez par là.
Deuxième principe: planifier le changement de manière progressive. Si vous forcez le changement pour tout le monde en même temps, vous créez un pic de sollicitations au support. Certains vont appeler, d’autres vont écrire leurs mots de passe dans un endroit non sécurisé parce qu’ils sont sous pression. On évite donc la bascule brutale.
Troisième principe: prévoir l’authentification forte quand c’est possible. Un mot de passe robuste reste un bon socle, mais l’authentification multi-facteur réduit le coût pour l’attaquant même quand un mot de passe fuit. Si votre organisation a accès à une solution MFA fiable, c’est souvent le meilleur complément, car il protège contre les fuites et contre une partie des attaques par réutilisation.
Mesurer le résultat de l’audit, avec des signaux concrets
Après avoir modifié la politique de mots de passe et les contrôles du login, vous devez vérifier que la sécurité s’est améliorée sans dégrader l’expérience au point de déclencher des contournements.
Concrètement, vous pouvez regarder les signaux suivants:
- la diminution des tentatives de connexion infructueuses (ou leur répartition, si vous avez des outils de monitoring), l’augmentation des réussites après saisie correcte (si votre anti brute force est trop agressif, vous verrez des blocages), la baisse du nombre de réinitialisations de mot de passe dues à des erreurs simples, et surtout, l’évolution de la liste des comptes actifs, avec une réduction des comptes inutiles.
Ces indicateurs ne prouvent pas l’absence totale de risque, mais ils racontent une histoire cohérente: soit vos utilisateurs ont mieux appliqué la règle, soit les attaquants sont moins en mesure d’itérer.
Mettre la politique en cohérence avec votre “gestion des comptes”
Un audit de sécurisation WordPress efficace ne s’arrête pas aux réglages. Il impose une cohérence opérationnelle.
Si vous avez des prestataires, définissez qui crée les comptes, qui les supprime, et quand. Si vous changez un rôle, décidez si vous forcez un changement de mot de passe ou si vous vous contentez d’appliquer un verrouillage temporaire. Si un utilisateur ne se connecte plus pendant une période longue, définissez une procédure de revue.
Cette cohérence évite une situation classique: vous renforcez la politique, puis quelqu’un crée un compte dans l’urgence avec un mot de passe généré mais communiqué par e-mail en clair, ou stocké dans un canal interne peu sécurisé. Le mot de passe reste fort, mais le secret est exposé ailleurs. Dans un audit, ce point revient comme un problème d’organisation autant que de technique.
Un plan d’action réaliste pour votre prochain audit
Vous n’avez pas besoin de tout refaire d’un coup. En audit, je préfère un plan qui obtient des gains rapides, puis consolide.
Commencez par cadrer la politique actuelle, puis identifiez les lacunes: longueur, contrôle de similarité, et règles de changement. En parallèle, vérifiez vos contrôles de tentatives de connexion et leurs paramètres. Ensuite, nettoyez les comptes, réduisez les rôles inutiles, et supprimez les comptes inactifs ou non maîtrisés.
Enfin, formez et déployez progressivement. Une politique de mots de passe qui fonctionne est celle que les équipes suivent sans improviser.
Si vous devez prioriser, je classerais souvent les actions comme suit: réduire la surface de comptes d’abord, renforcer ensuite la qualité et la validation des mots de passe, puis durcir le login contre les tentatives répétées. Le plus souvent, c’est aussi l’ordre qui minimise les risques opérationnels.
Garder une politique vivante, pas un document figé
La sécurité n’aime pas les documents figés. Votre WordPress, votre équipe, et vos prestataires changent. Une politique de mots de passe doit donc être révisée quand:
- de nouveaux rôles apparaissent (par exemple plus de contributeurs), des prestataires arrivent et repartent, des incidents de login surviennent, ou vous constatez que les utilisateurs contournent la règle.
Dans un audit et sécurisation WordPress, l’objectif n’est pas seulement de fermer des failles techniques. C’est de construire un système où le comportement attendu est celui que les gens adoptent naturellement.
Quand la politique est claire, réaliste, et appuyée par des contrôles au login, les mots de passe cessent d’être le maillon faible. Ils deviennent un des piliers d’un dispositif cohérent, où la combinaison de validation, d’hygiène des comptes et de friction sur les tentatives fait la vraie différence.