Aller au contenu

Mettre à jour WordPress sans casser son site : la méthode

Équipe V-Shield6 min de lecturePrévention
Illustration de l’article « Mettre à jour WordPress sans casser son site : la méthode » (Prévention)

Ne pas mettre à jour son site WordPress est plus dangereux que de le mettre à jour. Pourtant, beaucoup de dirigeants repoussent l'opération par peur de casser la mise en page, le formulaire de contact ou la boutique. Cette méthode montre comment appliquer les mises à jour régulièrement, avec un filet de sécurité, et revenir en arrière en quelques minutes si quelque chose se passe mal.

Pourquoi les mises à jour font peur (et pourquoi il faut les faire quand même)

Un site WordPress est un assemblage : le cœur de WordPress, un thème et souvent une vingtaine de plugins, chacun écrit par une équipe différente. Chaque brique évolue à son rythme. Quand l'une change, elle peut ne plus s'entendre avec les autres. C'est l'origine de la plupart des « mises à jour qui cassent ».

L'erreur fréquente consiste à en tirer la mauvaise conclusion : « je ne touche plus à rien ». Or les failles de sécurité publiées concernent très majoritairement des plugins, comme le montrent chaque année les bases de vulnérabilités de WPScan et Wordfence. Une fois qu'une faille est publiée avec son correctif, les robots des attaquants scannent le web à la recherche des sites restés sur l'ancienne version. Ne pas mettre à jour, c'est garder une porte ouverte dont la serrure est connue de tous.

Le vrai problème n'est donc pas la mise à jour elle-même. C'est la mise à jour faite sans sauvegarde, en bloc, sans test et sans plan de retour arrière.

Les enjeux d'une mise à jour bien menée

Une mise à jour ratée a trois coûts possibles, qu'il faut garder en tête pour doser ses précautions :

  • La sécurité : une version obsolète expose à des failles connues. C'est le risque le plus grave, car il est silencieux.
  • La disponibilité : une erreur PHP peut afficher l'écran « Il y a eu une erreur critique sur ce site » à tous vos visiteurs.
  • Les fonctions métier : le site s'affiche, mais le paiement, la prise de rendez-vous ou le formulaire ne fonctionnent plus. C'est le cas le plus sournois, car personne ne le voit tout de suite.

Il existe aussi plusieurs types de mises à jour. Les versions mineures du cœur (par exemple de 6.6.1 à 6.6.2) corrigent des bugs et des failles : WordPress les installe automatiquement par défaut. Les versions majeures (de 6.6 à 6.7) apportent des nouveautés et demandent plus de prudence. Pour les plugins, la numérotation dépend de chaque éditeur, et un petit numéro peut cacher un gros changement. Enfin, la version de PHP de l'hébergement compte aussi : un plugin ancien peut fonctionner en PHP 7.4 et planter en PHP 8.2.

Cas concrets

L'artisan qui avait 40 mises à jour en retard

Un menuisier fait gérer son site vitrine par un neveu, parti depuis deux ans. Le tableau de bord affiche 40 mises à jour en attente. En voulant tout mettre à jour d'un coup, il obtient une page blanche. La cause : un saut de plusieurs versions majeures d'un constructeur de pages, incompatible avec le thème. Avec une sauvegarde préalable, la restauration prend dix minutes. Ensuite, il procède par petits lots, en commençant par les plugins de sécurité et de formulaire.

La boutique WooCommerce et le paiement silencieusement cassé

Une boutique de thés en ligne met à jour WooCommerce et son module de paiement le même soir. Le site s'affiche normalement. Le lendemain, aucune commande. Le module de paiement attendait une version plus récente du thème enfant. Leçon : sur une boutique, chaque mise à jour se termine par une commande test complète, jusqu'à la page de confirmation.

Le cabinet libéral qui avait tout désactivé

Un cabinet de kinésithérapie a demandé à son prestataire de « bloquer les mises à jour pour être tranquille ». Deux ans plus tard, un plugin de prise de rendez-vous présente une faille publiée et exploitée. Le site se met à rediriger les patients vers des pages publicitaires. Ce scénario est détaillé dans notre article sur le site WordPress redirigé vers un autre site.

L'agence qui gère trente sites

Une petite agence applique les mises à jour chaque mardi matin. Elle commence par les sites les moins critiques, attend une heure, vérifie les retours, puis traite les boutiques en ligne. Si un plugin pose problème sur un premier site, elle le met de côté sur tous les autres jusqu'au correctif.

Méthode pas à pas

  1. Faire une sauvegarde complète : fichiers et base de données, stockés hors du serveur. Vérifiez qu'elle est bien terminée et datée du jour. Sans elle, pas de mise à jour. Notre guide de la sauvegarde WordPress détaille les options.
  2. Lire ce qui va changer : dans la liste des extensions, le lien « Voir les détails de la version » affiche le journal des modifications. Repérez les mots « breaking », « requires PHP » ou un changement de numéro majeur.
  3. Vérifier la version de PHP : dans Outils, puis Santé du site, WordPress indique la version utilisée. Assurez-vous que les nouvelles versions de vos plugins la supportent.
  4. Mettre à jour les plugins un par un : en commençant par les correctifs de sécurité. Après chaque plugin important, rechargez la page d'accueil et une page clé.
  5. Mettre à jour le thème, puis le cœur : si vous avez modifié directement les fichiers du thème au lieu d'utiliser un thème enfant, ces modifications seront écrasées. Vérifiez avant.
  6. Tester les parcours métier : formulaire de contact, inscription, panier et paiement, espace client. C'est ce test qui détecte les pannes silencieuses.
  7. Savoir revenir en arrière : en cas de problème, réinstallez la version précédente du plugin concerné ou restaurez la sauvegarde. Avec WP-CLI, l'outil en ligne de commande de WordPress, cela tient en quelques lignes :
