Mot de passe fort et 2FA sur WordPress

Si vous avez déjà vu des dizaines de tentatives de connexion par minute dans vos logs (ou dans l’écran “Santé du site”), vous avez déjà rencontré le problème : le mot de passe seul ne suffit plus.

Prérequis : WordPress 6.9.4 (avril 2026), PHP 8.1+ (recommandé), un accès administrateur, et idéalement un accès à votre hébergement (FTP/SSH) pour appliquer des protections serveur. Faites une sauvegarde (fichiers + base) avant tout changement. Ne modifiez jamais le cœur de WordPress.

La menace

Un attaquant qui obtient l’accès à votre compte administrateur peut tout faire : installer un plugin malveillant, injecter des liens SEO, rediriger vos visiteurs, voler des données (emails, commandes), ou bloquer votre site avec un rançongiciel. Dans la pratique, je vois surtout deux scénarios : une page d’accueil remplacée, ou des redirections “casino/pharma” invisibles pour vous mais visibles pour Google.

Le vecteur le plus fréquent reste la connexion : mots de passe faibles, réutilisés, ou volés via une fuite sur un autre service. Ensuite viennent les attaques par force brute (essais automatisés) et le credential stuffing (réutilisation de couples email/mot de passe déjà compromis). Même si WordPress stocke les mots de passe de façon hachée (pas en clair), ça ne protège pas contre un mot de passe devinable ou déjà connu ailleurs.

Le risque en langage simple : si votre mot de passe peut être deviné (ou si vous l’avez déjà utilisé ailleurs), quelqu’un finira par entrer. La 2FA (authentification à deux facteurs) ajoute une deuxième “clé” : même si le mot de passe fuite, la connexion échoue sans le code temporaire.

Pour référence, WordPress documente les bonnes pratiques de sécurité côté utilisateur et côté admin sur Hardening WordPress et côté développeur sur Security APIs.

Résumé rapide

Utilisez un gestionnaire de mots de passe et générez des mots de passe uniques (16–24+ caractères) pour chaque compte WordPress.
Activez la 2FA au minimum pour les administrateurs et éditeurs (TOTP via application, et idéalement clés physiques/WebAuthn si possible).
Désactivez l’authentification application/password inutile et limitez XML-RPC si vous ne l’utilisez pas.
Durcissez la page de connexion : limitation de tentatives, en-têtes de sécurité, et protection serveur (HTTP auth / WAF si dispo).
Surveillez : logs, alertes de connexions, et comptes admin inattendus.
Testez sans casser : faites vos changements sur un site de staging si vous en avez un, et gardez une méthode de secours (code recovery 2FA, compte admin secondaire).

Code vulnérable — ce qu’il ne faut PAS faire

Un piège courant chez les débutants : “simplifier” la connexion en ajoutant un formulaire custom, ou en bricolant l’authentification pour intégrer un “code 2FA maison” stocké en base… et au passage, supprimer des protections natives (nonce, validation, limitation).

Rappel de vocabulaire :

Un hook (crochet) est un point d’extension de WordPress.
Une action exécute du code à un moment précis (ex : init).
Un filtre modifie une valeur (ex : authenticate).
Un nonce est un jeton anti-CSRF (évite qu’un site tiers déclenche une action à votre place).

Exemple volontairement dangereux (ne copiez pas) : un “login + 2FA” bricolé qui :

accepte un mot de passe faible,
stocke un code 2FA en clair,
ne vérifie pas de nonce,
et fuit des informations via des messages d’erreur.

<?php
/**
 * EXEMPLE VULNÉRABLE — NE PAS UTILISER.
 * Problèmes : pas de nonce, 2FA statique en clair, messages d'erreur trop précis,
 * et contournement des écrans de connexion WordPress.
 */

