Comment surveiller les mises à jour de plugins avec WP-CLI ?

Un site WordPress laisse rarement tomber d'un coup ; il se dégrade par petites touches, et la plus courante commence par une extension restée trois versions en arrière. La surveillance des mises à jour de plugins ressemble à une évidence tant qu'on gère un seul site, puis devient un travail à part entière dès qu'on en gère quinze : ouvrir quinze tableaux de bord chaque lundi pour lire la même information n'est pas une méthode, c'est une corvée que l'on finit par sauter. WP-CLI, l'interface en ligne de commande officielle de WordPress, permet d'obtenir cette information sans navigateur, sur autant de sites qu'on veut, et de la recevoir par courriel dans un format lisible. Le gain n'est pas seulement du temps gagné, c'est surtout de la régularité : un rapport qui arrive tout seul se lit, un tableau de bord qu'il faut aller consulter finit par ne plus l'être.

Inventorier ce qui est réellement installé

Avant de surveiller quoi que ce soit, il faut savoir ce qui tourne. La commande d'inventaire des extensions renvoie, pour chaque extension présente sur le disque, son identifiant, son état d'activation, sa version installée, la disponibilité d'une mise à jour et la version cible. Cette liste comporte presque toujours des surprises : des extensions désactivées mais toujours présentes, des extensions installées par un prestataire précédent, parfois deux extensions qui font la même chose. C'est le premier bénéfice de la démarche, avant même la surveillance, et le point de départ de tout travail sérieux sur les extensions WordPress d'un site en production.

Lire la sortie au format machine

WP-CLI affiche par défaut un tableau destiné à un œil humain, ce qui convient pour un contrôle ponctuel et pas du tout pour un traitement automatisé. Toutes les commandes de liste acceptent un format de sortie alternatif, notamment CSV et JSON, et une sélection explicite des colonnes retenues. C'est cette forme qu'il faut utiliser dès qu'un script consomme le résultat : elle ne change pas de largeur, ne tronque pas les noms longs et ne dépend pas de la taille du terminal. Demander explicitement les colonnes utiles, plutôt que de prendre la sortie complète, protège en prime des évolutions de format entre versions de WP-CLI, qui ajoutent parfois des colonnes sans prévenir.

Distinguer l'inactif de l'inutile

Une extension désactivée ne s'exécute pas, mais son code reste accessible sur le disque, et une faille dans un fichier appelable directement s'exploite qu'elle soit activée ou non. La règle de gestion est donc simple : ce qui est désactivé depuis plus de quelques semaines se supprime, ce qui est conservé se met à jour comme le reste. L'inventaire permet de repérer ces extensions dormantes en une lecture, et de poser la question à qui de droit avant de les retirer. Sur un site repris à un confrère, cette seule opération divise souvent par deux le nombre d'extensions présentes.

Nommer les sites plutôt que les chemins

Dès qu'on surveille plusieurs sites, la sortie brute devient inexploitable si rien n'indique de quel site elle provient. La bonne pratique consiste à tenir un fichier de configuration listant les sites, avec pour chacun un nom court lisible et le chemin de son installation, puis à faire boucler le script sur ce fichier en préfixant chaque ligne de résultat par le nom court. Ce détail décide de la lisibilité du rapport final : un rapport qui dit que trois extensions sont en retard sans dire où ne fait avancer personne.

Se souvenir de l'état précédent

Un inventaire pris chaque semaine et conservé vaut bien plus qu'un inventaire pris une fois. La comparaison entre deux relevés successifs révèle ce qu'aucune photographie instantanée ne montre : une extension apparue sans que personne ne l'ait annoncée, une extension disparue, une version qui a reculé, signe d'une restauration de sauvegarde mal maîtrisée. Le stockage tient dans un fichier par site et par date, de quelques kilooctets, que l'on peut conserver plusieurs années sans y penser. C'est aussi ce qui permet, le jour où un dysfonctionnement apparaît, de répondre précisément à la question de savoir ce qui a changé sur ce site depuis la dernière fois qu'il fonctionnait, question à laquelle bien peu de parcs savent répondre.

Détecter ce qui est réellement en retard

Toutes les mises à jour ne se valent pas, et un rapport qui les traite à égalité produit exactement l'effet inverse de celui recherché : noyé sous quarante lignes chaque semaine, le destinataire cesse de les lire. Le tri se fait sur deux critères, l'écart de version et la nature du correctif. La même logique de priorisation vaut d'ailleurs pour les tâches planifiées d'un site, dont nous avons détaillé la mise en place propre dans notre article sur la manière de programmer une tâche récurrente propre avec l'API Cron de WordPress.

Lire l'écart de version, pas la présence d'une mise à jour

