L’audit des extensions commence par la liste réelle des dossiers, pas par le souvenir du chef de projet. Sur le serveur, wp plugin list affiche le slug, l’état (active, inactive, must-use), la version installée et la version disponible. Dans l’admin, le même constat est sous Extensions : les lignes actives, les lignes désactivées, l’onglet Indispensables pour les mu-plugins, et les drop-ins (object-cache.php, advanced-cache.php, db.php) signalés comme extensions avancées.
Sortir l’inventaire
- Depuis la racine WordPress, lancez
wp plugin list --format=csvet enregistrez le fichier dans le dossier du client, daté. - Ouvrez
wp-content/pluginset comparez les dossiers au CSV. Un dossier absent du CSV est rare ; un dossier présent mais jamais listé mérite un œil (extension au nom modifié, reste d’une installation cassée). - Listez
wp-content/mu-plugins. Chaque fichier PHP y est chargé avant les extensions normales. - Notez les drop-ins à la racine de
wp-content:advanced-cache.php,object-cache.php,db.php,sunrise.php. Ils viennent souvent d’une extension de cache ou d’un hébergeur, et une mise à jour d’extension ne les remplace pas toujours. - Relevez la version de PHP (
wp cli infoou le panneau d’hébergement) et la version de WordPress (wp core version). Une extension à jour sur PHP 8.3 peut être la seule qui tient encore le site en PHP 7.4, ou l’inverse.
Le CSV est la photo. Ne le remplacez pas par une capture d’écran : vous ne pourrez pas comparer le mois suivant.
Lire une ligne et trancher
| Signal | Lecture | Décision |
|---|---|---|
| inactive, dossier encore là | Plus chargée, fichiers encore en ligne | Supprimer si personne ne sait pourquoi elle est restée |
| update=available, site en production | Écart de version, changelog non lu | Mettre à jour d’abord sur une copie, puis en production |
| active, plus mise à jour depuis des années sur wordpress.org | Abandonnée ou renommée | Prévoir un remplacement, ne pas la laisser au seul motif qu’elle répond encore |
| premium sans licence | Plus de mises à jour de sécurité | Racheter la licence ou retirer l’extension |
| mu-plugin sans commentaire en tête de fichier | Chargé en silence | Demander qui l’a posé avant d’y toucher |
| slug présent deux fois (dossier et dossier-old) | Copie manuelle | Supprimer la copie après avoir vérifié qu’elle n’est pas le mu-plugin |
Le dépôt wordpress.org indique, sur la page de l’extension, la version et la date de la dernière mise à jour. Croisez-la avec le Stable tag du fichier readme.txt du site. Un readme qui annonce 2.4 alors que le PHP du plugin est encore en 1.9 signifie que quelqu’un a copié un readme sans le code, ou l’inverse : ne vous fiez pas au seul numéro affiché dans l’admin si le site a été restauré en partie.
Ce que l’écran Extensions ne montre pas
Du code dans functions.php du thème enfant, un snippet collé dans un extension du type code snippets , ou un fichier PHP déposé dans wp-content/uploads ne sont pas des extensions. L’audit des plugins ne les couvre pas. Si uploads contient des .php, ce n’est plus un inventaire : c’est une piste de compromission, à traiter comme dans le guide nettoyer un WordPress infecté. Les extensions souvent visées pour leur surface d’attaque sont à relire dans plugins WordPress ciblés, en partant de votre CSV, pas d’une liste générique.
Une extension de sécurité qui promet un pare-feu ne remplace pas la suppression d’une extension inactive. Les deux sujets sont distincts. Notez aussi les extensions qui écrivent dans wp-config.php ou qui créent un compte administrateur à l’activation : leur mise à jour change la sécurité du site, pas seulement une fonction.
La feuille d’arbitrage
Le livrable tient en une feuille, une ligne par slug : version actuelle, version proposée, état, décision (garder, mettre à jour, remplacer, supprimer), fenêtre retenue, personne. La mise à jour elle-même se fait plus tard : sauvegarde des fichiers et de la base, essai sur la copie, contrôle de l’accueil, de la connexion wp-login.php et d’un formulaire, puis production. Cinq extensions d’un coup sans sauvegarde, ce n’est pas un audit, c’est un pari.
Quand une ligne change de version sans décision dans la feuille, quelqu’un a activé les mises à jour automatiques, ou l’hébergeur l’a fait. Ce n’est pas interdit. Il faut que la feuille le dise, sinon le prochain incident n’aura pas de point de départ. Les fichiers modifiés en dehors de cette feuille se rapprochent du cas décrit dans fichiers WordPress modifiés sans raison.
Rangez le CSV et la feuille au même endroit. Le prochain audit commence par un diff des deux CSV, pas par une nouvelle visite dans l’admin.