add_action('init', function () {
	// Formulaire "maison" via ?custom_login=1
	if (!isset($_GET['custom_login'])) {
		return;
	}

	if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
		return;
	}

	// Entrées non validées
	$user_login = $_POST['user_login'] ?? '';
	$user_pass  = $_POST['user_pass'] ?? '';
	$otp        = $_POST['otp'] ?? '';

	$user = get_user_by('login', $user_login);
	if (!$user) {
		wp_die('Utilisateur inexistant'); // Trop d'info
	}

	// 2FA stockée en clair (catastrophique)
	$expected_otp = get_user_meta($user->ID, 'my_plain_otp', true);
	if ($otp !== $expected_otp) {
		wp_die('Code 2FA incorrect'); // Trop d'info
	}

	// Auth WordPress sans protections additionnelles
	$signon = wp_signon([
		'user_login'    => $user_login,
		'user_password' => $user_pass,
		'remember'      => true,
	], is_ssl());

	if (is_wp_error($signon)) {
		wp_die('Mot de passe incorrect'); // Trop d'info
	}

	wp_redirect(admin_url());
	exit;
});

Voici ce qui se passe en coulisses et pourquoi c’est exploitable :

Pas de nonce : un attaquant peut tenter de déclencher des requêtes à votre insu (CSRF). Ce n’est pas le plus probable sur un login, mais c’est une mauvaise habitude qui finit ailleurs (profil, email, etc.).
2FA statique : si le “code” est fixe et stocké en clair, il finira par fuiter (backup, plugin, DB dump). Une 2FA correcte génère des codes temporaires (TOTP) ou utilise WebAuthn.
Messages d’erreur précis : “utilisateur inexistant” + “mot de passe incorrect” aide à valider des identifiants (énumération).
Contournement du login natif : vous perdez des protections et la compatibilité avec des plugins sérieux (2FA, reCAPTCHA, limitation, SSO).

Dans mon expérience, ce type de snippet finit souvent collé au mauvais endroit (dans functions.php du thème parent), puis cassé à la prochaine mise à jour. Et quand il casse, il casse la connexion… le pire endroit pour casser.

Code sécurisé — la bonne implémentation

La stratégie saine pour WordPress 6.9.4 : ne réécrivez pas l’authentification. Utilisez :

un mot de passe fort et unique (généré),
une 2FA standard via un plugin maintenu (TOTP / WebAuthn),
et des garde-fous côté WordPress (politiques) + côté serveur (headers, limitation, désactivation de surfaces inutiles).

1) Choisir un mot de passe réellement solide (et praticable)

Un “bon” mot de passe pour un compte WordPress admin n’est pas “Azerty123!”. C’est :

unique (jamais réutilisé),
long (16 caractères minimum, 20–24 c’est confortable),
aléatoire (généré par un gestionnaire),
stocké dans un gestionnaire de mots de passe, pas dans un fichier texte.

WordPress s’appuie sur des fonctions PHP robustes pour le hachage des mots de passe. Si vous êtes curieux, PHP documente le hachage moderne ici : password_hash(). Vous n’avez pas à coder ça vous-même dans WordPress : laissez le cœur gérer.

2) Activer une 2FA fiable (TOTP / WebAuthn) sans vous enfermer

Pour un blogueur débutant, le plus simple est une 2FA TOTP (application type Authy/Google Authenticator/1Password). Pour un usage pro, je recommande souvent WebAuthn (passkeys / clés physiques) quand c’est possible, car ça réduit fortement le phishing.

Je ne vais pas vous donner une “liste magique” de plugins (ça bouge). Mon critère : plugin populaire, maintenu, compatible WP 6.9.x, et qui supporte au minimum TOTP + codes de secours. Cherchez côté répertoire officiel des extensions et vérifiez :

dernière mise à jour récente,
compatibilité déclarée avec votre version,
support actif,
et présence d’une doc claire sur la récupération.

Mes règles terrain :