Le versionnage sémantique, largement suivi dans l'écosystème WordPress même s'il n'y est pas obligatoire, découpe un numéro en trois niveaux dont chacun porte une promesse. Un changement du dernier niveau corrige sans rien modifier d'autre, un changement du niveau intermédiaire ajoute des fonctionnalités en principe sans casse, un changement du premier niveau autorise une rupture de compatibilité. Comparer les deux versions niveau par niveau, plutôt que de constater qu'elles diffèrent, permet de classer chaque mise à jour en trois piles et de traiter la première sans réfléchir, la deuxième avec un contrôle rapide et la troisième avec un vrai test.

Repérer les extensions abandonnées

Le cas le plus dangereux n'est pas l'extension en retard, c'est l'extension qui ne propose plus aucune mise à jour depuis deux ans. Elle n'apparaît jamais dans un rapport de mises à jour disponibles, puisqu'il n'y en a pas, et passe donc à travers toute surveillance naïve. Les informations publiées par le dépôt officiel donnent pour chaque extension la date de la dernière mise à jour et la version de WordPress avec laquelle elle a été testée. Un script de surveillance complet interroge ces données et signale toute extension dont la dernière publication remonte à plus de douze mois, ce qui est un signal d'alerte bien plus fiable qu'un numéro de version.

Traiter à part les extensions à licence

Les extensions commerciales ne passent pas par le dépôt officiel et n'apparaissent pas toujours correctement dans l'inventaire des mises à jour. Certaines n'annoncent leur nouvelle version que si la licence est active et enregistrée sur le site, ce qui crée un angle mort silencieux : la licence expire, l'extension cesse de proposer ses mises à jour, et rien ne le signale. Le rapport gagne donc à afficher une section distincte pour ces extensions, avec la date d'expiration de licence quand elle est lisible, et à traiter l'absence prolongée de mise à jour comme un motif de vérification manuelle plutôt que comme une bonne nouvelle.

Ne pas oublier le socle

La surveillance des extensions perd l'essentiel de son intérêt si le cœur de WordPress, le thème et la version de PHP restent hors du champ. Une extension à jour posée sur un socle périmé reste vulnérable, et la plupart des extensions récentes finissent par exiger une version de PHP que l'hébergement n'offre plus. Les mêmes commandes en ligne renseignent la version du noyau, celle du thème actif et celle de l'interpréteur, et ces trois valeurs méritent une ligne d'en tête dans le rapport, avant même la liste des extensions. Une version de PHP qui n'est plus maintenue est en général le problème le plus urgent d'un site, et le seul que personne ne voit dans le tableau de bord.

Envoyer un rapport que quelqu'un lira

Un rapport automatique n'a de valeur que s'il est lu, et il n'est lu que s'il est court, régulier et immédiatement compréhensible. Cela suppose des arbitrages de fond : envoyer moins souvent, n'envoyer que ce qui a changé, et présenter en tête ce qui appelle une décision. La même exigence de lisibilité vaut pour tout rapport technique adressé à un client, y compris ceux qui accompagnent le choix d'un plugin pour WordPress au moment de la construction du site.

Ne rien envoyer quand il n'y a rien à dire

Le courriel hebdomadaire qui répète que tout va bien apprend au destinataire à ne pas l'ouvrir, et le jour où il contient une alerte, il n'est pas ouvert non plus. La règle est donc de n'envoyer que lorsqu'il y a au moins une ligne à traiter, quitte à programmer un envoi mensuel de synthèse pour prouver que la surveillance fonctionne toujours. Ce silence conditionnel se code en trois lignes et change entièrement le rapport au rapport : un message qui arrive signifie qu'il faut agir, ce qui est exactement la propriété recherchée.

Composer un message lisible sur téléphone

La plupart de ces rapports se lisent sur un téléphone, souvent en marchant. Le sujet du message doit donc porter l'information essentielle, par exemple le nombre de sites concernés et le nombre d'alertes de sécurité, et le corps doit tenir sur un écran pour les cas simples. Un tableau HTML de six colonnes est illisible dans cette situation : une liste par site, chaque ligne portant le nom de l'extension, la version installée, la version cible et une pastille de priorité, passe beaucoup mieux. Le détail complet peut être joint en pièce attachée au format CSV pour ceux qui veulent le traiter dans un tableur.

Fiabiliser l'envoi lui même

