Mise à jour WordPress et du site : quoi, quand, et ce qu’il ne faut pas toucher seul

Vous ne mettez pas à jour « le site ». Vous mettez à jour ce que quelqu’un y a ajouté — et c’est là que se trouve la quasi-totalité du risque. Cette seule phrase change la liste des tâches davantage que tous les conseils sur la régularité.

Ce texte porte sur la routine : quoi, à quelle fréquence, dans quel ordre, et ce qu’il ne faut pas toucher sans prestataire. Les échéances extérieures, qui tombent indépendamment de vos projets — fin du support d’une version logicielle, exigences des navigateurs — relèvent d’une autre discussion, celle de la modernisation.

Où se trouvent réellement les vulnérabilités

En 2025, 11 334 nouvelles vulnérabilités ont été recensées dans l’écosystème WordPress — 42 % de plus que l’année précédente. C’est ce qui ressort du rapport de Patchstack. Mais le total n’est pas le plus intéressant ; c’est la répartition, parce qu’elle réfute le reproche le plus fréquent adressé à ce système :

91 % des vulnérabilités concernaient les extensions, 9 % les thèmes, et dans le cœur lui-même on en a trouvé six — toutes de faible priorité.

Le cœur de WordPress n’est pas le problème. Le problème, c’est ce qu’on y ajoute. La conséquence pratique est directe : un site avec trois extensions et un site avec trente présentent deux niveaux de risque différents, quel que soit le sérieux avec lequel l’un et l’autre sont mis à jour.

Ce n’est pas une abstraction pour la Suisse. Dans son rapport semestriel 2026/1, l’Office fédéral de la cybersécurité (OFCS) indique avoir identifié au premier semestre 191 sites web suisses sous WordPress que des pirates avaient compromis pour y placer un code JavaScript malveillant. Ce code oblige le navigateur des visiteurs à télécharger d’autres programmes malveillants : le site continue de s’afficher normalement, et c’est la clientèle qui encaisse l’attaque. L’OFCS signale ces sites à leurs exploitants pour qu’ils les remettent en état — encore faut-il que quelqu’un lise l’adresse de contact.

Rappelons ce que le chiffre de Patchstack ne dit pas. Il ne dit pas combien de sites ont été attaqués — il dit combien de failles ont été décrites. Une vulnérabilité décrite n’est pas une vulnérabilité exploitée, et la plupart de ces onze mille concernent des extensions qui ne sont pas sur votre site. Ce qui est utile ici, ce n’est pas le total, c’est la proportion : quoi qu’il arrive, cela arrive dans la couche que vous avez ajoutée vous-mêmes — et cette couche, vous la contrôlez.

C’est pourquoi la première tâche de cet article ne consiste pas à mettre quoi que ce soit à jour, mais à dresser la liste de ce qui est réellement installé. La liste des extensions avec la date de la dernière mise à jour de chacune, sur une seule page. Pour un site d’entreprise ordinaire, cela prend dix minutes et se termine en général par deux découvertes : il y a plus d’extensions que quiconque ne s’en souvenait, et plusieurs ne sont plus développées depuis des années.

Le chiffre qui change le sens du mot « régulièrement »

Tiré du même rapport : 46 % des vulnérabilités n’avaient pas reçu de correctif de leur auteur au moment de leur divulgation publique.

Autrement dit, pour près de la moitié des failles, la mise à jour consciencieuse n’aidera pas — il n’y a rien à installer. La vulnérabilité est décrite publiquement, le correctif n’existe pas, et personne ne sait quand il viendra.

Cela déplace le centre de gravité, et il faut le dire franchement, car tout le secteur de la maintenance technique vend la discipline seule :

• La discipline des mises à jour protège contre la moitié du problème. C’est beaucoup et c’est gratuit ; aucune raison d’y renoncer.
• L’autre moitié demande autre chose : savoir que la faille existe, et décider quoi en faire. Désactiver l’extension, bloquer le chemin vulnérable sur le serveur, remplacer le composant par un autre.