Activez 2FA d’abord sur un compte admin secondaire (de secours), puis sur votre compte principal.
Stockez les codes de récupération hors du site (gestionnaire de mots de passe).
Imposez 2FA au minimum aux rôles sensibles : administrateur, éditeur.

3) Forcer des mots de passe forts et bloquer les fuites de surface (mu-plugin)

Si vous gérez plusieurs auteurs, vous voulez une politique minimale : empêcher les mots de passe trop faibles, et réduire des points d’entrée inutiles.

Où coller le code : créez un mu-plugin (plugin “must-use”) pour éviter qu’un thème ou un plugin de snippets le désactive par erreur.

Créez le dossier wp-content/mu-plugins/ s’il n’existe pas.
Créez le fichier wp-content/mu-plugins/security-login-policy.php.

Ce mu-plugin fait trois choses :

refuse les mots de passe trop courts lors de la création / mise à jour utilisateur,
désactive XML-RPC si vous ne l’utilisez pas (surface d’attaque historique),
désactive les Application Passwords si vous n’en avez pas besoin (API REST via mots de passe applicatifs).

<?php
/**
 * Plugin Name: Sécurité - Politique de connexion (mots de passe + surfaces)
 * Description: Politique simple pour WordPress 6.9.4+ : longueur minimale des mots de passe, désactivation optionnelle de XML-RPC et des mots de passe applicatifs.
 * Version: 1.0.0
 * Author: Votre Nom
 *
 * À placer dans wp-content/mu-plugins/security-login-policy.php
 */

defined('ABSPATH') || exit;

/**
 * Longueur minimale : 16.
 * Objectif : couper net les mots de passe faibles, sans réécrire l'authentification.
 */
add_action('user_profile_update_errors', function ($errors, $update, $user) {
	// $user est un objet WP_User "en construction"
	if (empty($user->user_pass)) {
		return;
	}

	$min_length = 16;

	// Ne bloquez pas les mots de passe auto-générés : ils sont généralement longs.
	if (strlen($user->user_pass) < $min_length) {
		$errors->add(
			'password_too_short',
			sprintf(
				/* translators: %d: longueur minimale */
				__('Mot de passe trop court. Utilisez au minimum %d caractères (idéalement générés par un gestionnaire).', 'your-textdomain'),
				$min_length
			)
		);
	}
}, 10, 3);

/**
 * Option 1 : Désactiver XML-RPC si vous ne l'utilisez pas.
 * Attention : certains outils (anciens apps mobiles, Jetpack dans certains modes) peuvent en dépendre.
 * Si vous utilisez un page builder (Divi/Elementor/Avada), ça n'a généralement aucun impact.
 */
add_filter('xmlrpc_enabled', '__return_false');

/**
 * Option 2 : Désactiver les mots de passe applicatifs (Application Passwords).
 * Utile si vous n'utilisez pas d'intégrations externes via REST.
 * Doc : https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/
 */
add_filter('wp_is_application_passwords_available', '__return_false');

Explication simple :

user_profile_update_errors est une action qui vous laisse ajouter des erreurs quand un profil utilisateur est enregistré. Si une erreur est ajoutée, WordPress refuse l’enregistrement.
xmlrpc_enabled est un filtre : on renvoie false pour désactiver.
wp_is_application_passwords_available est un filtre : on renvoie false pour couper cette méthode d’auth si inutile.

Explication technique :

On ne touche pas au hachage des mots de passe : WordPress gère le stockage via ses APIs internes.
On réduit la surface d’attaque (XML-RPC, Application Passwords) quand elle n’est pas requise.

Piège que je vois souvent : des gens collent ce code dans functions.php du thème parent, puis changent de thème (ou mettent à jour) et perdent la protection. Le mu-plugin évite ça.

4) Imposer la 2FA pour les rôles sensibles (approche “garde-fou”)

