Mettre à jour ses plugins WordPress sans tout casser (l'histoire d'un vendredi à 21 h)

Un vendredi soir, à 21 h, un client m’appelle : plus personne n’arrive à payer sur sa boutique. Les visiteurs remplissent leur panier normalement, arrivent à l’étape du règlement, cliquent, et tombent sur une page blanche. Il venait de l’apprendre par une habituée qui lui demandait sur Instagram si la boutique avait fermé. Sa dernière commande datait de 14 h 15.

Vers 14 h, justement, quelqu’un de son équipe avait ouvert le tableau de bord WordPress, vu la pastille orange et son compteur, et cliqué sur Tout mettre à jour. Quatorze plugins d’un coup. Personne n’a ensuite vérifié le site, et personne n’avait de raison de le faire, puisque la page d’accueil s’affichait très bien. Elle s’affichait d’ailleurs toujours très bien à 21 h : une page d’accueil ne touche presque jamais au code qui traite un paiement.

Bilan : sept heures, un vendredi, l’un des deux meilleurs jours de vente de la semaine, sans une seule commande enregistrée, sur un site qui, vu de l’extérieur, avait l’air parfaitement normal.

Ce qui suit, c’est la routine que j’applique depuis ce jour-là, et qu’on applique aujourd’hui sur chaque site dont on s’occupe. Elle n’a rien de compliqué. Elle est simplement lente, et c’est précisément ce qui la rend utile : mettre à jour ses plugins WordPress sans tout casser tient à un enchaînement d’étapes, pas à un bouton.

Pourquoi « Tout mettre à jour » est le bouton le plus cher du tableau de bord

Le bouton est bien conçu, et il fait exactement ce qu’il annonce. Le problème tient à ce qu’il escamote : il ramène quatorze décisions distinctes à un seul geste, et il vous prive de la seule information vraiment utile le jour où ça tourne mal.

Vous mettez un plugin à jour, le site plante : vous savez pourquoi dans la seconde. Vous en mettez quatorze, le site plante, et vous voilà avec quatorze suspects, aucune trace de ce qui a bougé, et un client au téléphone. Ce vendredi-là, identifier le coupable a pris bien plus de temps que la réparation elle-même, qui a duré quatre minutes.

Il y a une seconde raison, dont on parle rarement : rien dans WordPress ne vous signale qu’une mise à jour est en réalité une réécriture. Passer de la version 4.9 à la version 5.0, ça peut aussi bien être une simple correction de bug qu’une base de code entièrement réécrite, qui se greffe au panier d’une tout autre façon. Le tableau de bord affiche le même petit lien bleu dans les deux cas.

Ce qui lâche, et pourquoi

Avec les années, les pannes se rangent dans quatre familles. Savoir laquelle on a sous les yeux, c’est déjà l’essentiel du diagnostic.

Un conflit entre deux plugins. Deux extensions interviennent au même endroit, en général le panier, les champs de commande ou le module de paiement, et chacune fonctionne parfaitement de son côté. La nouvelle version de la première change ce qu’elle transmet à la seconde, qui part alors en erreur sans que personne le voie : sur un site en production, les messages d’erreur sont masqués par défaut. C’est ce qui s’est produit ce vendredi-là.

Un conflit avec le thème. Fréquent quand le thème a été modifié directement, sans passer par un thème enfant. Le plugin renomme une fonction ou remplace un gabarit, le thème continue d’appeler l’ancienne version, et la page part en erreur. Celle-là, au moins, se voit tout de suite.

Un décalage avec la version de PHP. Soit le plugin est désormais écrit pour un PHP plus récent que celui de l’hébergement, soit c’est l’inverse et un vieux plugin finit par buter sur le PHP que l’hébergeur a mis à jour le mois dernier. Le symptôme classique, c’est une erreur 500 là où une page fonctionnait la veille.

Une réécriture de version majeure. L’auteur a reconstruit son extension : les réglages changent de place, des fonctionnalités disparaissent, la structure de la base de données évolue. De son point de vue rien n’est cassé, du vôtre tout a changé. C’est le seul cas où revenir en arrière ne suffit pas toujours, parce que la mise à jour a déjà transformé vos données au passage.

La routine, étape par étape

Sept étapes. Sur un site classique, avec une douzaine de plugins, comptez quarante minutes une fois par mois, dont une bonne partie d’attente.

1. Faites une sauvegarde du jour, et contrôlez-la. Pas celle de la nuit dernière : une nouvelle, prise maintenant, fichiers et base de données, stockée ailleurs que sur le serveur du site. Le mot « vérifiée » recouvre deux gestes différents. Chaque mois, assurez-vous que cette sauvegarde s’est bien terminée et que le fichier se trouve réellement hors du serveur, pas qu’un plugin a affiché « terminé ». Plus rarement, un trimestre suffit, allez plus loin et restaurez une sauvegarde pour de vrai quelque part : une sauvegarde jamais restaurée est une promesse, pas un filet. Si vous n’avez jamais fait cette restauration complète, ne serait-ce qu’une fois, c’est le premier point de la checklist d’audit, et il passe avant tout le reste.

