Maintenance WordPress : notre méthode, étape par étape

En bref : maintenir un site WordPress, c’est tester chaque mise à jour sur une préproduction (ou environnement de staging) alignée sur la production, installer les extensions une par une après une quarantaine de sept jours à trois semaines, sauvegarder la production avant d’y toucher, rejouer des scénarios de non-régression et rendre compte chaque mois. Les correctifs de sécurité du cœur, eux, doivent s’installer automatiquement.

Beaucoup de contrats de maintenance WordPress se résument à une pastille rouge dans l’administration et à un clic sur « Tout mettre à jour ». Tant que rien ne casse, personne ne s’en aperçoit. Le jour où quelque chose casse, c’est en production, devant les visiteurs, et souvent sans possibilité de revenir en arrière.

Tout dépend pourtant de ce qu’il y a à perdre, et il faut le bon outil pour le bon volume. Pour un site vitrine simple, sans paiement ni espace client, tout le processus décrit ici ne vaut pas forcément le coup : cliquer sur « Mettre à jour » directement en production, avec une sauvegarde récente, est un choix tout à fait défendable.

Nous détaillons ici une démarche professionnelle, volontairement pédagogique. Nous-mêmes, sur des sites personnels sans enjeu fonctionnel fort, et encore moins financier, nous prenons toutes ces précautions : une fois en place, elles coûtent peu. Chaque étape se dose aussi selon le budget de maintenance. Mieux vaut une démarche allégée tenue chaque mois qu’une démarche complète abandonnée au bout de trois.

Chez Ouzom, chaque campagne de mise à jour suit les mêmes étapes, du site vitrine à la boutique en ligne : une pré-production alignée sur la production, les extensions installées une par une après une quarantaine, une sauvegarde de la production, des scénarios de non-régression écrits, puis un rapport mensuel envoyé par mail.

1. Rien ne part directement en production

La première règle est la plus coûteuse à mettre en place et la seule qui ne se négocie pas : il faut un environnement de pré-production (on parle aussi de préproduction ou de staging) aligné sur la production.

Aligné, cela veut dire même version de PHP, mêmes extensions dans les mêmes versions, un contenu représentatif. Une pré-production qui a divergé depuis six mois ne teste plus rien : elle donne une fausse assurance, ce qui est pire que pas d’assurance du tout.

On aligne donc la pré-production avant chaque campagne, toujours dans le même sens : de la production vers la pré-production, jamais l’inverse.

En pratique : aligner la pré-production sur la production

récupérer la base de données de production, par un export depuis l’hébergeur ou avec wp db export en ligne de commande, ainsi que le dossier des médias
anonymiser les données personnelles si le site en contient (comptes clients, commandes, messages de formulaire) : noms, adresses e-mail et téléphones sont remplacés par des valeurs fictives
remplacer les URL de production par celles de la pré-production avec wp search-replace, qui respecte les données sérialisées de WordPress, là où un rechercher-remplacer dans le fichier SQL les corrompt
neutraliser tout ce qui pointe vers l’extérieur : paiement en mode test, envoi d’e-mails bloqué ou redirigé, services tiers branchés sur leurs comptes de test, indexation par les moteurs de recherche désactivée

Sur un site dont le contenu bouge beaucoup, cette synchronisation s’automatise, par exemple une fois par mois avant la campagne. Sinon, elle se fait à la main avant chaque campagne.

2. Une extension à la fois, notes de version lues

Nous mettons à jour une extension après l’autre, après avoir lu ses notes de version. La mise à jour groupée fait gagner cinq minutes et coûte une demi-journée le jour où elle casse quelque chose : quand dix extensions passent en même temps, rien ne dit laquelle est en cause.

Les notes de version signalent les changements de compatibilité, les fonctions dépréciées, les correctifs de sécurité, et parfois la nécessité de retoucher le thème.

Nous appliquons aussi un délai de quarantaine. Une version publiée le matin même n’a été testée par personne, et les régressions d’une nouvelle version sont en général corrigées par un correctif dans les jours qui suivent. Nous attendons donc :

sept jours pour un correctif (1.2.3 vers 1.2.4) ou une version mineure (1.2 vers 1.3)
trois semaines pour une version majeure (1.x vers 2.0)

Seule exception : une faille de sécurité connue qui touche la version installée. Avant chaque campagne, nous cherchons chaque extension dans WPVulnerability, une base publique des failles WordPress. Si la version en place est concernée, la mise à jour passe tout de suite, sans attendre la fin de la quarantaine ni la campagne du mois suivant, et on surveille.

3. Une sauvegarde avant chaque passage en production

Une fois la campagne validée en pré-production, on sauvegarde la base de données de production avant d’y toucher. Une extension comme UpdraftPlus le fait en quelques clics et peut envoyer la sauvegarde vers un stockage externe. Les sauvegardes de l’hébergeur ou wp db export font aussi l’affaire, à condition de vérifier que la sauvegarde se restaure.