Imposer la 2FA “en dur” uniquement par code est délicat, car WordPress core n’inclut pas (à ce jour) une API 2FA standard universelle. La bonne approche débutant : utiliser la fonctionnalité d’imposition fournie par votre plugin 2FA (souvent par rôle) et documenter le processus de récupération.

Si vous voulez quand même un garde-fou minimal côté code : vous pouvez afficher une alerte persistante aux admins tant qu’ils n’ont pas configuré la 2FA (selon le meta utilisé par votre plugin). Comme ce meta dépend du plugin, je ne vais pas inventer une clé qui n’existe pas. Prenez 2 minutes pour regarder dans wp_usermeta (phpMyAdmin) ou la doc du plugin, puis adaptez.

Configuration serveur

Le serveur est votre deuxième ligne de défense. Quand c’est bien fait, ça bloque des attaques avant même que WordPress ne s’exécute (moins de charge, moins de bruit).

.htaccess (Apache) : protéger wp-login.php et réduire l’exposition

Si votre hébergeur est sur Apache et que .htaccess est actif, vous pouvez ajouter des règles. Faites-le prudemment : une erreur de syntaxe peut provoquer une erreur 500. Sauvegardez le fichier avant.

1) Bloquer l’accès à xmlrpc.php (si vous l’avez désactivé)

# À ajouter dans .htaccess à la racine WordPress
# Objectif : refuser tout accès à xmlrpc.php (si vous n'en avez pas besoin)

<Files "xmlrpc.php">
  Require all denied
</Files>

2) Limiter l’accès à wp-login.php par IP (option “petite équipe”)

Très efficace pour un site perso si vous avez une IP fixe. Si vous êtes souvent en déplacement (4G, coworking), vous allez vous bloquer. Dans ce cas, préférez un WAF ou la 2FA + limitation de tentatives.

# Exemple Apache 2.4+ : autoriser seulement 2 IP à wp-login.php
<Files "wp-login.php">
  Require ip 203.0.113.10
  Require ip 198.51.100.25
</Files>

wp-config.php : forcer HTTPS et durcir quelques constantes

Collez ces lignes dans wp-config.php (au-dessus de “That’s all, stop editing!”). Vérifiez d’abord que votre site fonctionne bien en HTTPS.

<?php
// Forcer l'admin en HTTPS (utile si un proxy/CDN est mal configuré)
define('FORCE_SSL_ADMIN', true);

// Désactiver l'édition de fichiers depuis l'admin (réduit l'impact d'un compte compromis)
define('DISALLOW_FILE_EDIT', true);

// Option : désactiver l'installation/mise à jour de plugins/thèmes depuis l'admin
// À activer si vous gérez les déploiements autrement (Git, CI/CD).
// define('DISALLOW_FILE_MODS', true);

Note : si vous êtes sur un hébergement managé (ou avec un reverse proxy), FORCE_SSL_ADMIN peut révéler une mauvaise config des en-têtes X-Forwarded-Proto. Dans ce cas, corrigez côté serveur plutôt que de “forcer” à l’aveugle.

En-têtes HTTP (sécurité navigateur)

Ces en-têtes limitent l’impact de certaines attaques côté navigateur. Idéalement, configurez-les dans Nginx/Apache ou via votre hébergeur/CDN.

# Exemples (à adapter selon serveur)
# Content-Security-Policy est volontairement non fourni ici (trop spécifique et facile à casser).

X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

Si vous utilisez Elementor/Divi/Avada, évitez une CSP “copier-coller” trouvée sur un forum : elle casse souvent l’éditeur visuel (scripts inline, iframes, fonts). Faites-la progressivement, en mode report-only si vous savez ce que vous faites.

Vérifier si votre site est vulnérable

Ici, “vulnérable” veut dire : mots de passe faibles en circulation, absence de 2FA sur des comptes sensibles, et signaux de brute force.

WP-CLI : audit rapide des comptes

