Aucune trace de contrat de maintenance, aucun accès admin transmis, un nom de domaine renouvelé automatiquement depuis des années sans que personne ne sache pourquoi : ce constat, banal dans la profession, ouvre presque toujours la reprise d’un site WordPress dont l’agence d’origine a fermé boutique. Le réflexe de foncer directement sur une mise à jour globale se paie cher : sur ce type de site, chaque extension ancienne peut casser une fonctionnalité invisible tant qu’on ne l’a pas testée.
La checklist qui suit vient d’une reprise réelle : un site vitrine tournant depuis dix ans sur une version de WordPress vieille de six ans, avec des extensions dont certaines n’avaient plus été mises à jour depuis 2016. L’objectif n’est pas la refonte du contenu, mais la remise à niveau technique minimale qui permet de continuer à faire vivre le site en sécurité.
1. Cartographier les versions avant de toucher à quoi que ce soit
La première commande à lancer sur un tel site est wp core version, suivie de wp plugin list et wp theme list, pour obtenir un état des lieux complet avant toute action. Ces trois commandes suffisent à mesurer l’ampleur du chantier : version de WordPress, version de PHP hébergeur, liste des extensions actives avec leur dernière mise à jour connue.
wp core version
wp plugin list --fields=name,status,version,update
wp theme list --fields=name,status,version
php -v
Sur le site en question, wp core version a renvoyé une version WordPress sortie six ans avant l’audit, hébergée sur du PHP 5.6 encore actif faute de mise à jour côté hébergeur. Ce décalage à lui seul explique une bonne partie des incompatibilités qui apparaîtraient dès la première tentative de mise à jour.
2. Identifier les extensions abandonnées
Chaque extension listée par wp plugin list mérite une vérification individuelle sur le répertoire officiel WordPress.org : date de dernière mise à jour, compatibilité annoncée, nombre d’installations actives. Une extension non mise à jour depuis plus de deux ans et sans alternative claire est un candidat direct à la suppression ou au remplacement, surtout si elle touche à la sécurité (formulaire de contact, cache, pare-feu applicatif).
Les signaux qui doivent alerter
- Extension retirée du répertoire officiel WordPress.org
- Dernier changelog datant de plus de trois ans
- Nom de fonction ou de classe en doublon avec une autre extension active
- Fichiers modifiés directement dans le dossier de l’extension, signe d’un correctif fait à la main autrefois
3. Reconstituer les accès disparus
Sans compte administrateur transmis, l’accès à la base de données via l’hébergeur (souvent via phpMyAdmin ou un accès SSH) permet de créer un nouvel utilisateur administrateur directement en base, ou plus simplement via wp user create une fois un accès WP-CLI établi sur le serveur.
wp user create admin.repreneur admin@domaine-du-client.fr --role=administrator --user_pass=motdepasse-temporaire
Le renouvellement du nom de domaine et des certificats TLS mérite aussi une vérification directe auprès du registrar et de l’hébergeur : il n’est pas rare qu’un prélèvement automatique continue sur une carte bancaire de l’ancienne agence, ce qui expose le client à une coupure brutale le jour où ce prélèvement échoue.
4. Sauvegarder avant tout changement
Aucune modification, même mineure, ne devrait précéder une sauvegarde complète des fichiers et de la base de données. Sur un hébergement mutualisé sans outil de sauvegarde fiable, une exportation manuelle via wp db export couplée à une archive du dossier wp-content suffit pour disposer d’un point de retour sûr.
wp db export sauvegarde-avant-reprise.sql
tar -czf wp-content-avant-reprise.tar.gz wp-content/
5. Planifier la remise à niveau par étapes
Une montée en version brutale de WordPress 4.x vers la dernière version stable, sur un thème et des extensions jamais testés entre-temps, provoque presque toujours une page blanche. La bonne pratique consiste à monter version majeure par version majeure, en vérifiant après chaque étape que le site reste fonctionnel, plutôt que de sauter directement à la dernière version disponible.
- Passer PHP à une version récente compatible avec le thème (test préalable en environnement de copie)
- Mettre à jour WordPress version majeure par version majeure
- Mettre à jour les extensions une par une, en vérifiant le site après chacune
- Ne mettre à jour le thème qu’en dernier, en cas de personnalisations directes dans ses fichiers
Sur un site sans documentation, la prudence coûte une heure de plus ; l’impatience coûte souvent une journée de récupération après une page blanche en production.
Notre verdict
Reprendre un site abandonné par une agence disparue demande une discipline différente d’un projet neuf : chaque étape doit être réversible, et rien ne doit être supposé sans vérification directe. La checklist ci-dessus n’a rien d’exceptionnel, mais son ordre compte : cartographier avant de toucher, sauvegarder avant de mettre à jour, et avancer version par version plutôt que de viser directement la dernière version stable.
