Warning: mysqli_connect(): (HY000/1045): Access denied for user : ce message est apparu dès la première tentative de connexion à l’interface d’administration du mutualisé repris, sans qu’aucun mot de passe transmis ne fonctionne. Le freelance qui gérait le site jusque-là n’était plus joignable, et aucun document de passation n’avait été préparé avant son départ.
Ce scénario, loin d’être rare, impose une méthode différente de celle d’une reprise classique. Il ne s’agit plus d’auditer une configuration connue pour l’améliorer, mais de reconstituer, souvent depuis rien, l’inventaire complet de ce qui existe réellement sur le serveur avant de pouvoir se prononcer sur quoi que ce soit.
Reconstituer l’accès avant tout le reste
La première étape a consisté à contacter directement l’hébergeur mutualisé, muni des justificatifs prouvant que le client est bien titulaire du contrat, pour obtenir une réinitialisation des accès au panneau d’administration. Cette démarche, souvent plus rapide qu’on ne le craint, a permis de retrouver l’accès au panneau en moins de deux jours ouvrés, avec vérification d’identité du titulaire du contrat d’hébergement.
Une fois cet accès retrouvé, l’inventaire a commencé par les bases de données présentes, dont les identifiants avaient eux aussi été perdus avec le départ du freelance :
-- Depuis l'accès panneau retrouvé, réinitialisation
-- du mot de passe de chaque utilisateur de base repéré
SET PASSWORD FOR 'wp_site_user'@'localhost' = PASSWORD('nouveau_mot_de_passe_genere');
Vérifier ce que les sauvegardes contiennent vraiment
Le panneau d’hébergement affichait bien des sauvegardes automatiques quotidiennes, un point rassurant en apparence. La vérification a cependant révélé que ces sauvegardes, actives depuis plusieurs mois, ne couvraient que les fichiers du site et non la base de données, une case à cocher visiblement désactivée dans la configuration du plan de sauvegarde sans qu’on sache si ce choix avait été délibéré ou accidentel.
Le test de restauration, effectué sur un environnement isolé plutôt que directement en production, a confirmé le problème :
wp db import sauvegarde-test.sql --path=/var/www/test-restauration
# Erreur : le fichier sauvegarde-test.sql n'existe pas dans l'archive
Sans cette vérification concrète, la reprise aurait pu se poursuivre pendant des mois avec la fausse impression qu’un filet de sécurité existait, jusqu’au jour où un incident aurait révélé son absence réelle.
Cartographier les extensions et leurs licences
L’inventaire s’est poursuivi par la liste des extensions actives, certaines premium dont la licence était enregistrée au nom du freelance disparu plutôt qu’à celui du client final, une situation qui bloque les mises à jour futures tant que la licence n’est pas retransférée auprès de l’éditeur concerné :
wp plugin list --fields=name,status,version,update
Deux extensions premium sur cinq se sont révélées dans ce cas, nécessitant un contact direct avec leurs éditeurs respectifs pour transférer la propriété de la licence vers le nouveau titulaire du site, une démarche administrative qui a pris plusieurs semaines.
Fermer tous les accès hérités
Une fois l’inventaire terminé et les sauvegardes réellement fonctionnelles rétablies, l’étape suivante a consisté à considérer comme compromis tout ce qui avait pu être configuré par le prestataire précédent, sans supposer sa bonne foi ni sa négligence, simplement par prudence méthodique :
- changement de tous les mots de passe WordPress, panneau d’hébergement et base de données ;
- révocation des clés API tierces trouvées dans les options du site, régénérées auprès de chaque service concerné ;
- suppression des comptes utilisateurs WordPress inconnus ou inutilisés, après vérification qu’aucun n’était légitime ;
- vérification de l’absence de tâche cron système ou de fichier suspect ajouté hors du périmètre habituel de WordPress.
Reprendre un hébergement sans documentation ne se traite pas comme un audit d’amélioration : c’est une reconstitution complète de la confiance, poste par poste, avant même de parler d’optimisation.
Documenter pour que ça ne se reproduise plus
La dernière étape, souvent négligée après l’urgence de la reprise, a consisté à produire le document de passation qui aurait dû exister dès le départ : accès panneau, identifiants de base de données, liste des extensions premium avec leurs licences, procédure de restauration testée et fonctionnelle. Ce document, désormais conservé par le client lui-même dans un gestionnaire de mots de passe partagé, garantit qu’une prochaine reprise, si elle devait arriver, ne partira plus de rien.
Pour aller plus loin
Une reprise d’hébergement sans accès ni documentation demande d’accepter de tout revérifier avant de rassurer qui que ce soit : les sauvegardes affichées ne sont pas forcément complètes, les licences d’extensions ne sont pas forcément transférables sans démarche, et les accès laissés par le prestataire précédent doivent être fermés par principe. Le temps investi dans cette reconstitution méthodique évite des incidents bien plus coûteux à découvrir après coup.