WP-CLI est l’outil en ligne de commande de WordPress. S’il est disponible chez votre hébergeur, c’est le moyen le plus propre. Référence : WP-CLI commands.

# Lister les administrateurs
wp user list --role=administrator --fields=ID,user_login,user_email,registered

# Lister les comptes créés récemment (utile après suspicion)
wp user list --fields=ID,user_login,user_email,registered --orderby=registered --order=DESC --number=20

Ce que vous cherchez :

un admin que vous ne reconnaissez pas,
un email suspect (domaine jetable),
un pic de créations de comptes (si l’inscription est ouverte).

SQL (diagnostic) : repérer des admins inconnus

Si vous avez accès à la base, cette requête liste les comptes ayant la capacité admin via la meta de rôle. Adaptez le préfixe wp_ si besoin.

# À exécuter dans phpMyAdmin / Adminer (lecture seule)
# Remplacez wp_ par votre préfixe.
SELECT u.ID, u.user_login, u.user_email
FROM wp_users u
JOIN wp_usermeta um ON um.user_id = u.ID
WHERE um.meta_key = 'wp_capabilities'
AND um.meta_value LIKE '%administrator%';

Logs serveur : détecter brute force / credential stuffing

Sur Apache/Nginx, cherchez :

beaucoup de hits sur /wp-login.php (POST),
beaucoup de hits sur /xmlrpc.php,
des rafales depuis une même IP, ou au contraire une dispersion mondiale (botnet).

Exemple (si vous avez SSH) :

# Chercher les POST sur wp-login.php (chemin de log à adapter)
grep "POST /wp-login.php" /var/log/nginx/access.log | tail -n 50

Tableau de diagnostic (symptômes réels)

Symptôme	Cause probable	Vérification	Solution
Vous recevez des emails “échec de connexion” en rafale	Force brute sur wp-login.php	Logs serveur, plugin de sécurité, trafic sur wp-login.php	2FA + limitation de tentatives + éventuellement restriction IP/WAF
Un nouvel admin apparaît	Identifiants compromis ou plugin vulnérable	Historique utilisateurs, logs, liste des plugins récemment installés	Révoquer accès, reset mots de passe, scan, réinstallation propre
Redirections “spam” aléatoires	Injection (plugin/thème) ou compte admin compromis	Comparer fichiers, vérifier plugins, chercher du code obfusqué	Nettoyage + restauration + durcissement + 2FA obligatoire
Vous êtes bloqué après activation 2FA	Pas de codes de secours / mauvaise config horaire TOTP	Vérifier l’heure du téléphone, tenter recovery codes	Récupération via admin secondaire, puis reconfigurer 2FA

Erreurs de sécurité fréquentes

Erreur	Risque	Solution
Réutiliser le même mot de passe WordPress que votre email	Compromission en chaîne (fuite ailleurs → accès WordPress)	Gestionnaire + mots de passe uniques (16–24+)
Activer 2FA sans sauvegarder les codes de récupération	Perte d’accès (vous-même)	Stocker recovery codes dans un gestionnaire + compte admin de secours
Coller du code sécurité dans le mauvais endroit (thème parent, plugin de snippets instable)	Protection désactivée à la mise à jour / écran blanc	Utiliser un mu-plugin ou un plugin custom dédié
Oublier un point-virgule en modifiant wp-config.php	Erreur fatale, site indisponible	Éditer via un vrai éditeur, sauvegarder, tester sur staging
Utiliser un hook inadapté (confusion actions/filtres)	Le code “ne marche pas” ou casse l’admin	Vérifier la doc des hooks, tester avec un environnement de dev
Désactiver XML-RPC alors qu’une intégration en dépend	Fonctionnalité cassée (app, automatisation)	Identifier les usages avant, désactiver progressivement	Préférer REST + auth moderne, ou whitelist IP
Tester des changements de login sur production sans sauvegarde	Lock-out (impossible de se connecter)	Sauvegarde + plan de rollback + admin secondaire
PHP trop ancien (ex : 7.x) sur un vieux mutualisé	Plugins 2FA/sécurité incompatibles, failles non corrigées	Vérifier “Outils → Santé du site”	Passer à PHP 8.1+ (minimum recommandé)
Suivre un ancien tutoriel qui modifie l’authentification	Régression sécurité + incompatibilités WP 6.9.x	Comparer avec la doc officielle	Revenir au login natif + plugin 2FA maintenu

