Maintenir un site WordPress : la méthode que nous appliquons chez nos clients

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.

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 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.

Avant chaque campagne, on vérifie donc que les deux environnements sont bien au même niveau. S’ils ont divergé, on aligne la pré-production sur la production, jamais l’inverse.

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 (nous utilisons UpdraftPlus).

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 ?

WordPress met déjà à jour seul les versions mineures de son cœur. Pour les extensions, l’automatisme natif ne détecte que les erreurs PHP fatales ; WP Umbrella et le Smart Plugin Manager de WP Engine ajoutent une comparaison visuelle et un retour arrière automatique. Nous étudions ces deux outils sans avoir encore tranché.

Depuis la version 3.7, WordPress installe en arrière-plan les versions mineures du cœur, qui sont presque toujours des correctifs de sécurité. Depuis la 5.6, les nouvelles installations reçoivent aussi les versions majeures. Pour les extensions et les thèmes, l’option existe depuis la 5.5, désactivée par défaut, à activer extension par extension. Depuis la 6.6, WordPress annule la mise à jour automatique d’une extension si elle provoque une erreur PHP fatale sur la page d’accueil. C’est le seul contrôle : une page qui s’affiche mais dont le menu a disparu, ou un formulaire qui n’envoie plus rien, passe sans alerte.

WP Umbrella réunit tous les sites dans un seul tableau de bord, pour 1,99 € par site et par mois (tarif affiché en septembre 2026). Sa mise à jour sécurisée crée un point de restauration, vérifie que le site répond, compare des captures d’écran avant et après, et revient en arrière si l’écart dépasse un seuil. Les mises à jour se planifient, avec une option pour appliquer les correctifs de sécurité dès leur sortie.

Le Smart Plugin Manager de WP Engine suit le même principe : mises à jour planifiées, test visuel sur dix pages tirées au hasard dont l’accueil, retour arrière automatique, et une option pour tester d’abord sur la pré-production. Il ne fonctionne que sur les sites hébergés chez WP Engine.

La comparaison visuelle intégrée, la vue d’ensemble sur tous les sites et le coût nous intéressent. Trois limites nous retiennent pour l’instant. Aucun de ces outils ne lit les notes de version à notre place. La documentation de WP Umbrella ne prévoit pas de délai minimal avant d’installer une version récente : on peut seulement exclure une extension. Et une comparaison de captures voit un bloc déplacé, pas un paiement qui échoue ; WP Umbrella prévient que les contenus dynamiques et les publicités peuvent déclencher de fausses alertes. Les parcours propres à chaque site restent à 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.

En face, il y a le coût invisible : une journée d’indisponibilité en pleine campagne commerciale, une base de données compromise, 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 ?

Oui. Sans environnement de pré-production, toute mise à jour est jouée directement devant vos visiteurs. 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 ?

WordPress installe déjà seul les versions mineures du cœur. 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.

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.

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

← Tous les articles