Sécuriser les comptes administrateurs WordPress : rôles, 2FA et accès prestataires

Un accès administrateur WordPress permet de modifier les réglages du site, gérer les utilisateurs et, sur une installation classique, installer ou activer des extensions et des thèmes. Protéger wp-admin ne consiste donc pas seulement à choisir un mot de passe difficile : il faut décider qui dispose réellement de ces privilèges, comment chaque personne s’authentifie, quels accès sont accordés aux prestataires et comment ils sont révoqués.

Le risque le plus fréquent n’est pas nécessairement un piratage spectaculaire. Il peut s’agir d’un ancien compte toujours actif, d’un identifiant partagé entre plusieurs personnes, d’un administrateur utilisé pour une tâche qui ne l’exige pas, d’une session oubliée sur un ordinateur, d’un mot de passe d’application créé pour une intégration ou d’un accès prestataire jamais fermé après la mission.

La bonne méthode repose sur cinq principes : un compte nominatif par personne, le minimum de privilèges nécessaire, une authentification multifacteur, un cycle de vie clair pour les accès temporaires et une surveillance des changements sensibles. Ces règles doivent aussi s’appliquer à l’hébergement, à la messagerie, au DNS et aux outils connectés, car la 2FA de WordPress ne protège pas ces autres portes d’entrée.

Ce guide explique comment sécuriser les comptes administrateurs WordPress, déployer la 2FA sans bloquer les utilisateurs et encadrer les accès des agences, freelances et prestataires. Pour une vérification complète de votre configuration, consultez également la prestation Sécurisation WordPress.

Pourquoi les comptes administrateurs sont-ils une cible prioritaire ?

Le rôle Administrateur concentre des capacités qui permettent de modifier profondément un site. Sur une installation WordPress simple, il peut notamment gérer les extensions, les thèmes, les utilisateurs et de nombreux réglages. Sur un réseau multisite, les privilèges les plus élevés appartiennent au Super Admin. La documentation officielle distingue clairement ces rôles et les capacités qui leur sont associées.

Un attaquant qui prend le contrôle d’un compte privilégié peut parfois agir sans exploiter une nouvelle faille technique : ajouter un utilisateur, installer une extension, modifier une option, injecter du code dans un contenu, créer un mot de passe d’application ou désactiver un contrôle de sécurité. La documentation WordPress sur les rôles et capacités rappelle qu’un administrateur dispose de l’ensemble des fonctions d’administration d’un site simple.

Le niveau de protection doit donc être proportionnel à ce pouvoir. Un compte utilisé une fois par mois pour installer une mise à jour ne doit pas rester connecté sur plusieurs appareils ni partager le même mot de passe avec un compte éditorial utilisé tous les jours.

Commencer par inventorier tous les accès privilégiés

Avant de modifier les rôles ou d’imposer la 2FA, établissez une photographie de la situation. L’inventaire doit couvrir les comptes humains, les comptes de service et les accès extérieurs à WordPress.

Pour chaque compte, relevez au minimum :

• le nom de la personne ou du service responsable ;
• l’adresse e-mail et le rôle affiché ;
• les capacités particulières éventuellement ajoutées ;
• la date de création et la dernière utilisation connue ;
• la présence d’une 2FA, de codes de récupération et de méthodes secondaires ;
• les sessions actives et appareils utilisés ;
• les mots de passe d’application ou intégrations rattachés ;
• la justification métier de l’accès ;
• la date de prochaine révision ou de fin de mission.

Un compte dont personne ne connaît le propriétaire ne doit pas être conservé par prudence indéfiniment. Il doit être documenté, neutralisé si nécessaire et vérifié avant suppression afin de ne pas interrompre une automatisation légitime ou effacer des éléments utiles à un diagnostic.

Un compte nominatif pour chaque personne, jamais un identifiant partagé

