Les mises à jour de WordPress sont essentielles pour la sécurité de votre site, mais elles sont aussi l’une des principales sources de problème pour les agences web. Nous avons demandé à Sébastien Cavaillé, Product Marketing Manager chez OVHcloud, d’expliquer comment la fonctionnalité Smart Automatic Updates a été conçue pour résoudre ce dilemme.
Chaque agence en charge de la gestion de sites WordPress connaît la tension entre le besoin de mises à jour et le manque de temps ou de ressources pour les effectuer. D'une part, les mises à jour ne peuvent pas attendre. Selon le dernier rapport annuel du spécialiste de la sécurité WordPress Patchstack, 11 334 nouvelles vulnérabilités ont été enregistrées en 2025, dont 91 % dans les extensions, 9 % dans les thèmes et seulement six au cœur même de WordPress. De plus, les attaquants sont rapides : environ la moitié des vulnérabilités à fort impact sont exploitées dans les 24 heures suivant leur divulgation. Un plugin obsolète est l'un des points d'entrée les plus courants pour un attaquant. En outre, plus une mise à jour attend, plus un site reste exposé.
Mais d’autre part, chaque mise à jour comporte un risque : un plugin incompatible, un thème qui ne s’affiche plus correctement, une page qui renvoie soudainement une erreur. Pour éviter de s’exposer à ce risque sans garde-fou, bon nombre d’agences contrôlent chaque site manuellement. Cette opération prend beaucoup de temps lorsque vous gérez des dizaines, voire des centaines de sites. Et si le temps presse, les mises à jour sont reportées, parfois pendant des semaines ou des mois.
Pour sortir de cette impasse, l’équipe OVHcloud a développé les Smart Automatic Updates, une fonctionnalité incluse dans Managed Hosting for WordPress. Pour mieux comprendre cette problématique, nous avons parlé avec Sébastien, qui a travaillé sur le projet.
D'où vient l'idée du projet ?
Cela vient directement de nos clientes et clients. Sur notre plateforme d’hébergement mutualisé, nous hébergeons environ 6 millions de sites web, dont 80 % fonctionnent sous WordPress. Nous recevons ainsi beaucoup de retours et un besoin revient sans cesse : les gens savent qu'ils doivent tenir leurs sites à jour. Cependant, beaucoup ont vécu une mise à jour qui a mal tourné et ils n'ont pas le temps de vérifier chaque site manuellement.
Les mises à jour automatiques traditionnelles résolvent le problème de sécurité, mais en créent un autre : vous découvrez souvent qu'un site est en panne lorsqu'un ou une cliente appelle. Nous voulions une automatisation qui vérifie avant d'agir.
Une histoire en particulier nous a marqué. Un développeur web freelance dirigeait seul une agence et gérait, pour sa clientèle, des dizaines de sites WordPress. Une vulnérabilité a été rendue publique dans un plugin présent sur de nombreux sites de son parc et il n’a tout simplement pas pu tous les mettre à jour avant qu’un attaquant ne le devance. En peu de temps, 36 des sites de sa clientèle avaient ainsi été piratés et redirigeaient les internautes vers des sites malveillants.
Nettoyer les sites est une chose. Le plus difficile était de faire face à sa clientèle. Elle lui avait fait confiance pour prendre soin de leur site web et elle a appris que ses internautes avaient été redirigés vers des pages dangereuses. Pour un freelance dont l'activité repose sur la réputation et le bouche à oreille, une atteinte à sa crédibilité comme celle-ci prend beaucoup plus de temps à réparer que les sites eux-mêmes.
Depuis, il a migré les sites de ses clientes et clients vers Managed Hosting for WordPress et nous a confié la tâche de les tenir à jour. Son histoire est exactement le genre de situation que nous voulons éviter. Et ce, non pas parce qu'il a fait quelque chose de mal, mais parce que personne ne peut mettre à jour manuellement des dizaines de sites, semaine après semaine.
Comment les mises à jour WordPress sont-elles testées ?
Le principe est de ne jamais tester une mise à jour directement sur le site en ligne.
Quelles sont les quatre étapes du test ?
Nous vérifions chaque jour si de nouvelles mises à jour sont disponibles. Chaque mise à jour est ensuite testée en quatre étapes.
Tout d'abord, nous prenons un snapshot du site tel qu'il fonctionne aujourd'hui. Un crawler part de la page d’accueil et suit les liens de manière récursive : si la page d’accueil renvoie vers la page A, qui renvoie vers la page B, qui renvoie elle-même vers la page C, alors la page C est également analysée. Nous analysons jusqu’à 50 pages par site. Pour chaque page, nous enregistrons le code d'état HTTP retourné par le serveur, qui indique si la page se charge normalement ou retourne une erreur, ainsi qu'une capture d'écran de la page entière en résolution 1920×1080.
Nous clonons ensuite le site dans un environnement de test isolé. Ce clone, et seulement ce clone, est l'endroit où nous appliquons les mises à jour de WordPress, les thèmes et les plugins.
Dans un troisième temps, nous analysons le site cloné exactement de la même manière que le site d'origine, avec les mêmes pages, les mêmes codes d'état HTTP et les mêmes captures d'écran.
Enfin, nous comparons les deux. Cette comparaison détermine si la mise à jour peut être appliquée en production.
Qu'est-ce qui rend une mise à jour valide ?
Trois conditions à remplir :
- les codes d'état HTTP sont identiques. Si une page qui fonctionnait auparavant renvoie une erreur, la mise à jour est bloquée ;
- les captures d'écran correspondent, avec une petite tolérance pour les différences visuelles ;
- chaque mise à jour de thème et de plugin s'est installée sans erreur.
La comparaison visuelle est très stricte, by design. Un pixel est considéré comme différent dès que l'une de ses valeurs rouge, verte ou bleue change d'une seule unité. Il n’y a aucune tolérance de couleur. Ce que nous tolérons, c'est une petite proportion de pixels modifiés : jusqu'à 5 % de la page. Le seuil mesure donc la proportion de la page qui a changé et non l’ampleur du changement de chaque pixel.
Avant de prendre chaque capture d’écran, nous attendons également quelques secondes pour laisser les animations de chargement et les effets similaires se terminer.
Comment éviter les fausses alertes ?
De nombreux sites proposent des carrousels, des animations ou des contenus qui changent constamment. C'était l'un des problèmes les plus intéressants que nous ayons dû résoudre. Lors des tout premiers tests, nous avons été surpris par le nombre de mises à jour signalées comme des échecs, même si rien ne semblait cassé lorsque nous avons vérifié les sites manuellement. Lorsque nous avons examiné les captures d'écran, les coupables étaient presque toujours les mêmes : des sliders de page d'accueil qui étaient passés à l'image suivante, des compteurs de temps sur les sites d'événements, des widgets de « derniers articles » ou des flux de médias sociaux intégrés qui s'étaient rafraîchis entre deux captures. Les mises à jour étaient bonnes, les pages étaient tout simplement interactives.
La solution était de prendre plusieurs captures d'écran de chaque page à quelques secondes d'intervalle. Si la page change d'elle-même entre deux captures d'écran, le système la signale comme dynamique et l'exclut de la comparaison visuelle. Ces pages ne sont cependant pas laissées sans surveillance : leurs codes d’état HTTP sont toujours comparés, de sorte qu’une page dynamique qui commence à renvoyer une erreur bloquera toujours la mise à jour. Une fois que nous avons ajouté cette étape, les fausses alertes ont chuté de manière spectaculaire et nous avons pu à nouveau faire confiance à la comparaison visuelle.
Jusqu'où l'analyse est-elle poussée ?
Nous nous sommes concentrés sur ce qui compte le plus : les pages que vos internautes voient réellement. En pratique, cela couvre le cœur de la plupart des sites web : page d'accueil, sections principales et pages clés que les internautes parcourent.
Les pages qui ne sont pas accessibles depuis la page d’accueil, même indirectement, ne font pas partie de l’analyse. C’est intentionnel : si aucun lien ne mène à une page, les internautes ne peuvent pas y accéder en parcourant le site, donc ce n’est pas là qu’une mise à jour cassée les affecterait.
La même logique s'applique aux zones protégées par un identifiant, comme les comptes client ou le tableau de bord d’administration. Chaque site gère l'authentification de sa propre manière. Nous avons donc choisi de nous concentrer sur les pages publiques, sur lesquelles nous pouvons effectuer des vérifications fiables et cohérentes à grande échelle.
L’idée n’est pas de remplacer l’expertise d’une agence, mais de reprendre les vérifications répétitives qu’elle ferait manuellement, site après site. Cela libère du temps pour le travail que seules elles peuvent accomplir.
Lorsqu'un test réussit ou échoue
Que se passe-t-il si la validation échoue ?
Rien ne se passe sur le site en direct, c’est là tout l’intérêt. Si un critère n’est pas respecté, les mises à jour ne sont pas appliquées. Le site continue de fonctionner exactement comme avant.
Le ou la cliente reçoit ensuite un e-mail expliquant pourquoi la validation a échoué. Quatre causes sont possibles :
- les plugins ou thèmes n’ont pas pu être mis à jour complètement sur le site de test ;
- la page d'accueil a renvoyé une erreur 4xx ou était inaccessible, de sorte que le test n'a pas pu être effectué ;
- les réponses HTTP diffèrent entre le site d'origine et le clone ;
- les captures d'écran diffèrent entre les deux.
L'e-mail donne également accès au site cloné, sur lequel les mises à jour ont été appliquées. L'agence peut détecter le problème, le corriger directement sur le clone, puis déclencher la mise à jour de la production elle-même une fois que tout est en ordre.
Nous sommes fermes sur ce point : l’automatisation s’occupe du travail répétitif, mais elle ne prend jamais une décision risquée pour le compte de l’agence. En cas de doute, un être humain garde le contrôle.
Comment une mise à jour validée est-elle mise en ligne ?
Une fois la mise à jour validée, elle est appliquée en production peu de temps après, et la cliente ou le client reçoit une notification.
Il n'y a pas de retour en arrière automatique, puisque la mise à jour a déjà été testée avant d'être mise en ligne. Si un problème survient cependant par la suite, il est possible de restaurer une sauvegarde en un seul clic depuis l’espace client OVHcloud. Les sauvegardes sont faites site par site et non pas pour l’hébergement complet. Ainsi, une agence peut restaurer un site sans toucher aux autres.
Est-il possible d'exclure des plugins des mises à jour ?
Non et c'est un choix délibéré. Quand quelqu’un veut exclure un plugin, c’est généralement parce qu’il craint qu’une mise à jour ne casse le site. Or, s’assurer qu’il ne le fasse pas constitue précisément notre travail.
Certains cas nécessitent un traitement particulier et nous nous en occupons. Prenez WooCommerce : si un site utilise à la fois WooCommerce et une extension WooCommerce premium dont la licence a expiré, l'extension premium ne reçoit plus de mises à jour. Mettre à jour WooCommerce seul risquerait alors de casser le site, car une version récente de WooCommerce n’est pas compatible avec une version obsolète de l’extension. Dans ce cas, nous ne mettons pas à jour WooCommerce. Chaque fois que les Smart Automatic Updates révèlent d’autres cas comme celui-ci, nous les traitons également.
Et à propos des plugins et thèmes premium ?
La règle est simple : si vous pouvez cliquer sur « Mettre à jour » pour un plugin ou un thème dans votre tableau de bord WordPress, nous le mettons à jour. Si vous ne pouvez pas, par exemple parce qu'une licence a expiré, nous ne le faisons pas. Dans ce cas, nous informons le ou la cliente dans son espace client OVHcloud que le plugin doit être mis à jour, afin que ce dernier ne soit pas oublié.
Quels changements pour les agences ?
Je dirais trois choses.
Premièrement, la sécurité avant tout Les mises à jour ne s'accumulent plus car personne n'a le temps de les vérifier. Chaque site est mis à jour régulièrement, ce qui réduit la fenêtre pendant laquelle une vulnérabilité connue reste ouverte.
Deuxièmement, la tranquillité d’esprit. L'agence n'a plus à se demander si une mise à jour a cassé un site. Soit celle-ci a été validée et appliquée, soit la production est restée inchangée et la clientèle a été informée des raisons exactes. Et si jamais quelque chose va mal, le site de chaque cliente ou client peut être restauré individuellement en un seul clic, sans affecter les autres.
Troisièmement, le gain de temps. Une agence nous a dit que la maintenance de ses sites prenait jusqu'à 30 % de son temps. Les Smart Automatic Updates prennent en charge les vérifications répétitives, afin que les agences puissent consacrer davantage de temps à ce qui apporte le plus de valeur à leur clientèle.
Les Smart Automatic Updates sont incluses dans toutes nos offres Managed Hosting for WordPress. Ainsi, chaque mise à jour du CMS est testée avant d’arriver sur les sites de vos clientes et clients. En savoir plus sur la façon dont nous aidons les agences et les freelances à gérer leurs sites WordPress, ou découvrir pourquoi nous avons construit Managed Hosting for WordPress de cette façon.
La documentation Managed Hosting for WordPress couvre la configuration et le processus de mise à jour de manière plus détaillée.