Il en découle la chose la moins chère que l’on puisse faire en dehors du clic sur « mettre à jour » : avoir moins d’extensions. Chaque extension supprimée, c’est une décision de moins à prendre le jour où sa faille sera publiée.

Combien d’extensions, c’est trop ?

Il n’existe pas de seuil au-delà duquel quelque chose de grave se produit. Il existe en revanche une question qui met de l’ordre dans la liste en un quart d’heure. Pour chaque extension : que se passe-t-il si je la désactive ?

Les réponses sont généralement de trois sortes, et chacune signifie autre chose.

« Le site ne fonctionnera plus. » C’est une extension indispensable — formulaire, boutique, système de réservation. Elle reste, mais elle entre sur la courte liste des éléments à vérifier après chaque mise à jour importante.

« Un élément disparaîtra. » Carrousel, galerie, icônes des réseaux sociaux, carte. Elle reste si cet élément a une raison d’être. Très souvent, il n’en a plus — parce qu’il date d’un projet d’il y a trois ans.

« Je ne sais pas. » C’est la réponse la plus fréquente, et la plus révélatrice. Une extension dont personne ne sait dire à quoi elle sert est presque toujours un reste d’essais, d’un ancien prestataire ou d’une fonction jamais mise en service. Désactivez-la une semaine et voyez si quelqu’un le remarque.

Deux règles découlent de la même répartition des vulnérabilités :

Supprimez, ne désactivez pas. Une extension désactivée reste sur le serveur, garde son code et peut rester vulnérable. La désactivation est pratique pour vous, pas pour la sécurité.

N’installez rien « pour essayer » sur le site en production. C’est la source la plus courante des extensions de la catégorie « je ne sais pas » : quelqu’un a comparé trois solutions, en a retenu une, et les deux autres sont restées.

Payant ne veut pas dire plus sûr

La conviction qu’une extension premium est plus fiable par définition ne résiste pas non plus à ces données. Les composants payants et freemium représentaient 1 983 signalements, soit 29 % du total — mais 76 % des vulnérabilités trouvées dans les composants premium étaient exploitables, une proportion plus élevée que dans les gratuits.

Le prix de la licence ne mesure pas la qualité du code. Il mesure assez bien autre chose, et c’est cela qu’il vaut la peine d’acheter en connaissance de cause : vous payez pour que quelqu’un continue d’entretenir cette extension. La question à poser avant l’achat n’est pas « est-elle payante ? », mais « quand a eu lieu la dernière mise à jour, et combien de versions sont sorties l’an dernier ? ».

L’ampleur de la menace se lit d’ailleurs avec prudence. Sur ces 11 334 vulnérabilités, 1 966 (17 %) avaient une gravité élevée, et 4 124 (36 %) ont été jugées assez sérieuses pour exiger une règle de protection. Le reste relève de trouvailles à la portée pratique limitée — citer le total de 11 334 sans cette ventilation relèverait de l’épouvantail, pas de l’information.

Quatre couches, pas une seule

« Mettre le site à jour », ce sont en réalité quatre opérations différentes, au risque différent.

Correctifs de sécurité du cœur — automatiquement. Ils sont étroits, testés chez l’éditeur et rares. C’est la seule couche pour laquelle l’automatisme est plus sûr que votre mémoire — parce qu’une faille dans le cœur, bien que rare, touche d’un coup tous les sites du monde et se trouve exploitée massivement dans les heures qui suivent sa publication. Une distinction utile : ce qui s’installe automatiquement, ce sont en général les versions de sécurité, pas les grandes versions fonctionnelles. Celles-ci méritent de passer par le même processus que les extensions.

Extensions — manuellement et une par une. C’est là que se trouvent 91 % des vulnérabilités, et c’est là que la mise en page casse. Mettre à jour huit extensions d’un coup, c’est ne pas savoir laquelle a causé la panne — la différence entre un quart d’heure et une demi-journée. Une exception à connaître : si les notes de version d’une extension mentionnent le mot « security » ou un numéro CVE, n’attendez pas le moment commode. Le reste peut attendre le quart d’heure prévu.