Partager un compte « admin » entre le dirigeant, l’agence et plusieurs salariés empêche d’attribuer les actions à une personne précise. Il devient également impossible de retirer l’accès d’un intervenant sans changer le mot de passe pour tout le monde.

Chaque utilisateur doit disposer de son propre compte, même pour une mission courte. Cette séparation permet de :

• révoquer un seul accès sans perturber les autres ;
• appliquer une méthode 2FA propre à chaque personne ;
• identifier l’origine d’une modification dans les journaux disponibles ;
• adapter les droits à la mission ;
• imposer une date de fin ou de révision ;
• éviter la circulation d’un mot de passe commun par e-mail ou messagerie.

Les comptes génériques ne se justifient que pour certains usages techniques, et ils doivent alors être traités comme des comptes de service : propriétaire identifié, privilèges minimaux, secret distinct, usage documenté, absence de connexion humaine normale et révocation possible.

Qui doit réellement conserver le rôle Administrateur ?

Le principe du moindre privilège consiste à attribuer uniquement les capacités nécessaires à la tâche. Il ne faut pas donner le rôle Administrateur par défaut à une personne qui publie des contenus, traite des commandes ou consulte des statistiques.

Besoin réel	Rôle ou approche à privilégier	Pourquoi éviter Administrateur
Propriétaire technique du site	Administrateur nominatif fortement protégé	Ce compte doit pouvoir gérer les composants et les utilisateurs, mais rester peu utilisé
Rédaction et publication	Éditeur, Auteur ou rôle personnalisé	La gestion des extensions, thèmes et comptes n’est pas nécessaire
Gestion courante d’une boutique	Shop Manager lorsque ses capacités conviennent	WooCommerce prévoit ce rôle pour gérer la boutique sans donner tous les pouvoirs WordPress
Intervention technique ponctuelle	Compte temporaire avec droits adaptés à la mission	L’accès ne doit pas survivre au devis, au ticket ou à la période d’intervention
SEO ou analytics	Accès aux outils externes et rôle WordPress limité	La plupart des actions SEO ne nécessitent pas la gestion des utilisateurs ou des extensions
Automatisation ou API	Compte de service dédié et mot de passe d’application	Le secret doit être révocable indépendamment et associé à un utilisateur aux droits minimaux
Support ou formation	Compte de démonstration limité	Un environnement de formation ne doit pas exposer les réglages sensibles

WooCommerce ajoute notamment le rôle Shop Manager pour gérer les produits, commandes, remboursements et plusieurs fonctions de la boutique sans accorder automatiquement le rôle Administrateur. Il faut néanmoins vérifier ses capacités réelles et les extensions installées, comme le précise la documentation WooCommerce sur les rôles.

Dans un site très personnalisé, un rôle sur mesure peut être préférable. Il doit être documenté et testé avec un compte de contrôle afin de vérifier ce que l’utilisateur peut réellement voir et modifier.

La 2FA protège quoi, et que ne protège-t-elle pas ?

L’authentification à deux facteurs ajoute une seconde preuve après le mot de passe. Si le mot de passe est volé, réutilisé ou deviné, l’attaquant ne peut pas se connecter sans ce second élément.

La 2FA réduit donc fortement le risque lié aux fuites de mots de passe, aux attaques par force brute et à la réutilisation d’identifiants. La documentation WordPress recommande son activation pour les administrateurs et les utilisateurs privilégiés. Le cœur de WordPress ne fournit toutefois pas encore cette fonction nativement : elle doit être apportée par une extension maintenue, un fournisseur d’identité ou un système SSO.

Elle ne protège pas automatiquement :

• un poste déjà compromis après la connexion ;
• une session WordPress déjà volée ou laissée ouverte ;
• un accès SFTP, SSH, hébergement, DNS ou messagerie ;
• un mot de passe d’application utilisé par une API ;
• une extension vulnérable exploitée sans authentification ;
• un administrateur légitime qui valide lui-même une action frauduleuse ;
• une mauvaise attribution de rôles ou des droits excessifs.

