Mettre à jour ses extensions WordPress : ce qui arrive si vous ne le faites pas

Dans presque tous les tableaux de bord WordPress, un petit nombre se tient à côté de Extensions. Il ne dérange personne. Vous le chassez d'un clic parce qu'autre chose est plus urgent, et à la connexion suivante le nombre a grandi. Ce qui frappe, c'est que rien ne se passe. La page s'affiche, le formulaire de contact envoie, la boutique encaisse. Le problème est exactement là. Le coût de l'inaction reste invisible jusqu'à ce qu'il cesse de l'être, et il arrive alors d'un seul coup.

Cet article explique ce qui se passe réellement entre la pastille de mise à jour et l'incident, du point de vue de celles et ceux qui écrivent ces mises à jour. Nous développons nous mêmes des extensions WordPress, nous publions les mises à jour dont il est question ici, et nous voyons ce qui se passe ensuite.

Pourquoi une pastille de mise à jour n'est pas une invitation au rangement

1. Une mise à jour de sécurité est ce qui rend la faille publique

C'est le point que presque personne ne connaît, et il retourne l'intuition. Tant qu'une faille de sécurité dort sans avoir été découverte dans une extension, personne n'en sait rien. Au moment où le développeur la ferme et publie la nouvelle version, quelque chose de neuf apparaît : une comparaison publique entre l'avant et l'après. Les extensions WordPress sont sous licence GPL, leur code source est ouvert, et chaque version reste consultable dans le répertoire. Poser deux versions côte à côte et voir quelle ligne a changé relève de la routine.

Publier une mise à jour de sécurité revient donc à publier aussi le chemin vers la faille de l'ancienne version. Ce n'est pas un argument contre les mises à jour, c'est l'argument le plus fort en faveur de mises à jour rapides. La période la plus dangereuse dans la vie d'une faille ne commence pas quand elle est écrite, elle commence quand elle est corrigée. Mettre à jour trois semaines plus tard, c'est avoir exploité pendant trois semaines une faiblesse documentée.

2. Personne ne vous attaque, quelque chose vous scanne

L'objection la plus fréquente tient en une phrase : mon site est bien trop petit pour intéresser quelqu'un. Cela suppose qu'à l'autre bout se trouve une personne qui choisit. Il n'y en a pas. Ce qui tourne, ce sont des scans automatiques qui traitent des listes d'adresses et cherchent des empreintes : des chemins que seule une extension précise crée, des indications de version dans des fichiers lisibles publiquement, des réponses qui trahissent une version donnée.

Pour ce processus, peu importe que votre site reçoive dix ou dix mille visiteurs. Ce qui intéresse n'est pas votre audience, mais le serveur, la boîte d'envoi pour le spam et la place pour des redirections. Un petit site n'est donc pas une moins bonne cible, seulement une cible moins voyante. C'est d'ailleurs pourquoi les intrusions passent souvent inaperçues pendant des mois.

3. Une extension, c'est plus que le code écrit par son développeur

Presque toute extension d'une certaine taille embarque des bibliothèques tierces : pour générer des PDF, traiter des images, brancher des paiements, dessiner des graphiques. Elles se trouvent dans le dossier de l'extension et sont livrées avec. Si une faille est révélée dans l'une de ces bibliothèques, le fait que la version corrigée vous parvienne dépend uniquement de l'éditeur de l'extension. Vous ne voyez pas ces dépendances dans le tableau de bord et vous ne pouvez pas non plus les mettre à jour vous même.

Du point de vue du développement, c'est une bonne part de notre travail de mise à jour, et elle reste totalement invisible de l'extérieur. Une version dont le journal des modifications se contente d'annoncer des dépendances mises à jour n'a l'air de rien et peut malgré tout être la plus importante du trimestre.

4. L'extension la plus dangereuse est celle qui a été abandonnée

Une extension qui n'a pas reçu de mise à jour depuis deux ans n'est pas inoffensive parce que rien ne s'est produit. Elle est dangereuse parce que plus rien ne se produira. Si une faille y est trouvée, aucune mise à jour n'arrivera, et en règle générale vous ne l'apprendrez pas.

Nous avons mesuré l'ampleur du phénomène lors d'une recherche interne. Pour notre panorama du marché, nous avons passé en revue des articles comparatifs et vérifié à la source les extensions recommandées. Dans un article récent proposant vingt recommandations, cinq d'entre elles étaient fermées dans le répertoire WordPress. L'article les recommande toujours, et celui qui les a installées voit dans sa liste d'extensions exactement la même chose qu'avant : un nom, un numéro de version, aucun avertissement. Une extension fermée ne disparaît pas de votre site, elle cesse simplement de livrer des mises à jour.

Comment cela se passe de notre côté

Nous nous tenons de l'autre côté de ce processus, voici donc la partie sans éclat.