Le retour arrière doit rester possible à tout moment, y compris deux heures après la mise à jour, quand le client signale un problème que personne n’avait vu.

4. Des scénarios de non-régression écrits

Après chaque mise à jour, en pré-production puis en production, on rejoue les mêmes vérifications :

les cinq pages principales du site s’affichent sans anomalie visuelle ni erreur
la connexion fonctionne, si le site a un espace authentifié
les parcours spécifiques au projet passent : un tunnel de commande, un formulaire de contact, un module de réservation, un paiement en environnement de test

Ces scénarios sont écrits une fois, au démarrage du contrat, puis rejoués à l’identique. C’est ce qui permet à une autre personne de l’équipe de prendre le relais sans perdre la mémoire du projet.

Si une anomalie visible apparaît, elle est corrigée immédiatement. Si le problème est plus profond et que le volume d’heures réservé pour le mois est consommé, il est noté, documenté et planifié pour le mois suivant.

5. Un rapport mensuel écrit

Chaque mois, le client reçoit par mail un rapport qui contient :

la disponibilité de chaque domaine sur la période, relevée par UptimeRobot
la liste des extensions, thèmes et versions du cœur mis à jour, avec ce que ces versions corrigent, en particulier les failles de sécurité
les sujets traités : support, correctifs, petites évolutions
ce qui est reporté au mois suivant, et pourquoi
le temps passé, ventilé

Nous n’attendons pas du client qu’il le lise en détail chaque mois. Le rapport sert de référence le jour où quelque chose ne va pas : on y retrouve quelle version a été installée, quand, et ce qu’elle changeait. Il permet aussi de suivre le temps consommé d’un mois sur l’autre. Un client doit pouvoir répondre à la question « qu’est-ce que je paie ? » sans avoir à la poser.

Le rapport sert enfin à remonter ce que personne n’a demandé. Quand une extension payante ne peut plus être mise à jour faute de licence, nous indiquons la version bloquée, la dernière version disponible et ce qu’elle apporte, pour que le client décide s’il renouvelle. Quand nous tombons sur des extensions désactivées depuis longtemps ou des sous-sites marqués pour suppression depuis des années, nous proposons de faire le ménage.

6. Ce que la maintenance doit aussi faire reculer

Un bon contrat de maintenance fait reculer la dette technique au lieu de l’accumuler. Trois sujets reviennent presque toujours sur les sites WordPress installés depuis quelques années :

La configuration dispersée. Une partie des réglages vit dans le thème enfant, une autre dans l’administration, une troisième dans les options d’un constructeur de pages. Rien n’est versionné, aucun retour arrière n’est possible, et personne ne sait qui a changé quoi. Ramener progressivement cette configuration dans le code versionné est un chantier ingrat, et l’un des plus rentables.

Le cache et l’optimisation mal réglés. Une extension de cache configurée trop agressivement casse l’affichage : titres masqués, animations perdues, modules qui ne s’initialisent plus. Le bon réglage se trouve par itérations mesurées, sur la pré-production, pas en direct sur le site.

Les extensions inutiles. Chaque extension est une surface d’attaque, un poids supplémentaire et une dépendance de plus lors des montées de version. Une revue annuelle du parc, avec suppression de ce qui ne sert plus, vaut mieux que dix mises à jour bien faites.

Faut-il activer les mises à jour automatiques ?

Pour les correctifs de sécurité du cœur : oui

Depuis la version 3.7, WordPress installe seul ses versions mineures, qui sont presque toujours des correctifs de sécurité. Le réglage est actif par défaut, mais un hébergeur, une extension ou une ligne dans wp-config.php peut l’avoir coupé. Trois vérifications :

Tableau de bord > Mises à jour indique si le site reçoit automatiquement les versions de maintenance et de sécurité
Outils > Santé du site doit signaler que les mises à jour en arrière-plan fonctionnent
wp-config.php ne doit contenir ni AUTOMATIC_UPDATER_DISABLED à true, ni WP_AUTO_UPDATE_CORE à false

Pour les extensions et les thèmes : c’est plus nuancé

Ce que fait WordPress seul :

l’option existe depuis la version 5.5, désactivée par défaut, à activer extension par extension
depuis la version 6.6, WordPress annule la mise à jour d’une extension si elle provoque une erreur PHP fatale sur la page d’accueil
c’est le seul contrôle : une page dont le menu a disparu, ou un formulaire qui n’envoie plus rien, passe sans alerte

Ce qu’ajoutent les outils spécialisés :

WP Umbrella, 1,99 € par site et par mois (tarif affiché en septembre 2026) : tous les sites dans un tableau de bord, point de restauration, captures d’écran avant et après, retour arrière automatique au-delà d’un seuil, correctifs de sécurité appliqués dès leur sortie en option
le Smart Plugin Manager de WP Engine : même principe, test visuel sur dix pages dont l’accueil, test possible sur la pré-production, réservé aux sites hébergés chez WP Engine