La 2FA est donc une couche essentielle, mais elle doit être intégrée à une politique globale des accès.

Quelle méthode 2FA choisir pour WordPress ?

Toutes les méthodes ne résistent pas de la même manière au phishing, à la perte du téléphone ou à la compromission de la messagerie. Le choix doit tenir compte de la criticité du compte et de la capacité de récupération de l’organisation.

Méthode	Avantages	Limites	Usage conseillé
Passkey ou clé de sécurité WebAuthn	Résistance élevée au phishing, liée au domaine, expérience rapide	Compatibilité à vérifier, prévoir au moins un second authentificateur	Administrateurs principaux, comptes très sensibles et prestataires réguliers
Application TOTP	Standard répandu, fonctionne hors ligne, simple à déployer	Le code peut être saisi sur une fausse page et reste donc phishable	Choix pragmatique pour la majorité des administrateurs
Code envoyé par e-mail	Déploiement facile, pas d’application dédiée	Dépend de la sécurité de la boîte e-mail et du bon acheminement	Méthode transitoire ou secondaire, pas unique pour les comptes critiques
SMS ou appel	Accessible à de nombreux utilisateurs	Dépend du réseau mobile et présente des risques de détournement	Solution de secours selon le contexte, pas premier choix pour les privilèges élevés
Codes de récupération	Permettent de reprendre l’accès sans appareil principal	Doivent être stockés avant l’incident et utilisés une seule fois	Méthode de secours obligatoire, conservée séparément
SSO avec MFA	Gestion centralisée des départs, politiques et authentificateurs	Configuration plus complexe et dépendance au fournisseur d’identité	Équipes structurées, plusieurs sites ou parc important

Les recommandations NIST distinguent les méthodes OTP, qui ne sont pas résistantes au phishing, des authentificateurs cryptographiques comme WebAuthn qui peuvent l’être. Pour un compte très privilégié, une passkey ou une clé de sécurité constitue donc une protection plus robuste lorsqu’elle est correctement intégrée. Le référentiel NIST SP 800-63B décrit cette différence.

Le plugin communautaire Two Factor disponible sur WordPress.org illustre plusieurs options courantes, notamment TOTP, codes par e-mail et codes de récupération. Le choix d’une extension doit néanmoins reposer sur sa maintenance, sa compatibilité, la possibilité d’imposer la 2FA par rôle et la qualité de la procédure de récupération.

Déployer la 2FA sans bloquer les administrateurs

Une activation brutale sur tous les comptes peut provoquer des blocages, surtout lorsque les utilisateurs n’ont pas préparé de méthode de secours. Le déploiement doit être organisé comme un changement de sécurité, pas comme une simple case à cocher.

1. choisir la solution et vérifier sa compatibilité avec la version de WordPress, le multisite, WooCommerce, les connexions SSO et les extensions de sécurité ;
2. tester la configuration sur une préproduction ou sur un compte administrateur secondaire ;
3. activer deux méthodes de récupération lorsque cela est possible ;
4. générer les codes de secours et vérifier qu’ils sont stockés hors du site ;
5. inscrire d’abord les propriétaires techniques et les administrateurs réguliers ;
6. prévoir une période de grâce courte et une date d’obligation pour les autres comptes privilégiés ;
7. tester la connexion, la déconnexion, la récupération et la révocation d’un appareil ;
8. documenter la procédure d’assistance et identifier qui peut réinitialiser la 2FA d’un autre utilisateur ;
9. supprimer les méthodes faibles ou temporaires après stabilisation.

Ne conservez pas un compte administrateur exempté de 2FA simplement « au cas où ». Le compte de récupération doit être fortement protégé, peu utilisé et surveillé, avec une procédure d’accès documentée.

Gérer correctement les accès des prestataires

Une agence, un développeur, un consultant SEO ou un support d’extension ne doit pas utiliser le compte personnel du dirigeant. Chaque prestataire reçoit un compte nominatif ou un compte d’équipe clairement attribué, limité à la mission et soumis à une date de révision.

