wp plugin list --status=active --format=csv renvoie trente-quatre lignes. Onze d’entre elles n’ont pas reçu de mise à jour depuis plus de trois ans, et deux ne figurent plus du tout sur le répertoire officiel. Voilà le point de départ réaliste d’un audit de dette technique sur une boutique WooCommerce ancienne : pas un ressenti, une liste.
Reprendre un projet qui tourne depuis six ans est un exercice différent d’un audit de performance classique. La boutique fonctionne, les commandes arrivent, mais chaque intervention devient risquée parce que personne ne sait plus exactement quel hook fait quoi, ni pourquoi telle extension a été installée en 2019 pour un problème qui n’existe peut-être plus. L’enjeu n’est pas esthétique : il est de rendre le système modifiable sans casser le tunnel de commande.
Étape 1 : cartographier les extensions avant de toucher au code
La première priorité n’est pas la base de données ni le thème, mais l’inventaire des extensions. Sur un projet mature, il n’est pas rare de trouver des doublons fonctionnels : deux plugins de champs personnalisés, trois solutions de cache qui se marchent dessus, une extension de coupons jamais activée mais toujours chargée en mémoire. Chaque extension active consomme des cycles PHP à chaque requête, qu’elle serve ou non.
- Lister les extensions actives et leur dernière mise à jour avec
wp plugin list --format=json - Croiser cette liste avec les logs d’erreurs PHP des trente derniers jours
- Identifier les extensions qui déclarent des hooks sur
woocommerce_checkout_processouwoocommerce_before_calculate_totals, souvent sources de comportements imprévisibles - Repérer les extensions abandonnées : dépôt GitHub inactif, absence de compatibilité déclarée avec la version de WooCommerce en place
Ce travail seul suffit parfois à expliquer des symptômes que l’équipe pensait liés au thème : un total de commande qui varie selon l’ordre de chargement des plugins, un champ de facturation qui disparaît sur certains navigateurs.
Étape 2 : isoler les hooks fragiles avant toute modification
Une fois l’inventaire des extensions dressé, il faut comprendre comment elles s’articulent avec le thème et les personnalisations maison. Sur une boutique de six ans, il est fréquent de trouver des morceaux de code ajoutés directement dans functions.php par plusieurs développeurs successifs, sans convention commune. Le risque n’est pas la lecture de ce code, mais l’ordre d’exécution des hooks qui s’y accrochent.
La méthode la plus fiable consiste à activer temporairement un plugin de débogage de hooks (ou un journal maison basé sur add_action( 'all', ... ) en environnement de recette uniquement) pour observer, sur un parcours d’achat complet, la séquence réelle des actions déclenchées. On découvre souvent qu’un même hook, comme woocommerce_before_calculate_totals, est utilisé par deux extensions différentes avec des priorités qui se chevauchent, ce qui explique des totaux instables signalés depuis des mois sans qu’on ait pu les reproduire de façon fiable.
add_action( 'all', function( $tag ) {
if ( strpos( $tag, 'woocommerce_' ) === 0 ) {
error_log( '[AUDIT HOOK] ' . $tag );
}
} );
Ce journal, activé uniquement en recette sur un parcours de test complet (ajout au panier, application d’un coupon, passage en caisse), donne en quelques minutes une image beaucoup plus fidèle que n’importe quelle relecture de code.
Étape 3 : mesurer la base de données avant de promettre un délai
La table wp_postmeta d’une boutique de six ans dépasse fréquemment plusieurs gigaoctets, avec des metadonnées orphelines issues d’extensions désinstallées sans nettoyage. Avant d’estimer la durée d’un chantier de refactorisation, il est indispensable de mesurer la taille réelle des tables concernées :
SELECT table_name, ROUND(((data_length + index_length) / 1024 / 1024), 2) AS taille_mo
FROM information_schema.TABLES
WHERE table_schema = 'nom_de_la_base'
ORDER BY (data_length + index_length) DESC
LIMIT 10;
Cette mesure oriente directement la suite : une table wp_postmeta de huit gigaoctets ne se nettoie pas en une matinée, et toute promesse de délai faite avant cette étape est une estimation à l’aveugle.
Prioriser les corrections selon le risque, pas selon la facilité
Une fois l’inventaire, la cartographie des hooks et la mesure de la base réalisés, l’ordre de correction doit suivre le risque métier, pas la facilité technique. Corriger un warning PHP inoffensif avant de traiter un hook qui double parfois une remise sur le total de commande serait une erreur de priorisation, même si le warning se règle en cinq minutes et le hook en deux jours.
- Risque élevé : tout ce qui touche au calcul du total, au statut de la commande, aux emails transactionnels
- Risque moyen : les extensions obsolètes sans faille de sécurité connue mais sans maintenance
- Risque faible : les avertissements PHP silencieux, les métadonnées orphelines qui n’impactent pas les performances
Sur un audit, la question qui compte n’est pas « qu’est-ce qui est cassé ? » mais « qu’est-ce qui peut casser si je touche à ce fichier ? ». La différence détermine tout le plan d’action qui suit.
Ce qu’un audit ne doit pas inclure
Il est tentant, une fois plongé dans une boutique ancienne, de vouloir tout refaire : moderniser le thème, migrer vers de nouveaux blocs, revoir l’identité visuelle. Ce n’est pas l’objet d’un audit de dette technique. Mélanger refonte graphique et assainissement du code dilue les priorités et retarde la correction des points réellement risqués pour l’activité. Le livrable d’audit doit rester un document de priorisation technique, pas un cahier des charges de refonte.
En résumé
Auditer une boutique WooCommerce de six ans commence par l’inventaire froid des extensions actives, se poursuit par l’observation réelle des hooks en environnement de recette, et se conclut par une mesure chiffrée de la base de données. Cet ordre n’est pas arbitraire : il va du risque le plus visible au risque le plus profond, et il évite de promettre un calendrier avant d’avoir des chiffres. Le reste — thème, ergonomie, identité visuelle — relève d’un autre chantier, à mener une fois le socle technique stabilisé.