# Lister ce qui peut être mis à jour
wp plugin list --update=available

# Sauvegarder la base avant d'agir
wp db export avant-maj.sql

# Mettre à jour un seul plugin
wp plugin update contact-form-7

# Revenir à une version précise si besoin
wp plugin install contact-form-7 --version=5.9.8 --force

Si vous gérez la configuration de votre site, la constante WP_AUTO_UPDATE_CORE dans le fichier wp-config.php contrôle les mises à jour automatiques du cœur. La valeur minor correspond au comportement par défaut et constitue le bon compromis pour la plupart des sites.

Bonnes pratiques

  • Fixer un rendez-vous régulier : une demi-heure par semaine, toujours le même jour, plutôt qu'une grosse session tous les six mois.
  • Éviter le vendredi soir : mettez à jour quand quelqu'un peut réagir dans les heures qui suivent.
  • Réduire le nombre de plugins : chaque extension supprimée est une mise à jour de moins à surveiller et une faille potentielle de moins.
  • Utiliser un thème enfant : vos personnalisations survivent ainsi aux mises à jour du thème parent.
  • Tenir un petit journal : date, éléments mis à jour, anomalies constatées. En cas de souci trois jours plus tard, vous saurez quoi suspecter.
  • Tester sur une copie pour les gros sauts : une préproduction est indispensable pour une boutique ou un site très personnalisé.

Erreurs fréquentes à éviter

  • Cliquer sur « Tout mettre à jour » sur un site très en retard, sans sauvegarde récente.
  • Désactiver toutes les mises à jour automatiques, y compris les correctifs de sécurité mineurs du cœur.
  • Conserver un plugin abandonné par son éditeur depuis des années, sous prétexte qu'il « marche encore ».
  • Considérer qu'un site qui s'affiche est un site qui fonctionne, sans tester le formulaire ni le paiement.

Comment V-Shield vous aide

V-Shield applique les mises à jour du cœur, des plugins et des thèmes depuis votre portail, avec un retour arrière possible si une mise à jour pose problème. Une sauvegarde des fichiers et de la base, stockée hors de votre hébergement, peut être faite avant l'opération, et la restauration est guidée. Le monitoring vérifie toutes les 5 minutes que votre site répond, et vous alerte par email s'il tombe après une intervention. Les détails sont sur la page fonctionnalités de V-Shield et les formules sur la page tarifs. Pour aller plus loin, lisez notre méthode pour réagir à une vulnérabilité WordPress et notre checklist sécurité WordPress 2026.

Vous voulez des mises à jour suivies, avec sauvegarde et retour arrière ? Démarrez avec la formule Pro, satisfait ou remboursé 30 jours.

Questions fréquentes

Faut-il activer les mises à jour automatiques de WordPress ?

Pour les versions mineures du cœur, oui : elles corrigent surtout des failles et WordPress les applique par défaut. Pour les plugins, activez l'automatique sur les extensions simples et bien maintenues, et gardez la main sur celles qui touchent au paiement, au constructeur de pages ou au multilingue, avec une sauvegarde systématique avant.

Dans quel ordre mettre à jour WordPress, les plugins et le thème ?

Commencez par une sauvegarde complète, puis mettez à jour les plugins un par un en testant après chacun, ensuite le thème, et enfin le cœur de WordPress. Si une version majeure du cœur est disponible, vérifiez d'abord que vos plugins critiques annoncent leur compatibilité avec elle.

Que faire si mon site affiche une erreur critique après une mise à jour ?

Ne paniquez pas : WordPress envoie généralement un email à l'administrateur avec un lien de mode de récupération. Ce lien permet de vous connecter et de désactiver l'extension fautive. Sans cet email, renommez le dossier du plugin concerné par FTP, ou restaurez la sauvegarde faite juste avant l'opération.

À quelle fréquence faut-il faire les mises à jour WordPress ?

Une session hebdomadaire suffit pour la plupart des sites vitrines. En revanche, une mise à jour de sécurité qui corrige une faille activement exploitée doit être appliquée dans la journée. L'essentiel est de ne pas laisser s'accumuler des dizaines de versions de retard, car le saut devient alors bien plus risqué.

Peut-on revenir à l'ancienne version d'un plugin WordPress ?

Oui. Les plugins du répertoire officiel conservent leurs anciennes versions, qu'on peut réinstaller manuellement ou avec WP-CLI en précisant le numéro de version. C'est une solution de dépannage : signalez le problème au développeur et revenez à la version corrigée dès qu'elle sort, sinon vous gardez la faille.