Avant d’ouvrir l’accès, définissez :

• le périmètre exact de l’intervention ;
• le rôle nécessaire et les capacités supplémentaires éventuelles ;
• la durée prévue et la date de fin ;
• les environnements concernés : production, préproduction ou multisite ;
• les accès complémentaires : hébergement, SFTP, SSH, base, DNS, CDN ou Search Console ;
• la méthode sécurisée de transmission des secrets ;
• les règles de journalisation et de sauvegarde ;
• la personne interne qui valide la fermeture de l’accès.

Un accès permanent « pour les prochaines fois » augmente inutilement la surface d’exposition. Un compte peut être recréé ou réactivé lors d’une nouvelle mission, avec des droits adaptés au besoin du moment.

Checklist d’ouverture et de fermeture d’un accès prestataire

Étape	À l’ouverture	À la fermeture
Identité	Compte nominatif, e-mail professionnel, responsable identifié	Confirmer la fin de mission et le propriétaire des livrables
Droits	Rôle minimal et capacités documentées	Retirer le rôle, désactiver ou supprimer le compte
2FA	Enrôlement obligatoire avant accès à la production	Révoquer les méthodes et appareils associés
Sessions	Limiter les appareils et éviter les postes partagés	Détruire toutes les sessions actives
Applications	Créer un secret séparé par intégration si nécessaire	Révoquer les mots de passe d’application et clés API
Accès serveur	Compte SFTP ou SSH individuel avec permissions limitées	Désactiver la clé ou le compte technique
Sauvegarde	Point de retour avant intervention	Conserver le rapport et la sauvegarde selon la politique
Traçabilité	Ticket, devis ou ordre de mission lié au compte	Noter la date de fermeture et les vérifications réalisées

Lorsque des identifiants ont malgré tout été partagés, leur rotation doit faire partie de la clôture. Changer uniquement le mot de passe WordPress ne suffit pas si le même intervenant connaissait aussi les accès à l’hébergement, au DNS ou à la messagerie.

Ne pas confondre compte humain et compte de service

Les outils de publication, applications mobiles, connecteurs, automatisations et services externes ne devraient pas utiliser le mot de passe principal d’un administrateur humain.

Depuis WordPress 5.6, les mots de passe d’application permettent à un service de s’authentifier auprès de l’API REST via HTTPS. Chaque secret peut être nommé et révoqué indépendamment du mot de passe principal. Il hérite toutefois des capacités du compte auquel il est rattaché : il n’est pas automatiquement limité à une seule action.

La meilleure pratique consiste donc à :

• créer un compte de service distinct pour chaque intégration importante ;
• lui attribuer uniquement les capacités nécessaires ;
• nommer clairement chaque mot de passe d’application ;
• conserver la date de création, l’outil, le propriétaire et la dernière utilisation ;
• révoquer les secrets inutilisés ou liés à un ancien prestataire ;
• ne pas considérer la 2FA du login comme une protection de ces secrets API.

WP-CLI permet de lister, créer, modifier et supprimer les mots de passe d’application d’un utilisateur. La documentation de la commande correspondante peut être utilisée pendant un audit technique.

Contrôler les sessions actives et les appareils

Changer un mot de passe ou activer la 2FA ne ferme pas nécessairement toutes les sessions déjà ouvertes selon le scénario et les extensions utilisées. Lors d’un départ, d’un doute ou d’un durcissement initial, révoquez explicitement les sessions du compte.

Les points à vérifier sont :

• les appareils personnels et professionnels utilisés ;
• les navigateurs partagés ou les postes d’agence ;
• les sessions anciennes encore actives ;
• les connexions depuis des pays ou adresses inhabituels ;
• les cookies conservés après une modification de rôle ;
• les sessions des comptes ayant changé de propriétaire.