La fonction d'envoi de courriel native de PHP passe très mal les filtres antispam quand elle expédie depuis un serveur qui n'est pas déclaré comme émetteur légitime du domaine. Un rapport qui finit systématiquement en indésirables est pire qu'aucun rapport, puisqu'il donne l'illusion d'une surveillance. Le paramétrage correct passe par un serveur d'envoi authentifié, une adresse d'expéditeur appartenant à un domaine dont les enregistrements d'authentification sont en place, et un test réel vers plusieurs fournisseurs de messagerie. Le contrôle se fait une fois, à l'installation, et se refait le jour où l'on change d'hébergement.

Choisir la bonne fréquence de collecte

La collecte et l'envoi n'ont pas à suivre le même rythme. Relever l'inventaire tous les jours coûte quelques secondes par site et donne une chronologie fine, précieuse en cas d'incident ; envoyer un rapport tous les jours est en revanche le meilleur moyen de le rendre invisible. Le réglage qui fonctionne consiste donc à collecter quotidiennement, à envoyer une synthèse hebdomadaire des écarts non traités, et à déclencher un envoi immédiat hors rythme dans un seul cas, celui d'un correctif de sécurité annoncé. Cette exception, et elle seule, justifie d'interrompre quelqu'un, ce qui lui donne tout son poids quand elle survient.

Mettre à jour sans casser le site

La surveillance ne sert à rien si l'étape suivante fait peur. Or la mise à jour d'extension a mauvaise réputation, méritée dans les cas où elle est faite sans filet, sur le site en production, un vendredi soir. Les mêmes commandes qui produisent l'inventaire permettent d'organiser une mise à jour réversible, et le passage par la ligne de commande apporte ici un avantage décisif : chaque étape est scriptable, donc reproductible à l'identique sur les quinze sites du parc.

Sauvegarder ce qu'il faut, pas tout

La sauvegarde préalable est indispensable, mais elle n'a pas besoin d'être complète pour être utile. Avant une mise à jour d'extension, ce qui compte est l'état du dossier de l'extension et l'état de la base de données, la médiathèque n'étant pas concernée. Une archive du seul dossier de l'extension et un export de la base pèsent quelques dizaines de mégaoctets là où une sauvegarde intégrale en pèse plusieurs gigaoctets, et se restaurent en quelques secondes. Cette différence de coût décide en pratique de la fréquence à laquelle la sauvegarde est réellement faite. Reste le cas des extensions qui modifient la structure de la base lors de leur mise à jour, ce qui est fréquent sur les boutiques et les extensions de formulaires : la restauration du seul dossier ne suffit alors plus, puisque le code revenu en arrière ne sait pas relire des tables déjà migrées. Ces extensions se repèrent à leur documentation, qui mentionne une routine de migration, et méritent une sauvegarde complète de la base avant intervention, ainsi qu'un essai préalable ailleurs qu'en production.

Mettre à jour par groupes homogènes

Mettre à jour les vingt extensions d'un coup et découvrir une page cassée oblige à chercher laquelle des vingt est en cause. Procéder une par une est plus sûr mais trop lent pour un parc de sites. Le compromis consiste à travailler par groupes : d'abord toutes les mises à jour de dernier niveau, réputées sans effet de bord, en un seul lot avec un contrôle après ; puis les autres une par une, chacune suivie de son contrôle. Sur un site typique, ce découpage ramène vingt mises à jour à un lot et trois opérations individuelles, ce qui tient dans une demi heure. La fenêtre choisie compte autant que la méthode : un mardi matin laisse trois jours ouvrés pour rattraper une surprise, un vendredi soir n'en laisse aucun, et une boutique se met à jour en dehors de ses heures de commande plutôt qu'en pleine soirée.

Vérifier après coup, automatiquement

Le contrôle qui suit la mise à jour doit être aussi automatisé que le reste, sans quoi il est sauté. Trois vérifications couvrent la grande majorité des incidents : le site répond bien un code 200 sur une poignée d'URL représentatives, aucune erreur fatale n'est apparue dans le journal PHP depuis le début de l'opération, et le nombre de pages du plan de site n'a pas chuté. Cette dernière vérification attrape le cas particulièrement discret où une extension de référencement change son comportement par défaut après mise à jour et retire des contenus de l'index sans que rien ne le signale à l'écran.

Garder une trace de ce qui a été fait

Chaque opération de mise à jour gagne à écrire sa propre ligne dans un journal simple : date, site, extension, version de départ, version d'arrivée, résultat du contrôle. Ce journal sert à trois choses, dont deux ne se révèlent qu'après plusieurs mois. Il permet de répondre à un client qui demande ce qui a été fait sur son site, il alimente la comparaison lors du prochain incident, et il fait apparaître les extensions qui reviennent trop souvent, celles dont chaque mise à jour demande une correction derrière. Ces dernières coûtent en réalité bien plus cher que leur prix d'achat, et le journal est le seul endroit où cette dépense devient visible.