Un compte inconnu demande une vérification, puis une décision
Vous découvrez un administrateur dont le nom ne vous dit rien dans WordPress. Ce constat mérite une vérification rapide : ce compte peut disposer de pouvoirs importants. Il peut toutefois appartenir à un prestataire autorisé, provenir d’une migration ou correspondre à une intervention oubliée. Son nom ne permet pas, à lui seul, de conclure à un piratage.
Le résultat recherché est de savoir qui a autorisé cet accès, de limiter les possibilités d’une intervention non autorisée et de conserver les éléments nécessaires à l’enquête. Supprimer le compte immédiatement peut retirer des informations utiles et affecter les contenus qui lui sont attribués.
Commencez par prévenir le propriétaire ou le responsable technique connu. Si des modifications dangereuses sont en cours, demandez simultanément un confinement à l’hébergeur : la recherche d’explications ne doit pas laisser une attaque se poursuivre.
Confirmer le site, le compte et les accès disponibles
Ouvrez l’administration par votre adresse habituelle, saisie directement ou conservée dans un favori fiable. Vérifiez le domaine : production et préproduction peuvent porter le même titre. Ne suivez pas un lien reçu dans un courriel suspect pour effectuer cette vérification.
Avec un compte autorisé à gérer les utilisateurs, ouvrez Comptes, puis Tous les comptes ; le menu peut s’appeler Utilisateurs. Filtrez les administrateurs, puis revenez à la liste complète si nécessaire. Comparez l’identifiant de connexion, le nom affiché et le rôle : ces informations ne sont pas interchangeables.
Relevez la version de WordPress et les outils d’authentification présents. Les écrans décrits concernent principalement un site autohébergé. WordPress.com et le multisite possèdent des particularités détaillées plus loin. Si la liste est inaccessible avec votre compte, transmettez le constat au responsable ; n’empruntez pas son mot de passe et ne tentez pas de vous promouvoir.
Constituer un relevé privé avant les changements
Pour chaque compte concerné, notez le site, l’identifiant, le rôle observé et l’heure de découverte avec le fuseau. Lorsque l’identifiant numérique est accessible dans l’adresse d’édition du compte, conservez-le aussi. Il aide à suivre le même enregistrement malgré un changement de nom affiché.
Gardez une capture datée de la fiche et des informations utiles, dans un dossier privé accessible seulement aux personnes chargées du dossier. Relevez l’adresse électronique lorsque cela est nécessaire à l’identification, sans chercher à collecter toutes les données personnelles des utilisateurs.
Séparez les faits des suppositions : « compte vu ce matin » ne signifie pas « compte créé ce matin ». Notez les interventions récentes connues et chaque action effectuée ensuite. Ne publiez ni liste de comptes, ni adresse personnelle, ni journal complet sur un forum. Cookies, jetons et mots de passe n’ont pas leur place dans ce relevé.
Préserver l’état actuel et les anciennes sauvegardes
Dans le panneau d’hébergement, ou par son support authentifié, demandez une copie des fichiers et de la base avant les opérations risquées. Faites conserver les journaux disponibles avant leur rotation, c’est-à-dire leur remplacement automatique. Une capture de la liste des comptes ne remplace pas cette préservation.
Nommez la nouvelle copie comme un état observé potentiellement compromis. Elle sert à l’analyse et à la conservation des données récentes ; elle ne doit pas être présentée comme une sauvegarde saine. Protégez son emplacement et demandez qui peut y accéder. Faites garder une copie hors du répertoire public et, si possible, hors de l’accès potentiellement compromis. Conservez les fichiers exportés d’origine et travaillez sur des copies pour l’analyse ; notez qui a réalisé l’export et à quel moment.
Gardez séparément les sauvegardes antérieures. Ne restaurez pas toute la base pour faire disparaître un utilisateur : commandes, inscriptions et contenus récents pourraient être perdus. L’analyse d’une ancienne copie doit se faire dans un environnement isolé, avec base distincte, accès protégé et paiements, courriels et intégrations réelles neutralisés.
Choisir entre trois parcours
Le premier parcours convient lorsque le propriétaire identifie le compte et retrouve une intervention autorisée. Il consiste à documenter sa mission et à ajuster les privilèges réellement nécessaires. Une identité reconnue ne dispense pas de vérifier une activité inhabituelle.
Le deuxième s’applique lorsque l’origine reste incertaine, sans dommage observé. Il associe une vérification par des contacts connus, la consultation des traces existantes et, avec le responsable, une restriction temporaire adaptée. Définissez qui doit répondre et quand réévaluer la situation ; ne laissez pas le doute sans suivi.
Le troisième devient prioritaire si le propriétaire refuse cet accès, si des changements non autorisés apparaissent ou si l’hébergeur signale une intrusion. Faites traiter le site comme un incident, avec confinement et investigation. Ces parcours répondent à des niveaux de preuve différents ; ils ne sont pas trois manipulations à appliquer successivement à tous les comptes.
Parcours 1 : confirmer une intervention légitime
Contactez le propriétaire, l’agence ou l’hébergeur par les coordonnées déjà présentes dans vos documents habituels. N’utilisez pas comme seule référence l’adresse du compte suspect. Demandez quel identifiant exact a été utilisé, pour quelle mission, à quelle période et avec quelle autorisation.
Rapprochez la réponse d’un ticket, d’une demande de maintenance ou d’une migration effectivement réalisée. Un nom comme « support » ne prouve rien ; une facture générale ne confirme pas automatiquement cet accès précis. Si le prestataire ne reconnaît pas le compte ou si les éléments se contredisent, passez au deuxième ou au troisième parcours.
Lorsque la mission est confirmée, inscrivez son responsable et sa date de fin dans le registre des accès. Si une activité reste inexpliquée, poursuivez sa vérification : un compte légitime peut aussi avoir été utilisé par un tiers.
Ajuster un compte reconnu sans supprimer son contenu
Pour un accès légitime devenu trop large, un administrateur autorisé ouvre sa fiche depuis Tous les comptes, relève le rôle actuel et choisit le rôle convenu avec le propriétaire. Il enregistre uniquement ce changement. Évitez les sélections collectives : plusieurs personnes peuvent avoir des missions différentes.
Choisissez les privilèges selon le travail restant, pas selon la facilité. Une personne chargée de relire des articles n’a pas nécessairement besoin d’administrer les utilisateurs ou les extensions. Si les rôles ont été personnalisés, faites confirmer leurs capacités par le mainteneur.
Faites ensuite vérifier l’action attendue avec le compte de la personne concernée, sans partager ses identifiants. Si le rôle choisi ne convient pas, corrigez l’attribution après accord. Un retour au rôle antérieur exige une justification ; il ne doit pas devenir une promotion automatique pour faire disparaître un refus.
Parcours 2 : chercher l’origine dans les traces disponibles
Consultez les tickets de maintenance, les notifications conservées et les journaux déjà présents. Demandez au responsable de rapprocher les créations ou promotions de comptes des interventions connues. Un journal d’activité installé après la découverte ne peut pas reconstituer les événements qu’il n’enregistrait pas auparavant.
Une date d’inscription est distincte d’une date de dernière connexion. Elle ne prouve pas non plus le moment d’une promotion administrateur. Demandez la signification exacte de chaque colonne : certaines informations viennent d’une extension ou de l’hébergeur.
Une adresse réseau peut aider à rapprocher des événements, mais ne désigne pas nécessairement une personne. L’absence de trace peut résulter d’une rétention courte ou d’un événement non enregistré. Faites qualifier ces limites plutôt que de conclure « aucun problème ». Si l’origine reste inconnue, convenez d’une restriction et d’une vérification assistée sans attendre indéfiniment une réponse du prestataire.
Réduire temporairement les privilèges sans effacer le compte
Sur un site autohébergé simple, après préservation et accord du responsable, un autre administrateur fiable peut ouvrir la fiche concernée et sélectionner « Aucun rôle pour ce site », lorsque cette option est disponible. Enregistrez le changement, puis rouvrez la fiche pour confirmer la valeur. Conservez le rôle précédent dans le relevé privé.
Cette mesure retire les droits liés au rôle, tout en préservant le compte et ses contenus. Elle n’empêche pas nécessairement l’authentification et ne constitue pas un verrouillage complet. Des capacités attribuées directement au compte peuvent subsister après le retrait du rôle. Faites vérifier ces droits individuels et les mécanismes de connexion externe par le mainteneur. Le rôle Abonné conserve lui aussi un accès ; ne le présentez pas comme un blocage total.
Si l’option manque, si le compte possède des privilèges réseau ou si le réglage revient tout seul, demandez l’intervention de l’hébergeur. Ne supprimez pas le compte pour contourner cette difficulté. Une réattribution ultérieure attendra la clarification de son origine.
Fermer les sessions du bon utilisateur
Une session permet à un navigateur déjà connecté de continuer à agir sans ressaisir constamment le mot de passe. Après conservation des traces utiles, ouvrez la fiche du compte visé avec un administrateur autorisé. Si la rubrique Sessions propose « Déconnecter partout », vérifiez soigneusement le compte avant d’utiliser ce bouton.
Sur votre propre profil, « Déconnecter partout ailleurs » vise vos autres sessions et conserve la session courante. Ce bouton ne déconnecte pas tous les administrateurs du site. Son absence ou son état désactivé ne suffit pas à établir qu’aucun autre moyen d’accès n’existe.
Consignez l’heure et le résultat affiché. Si le bouton échoue ou si vous ne pouvez pas modifier cet utilisateur, faites révoquer ses sessions par le mainteneur. Leur fermeture ne change pas, à elle seule, le secret permettant une nouvelle connexion : elle doit accompagner le traitement de l’accès concerné.
Examiner les accès des applications séparément
Les mots de passe d’application permettent à des outils de communiquer avec WordPress sans utiliser le mot de passe principal. Dans la fiche du compte, consultez leur rubrique lorsqu’elle est disponible. Conservez les noms et métadonnées utiles avant de révoquer les accès concernés ; ne créez pas un nouveau secret pour les tester.
Ces accès doivent être examinés séparément des sessions du navigateur. Les indications de dernière utilisation ne constituent pas un historique complet : leur mise à jour peut être espacée. Un nom rassurant n’est pas une preuve d’autorisation.
Une révocation peut interrompre une application mobile ou une synchronisation légitime. Prévenez son responsable. Après sécurisation, seuls les outils reconnus recevront de nouveaux accès adaptés. Ne réutilisez pas un secret suspect pour annuler l’intervention et ne cherchez pas à lire les secrets stockés dans la base.
Parcours 3 : contenir un accès non autorisé avec l’hébergeur
Si l’accès est refusé par le propriétaire ou accompagné d’actions dangereuses, contactez immédiatement l’hébergeur depuis le compte client connu. Décrivez les faits et demandez une restriction adaptée : limitation de l’administration, isolation de l’installation ou autre mesure qu’il peut appliquer sans exposer davantage le serveur.
Précisez les fonctions à préserver et les dommages observés. Une boutique qui diffuse une page frauduleuse n’a pas les mêmes contraintes qu’un site sans modification visible. Le prestataire doit tenir compte des services partagés ; ne coupez pas vous-même un serveur qui héberge d’autres sites.
Le confinement vise à réduire les actions possibles pendant l’analyse. Il ne supprime pas les causes de l’intrusion. Une page de maintenance visible ne prouve pas que les accès administratifs ou techniques sont fermés. Demandez ce qui est réellement bloqué, à quelle heure et selon quel critère l’ouverture pourra être réévaluée.
Protéger les accès fiables dans un ordre coordonné
Travaillez depuis un appareil considéré comme fiable, avec le propriétaire. Faites examiner les accès à la messagerie de récupération, à l’hébergement et aux services capables de modifier le site. Une nouvelle valeur WordPress saisie depuis un appareil compromis ou dans un environnement encore contrôlé par un tiers peut être de nouveau exposée.
Sur un site autohébergé, pour votre compte légitime, le changement de mot de passe se fait dans Profil, rubrique de gestion du compte, puis par l’enregistrement du profil. Utilisez un secret unique et conservez les moyens de récupération dans un emplacement privé. Activez la double authentification proposée par le service ou l’outil déjà retenu, avec ses codes de secours.
Pour le compte non autorisé, coordonnez blocage, sessions, récupération et intégrations avec le mainteneur. Envoyer simplement un lien de réinitialisation à son adresse ne retire pas son contrôle. Ne remplacez pas arbitrairement ses coordonnées pour transformer ce compte en votre nouveau compte principal.
Adapter l’intervention au multisite
En multisite, plusieurs sites partagent une installation et des comptes. Vérifiez le site sélectionné dans Mes sites, puis faites intervenir le responsable du réseau. Un utilisateur absent d’un site peut encore exister dans le réseau ou appartenir à un autre site.
Un administrateur local ne dispose pas nécessairement des permissions permettant de modifier le profil concerné. Un super administrateur possède une portée plus large : retirer un rôle sur un seul site ne doit pas être présenté comme le retrait de ses pouvoirs réseau.
Les sessions natives et les mots de passe d’application sont attachés au compte partagé : leur révocation peut aussi couper ses accès aux autres sites du réseau. Il ne s’agit donc pas nécessairement d’une action limitée au site affiché. Demandez au responsable de vérifier les appartenances, le statut réseau et la portée des accès techniques avant toute restriction globale. Il doit préserver les autres sites et documenter les conséquences prévues. Si personne ne reconnaît le super administrateur, l’hébergeur et le propriétaire du réseau doivent traiter ensemble le problème ; n’improvisez pas une modification des tables partagées.
Adapter les contrôles à WordPress.com
Sur WordPress.com, sélectionnez le site puis ouvrez Utilisateurs, Tous les utilisateurs, selon le style d’interface. Distinguez membre de l’équipe et invitation en attente. Une invitation envoyée et non acceptée n’a pas le même statut qu’un accès déjà utilisé. Faites confirmer qui l’a demandée. Sur les sites permettant une connexion locale distincte, une invitation WordPress.com en attente ne prouve pas que le compte local est inutilisable. Faites vérifier le mode de connexion prévu, sans désactiver la connexion WordPress.com pour essayer.
Le label de collaborateur externe ne réduit pas, à lui seul, les permissions. Un administrateur n’est pas non plus nécessairement propriétaire du site, du domaine ou de l’abonnement. Pour une restriction ou une récupération que vous ne pouvez effectuer, passez par le propriétaire reconnu et le support WordPress.com. Si un mot de passe WP Admin distinct existe, le modifier ne change pas celui du compte WordPress.com : faites traiter les deux accès concernés, sans les confondre.
Consultez Jetpack, puis Journal d’activité, lorsque cet écran est disponible. La profondeur visible dépend de l’offre et de la rétention ; l’absence d’un événement ne clôt pas l’enquête. Pour votre propre compte WordPress.com, vérifiez aussi Sécurité, Applications connectées : examinez la portée des connexions et déconnectez celles qui sont non autorisées. Une connexion rétablie plus tard doit être explicitement validée.
Contrôler le confinement et préserver les fonctions légitimes
Rouvrez la liste des utilisateurs depuis votre accès fiable. Vérifiez le rôle enregistré et les confirmations de révocation obtenues. Faites contrôler les nouvelles traces après l’heure d’intervention. Si un administrateur inconnu apparaît de nouveau ou retrouve ses droits, signalez cette récidive au prestataire sans répéter une boucle de suppressions.
Contrôlez aussi les fonctions légitimes affectées : publication prévue, synchronisation identifiée et accès des personnes autorisées. Réservez les essais qui écrivent des données ou envoient des messages à une copie neutralisée ou à un mode de test maîtrisé. Un paiement réel n’est pas un contrôle de sécurité nécessaire.
Ne tentez pas une connexion avec un secret suspect pour vérifier son blocage. Demandez une validation technique ciblée. Un site qui semble normal, un compte rétrogradé ou un résultat de scanner satisfaisant ne garantissent pas l’absence d’autre accès. La durée d’observation et les contrôles complémentaires dépendent de l’incident réel.
Transmettre un dossier exploitable et organiser la suite
Dans le ticket privé, indiquez le domaine, votre autorisation à intervenir, l’heure de découverte, le compte concerné et les changements observés. Ajoutez les vérifications auprès des prestataires, les mesures prises avec leurs horaires et la présence de sauvegardes préservées. Demandez les limites des journaux disponibles et la prochaine action attendue.
Si des données de clients ou d’utilisateurs semblent exposées, informez le responsable de leur protection dans votre organisation pour qu’il fasse évaluer la situation. Ne publiez pas ces données pour démontrer l’incident. L’investigation doit aussi chercher comment l’accès a été obtenu ; ce guide ne constitue pas une procédure de nettoyage complet.
Pour la suite, conservez un registre des administrateurs avec responsable, mission et date de révision. Séparez les comptes personnels et les interventions de prestataires. Réexaminez les privilèges à la fin des missions et vérifiez régulièrement les sauvegardes. Tout retrait définitif de compte attendra une décision documentée sur ses contenus et la conservation des preuves.