WP-CLI permet de lister les sessions d’un utilisateur et de les détruire individuellement ou en totalité. La commande officielle wp user session facilite ce contrôle lorsque l’accès serveur est disponible.

Après une révocation, testez que l’utilisateur est bien déconnecté et qu’il ne peut pas reprendre l’accès par une autre méthode, un mot de passe d’application ou un compte parallèle.

Étendre la MFA au-delà de WordPress

Le compte WordPress n’est qu’une partie de la chaîne d’administration. Un attaquant qui contrôle la boîte e-mail peut demander une réinitialisation de mot de passe. Un accès à l’hébergement peut modifier les fichiers ou la base sans passer par wp-admin. Un accès DNS peut détourner le domaine.

Activez une authentification forte et des comptes nominatifs sur :

• l’espace client de l’hébergeur ;
• le registrar et la gestion DNS ;
• la messagerie associée aux comptes administrateurs ;
• le CDN, le WAF et les outils de sauvegarde ;
• les prestataires de paiement et outils WooCommerce ;
• Search Console, Analytics et les services marketing ;
• les dépôts Git, plateformes de déploiement et gestionnaires de secrets.

Évitez d’utiliser la même adresse e-mail et le même mot de passe partout. La compromission d’un service périphérique ne doit pas permettre de reconstituer immédiatement l’ensemble de la chaîne d’accès.

Cas particulier de WooCommerce

Une boutique cumule les privilèges WordPress et des fonctions métier sensibles : commandes, remboursements, données clients, coupons, produits et intégrations de paiement. Tous les utilisateurs qui traitent ces opérations ne doivent pas être Administrateurs.

Le rôle Shop Manager peut convenir à la gestion courante, mais il reste puissant. Il doit lui aussi être nominatif, protégé par 2FA et revu régulièrement. Les droits peuvent être élargis par des extensions, notamment pour les abonnements, la marketplace, la facturation ou la logistique.

Les comptes qui peuvent rembourser une commande, modifier les coordonnées bancaires, gérer des clés API ou accéder aux données clients doivent être considérés comme privilégiés même s’ils ne portent pas le rôle Administrateur.

Cas particulier du multisite WordPress

Dans un réseau multisite, le Super Admin dispose de pouvoirs sur l’ensemble du réseau. Il peut notamment gérer les sites, les utilisateurs du réseau, les extensions et les thèmes à l’échelle globale. Ce rôle doit être réservé à un nombre très limité de personnes.

L’audit doit distinguer :

• les super-administrateurs du réseau ;
• les administrateurs de chaque site ;
• les comptes présents sur plusieurs sites ;
• les rôles personnalisés et capacités réseau ;
• les extensions obligatoires et outils d’administration centralisée ;
• les intégrations qui utilisent un compte global.

Un administrateur local ne doit pas recevoir le rôle Super Admin pour contourner un problème de permission. Corrigez plutôt la capacité manquante ou le processus d’intervention.

Surveiller les événements liés aux comptes privilégiés

WordPress ne fournit pas à lui seul un journal d’audit exhaustif de toutes les actions administratives. Selon la criticité du site, utilisez une solution de journalisation maintenue, les journaux de l’hébergeur et les logs des outils externes.

Les événements prioritaires sont :

• création, suppression ou réactivation d’un utilisateur ;
• passage vers Administrateur, Super Admin ou Shop Manager ;
• ajout ou retrait de capacités directes ;
• réinitialisation de mot de passe ;
• activation, désactivation ou réinitialisation de la 2FA ;
• création et utilisation d’un mot de passe d’application ;
• connexion depuis un appareil, pays ou plage IP inhabituelle ;
• modification d’une adresse e-mail administrateur ;
• installation d’une extension ou modification d’un réglage de sécurité.

Une alerte doit conduire à une vérification humaine, pas seulement à l’accumulation de journaux. Définissez qui reçoit les notifications et dans quel délai une modification sensible doit être confirmée.

À quelle fréquence revoir les comptes administrateurs ?

