« Qui a les accès de ce site ? » Cette question, posée en réunion de reprise de projet, reste trop souvent sans réponse claire. Reprendre une boutique WooCommerce laissée à l’abandon par un prestataire précédent commence toujours par là : pas par le code, pas par le design, mais par l’inventaire de ce qui existe réellement et de qui peut y toucher.
Le scénario est courant : un commerçant change de prestataire, souvent après une rupture de contact plutôt qu’une fin de mission propre, et le nouveau développeur hérite d’un accès administrateur WordPress, sans documentation, sans changelog des dernières interventions, avec des extensions dont certaines n’ont pas été mises à jour depuis des mois.
Étape 1 — Recenser avant de toucher à quoi que ce soit
La première commande à lancer n’est pas une mise à jour, c’est un inventaire. WP-CLI donne un état des lieux rapide et fiable, sans dépendre de l’interface d’administration qui peut elle-même être ralentie par des extensions défaillantes :
wp plugin list --fields=name,status,version,update
wp theme list --fields=name,status,version
wp core versionCette commande révèle en général la même chose : des extensions actives dont personne ne se souvient de la raison d’être, des versions vieilles de plusieurs années, et parfois un thème enfant modifié directement sans aucune trace de ces modifications ailleurs que dans les fichiers eux-mêmes.
Étape 2 — Chercher les traces d’un code personnalisé caché
Le vrai risque, pour une boutique reprise sans documentation, tient dans les modifications logées hors des extensions officielles : un fichier mu-plugins oublié, une fonction ajoutée directement dans le thème enfant sans commentaire explicatif, un cron personnalisé enregistré par du code disparu depuis. Un passage systématique par wp cron event list et une lecture attentive du dossier mu-plugins permettent de repérer ce genre de logique cachée avant de désactiver quoi que ce soit.
Ne jamais désactiver une extension sans comprendre son rôle
Une extension qui semble inutile au premier regard peut en réalité gérer une fonctionnalité critique invisible de l’extérieur, comme la génération d’un flux de synchronisation avec un entrepôt ou l’ajout d’un champ obligatoire de conformité fiscale. Avant toute désactivation, une recherche du nom de l’extension dans le code du thème (hooks, fonctions spécifiques, vérifications de classe) évite une mauvaise surprise en production.
Étape 3 — Régénérer tous les identifiants partagés
Un accès administrateur hérité d’un ancien prestataire n’est jamais suffisant à lui seul : il faut supposer que d’autres personnes détiennent encore des identifiants valides, y compris des clés d’API de paiement, des accès FTP ou des jetons d’API REST WooCommerce. Chacun de ces éléments doit être régénéré, pas simplement noté dans un tableau de suivi.
- Clés API des passerelles de paiement, régénérées et remplacées dans les réglages WooCommerce
- Comptes utilisateurs WordPress à privilège élevé, audités et réduits au strict nécessaire
- Clés d’API REST WooCommerce existantes, révoquées puis recréées pour les intégrations légitimes
Étape 4 — Mettre à jour progressivement, pas en une fois
Face à quatorze extensions en retard de plusieurs versions, la tentation est de tout mettre à jour d’un coup. C’est précisément l’erreur à éviter : chaque mise à jour doit se faire isolément, sur une copie de la boutique en environnement de recette, avec vérification du tunnel de commande complet après chaque changement. Une extension de paiement mise à jour en même temps que le thème peut masquer l’origine réelle d’une régression si les deux changements sont appliqués simultanément.
Une mise à jour à la fois, un test complet du tunnel de commande après chacune : c’est plus lent, mais c’est la seule méthode qui permette d’identifier précisément l’origine d’une régression.
Étape 5 — Documenter, cette fois pour de bon
Une fois la situation stabilisée, consigner ce qui a été trouvé devient aussi important que les corrections elles-mêmes : liste des extensions actives et leur rôle réel, emplacement du code personnalisé, procédure de sauvegarde en place. Cette documentation, souvent absente au moment de la reprise, évite de refaire ce même travail d’archéologie au prochain changement de prestataire.
Ce que cette reprise ne couvre pas
La refonte visuelle du site, souvent envisagée en même temps qu’un changement de prestataire, reste un projet distinct à traiter après la stabilisation technique. Mélanger audit de sécurité et refonte graphique dans la même intervention complique inutilement le diagnostic des problèmes hérités.
En résumé technique
Reprendre une boutique abandonnée demande de la méthode plus que de la vitesse : recenser avant de modifier, comprendre avant de désactiver, régénérer chaque identifiant partagé, et mettre à jour une extension à la fois. Le prestataire précédent a peut-être laissé le site dans un état fragile ; la reprise ne doit pas ajouter une nouvelle couche d’incertitude par-dessus.