Thème et ses modules — manuellement, après une copie. Une mise à jour du thème peut écraser des modifications faites directement dans le gabarit. Si quelqu’un a un jour « corrigé quelque chose dans le code », c’est ici que cela disparaîtra — sans avertissement ni trace, et le reconstituer suppose de se souvenir de ce que c’était. La solution prévue pour cela est le thème enfant, dans lequel vos propres modifications vivent à part et survivent à la mise à jour. Si vous ne savez pas si vous en avez un, c’est une question à poser au prestataire avant la première mise à jour du thème, pas après.

Version de PHP — pas sans prestataire. Ce n’est pas une mise à jour, mais un changement de l’environnement dans lequel le site tourne. Il peut tout faire tomber d’un coup, et revenir en arrière demande un accès à l’hébergement. Quand il faut le faire, indépendamment de vos projets, c’est le texte sur la modernisation qui le tranche.

Il existe une cinquième couche, à laquelle on ne pense pas comme à une mise à jour, et qui peut casser le site tout autant : les scripts collés directement dans le gabarit. Pixel, chat, widget d’avis, compteur. Ils n’apparaissent pas dans la liste des extensions, n’ont pas de numéro de version et personne ne les met à jour — mais quand le fournisseur change sa manière de les intégrer, ils cessent de fonctionner ou se mettent à bloquer le chargement de la page. Passez-les en revue en même temps que les extensions.

Un mot, enfin, sur ce qui n’est pas une mise à jour. Le même rapport de l’OFCS décrit des campagnes où la victime est invitée à installer une prétendue mise à jour logicielle — par exemple d’un outil de visioconférence — qui est en fait un programme malveillant. La règle est simple : les vraies mises à jour de votre site se lancent depuis le panneau d’administration ou chez votre hébergeur, jamais depuis une fenêtre qui s’affiche sur une page web ou depuis un lien reçu par courriel.

Qui s’en charge, et combien de temps cela prend

La réponse honnête à la question du temps : pour un site d’entreprise ordinaire, c’est un quart d’heure par mois, si rien ne surprend, plus une heure par trimestre pour revoir la liste des extensions. C’est à la portée d’une personne non technique, à condition qu’elle ait accès au panneau et une copie de sauvegarde.

La confier à l’extérieur a du sens dans trois cas :

Personne dans l’entreprise n’ouvre le panneau. Si la seule personne qui s’y est jamais connectée était le prestataire, personne ne remarquera que quelque chose attend une mise à jour.

Le site rapporte de l’argent. Pour une boutique ou un système de réservation, la différence entre une panne détectée dans l’heure et une panne détectée après le week-end est chiffrable — et c’est elle, pas la mise à jour elle-même, que l’on paie.

Vous avez des extensions qu’on ne peut pas toucher sans risque soi-même. Généralement des solutions fortement adaptées à votre cas, ou des intégrations avec un système externe.

Pour donner un ordre de grandeur, voici notre propre tarif, tel qu’il figure dans notre calculateur du coût de maintenance : une routine de mises à jour mensuelle à 50 CHF par mois, toutes les deux semaines à 75 CHF, hebdomadaire à 125 CHF, hors taxes. Ce que ce montant achète, ce n’est pas le quart d’heure de clics : c’est la copie faite avant, la vérification après, et quelqu’un qui sait revenir en arrière quand une extension casse le formulaire.

Ce qui ne vaut pas la peine d’être acheté : les forfaits de maintenance où les « mises à jour » sont la seule ligne. C’est un quart d’heure de travail par mois — si le prix semble correspondre à beaucoup plus, c’est que vous payez autre chose, et il vaut la peine de demander quoi exactement.

L’ordre qui ne casse pas le site

Six étapes. Pour un site d’entreprise, c’est un quart d’heure par mois si rien ne surprend.