Checklist de durcissement

Un mot de passe unique (16–24+ caractères) pour chaque compte WordPress.
2FA activée au minimum pour administrateurs et éditeurs.
Codes de récupération stockés hors du site (gestionnaire).
Compte admin de secours (email différent), protégé par 2FA, non utilisé au quotidien.
XML-RPC désactivé si inutile (filtre + blocage serveur).
Application Passwords désactivés si inutiles.
DISALLOW_FILE_EDIT activé dans wp-config.php.
Mises à jour WordPress / plugins / thèmes appliquées rapidement.
Backups automatiques testés (restauration vérifiée au moins une fois).
Surveillance des connexions (alertes email, logs, plugin sécurité).
Cache vidé après changements (plugin cache + cache serveur + navigateur), sinon vous “croyez” que rien n’a changé.

Que faire si le site est déjà compromis ?

Si vous suspectez une compromission, agissez comme si le mot de passe admin était déjà connu de l’attaquant. Le but : stopper l’hémorragie, reprendre le contrôle, puis réparer proprement.

Mettez le site en maintenance (ou bloquez temporairement l’admin). Si vous avez un WAF/CDN, activez un mode “Under Attack”/challenge sur /wp-login.php.
Sauvegardez une copie de l’état compromis (fichiers + base) avant nettoyage. Ça sert pour comprendre l’entrée et pour des preuves si besoin.
Changez immédiatement :
- mots de passe WordPress (tous les admins, puis tous les comptes),
- mot de passe FTP/SFTP/SSH,
- mot de passe base de données,
- mot de passe du compte hébergeur,
- clés API (SMTP, CDN, etc.).
Révoquez les sessions : déconnectez tous les utilisateurs. (Un plugin de sécurité le fait souvent ; sinon vous pouvez forcer la réauth en réinitialisant les mots de passe et en changeant les clés de salage.)
Vérifiez les utilisateurs : supprimez tout admin suspect, vérifiez les emails et les rôles.
Réinstallez proprement :
- téléchargez une copie propre de WordPress depuis wordpress.org/download,
- remplacez wp-admin et wp-includes (sans toucher à wp-content au début),
- réinstallez les plugins depuis leurs sources officielles,
- supprimez tout plugin/thème nul ou “nulled”.
Inspectez wp-content (c’est là que je trouve le plus de backdoors) :
- fichiers PHP récents dans uploads,
- code obfusqué (base64_decode, longues chaînes, eval),
- fichiers avec noms “wordpress.php”, “class.api.php”, etc.
Activez 2FA pour les comptes sensibles après reprise de contrôle, et imposez-la.
Demandez une revue : si le site est business-critical, faites auditer (logs, diff, IOC). Sans comprendre l’entrée, vous risquez une re-compromission.

Note : évitez les “cleaners” miracles qui modifient tout sans rapport. Préférez une restauration depuis un backup sain + mise à jour + durcissement. C’est souvent plus rapide et plus fiable.

Conseils de maintenance et compatibilité

Divi 5, Elementor et Avada n’empêchent pas la 2FA. Les problèmes viennent plutôt de :

la mise en cache agressive de pages de login (rare mais déjà vu sur des configs proxy),
des plugins de “custom login URL” mal codés,
des règles serveur trop strictes (CSP, blocage REST) qui cassent l’éditeur.

Bonnes pratiques qui tiennent dans le temps

