Comment auditer vos extensions WordPress en 5 étapes

Introduction : un audit qui ne se termine pas par une suppression n'est pas un audit

La plupart des « audits d'extensions » produisent un tableau. Le tableau est lu une fois, jugé intéressant, puis rangé. Six mois plus tard, on refait le même tableau, avec les mêmes lignes et une de plus.

Un audit utile a une propriété unique et non négociable : il se termine par des suppressions datées. Tout le reste — le comptage, le classement, la mise en couleur — n'est qu'un moyen d'y arriver.

Ce protocole tient en cinq étapes et une demi-journée pour un site, moins par site sur un parc. Il ne demande aucun outil payant. Ce qu'il demande, c'est d'accepter que la bonne réponse soit souvent « on supprime », y compris pour une extension qui fonctionne parfaitement.

Étape 1 — Inventorier, avec la seule colonne qui compte

Listez toutes les extensions : actives et inactives. Une extension inactive n'est pas neutre — son code reste sur le disque et reste parfois atteignable.

Pour chacune, quatre colonnes suffisent :

• le nom et sa version installée ;
• la date du dernier commit de l'auteur, pas la date d'installation ni la note. C'est la seule colonne qui prédit l'avenir : elle dit si quelqu'un corrigera la prochaine faille ;
• actif ou inactif ;
• qui l'a installée, et pourquoi. Si personne ne sait, notez-le — c'est une information, pas un blanc.

⚠ Le piège de cette étape est de la faire à l'intuition. On croit connaître son site ; l'inventaire dit presque toujours autre chose. Faites la liste avant d'avoir une opinion.

Étape 2 — Mesurer l'usage réel, pas l'usage supposé

C'est l'étape que tout le monde saute, et c'est celle qui décide.

Pour chaque extension, la question n'est pas « à quoi sert-elle ? » mais « quand a-t-elle servi la dernière fois ? ». Trois façons de répondre, par ordre de fiabilité :

1. une trace — une commande passée, un formulaire envoyé, une page générée. C'est une preuve ;
2. une page qui l'utilise visiblement, retrouvée sur le site public. C'est un indice fort ;
3. quelqu'un qui l'affirme. C'est une hypothèse, et elle se vérifie par 1 ou 2.

Classez ensuite en trois piles seulement : utilisée · jamais vue en usage · installée « au cas où ». La troisième pile est la plus grosse sur presque tous les sites, et c'est celle qui vous coûte le plus pour ce qu'elle rapporte.

Étape 3 — Mesurer ce que chacune coûte

Trois coûts, et le troisième est le seul qui se voie sur la durée.

Le coût de page. Une extension qui charge ses scripts sur toutes les pages alors qu'elle ne sert que sur une seule est un cas fréquent et facile à repérer : comparez le poids d'une page de contenu simple avec et sans elle.

Le coût de base. Les extensions qui écrivent à chaque visite — statistiques, journaux, compteurs — grossissent la base en silence. Le symptôme n'est pas une page lente, c'est une sauvegarde qui s'allonge de mois en mois.

Le coût de maintenance. C'est le vrai. Chaque extension ajoute une mise à jour à surveiller, une compatibilité à vérifier, une casse potentielle après chaque montée de version. Ce coût est linéaire dans le nombre d'extensions et il ne baisse jamais tout seul.

Le détail de la partie performance est dans notre guide de l'audit de sécurité en 10 minutes, qui couvre les mêmes mesures sous l'angle du risque.

Étape 4 — Mesurer le risque, en trois questions

Est-elle abandonnée ? Un dernier commit qui remonte à plus d'un an, sans réponse aux signalements, est le signal le plus fort de la liste. Une extension abandonnée est plus dangereuse qu'une extension vulnérable, parce qu'aucun correctif ne viendra jamais.

Que peut-elle atteindre ? Une extension qui écrit des fichiers, exécute des tâches planifiées, ouvre un point d'entrée public ou manipule des paiements n'a pas le même profil qu'une extension d'affichage. Le nombre d'installations ne dit rien de ça.

Fait-elle doublon ? Deux extensions qui font la même chose, c'est deux fois la surface pour une fois la fonction — et c'est étonnamment courant sur un site qui a plusieurs années.

Sur ce que ces mesures protègent réellement, voir la protection proactive contre les menaces zero-day.

Étape 5 — Décider, et exécuter dans cet ordre

C'est l'étape qui transforme le tableau en résultat. Trois règles.

Supprimer, pas désactiver. Désactiver laisse le code sur le disque, donc la surface, donc la mise à jour à suivre. C'est le confort d'une décision non prise. Si vous n'osez pas supprimer, c'est que l'étape 2 n'est pas finie.

Une à la fois, avec une sauvegarde éprouvée avant. Une suppression groupée qui casse quelque chose vous laisse sans savoir laquelle. Une par une, c'est plus lent une fois et beaucoup plus rapide toutes les fois suivantes.

Dans cet ordre précis, parce qu'il va du gain certain au gain discutable :

• les inactives — aucun risque, gain immédiat sur la surface et la liste de mises à jour
• les abandonnées dont la fonction n'est plus utilisée
• les doublons, en gardant celle qui est maintenue, pas celle qu'on connaît
• les « au cas où » de l'étape 2 — c'est ici que la discussion est la plus difficile, et le gain le plus grand
• les abandonnées encore utilisées : celles-là demandent un remplacement d'abord, pas une suppression sèche

Puis, une fois seulement : notez la date et le nombre restant. C'est ce chiffre, comparé dans six mois, qui dira si l'audit a servi ou s'il a été un tableau de plus.

Ce que cet audit ne fait pas

Il ne juge pas la qualité du code d'une extension — ça demande une lecture, pas un inventaire. Il ne dit rien de la conformité de ce qu'elles collectent. Et il ne remplace pas une surveillance continue : un audit est une photo, et une photo se périme.

Conclusion

Passer de trente extensions à quinze divise la surface d'attaque par deux, réduit la charge de maintenance de moitié, et ne coûte aucun logiciel supplémentaire. C'est la mesure la plus rentable de toute la gestion d'un site WordPress, et la seule qui soit gratuite.

La difficulté n'est jamais technique. Elle est dans l'étape 2 : accepter de mesurer l'usage réel plutôt que de se fier à l'intention qu'on avait en installant. Une extension qu'on garde « au cas où » est un coût certain contre un bénéfice hypothétique — et c'est l'inverse de ce qu'on croit faire en la gardant.

Si l'inventaire vous a montré une pile fragmentée, la suite est migrer un stack WordPress fragmenté, et le diagnostic complet est dans l'enfer des extensions. Pour remplacer plusieurs outils par un ensemble cohérent, voir comment notre écosystème automatise la gestion de site. Nos extensions premium sont disponibles avec remboursement intégral sous 14 jours : voir le catalogue.