# Reprendre une boutique WooCommerce laissée à l’abandon par un prestataire > Hériter d'une boutique WooCommerce sans documentation, avec des extensions obsolètes et des identifiants partagés : la méthode pour reprendre pied sans casser ce qui fonctionne encore. - Auteur : WordPress Développement - Publié le : 2021-11-08 - Mis à jour le : 2021-11-08 - Catégorie : E-commerce - URL : https://www.wpmoderne.fr/ecommerce/reprendre-boutique-woocommerce-abandonnee/ ## L’essentiel - Recenser d'abord, modifier ensuite, jamais l'inverse - Les extensions obsolètes ne se mettent pas à jour toutes en même temps - Chaque identifiant partagé doit être régénéré, pas seulement noté « 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 version ``` Cette 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. > L'essentiel à retenir : Recenser d'abord, modifier ensuite, jamais l'inverse ; Les extensions obsolètes ne se mettent pas à jour toutes en même temps ; Chaque identifiant partagé doit être régénéré, pas seulement noté ### 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.