Fréquence	Contrôle recommandé	Déclencheur supplémentaire
Chaque mois	Comptes privilégiés, nouvelles sessions, mots de passe d’application et alertes	Site e-commerce, données sensibles ou interventions fréquentes
Chaque trimestre	Justification des rôles, anciens prestataires, comptes de service et méthodes 2FA	Changement d’équipe ou de prestataire
Après chaque mission	Fermeture des accès temporaires et révocation des secrets	Livraison, ticket clôturé ou contrat terminé
Immédiatement	Révocation des sessions, mots de passe et intégrations	Départ, appareil perdu, compte suspect ou incident
Avant une migration	Inventaire complet des accès et propriétaires	Changement d’hébergeur, d’agence ou de domaine
Après restauration	Vérifier que d’anciens comptes ou secrets n’ont pas été réintroduits	Retour à une sauvegarde antérieure

La revue doit produire une décision explicite pour chaque compte : conserver, réduire, suspendre, supprimer ou transformer en compte de service.

Les erreurs fréquentes qui fragilisent wp-admin

Conserver plusieurs administrateurs « au cas où »

Un compte inutilisé n’est pas une assurance de continuité. C’est un accès supplémentaire à protéger, surveiller et révoquer. Conservez seulement les comptes nécessaires, avec une procédure de récupération documentée.

Partager un mot de passe dans un e-mail ou un tableur

Le secret se propage alors dans les boîtes, historiques, sauvegardes et appareils. Utilisez un gestionnaire de mots de passe ou un canal de partage sécurisé et créez des comptes distincts.

Activer la 2FA sans codes de secours

La sécurité devient dépendante d’un téléphone ou d’une application unique. La perte de l’appareil peut provoquer une interruption, surtout si personne ne maîtrise la procédure de réinitialisation.

Croire que la 2FA protège l’hébergement et les API

Les autres services disposent de leurs propres mécanismes d’authentification. Les mots de passe d’application, clés API, SFTP, SSH et comptes d’hébergement doivent être contrôlés séparément.

Donner Administrateur pour gagner du temps

Cette habitude transforme chaque compte éditorial ou prestataire en point de compromission potentiel. Commencez par le rôle minimal et augmentez les droits seulement lorsqu’une tâche précise le justifie.

Supprimer un prestataire sans révoquer ses autres accès

Le compte WordPress n’est parfois qu’un élément du périmètre. Vérifiez aussi les sessions, applications, clés API, SFTP, SSH, hébergement, DNS, Git, Search Console et outils de paiement.

Installer plusieurs extensions de sécurité sans gouvernance

Les plugins ne remplacent pas l’inventaire des comptes, l’offboarding ni la responsabilité interne. Une politique claire avec une solution maintenue vaut mieux qu’une accumulation de contrôles non suivis.

Plan de mise en œuvre en quatre étapes

Étape 1 — Inventaire et réduction

Listez tous les comptes, identifiez leurs propriétaires, réduisez les rôles excessifs et supprimez les comptes manifestement obsolètes après vérification.

Étape 2 — Authentification et récupération

Activez la 2FA sur les comptes privilégiés, préparez les codes de secours, inscrivez deux authentificateurs pour les comptes critiques et testez la procédure de récupération.

Étape 3 — Prestataires et intégrations

Créez des comptes nominatifs, fixez des dates de fin, séparez les comptes de service, auditez les mots de passe d’application et révoquez les secrets inutilisés.

Étape 4 — Surveillance et revue

Activez les journaux nécessaires, définissez les alertes, planifiez une revue trimestrielle et intégrez la fermeture des accès à chaque fin de mission ou départ.

Ce qu’un audit des accès doit vérifier

Une vérification sérieuse ne s’arrête pas au nombre de comptes Administrateur. Elle doit rapprocher les droits techniques des responsabilités réelles et des intégrations utilisées.