2. Lisez les changelogs, et pas seulement ceux des gros sauts de version. Il n’est pas question d’en lire quatorze. Commencez par les deux ou trois où le premier chiffre a bougé, ou dont les notes contiennent « breaking », « removed », « rewritten » ou « requires PHP ». Lisez ensuite les notes de tout ce qui touche à la commande, au paiement, à la connexion, aux formulaires ou à la base de données, même pour une petite montée de version : les plugins ne suivent pas tous la même numérotation, et un changement cassant peut se cacher derrière une mise à jour d’apparence mineure. Cinq minutes, et c’est là qu’on repère les réécritures avant qu’elles ne vous tombent dessus.

3. Passez par une préproduction si le site rapporte. Une préproduction, c’est une copie du site, en ligne à une autre adresse, où vous pouvez tout casser sans témoin. Aujourd’hui, la plupart des hébergeurs sérieux en créent une en deux clics. Si votre site encaisse des paiements, prend des réservations ou reçoit des demandes de devis qui comptent, l’étape n’est pas facultative : c’est ce qui sépare une soirée pourrie d’un trimestre dans le rouge.

4. Procédez par lots de trois ou quatre, jamais les quatorze d’un coup. Regroupez grossièrement : ce qui touche à la vente ensemble, ce qui touche aux formulaires ensemble, les petits utilitaires ensemble. Un lot, puis l’étape 5, et seulement après le lot suivant.

5. Après chaque lot, ouvrez les trois pages qui comptent. Surtout pas la page d’accueil, qui ment. Ouvrez celles où l’argent et les prises de contact arrivent vraiment : la page de commande, avec un vrai produit dans le panier ; le formulaire de contact, avec un vrai envoi ; et la fonctionnalité sur mesure dont votre site dépend. Quelques minutes chacune, pas un simple coup d’œil. Si un lot a fait sauter quelque chose, vous avez trois ou quatre suspects au lieu de quatorze.

6. Le cœur de WordPress en dernier, pas en premier, sauf si un plugin l’exige. Les auteurs de plugins ne rendent leurs extensions compatibles avec une nouvelle version du cœur que dans les semaines qui suivent sa sortie : commencer par le cœur, c’est donc bouger avant que vos plugins aient suivi. L’exception, c’est un plugin qui réclame déjà la nouvelle version du cœur : celui-là se met à jour après le cœur, pas avant. Regardez ce que chaque mise à jour annonce comme prérequis, et testez l’ordre en préproduction avant de vous y fier.

7. Notez ce que vous avez fait. Date, plugins concernés, versions avant et après, et tout ce qui vous a paru bizarre. Un fichier texte suffit. L’intérêt apparaît trois semaines plus tard, quand quelque chose cloche sans qu’on sache pourquoi et que la seule question qui compte devient : qu’est-ce qui a changé ?

Quand ça plante quand même

Ça arrivera, tôt ou tard. La routine ne rend pas la panne impossible, elle la rend peu coûteuse. Voici dans quel ordre procéder, et cet ordre compte autant que celui de la routine.

Arrêtez les mises à jour. Quel que soit le lot en cours, arrêtez-vous là. N’enchaînez surtout pas sur le suivant en espérant que ça se débloque tout seul.

Désactivez, ne supprimez pas. Si vous savez de quel lot il s’agit, désactivez ces plugins un par un, en rechargeant la page en panne à chaque fois. Le site redevient normal juste après l’un d’eux : vous tenez votre coupable.

Revenez en arrière sur ce plugin-là uniquement. Les anciennes versions des extensions du répertoire officiel restent téléchargeables : revenir en arrière, c’est remettre les anciens fichiers en place, pas supprimer le plugin pour le réinstaller. Ne touchez pas au reste du site. Une restauration complète effacerait toutes les commandes, tous les commentaires et tous les envois de formulaire reçus depuis la sauvegarde, ce qui, un vendredi chargé, vous vaudrait une deuxième catastrophe dans la soirée.

Ne restaurez la sauvegarde complète que si le site est inutilisable et que la cause vous échappe encore au bout de quinze minutes. C’est la raison d’être de l’étape 1, et c’est vraiment le dernier recours.

Ensuite, décidez ce que vous faites du plugin figé. Le voilà bloqué sur une ancienne version, ce qui constitue un risque en soi, surtout si la mise à jour contenait un correctif de sécurité. Trois options : attendre la prochaine version de l’auteur, lui chercher un remplaçant, ou payer quelqu’un pour faire fonctionner la nouvelle version avec votre installation. Un plugin figé puis oublié, c’est exactement comme ça qu’on se retrouve avec un incident de sécurité six mois plus tard.