Il faut une adresse à laquelle quelqu'un peut écrire. Qui trouve une faille doit pouvoir la signaler sans passer par un formulaire de contact qui atterrit au service commercial. Nous maintenons pour cela une adresse de sécurité dédiée. Ce n'est pas grand chose à mettre en place, et c'est la différence entre un signalement qui arrive et un signalement qui finit par devenir public parce que personne n'a répondu.

Nous préférons publier petit et souvent plutôt que gros et rarement. Un exemple de cette semaine : notre version 2.3.0 est sortie le 17 août, la 2.3.1 le 18 août, parce que la bannière de consentement se réaffichait à des visiteurs qui avaient déjà tranché. Aucune faille de sécurité, une simple gêne. Ce genre de correction part malgré tout immédiatement et n'attend pas le prochain gros paquet. La raison est concrète : une version qui change une chose peut être vérifiée. Une version qui change huit choses ne permet plus à personne de remonter à la seule modification qui a cassé la mise en page.

Et la partie que les éditeurs écrivent à contrecoeur : les mises à jour tournent parfois mal. Ce n'est pas de la théorie, c'est notre quotidien autant que le vôtre. Qui affirme que ses mises à jour sont sans risque a soit peu d'utilisateurs, soit la mémoire courte. La bonne réponse n'est pas de mettre à jour moins souvent, elle consiste à garder chaque mise à jour petite et réversible. Si un écran blanc apparaît sur votre site après une mise à jour, c'est agaçant et réglé en dix minutes. Une intrusion, non.

La formule never touch a running system vient d'un monde où le système se trouvait dans une pièce et où la porte était fermée à clé. Votre installation WordPress se trouve sur internet. Son environnement change tous les jours même si vous ne touchez à rien : versions de PHP, navigateurs, le coeur de WordPress, et les outils de celles et ceux qui cherchent les anciennes versions. Un système qui ne bouge pas ne devient pas plus stable dans cet environnement, il devient seulement plus vieux.

Ce que le Cyber Resilience Act change au 11 septembre

Le Cyber Resilience Act est un règlement européen visant les produits comportant des éléments numériques, et le logiciel en fait partie. À partir du 11 septembre 2026 s'appliquent les obligations de signalement : les vulnérabilités activement exploitées et les incidents de sécurité graves doivent être signalés. Le reste des obligations suit de manière échelonnée.

Pour les fabricants, cela se ramène pour l'essentiel à trois choses qui relevaient auparavant du volontariat : traiter les vulnérabilités de façon ordonnée, fournir des mises à jour de sécurité pendant une durée annoncée, et disposer d'un point de contact joignable pour cela. Qui a déjà tenté de joindre le développeur d'une extension qui n'a plus été mise à jour depuis 2021 comprend immédiatement quel problème est visé ici.

Deux réserves font honnêtement partie du tableau. La première : savoir qui compte comme fabricant dans le cas des logiciels libres et open source est précisément le point qui reste discuté. Nous le décrivons ici, nous ne le tranchons pas pour vous. Cet article est une mise en perspective et non un conseil juridique, et pour votre situation propre rien ne remplace un examen professionnel. La seconde : le CRA ne met pas votre site à jour. Il change ce que vous pouvez attendre d'un éditeur, pas qui installe la mise à jour. Cela reste votre tâche, et si vous gérez des sites pour des clients, elle devient contractuelle.

Concrètement, pour le choix d'une extension : celle qui n'indique ni adresse de sécurité ni durée de support n'est pas mauvaise pour autant. Mais elle vous dit quelque chose sur la structure qui se tient derrière, et cette information, vous l'obtiendrez désormais sans avoir à la demander.

En pratique : mettre à jour sans démolir son propre site

Une sauvegarde que vous avez déjà restaurée une fois. Une sauvegarde jamais restaurée n'est pas une protection, c'est un espoir. Essayez une fois et vous saurez combien de temps cela prend et si cela fonctionne. Les outils qui conviennent pour cela sont traités dans l'article sur les extensions de sauvegarde pour WordPress.

Mises à jour automatiques pour les versions de sécurité, manuelles pour tout le reste. WordPress sait mettre les extensions à jour tout seul. Pour les petites versions correctives, c'est le bon réglage, parce que c'est là que le délai entre publication et installation compte le plus. Pour les grands sauts de version qui apportent de nouvelles fonctions, le coup d'oeil manuel se justifie.

Trente secondes dans le journal des modifications. S'il y est écrit security fix, l'affaire est urgente et non négociable. S'il y est décrit une fonction dont vous n'avez pas besoin, cela peut attendre le week-end.

Un environnement de test dès que le site rapporte de l'argent. Pour un blog, une sauvegarde suffit. Pour une boutique ou un espace membres, vous voulez avoir vu la mise à jour ailleurs avant que vos clients ne la voient.

Un inventaire deux fois par an. Toute extension dont vous n'avez plus besoin est une surface d'attaque sans contrepartie. La désactiver ne suffit pas, car les fichiers restent sur le serveur. Supprimez.

Comment repérer une extension qui va vous laisser en plan

Questions fréquentes