1. Une sauvegarde — avant, pas après. Pas « nous avons des copies », mais une copie fraîche, d’aujourd’hui. Pourquoi ce sont deux choses différentes, nous l’expliquons à part.
2. Si vous avez un environnement de test — d’abord là. Sinon, passez à l’étape trois et compensez par la prudence.
3. Le cœur d’abord, le reste ensuite. L’ordre inverse provoque parfois des conflits, parce que les extensions sont publiées pour la nouvelle version du système, pas pour l’ancienne.
4. Les extensions une par une, avec une vérification après chacune. La vérification prend trente secondes : page d’accueil, une page de service, formulaire de contact.
5. À la fin, parcourez le site sur un téléphone. Le défaut le plus fréquent après une mise à jour n’est pas une erreur serveur, mais une mise en page décalée — et elle ne se voit que sur un écran étroit.
6. Notez la date et ce qui a été fait. Une phrase, dans le document où vous gardez les accès. À la panne suivante, c’est la première chose que l’on cherche.

Ce qu’il faut vérifier exactement à l’étape quatre pour que cela ait un sens : la page d’accueil, une page de service, le formulaire de contact, et le panier s’il y en a un. Quatre endroits, trente secondes. La tentation de vérifier seulement « si le site s’ouvre » est grande et inutile — le site s’ouvre presque toujours ; ce qui casse, c’est ce qui a un état : le formulaire qui n’envoie plus, le paiement qui ne passe plus.

Quand le faire : ni le vendredi après-midi, ni avant les vacances. Cela paraît banal, et c’est la règle la plus souvent enfreinte de toute la liste — une panne découverte le lundi matin a eu trois jours pour produire ses conséquences.

Quand une mise à jour met le site à terre

Trois symptômes couvrent la plupart des cas, et chacun appelle une première réaction différente.

Une page blanche, sans aucun message. Généralement un conflit entre une extension et la nouvelle version du cœur ou de PHP. Premier geste : désactiver la dernière extension mise à jour. Si vous n’avez plus accès au panneau, on le fait en renommant son dossier depuis l’hébergement.

Une erreur 500 ou un message d’erreur critique. Même origine, mais WordPress envoie alors généralement un courriel à l’adresse de l’administrateur, avec un lien vers le mode de récupération. Il vaut la peine de savoir à quelle adresse — c’est parfois une boîte d’il y a deux prestataires.

Le site fonctionne, mais il n’a plus le même aspect. Le plus souvent un thème écrasé, ou une extension de mise en page qui a changé de comportement. C’est le cas où restaurer une copie est parfois plus rapide que de chercher la cause.

Règle commune aux trois : annulez la dernière modification, pas toutes à la fois. Si vous avez mis à jour un élément à la fois, vous savez lequel — et c’est précisément pour cela qu’on met à jour un élément à la fois.

Que faire quand l’annulation ne suffit pas : restaurer la copie et laisser le problème pour plus tard. Ce n’est pas un échec, c’est la bonne décision — un site qui fonctionne dans son ancienne version est en meilleur état qu’un site qui ne fonctionne pas dans la nouvelle. La cause peut se chercher le lendemain, au calme, de préférence sur une copie de l’environnement et non sur le site en production.

Et une chose que l’on oublie dans la panique : vérifiez si d’autres voient aussi le problème. Il arrive que le site « ne fonctionne pas » uniquement dans votre navigateur, parce qu’il garde en mémoire une ancienne version des fichiers. L’ouvrir en navigation privée ou sur un téléphone prend dix secondes, et c’est parfois toute la solution.

Trois phrases que nous entendons le plus souvent

« Nous ne mettons pas à jour, parce que ça marche. » Ça marche jusqu’au jour où ça ne marche plus — et avec 46 % de failles sans correctif, « ça marche » ne signifie pas « c’est sûr ». Plus important encore : plus on attend, plus la première mise à jour devient difficile. Un saut de deux ans n’est pas la même opération qu’un saut d’un mois.

« Nous avons activé les mises à jour automatiques, le sujet est réglé. » L’automatisme couvre la couche du cœur. Il ne couvre pas les extensions abandonnées par leurs auteurs, ne remarquera pas que quelque chose a cessé de fonctionner après une mise à jour, et ne prendra pas la décision à propos d’un composant qui a une faille sans correctif.