Ce qui nous retient pour l’instant :

aucun de ces outils ne lit les notes de version à notre place
WP Umbrella ne prévoit pas de délai minimal avant d’installer une version récente, on peut seulement exclure une extension
une comparaison de captures voit un bloc déplacé, pas un paiement qui échoue, et les contenus dynamiques déclenchent de fausses alertes

Nous étudions ces deux outils sans avoir encore tranché. Les parcours propres à chaque site restent, de toute façon, à tester à la main.

Ce que ça coûte, et ce que ça évite

Une maintenance sérieuse représente quelques heures par mois pour un site vitrine, davantage pour une boutique ou un site à forte audience. C’est un coût visible, régulier, qu’on peut budgéter.

C’est surtout une affaire d’hygiène numérique. Un site qu’on n’entretient pas accumule de la dette technique sans que personne ne la voie : des versions de retard, des extensions abandonnées par leur éditeur, une version de PHP qui n’est plus maintenue. Cette dette ne coûte rien, jusqu’au jour où il faut la rembourser d’un coup.

Et plus on attend, plus la marche est haute. Passer une extension à la version suivante, c’est lire une note de version. Sauter trois versions majeures, c’est cumuler toutes les ruptures de compatibilité, les migrations de données et les fonctions supprimées entre-temps, sans pouvoir dire laquelle a cassé quoi. Il en va de même pour PHP : une version à la fois se prépare, plusieurs d’un coup deviennent un chantier.

En face du coût mensuel, il y a donc le coût invisible : une journée d’indisponibilité en pleine campagne commerciale, une base de données compromise par une faille corrigée depuis des mois, ou la refonte complète d’un site devenu impossible à mettre à jour parce que personne n’a touché à ses extensions pendant trois ans. C’est le scénario que nous rencontrons le plus souvent, et de loin le plus cher.

Questions fréquentes sur la maintenance WordPress

À quelle fréquence faut-il mettre à jour un site WordPress ?

Une campagne de mise à jour mensuelle couvre la majorité des besoins. Les correctifs de sécurité critiques, eux, se traitent dès leur publication, sans attendre la campagne suivante.

Combien de temps attendre avant d’installer une nouvelle version d’extension WordPress ?

Chez Ouzom, nous attendons sept jours pour un correctif ou une version mineure, et trois semaines pour une version majeure, parce que les régressions d’une nouvelle version sont en général corrigées dans les jours qui suivent. Une faille de sécurité connue qui touche la version installée fait exception : la mise à jour passe tout de suite.

Faut-il un environnement de pré-production pour maintenir un site WordPress ?

Pour un site à enjeu (boutique, espace client, formulaires critiques), oui : sans pré-production, toute mise à jour est jouée devant vos visiteurs. Pour un site vitrine simple, une sauvegarde récente avant la mise à jour peut suffire. Dans tous les cas, la pré-production doit être alignée sur la production pour que le test ait une valeur.

Que doit contenir un rapport de maintenance WordPress ?

La disponibilité du site sur la période, la liste des extensions, thèmes et versions du cœur mis à jour avec les correctifs de sécurité associés, les sujets traités, les problèmes reportés au mois suivant et le temps passé. Envoyé par mail chaque mois, il sert de référence en cas de problème et de suivi du temps consommé.

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

Oui pour les correctifs de sécurité du cœur, que WordPress installe seul par défaut : il faut simplement vérifier que ce réglage n’a pas été désactivé. Pour les extensions, la mise à jour automatique native n’annule une version que si elle provoque une erreur PHP fatale sur la page d’accueil. Des outils comme WP Umbrella ou le Smart Plugin Manager de WP Engine ajoutent une comparaison visuelle et un retour arrière automatique, mais aucun ne lit les notes de version ni ne teste les parcours propres au site, comme un tunnel de commande.

Transparence : comment cet article a été produit

Nous utilisons l’intelligence artificielle dans notre travail éditorial, et nous préférons le dire clairement.

Pour cet article, elle a servi à défricher le sujet et à identifier des sources potentielles.

La méthode décrite est celle que nous appliquons sur les sites que nous maintenons. Les références techniques ont été vérifiées dans leur documentation : WordPress.org, WP Engine, WP Umbrella, UpdraftPlus, WPVulnerability. Les liens de l’article et de la section Sources permettent de refaire ce chemin de vérification.

L’illustration en tête d’article est, elle aussi, générée par intelligence artificielle.

Sources

Nous appliquons cette méthode sur les sites que nous suivons, avec un volume de temps réservé chaque mois et un rapport écrit. Vous pouvez en lire un exemple dans le cas d’étude NOOUS, où trois sites WordPress sont maintenus dans le même contrat, ou nous écrire pour parler de votre site.

← Tous les articles