Pourquoi tout se joue sur la taille du lot

S’il ne faut retenir qu’une chose, ce n’est pas la sauvegarde : tout le monde sait déjà qu’il faudrait la faire. C’est le découpage en lots.

Le lot, c’est ce qui préserve le lien entre la cause et l’effet. Quatorze d’un coup, vous êtes devant une énigme. Trois à la fois, vous avez une liste de suspects assez courte pour la passer en revue avant que le client au bout du fil ne raccroche.

C’est aussi pour ça que la réponse honnête à « ça prend combien de temps ? » n’a rien de vendeur : plus de temps que d’appuyer sur un bouton. Quarante minutes par mois contre sept heures de paiement hors service, le calcul est vite fait, mais on ne s’en rend compte qu’après avoir vécu les sept heures.

Qui s’en charge, et quel jour

Le dernier point n’a rien de technique : il faut que quelqu’un soit nommément responsable du créneau mensuel, à une date fixe. Les sites qui tombent pendant les mises à jour sont presque toujours ceux où la mise à jour revient à celui qui a vu la pastille, au moment où il l’a vue. D’où le vendredi à 14 h, avec le week-end juste derrière.

Choisissez un jour, et surtout pas le vendredi. Le mardi ou le mercredi matin, quand votre équipe est disponible, quand le support de votre hébergeur est en poste, et quand il vous reste trois jours ouvrés s’il faut y revenir. Mettez-le dans un agenda, avec un nom en face.

Si, honnêtement, personne chez vous ne s’en occupe, autant l’externaliser. C’est tout l’objet de nos forfaits de maintenance WordPress : le créneau a lieu à date fixe, que quelqu’un y pense ou non. Et les agences qui préfèrent que leurs clients n’entendent jamais parler de maintenance nous la délèguent en marque blanche.

FAQ

Faut-il activer les mises à jour automatiques des plugins WordPress ?

Pour les petits utilitaires sans effet sur les ventes ni sur les prises de contact, oui : les mises à jour automatiques referment les failles plus vite qu’un créneau mensuel. Pour tout ce qui touche à la commande, au paiement, aux formulaires, aux réservations ou aux comptes membres, non. Ceux-là se traitent à la main, par petits lots, en rechargeant une page après chaque lot.

À quelle fréquence faut-il mettre à jour ses plugins ?

Une fois par mois pour le créneau complet, et immédiatement pour tout plugin concerné par une faille de sécurité publiée. Un correctif de sécurité n’attend pas votre agenda ; le reste, si.

Peut-on revenir en arrière après une mise à jour de plugin ?

Oui. Les anciennes versions des extensions du répertoire officiel restent téléchargeables : revenir en arrière consiste à remettre les fichiers de la version précédente, en général avec une extension de rollback ou par FTP. Ne passez pas par le bouton « Supprimer » du tableau de bord pour y arriver : supprimer un plugin peut déclencher son propre nettoyage et effacer les données qu’il stockait. Désactivez, puis remplacez les fichiers. Seule exception : une version majeure qui a migré votre base de données à l’installation. Remettre l’ancien code ne remet pas forcément les anciennes données, et c’est précisément pour ça que l’étape 1 impose une sauvegarde du jour.

Pourquoi mon site a-t-il planté après une mise à jour alors que tout semblait normal ?

Parce que la page que vous avez vérifiée n’est presque jamais celle qui a lâché. Une page d’accueil est simple et ne touche quasiment jamais au code qui fait tourner une commande, un envoi de formulaire ou un espace membre. Ne vérifier que l’accueil après une mise à jour, c’est tester la partie du site la moins susceptible d’être touchée.

Une préproduction est-elle vraiment nécessaire ?

Si le site rapporte de l’argent ou collecte des demandes qui comptent, oui. Pour un site vitrine de cinq pages avec un formulaire de contact, une sauvegarde vérifiée et de petits lots suffiront largement. La règle simple : si une journée de panne coûte plus cher qu’une année de préproduction, vous avez déjà votre réponse.

Que faire d’un plugin que son auteur n’a pas mis à jour depuis deux ans ?

Alors la bonne question n’est plus celle de la mise à jour, mais celle du remplacement. Une extension laissée à l’abandon ne recevra plus de correctif de sécurité : c’est une dette qui grossit tranquillement. Prévoyez le remplacement pendant que le site va bien, pas au milieu d’un incident.

Peut-on mettre à jour le cœur de WordPress et les plugins le même jour ?

Oui, à condition de faire les plugins d’abord et le cœur en dernier, avec une vérification de page entre les deux. Ce qui n’est pas prudent, c’est de lancer les deux d’un coup, en un clic, et d’apprendre par un client ce que vous auriez dû voir vous-même.

Une question sur cet article ? Réponse par e-mail, en privé. Rien n'est publié sur le site. +