« C’est le travail de l’informaticien. » Dans le périmètre de cet article — non. Une copie, un clic sur « mettre à jour » élément par élément et la vérification de trois pages, ce sont des gestes administratifs, pas de la programmation. Le prestataire est nécessaire pour la version de PHP et pour les extensions adaptées à votre cas, soit deux situations sur une quinzaine.

Une boutique, c’est une autre catégorie

Tout ce qui précède concerne un site d’entreprise. Pour une boutique en ligne, trois choses changent assez pour qu’on les cite à part.

L’environnement de test cesse d’être un luxe. Pour un site vitrine, une panne coûte de l’image ; pour une boutique, elle coûte des commandes en temps réel, et mettre à jour « en direct » devient indéfendable.

Les intégrations de paiement et de livraison se vérifient à part. Ce sont généralement des extensions de tiers qui évoluent indépendamment de votre boutique — et ce sont elles qui cessent le plus souvent de fonctionner en silence, sans aucun message. La vérification consiste à passer une commande de test, pas à regarder la page.

Le moment a une valeur chiffrée, pas seulement organisationnelle. Une heure d’arrêt le vendredi après-midi et une heure d’arrêt le mardi matin, ce sont deux montants différents, et pour une boutique, on peut les calculer à partir de ses propres chiffres de vente.

Ce qu’il faut vérifier une fois par an

La routine mensuelle couvre le risque courant. Une fois par an, il vaut la peine de regarder ce qui ne se signale pas tout seul, parce que cela n’apparaît jamais sous forme de pastille rouge dans le panneau.

• La version des logiciels du serveur. Une question à l’hébergeur ou un écran dans son interface. C’est la couche qui ne se met pas à jour toute seule et dont on ne se souvient qu’en cas de panne.
• Les extensions sans mise à jour depuis plus d’un an. Elles ne sont pas stables, elles sont abandonnées — et c’est justement chez elles qu’apparaît la faille sans correctif.
• L’existence d’un thème enfant, si quelqu’un a un jour modifié quoi que ce soit dans le code.
• La possibilité de restaurer la sauvegarde. Pas son existence — le fait que quelqu’un l’ait restaurée, et en combien de temps. C’est un sujet à part, et le plus souvent négligé.
• Qui a accès au panneau. Au bout d’un an, la liste des comptes ne ressemble plus à vos souvenirs ; nous le détaillons dans le texte sur la sécurité du site internet.

Toute la revue prend une heure par an. C’est le seul point de cet article qu’il faut inscrire dans un agenda — la routine mensuelle se rappelle d’elle-même, parce que le panneau affiche le nombre de mises à jour en attente. La revue annuelle ne se rappellera jamais d’elle-même.

Ce que ce texte ne traite pas, délibérément

• Les échéances extérieures et la fin du support des versions logicielles — c’est la modernisation, une décision distincte avec son propre calendrier.
• Les sauvegardes — à part, avec la question de savoir qui a restauré pour la dernière fois.
• Le contrôle des accès et les comptes du panneau — la sécurité du site internet, où l’on trouve aussi ce que disent les signalements reçus en Suisse.
• Le coût complet de la maintenance technique — c’est la rubrique maintenance, pas la sécurité.

Le résumé le plus court : mettez à jour un élément à la fois, faites la copie avant, et retirez le reste du risque en supprimant les extensions dont vous ne vous servez pas. La discipline ferme la moitié du problème — l’autre moitié, aucune ne la fermera, parce que pour 46 % des failles il n’y a rien à installer.

S’il ne fallait garder qu’une phrase de ce texte, ce serait celle-ci : la mise à jour la plus efficace, c’est la suppression de ce que vous n’utilisez pas. Elle ne demande pas de copie, ne casse pas la mise en page, n’a pas de version et n’apparaîtra dans aucun rapport de vulnérabilités — parce qu’un composant qui n’existe pas, personne ne l’attaque. Sur un site d’entreprise ordinaire, un premier rangement de ce genre retire de la liste de quelques éléments à une quinzaine, et c’est le seul geste de cet article après lequel le risque baisse durablement, et pas seulement jusqu’à la prochaine version.