Reprendre la maintenance d’un site WordPress existant commence presque toujours par la même découverte : une liste d’extensions bien plus longue que ce que le site semble réellement nécessiter. Sur les audits qu’on mène régulièrement pour des clients qui reprennent un site développé par un précédent prestataire, la proportion d’extensions jamais réellement sollicitées par une fonctionnalité active du site dépasse souvent 40 %.
Cet article détaille une méthode d’audit structurée, avec une grille de critères reproductible, pour transformer une liste d’extensions en plan d’action priorisé plutôt qu’en simple constat.
Étape 1 : inventorier sans a priori
La première étape consiste à lister l’ensemble des extensions installées, actives ou non, avec leurs métadonnées de base :
wp plugin list --format=csv --fields=name,status,version,update,auto_update > audit-extensions.csvCette commande seule ne suffit pas : elle ne dit rien de l’usage réel. Une extension active peut très bien ne plus être sollicitée par aucune fonctionnalité du site (un ancien module de paiement remplacé sans être désinstallé), tandis qu’une extension désactivée peut avoir laissé des tables ou des tâches cron orphelines qui continuent de s’exécuter silencieusement.
Étape 2 : croiser avec l’usage réel
Pour chaque extension, quelques vérifications déterminent si elle est réellement utilisée :
- Recherche du prefixe de ses shortcodes, blocs ou widgets dans le contenu publié (table
wp_posts) - Vérification de la présence de ses tâches dans
wp cron event list - Inspection des logs d’accès pour ses éventuels endpoints REST ou webhooks personnalisés
- Entretien avec l’équipe éditoriale ou le client, qui sait souvent immédiatement si une fonctionnalité est encore utilisée en pratique
# Rechercher l'usage d'un shortcode spécifique dans le contenu publié
wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_content LIKE '%[ancien_shortcode%' AND post_status = 'publish'"
Étape 3 : une grille de criticité à deux axes
Chaque extension est ensuite positionnée selon deux axes : la criticité fonctionnelle (le site est-il sérieusement affecté si elle disparaît demain ?) et le niveau de risque technique (mise à jour absente, faille connue, poids sur les performances).
| Quadrant | Criticité fonctionnelle | Risque technique | Action recommandée |
|---|---|---|---|
| À désinstaller | Faible | Élevé ou faible | Suppression immédiate, la plus rentable des actions |
| À surveiller | Élevée | Faible | Aucune action urgente, revue périodique |
| À remplacer | Élevée | Élevé | Chercher une alternative maintenue, chantier planifié |
| À sécuriser | Faible | Élevé | Mise à jour ou correctif ciblé si suppression impossible |
Le quadrant « à désinstaller » constitue presque toujours le gain le plus rapide et le moins coûteux d’un audit : chaque extension retirée réduit la surface d’attaque du site, le nombre de requêtes potentielles et le temps de traitement des futures mises à jour de cœur WordPress, sans nécessiter le moindre développement.
Étape 4 : estimer l’effort de chaque recommandation
Une recommandation sans estimation d’effort reste théorique aux yeux d’un client qui doit arbitrer un budget. La grille finale associe systématiquement un niveau d’effort à chaque action :
| Niveau d’effort | Exemple typique |
|---|---|
| Faible (moins d’une heure) | Désinstallation d’une extension inutilisée avec vérification post-suppression |
| Moyen (une demi-journée à deux jours) | Migration vers une extension alternative pour une fonctionnalité équivalente |
| Élevé (plus de trois jours) | Réécriture d’une fonctionnalité métier actuellement dépendante d’une extension abandonnée |
Un client retient toujours mieux un audit qui dit « ces douze extensions peuvent être supprimées en une demi-journée, pour un gain immédiat de sécurité et de vitesse » qu’un audit qui liste abstraitement des risques sans les hiérarchiser ni les chiffrer en temps de travail.
Le cas particulier des extensions qui se chevauchent fonctionnellement
Un cas fréquent en audit : deux ou trois extensions couvrent partiellement la même fonctionnalité (plusieurs extensions de cache actives simultanément, par exemple, ou deux extensions SEO qui génèrent chacune leur propre sitemap). Ce chevauchement n’est presque jamais intentionnel ; il résulte généralement de l’empilement de décisions prises par des intervenants différents au fil du temps, sans vision d’ensemble. Ce cas mérite un traitement spécifique dans l’audit, car la coexistence de deux extensions concurrentes peut produire des résultats contradictoires invisibles à l’œil nu (deux sitemaps XML différents soumis à Google Search Console, par exemple).
Restituer l’audit sous une forme actionnable
Le livrable final ne doit jamais être une simple liste brute. Un tableau trié par priorité, avec pour chaque ligne l’extension, le quadrant de criticité, l’action recommandée et l’effort estimé, permet à un client non technique de comprendre immédiatement où se situent les gains rapides et où se situent les chantiers plus lourds à planifier sur plusieurs sprints.
En résumé
Un audit de dette technique sur un parc d’extensions gagne à être structuré en quatre étapes claires : inventaire exhaustif, vérification de l’usage réel, positionnement sur une grille de criticité et de risque, puis estimation de l’effort. Cette méthode transforme un exercice qui pourrait rester théorique en plan d’action concret, avec des gains rapides identifiables dès la première semaine.
