# Consigner les extensions et hooks d’une boutique WooCommerce avant un changement de prestataire

> Trente et un octobre, fin de mission : que transmettre à l'agence suivante pour qu'elle reprenne la boutique sans deviner ce que fait chaque hook personnalisé ?

- Auteur : WordPress Développement
- Publié le : 2023-10-31
- Mis à jour le : 2023-10-31
- Catégorie : E-commerce
- URL : https://www.wpmoderne.fr/ecommerce/consigner-extensions-hooks-boutique-avant-changement-prestataire/

## L’essentiel

- Un export de la liste des extensions actives ne suffit jamais seul
- Chaque hook personnalisé mérite un commentaire expliquant sa raison d'être
- Les clés d'API doivent être listées sans jamais être transmises en clair

Fin de mission un 31 octobre, jour symbolique s'il en est pour clôturer un contrat d'agence : la boutique WooCommerce doit être transmise à une nouvelle équipe, sans période de recouvrement prévue au contrat. La question qui se pose alors n'est pas contractuelle, mais purement technique : comment s'assurer que rien d'essentiel ne se perde dans la passation ?

L'expérience répétée de ce type de transmission a permis de dégager une liste précise de ce qui doit systématiquement être consigné, au-delà du simple export de la liste des extensions actives, qui ne raconte jamais pourquoi telle extension a été installée ni ce qu'elle remplace.

## Un export d'extensions ne dit rien du pourquoi

La commande `wp plugin list --status=active` fournit une liste exacte des extensions actives, mais elle ne renseigne ni sur les raisons de leur choix, ni sur les alternatives écartées, ni sur d'éventuelles configurations spécifiques appliquées après installation. Une nouvelle équipe qui découvre une extension de gestion de stock multi-entrepôt sans explication perdra un temps précieux à comprendre si elle est encore réellement utilisée ou si elle constitue un résidu d'un projet abandonné.

## Documenter chaque hook personnalisé, pas seulement le lister

> L'essentiel à retenir : Un export de la liste des extensions actives ne suffit jamais seul ; Chaque hook personnalisé mérite un commentaire expliquant sa raison d'être ; Les clés d'API doivent être listées sans jamais être transmises en clair

Le point le plus souvent négligé lors d'une transmission concerne les hooks personnalisés ajoutés au fil du temps, en particulier ceux qui modifient un comportement natif de WooCommerce sans que rien dans l'interface d'administration ne le signale. Un filtre sur `woocommerce_product_get_price` qui applique une remise conditionnelle selon un rôle utilisateur, par exemple, restera invisible pour la nouvelle équipe tant qu'elle n'aura pas relu l'intégralité du code du thème et des extensions maison.

```
wp shell
>>> global $wp_filter;
>>> foreach ( array_keys( $wp_filter ) as $hook ) {
>>>     if ( strpos( $hook, 'woocommerce_' ) === 0 ) {
>>>         echo $hook . PHP_EOL;
>>>     }
>>> }
```

Cette exploration via `wp shell`, la console interactive de WP-CLI, permet de lister tous les hooks WooCommerce réellement accrochés sur le site, y compris ceux ajoutés par des extensions tierces. Chaque hook identifié comme personnalisé, ajouté par le thème ou une extension maison, doit ensuite recevoir une ligne d'explication dans le document de passation : quel comportement il modifie, et pourquoi.

## La checklist retenue pour ce type de transmission

- Liste des extensions actives et inactives, avec pour chacune une phrase sur son rôle réel dans le projet.
- Liste des hooks personnalisés touchant WooCommerce, avec le fichier source et la raison de leur ajout.
- Inventaire des clés d'API externes utilisées (passerelle de paiement, transporteur, service d'e-mail transactionnel), sans jamais transmettre la valeur en clair dans un document partagé.
- Liste des templates WooCommerce surchargés dans le thème, avec la version d'extension au moment de la copie.
- Description des tâches planifiées personnalisées, en dehors de celles nativement gérées par les extensions installées.

## Transmettre les clés d'API sans les exposer

Sur ce point précis, la bonne pratique consiste à documenter l'existence et l'usage de chaque clé, sans jamais l'écrire en clair dans le document de passation lui-même : un simple renvoi vers le gestionnaire de secrets utilisé par l'agence, avec les droits d'accès transférés séparément à la nouvelle équipe, évite qu'une clé sensible ne circule dans un fichier partagé par e-mail ou stocké sans chiffrement.

## Le cas des extensions abandonnées mais toujours actives

Un audit de ce type révèle presque systématiquement au moins une extension installée pour un besoin ponctuel, jamais désactivée depuis. Plutôt que de la retirer unilatéralement en fin de mission, ce qui pourrait casser un usage encore réel mais mal documenté, mieux vaut la signaler explicitement dans le document de passation, en laissant la décision de désactivation à la nouvelle équipe une fois le contexte vérifié.

> Un document de passation qui ne liste que ce qui existe ne vaut pas grand-chose. Ce qui compte vraiment, c'est d'expliquer pourquoi chaque élément existe, pour que la nouvelle équipe puisse juger elle-même s'il faut le garder.

## Ce qui reste hors périmètre technique

Cette checklist couvre uniquement l'aspect technique de la transmission. Les aspects contractuels de la cession elle-même, comme le transfert de propriété du code ou les clauses de non-concurrence entre agences, relèvent d'un tout autre document, généralement rédigé par les parties prenantes commerciales et juridiques du projet.

## En résumé

Une transmission de boutique WooCommerce réussie tient moins à la quantité d'informations consignées qu'à leur qualité explicative : un hook documenté avec sa raison d'être fait gagner des heures à la nouvelle équipe, là qu'une simple liste technique, aussi exhaustive soit-elle, ne suffira jamais à elle seule.
