Un site laissé à l’abandon est rarement un site cassé. C’est un site qui fonctionne encore : les pages s’affichent, le formulaire envoie ses messages, personne ne se plaint. Sauf que le prestataire d’origine a disparu, que plus personne ne sait où sont les sauvegardes, que le tableau de bord annonce trente-sept mises à jour en attente — et que le jour où quelque chose lâchera, il n’y aura ni interlocuteur, ni point de retour.
C’est une situation que nous reprenons régulièrement. Voici notre méthode, dans l’ordre où nous l’appliquons. Précision utile : plusieurs des exemples qui suivent viennent de notre propre migration d’hébergeur, en août 2026. On ne se prétend pas au-dessus du problème.
Jour 1 : ne rien mettre à jour
Le premier réflexe, face à un site en retard, consiste à cliquer sur « Tout mettre à jour ». C’est aussi la façon la plus rapide de casser un site qu’on ne connaît pas encore, et de le casser sans pouvoir revenir en arrière.
L’ordre est donc : récupérer les accès (hébergement, base de données, DNS, registrar, comptes administrateurs), faire une sauvegarde complète — fichiers et base — stockée ailleurs que sur le serveur, puis tester la restauration. Une sauvegarde qu’on n’a jamais restaurée est une hypothèse, pas une sauvegarde. Ensuite seulement, on monte une copie de travail pour y faire les essais.
Inventaire : de quoi ce site est-il fait ?
On relève les versions (WordPress, PHP, base de données), le thème et surtout la façon dont il a été modifié : thème enfant propre, ou fichiers du thème parent édités directement — auquel cas la prochaine mise à jour effacera le travail. Puis les extensions actives, les extensions désactivées mais toujours présentes, et les tâches planifiées.
Le point aveugle, ce sont les mu-plugins : ces fichiers déposés dans wp-content/mu-plugins/ se chargent d’office et n’apparaissent pas dans la liste habituelle des extensions. Sur notre propre site, la reprise a mis au jour deux mu-plugins laissés par l’ancien hébergeur, dont l’un désactivait les mises à jour automatiques et redirigeait les appels à wordpress.org vers son propre miroir. Vu du tableau de bord, tout semblait normal.
Même chose pour le code mort qui traîne à côté de WordPress : règles de réécriture dans le .htaccess laissées par une extension supprimée, fichiers drop-in orphelins, constantes inutiles dans wp-config.php. Ce n’est pas de la poussière décorative : chez nous, une règle de réécriture abandonnée par un ancien plugin de cache empêchait purement et simplement le cache en place de fonctionner.
Sécurité : avant tout le reste
Un site abandonné a presque toujours un problème de comptes. On liste les utilisateurs, on cherche les comptes administrateurs dormants — anciens prestataires, stagiaires, « admin » créé à l’installation et jamais retiré — et on vérifie si le site publie lui-même la liste de ses auteurs, ce que WordPress fait par défaut via son API.
- Réinitialiser les accès : mots de passe des comptes conservés, identifiants FTP et base de données, clés de salage de
wp-config.php(ce qui déconnecte toutes les sessions actives, y compris celles qu’on ne connaît pas). - Supprimer, pas désactiver, les comptes qui n’ont plus de raison d’être — et rétrograder ceux qui n’ont pas besoin du rôle administrateur.
- Chercher les traces d’injection dans les répertoires qui ne devraient contenir que des médias, et vérifier les droits sur les fichiers.
- Activer la double authentification sur les comptes restants.
Si le site est déjà compromis, le raisonnement change : on ne nettoie pas une infection à la main sur la production. On isole, on repart d’une base saine, et on remonte les contenus.
Les extensions : moins, pas plus
Une extension désactivée n’est pas neutralisée : son code reste sur le disque, et certaines vulnérabilités connues sont exploitables sans que l’extension soit active. Un gestionnaire de fichiers laissé « au cas où » dans un coin du site est une porte, pas un outil.
À l’inverse, désinstaller ne suffit pas toujours à faire le ménage : la plupart des extensions ne nettoient rien en partant. Dans notre base, nous avons retrouvé six tables appartenant à des extensions disparues, une file de tâches planifiées contenant plus de huit cents actions en échec pour un plugin qui n’existait plus, et un journal de tâches de près de 281 000 lignes. Rien de dramatique, mais ce sont des requêtes, de la sauvegarde et du temps de migration pour rien.
Notre règle de tri : chaque extension doit avoir une raison d’être identifiable, un éditeur qui la maintient encore, et une alternative connue si elle s’arrête. Les autres partent.
Mettre à jour : dans l’ordre, avec un point de retour
Sur la copie de travail, on avance par étapes séparées, en vérifiant le site entre chacune : le cœur de WordPress, puis les extensions une par une pour celles qui touchent au contenu ou aux formulaires, puis le thème, puis la version de PHP. Grouper les mises à jour fait gagner dix minutes et coûte une demi-journée de diagnostic quand quelque chose casse.
Une mise à jour qu’on ne peut pas annuler n’est pas une mise à jour : c’est un pari.
Si une extension bloque la montée de version de PHP, la vraie question n’est pas « comment la garder » mais « par quoi la remplacer ». Un site qui reste sur une version de PHP obsolète n’est pas seulement lent : il est privé des correctifs de sécurité du langage lui-même.
Le SEO : ce qui casse sans qu’on le voie
Une reprise est aussi le bon moment pour vérifier ce que le site raconte aux moteurs, parce que c’est le genre de dégât silencieux : pages de test restées publiques et indexées, balises title et méta descriptions manquantes, redirections en chaîne qui font deux ou trois sauts, sitemap qui annonce des URL redirigées, robots.txt qui interdit ou expose ce qu’il ne faut pas.
On croise le sitemap avec les URL réellement servies, on regarde les erreurs remontées par la Search Console, et on corrige avant de toucher au contenu. C’est la partie détaillée dans notre page référencement naturel.
Performance : chercher la cause, pas le plugin
Le réflexe habituel — installer une extension d’optimisation de plus — arrive presque toujours trop tôt. L’ordre utile est : temps de réponse du serveur, cache de page, poids des médias, puis CSS et JavaScript.
Deux exemples pris chez nous. Une fois la règle de réécriture morte retirée du .htaccess, le cache de page a recommencé à servir : le temps de réponse est passé d’environ 0,55 s à 0,1 s, sans installer quoi que ce soit. Et à l’inverse, un lazy-load mal réglé imposait une largeur de remplacement de 500 px à chaque logo d’une bande d’images : la mise en page sautait au chargement. Une extension d’optimisation mal configurée dégrade l’expérience qu’elle prétend améliorer.
Documenter, puis rendre les clés
La reprise se termine par un document court et à jour : où est hébergé le site, qui gère le nom de domaine, quels sont les accès et qui les détient, à quoi sert chaque extension conservée, où sont les sauvegardes et à quelle fréquence, comment se déroule une mise à jour, qui appeler en cas d’incident. Plus une formation de la personne qui édite le site au quotidien.
Un site repris mais non documenté est un site qui sera abandonné une deuxième fois. C’est la seule partie du travail qui empêche le problème de revenir.
Ce que nous refusons de faire
- Mettre à jour sans sauvegarde restaurable et testée.
- Désinfecter un site compromis directement en production.
- Conserver une extension abandonnée par son éditeur parce qu’elle « marche encore ».
- Proposer une refonte quand une remise à niveau suffit — et l’inverse : rafistoler un site dont la dette technique coûte désormais plus cher que sa reconstruction.
Un site à reprendre ?
Nous commençons toujours par un audit : inventaire, sécurité, performance, SEO, et un plan chiffré qui distingue ce qui est urgent de ce qui peut attendre. Ce que couvre ensuite la maintenance WordPress : mises à jour surveillées, sauvegardes, supervision de sécurité et un interlocuteur qui connaît le site.
Si vous avez hérité d’un site dont personne ne sait plus quoi faire, écrivez-nous via la page contact : réponse sous 48 heures, avec un premier avis honnête — y compris quand la bonne réponse est de ne pas tout refaire.