Gardez WordPress à jour. Les correctifs de sécurité arrivent en mineur/patch. Suivez les annonces sur developer.wordpress.org/news (Security).
Minimisez les plugins. Chaque plugin est du code en plus, donc une surface en plus.
Évitez les snippets “auth” trouvés sur des blogs (surtout vieux). Sur WP 6.9.4, privilégiez les APIs et le login natif.
Performance : la 2FA ajoute une étape à la connexion, pas aux pages publiques. L’impact SEO est quasi nul. Le gros gain perf vient du blocage serveur (moins de PHP exécuté sur brute force).

Deux détails que beaucoup oublient

Heure du téléphone : le TOTP dépend du temps. Si l’horloge dérive, vos codes “sont faux”.
Priorité de hook : si vous ajoutez des filtres sécurité, un autre plugin peut passer avant/après et changer le comportement. Si quelque chose “ne marche pas”, vérifiez les priorités et testez en désactivant temporairement les plugins non essentiels.

Ressources

FAQ

Est-ce que WordPress 6.9.4 impose la 2FA nativement ?

Non. WordPress 6.9.4 fournit une base solide (rôles/capacités, nonces, stockage de mots de passe, REST, etc.), mais la 2FA est généralement ajoutée via un plugin maintenu. Évitez de la coder vous-même.

Quelle longueur de mot de passe choisir pour un administrateur ?

16 caractères minimum. Pour un compte admin, 20–24 caractères générés par un gestionnaire est un bon standard. La longueur bat presque toujours la “complexité” artificielle.

Une phrase de passe (passphrase) est-elle acceptable ?

Oui, si elle est longue, unique, et difficile à deviner. En pratique, un gestionnaire + mot de passe aléatoire reste plus fiable (moins de biais humains).

La 2FA va-t-elle ralentir mon site ?

Non pour vos visiteurs. Elle ajoute une étape uniquement à la connexion. L’impact serveur est négligeable comparé au coût d’une attaque par brute force non filtrée.

Je suis sur Elementor/Divi/Avada : la 2FA peut casser l’éditeur ?

Très rarement. Les soucis viennent plutôt d’un durcissement trop agressif (CSP “copier-coller”, blocage REST) ou d’un plugin de login exotique. Testez sur un compte non critique d’abord.

Dois-je désactiver XML-RPC ?

Si vous ne l’utilisez pas, oui : c’est une surface d’attaque en moins. Si vous avez une intégration qui en dépend, basculez vers REST quand possible ou limitez par IP/WAF.

Dois-je désactiver les Application Passwords ?

Si vous n’utilisez pas d’applications externes (automatisations, intégrations) qui en dépendent, les désactiver réduit la surface. Sinon, gardez-les et surveillez les comptes concernés.

Comment éviter de me bloquer avec la 2FA ?

Activez d’abord 2FA sur un compte admin secondaire, conservez les codes de récupération, et vérifiez que votre email admin est accessible. N’activez jamais 2FA “en dernier recours” en production sans plan B.

Est-ce que changer l’URL de wp-admin suffit ?

Non. C’est au mieux de l’obscurcissement. Ça peut réduire le bruit dans les logs, mais ça ne remplace ni un mot de passe fort, ni la 2FA, ni la mise à jour des plugins.

Que faire si je vois des tentatives de connexion toutes les minutes ?

Activez 2FA, ajoutez une limitation de tentatives (plugin/WAF), bloquez XML-RPC si inutile, et vérifiez que vos admins ont des mots de passe uniques. Ensuite, regardez les logs pour confirmer que les échecs ne deviennent pas des succès.

J’ai collé un code trouvé sur internet et j’ai une erreur critique : que faire ?

Si c’est dans functions.php, renommez temporairement le thème via FTP (ou restaurez le fichier), puis déplacez le code dans un mu-plugin propre. Souvent, l’erreur vient d’un point-virgule manquant ou d’une fonction appelée trop tôt.