• liste complète des utilisateurs, rôles et capacités directes ;
• super-administrateurs en multisite ;
• comptes partagés, génériques ou sans propriétaire ;
• méthodes 2FA, exemptions, codes de secours et procédure de récupération ;
• sessions actives et appareils connus ;
• mots de passe d’application et dernière utilisation ;
• comptes de service, webhooks, API et automatisations ;
• accès prestataires et dates de fin ;
• accès hébergement, SFTP, SSH, DNS et messagerie ;
• journaux disponibles et alertes configurées ;
• processus d’entrée, changement de rôle et départ d’un utilisateur.

Pour comprendre le périmètre global d’une mission, consultez également Que vérifie réellement un audit de sécurité WordPress ?.

Les informations à préparer pour sécuriser les accès

Rassemblez avant l’intervention :

• l’URL du site et l’existence éventuelle d’un multisite ;
• la liste des personnes et prestataires qui interviennent actuellement ;
• les rôles dont chacun pense avoir besoin ;
• les solutions 2FA, SSO ou gestionnaires de mots de passe déjà utilisées ;
• les accès externes : hébergement, DNS, SFTP, SSH, Search Console et paiement ;
• les intégrations, applications mobiles, API et outils d’automatisation ;
• les départs récents, appareils perdus ou comptes douteux ;
• la procédure actuelle de récupération et le propriétaire du compte principal.

Ne transmettez pas les mots de passe dans le formulaire initial. Les accès éventuellement nécessaires doivent être demandés séparément, limités dans le temps et remplacés ou révoqués après l’intervention.

Questions fréquentes

Combien de comptes administrateurs faut-il conserver ?

Le minimum nécessaire pour assurer l’exploitation et la récupération. Pour une petite structure, un propriétaire technique et éventuellement un second compte de secours fortement protégé peuvent suffire. Les autres utilisateurs doivent recevoir un rôle adapté à leurs tâches.

Faut-il activer la 2FA uniquement pour les administrateurs ?

Commencez par les Administrateurs, Super Admins, Shop Managers et comptes pouvant modifier des utilisateurs, paiements, données sensibles ou intégrations. Étendez-la ensuite aux autres profils selon le risque et les possibilités de la solution.

Une application TOTP suffit-elle ?

Elle apporte une amélioration importante par rapport au mot de passe seul. Elle n’est toutefois pas résistante au phishing. Pour les comptes les plus critiques, privilégiez une passkey ou une clé de sécurité compatible, avec un second authentificateur de secours.

Peut-on garder un compte administrateur commun pour l’agence ?

Ce n’est pas recommandé. Créez un compte nominatif pour chaque intervenant ou, à défaut, un compte d’équipe clairement attribué, protégé par 2FA, limité à la mission et fermé lorsque l’intervention est terminée.

La 2FA protège-t-elle les mots de passe d’application ?

Non, ces secrets sont utilisés séparément pour les API et intégrations. Ils doivent être recensés, rattachés à des comptes de service aux droits minimaux et révoqués lorsqu’ils ne sont plus nécessaires.

Que faire lorsqu’un prestataire a besoin du rôle Administrateur ?

Accordez-le uniquement pendant la période où la tâche l’exige, avec un compte nominatif et une 2FA. Préservez une sauvegarde, documentez la mission, puis réduisez ou supprimez le compte et révoquez toutes les sessions en fin d’intervention.

Faut-il changer l’URL de connexion wp-admin ?

Cela peut réduire une partie du bruit automatisé selon la configuration, mais ce n’est pas une protection suffisante. Les comptes nominatifs, les rôles minimaux, la 2FA, la limitation des tentatives, la mise à jour des composants et la surveillance restent prioritaires.

Que faire si un administrateur inconnu apparaît ?

Considérez-le comme un incident potentiel. Conservez les informations utiles, neutralisez les privilèges et les sessions, contrôlez les autres accès et recherchez l’origine de la création. Suivez le guide Administrateur inconnu WordPress plutôt que de simplement supprimer le compte.