Dernière mise à jour : septembre 2026
Quand un prestataire annonce « maintenance WordPress incluse », la question qui manque presque toujours est : quel type de maintenance ? Parce que le mot recouvre trois réalités très différentes — préventive, corrective, évolutive — qui n’ont ni le même déclencheur, ni le même coût, ni le même impact sur la continuité d’un site.
Confondre les trois, c’est finir par payer pour des mises à jour automatiques en pensant être protégé contre une attaque. Ou découvrir, le jour où le site tombe, que personne n’avait prévu de procédure de restauration.
Cet article pose les définitions concrètes, avec des exemples tirés de la gestion quotidienne de sites WordPress en production.
Maintenance préventive : agir avant la panne
La maintenance préventive, c’est tout ce qui se fait quand le site fonctionne — justement pour qu’il continue de fonctionner. Son principe : réduire la surface de risque avant qu’un incident ne se produise.
En pratique, sur un site WordPress en production, cela couvre :
- La veille de sécurité — Suivre les CVE publiées sur les plugins et thèmes installés. Quand une faille critique est signalée sur un plugin actif, le correctif est appliqué le jour même, pas au prochain « créneau de maintenance ». C’est la différence entre un patch et un incident.
- Les mises à jour planifiées — Les mises à jour non critiques (nouvelles fonctionnalités, corrections mineures) sont regroupées, testées, et déployées selon un calendrier. Sur l’infrastructure SL SYSTEM, les mises à jour de sécurité système (kernel, OpenSSL, PHP) sont traitées au même niveau que les mises à jour WordPress — parce qu’un serveur non patché rend toute protection applicative caduque.
- Le monitoring continu — Disponibilité, temps de réponse, espace disque, certificats SSL, charge serveur. Une alerte qui part quand le disque atteint 85% évite la panne quand il atteint 100%.
- Les sauvegardes vérifiées — Une sauvegarde n’existe que si elle a été testée. Les sauvegardes sont réalisées au niveau serveur (pas par un plugin WordPress), stockées sur un cloud externalisé, et leur restauration est testée périodiquement.
La préventive est la moins visible des trois — quand elle fonctionne bien, il ne se passe rien. C’est précisément pour ça qu’elle est négligée. Et c’est précisément son absence qui transforme un incident mineur en crise.
Maintenance corrective : réparer quand ça casse
La maintenance corrective intervient après un dysfonctionnement constaté. Le site affiche une erreur 500, un formulaire ne soumet plus, une page renvoie une erreur fatale après une mise à jour, un plugin a été compromis — le problème est là, il faut le résoudre.
La qualité d’une maintenance corrective ne se mesure pas à sa rapidité d’exécution, mais à sa méthode :
- Identifier avant d’agir — Activer le debug WordPress, lire les logs serveur (error log, access log), isoler le composant fautif. Désactiver un plugin suspect sur un environnement de staging avant de toucher au site live.
- Restaurer si nécessaire — Quand le diagnostic montre qu’une mise à jour a cassé quelque chose de structurel, le rollback depuis la dernière sauvegarde est parfois plus rapide et plus sûr qu’un correctif manuel. Encore faut-il que cette sauvegarde existe et soit récente — c’est le lien direct avec la préventive.
- Documenter l’incident — Chaque intervention corrective est tracée : cause identifiée, action prise, temps de résolution. Cette documentation alimente la préventive : si le même plugin cause un conflit trois fois, il est temps de le remplacer.
Un point critique : la corrective sans préventive est un mode pompier permanent. Si chaque semaine apporte son lot d’urgences, le problème n’est pas la malchance — c’est l’absence de prévention en amont.
Maintenance évolutive : faire progresser le site
La maintenance évolutive concerne tout ce qui fait avancer le site au-delà de son état actuel. Ce n’est pas de la réparation, c’est de l’amélioration — mais elle exige le même cadre méthodique que les deux autres.
Exemples concrets :
- Migration de version PHP — Passer de PHP 8.1 à 8.3 améliore les performances et la sécurité, mais nécessite de vérifier la compatibilité de chaque plugin et thème. C’est une évolution planifiée, testée sur staging, déployée avec un point de restauration.
- Optimisation des performances — Améliorer les Core Web Vitals, réduire le poids des pages, optimiser le cache. Ce n’est pas de la maintenance corrective (le site fonctionne), c’est de l’amélioration continue.
- Ajout de fonctionnalités — Intégrer un nouveau système de réservation, un espace membre, un tunnel de paiement. Chaque ajout fonctionnel est aussi un ajout de complexité — et donc de surface de maintenance future.
- Conformité réglementaire — Adapter le site aux évolutions RGPD, mettre à jour les mentions légales, ajouter un bandeau de consentement conforme. C’est de l’évolutif déclenché par le cadre juridique, pas par un bug.
La maintenance évolutive est celle que les propriétaires de sites demandent le plus — et celle qui se passe le plus mal quand elle est faite sans les deux autres. Ajouter des fonctionnalités sur un site dont les plugins ne sont pas à jour et dont le serveur n’est pas supervisé, c’est construire un étage sur des fondations fissurées.
Comment les trois s’articulent
Les trois types de maintenance ne sont pas des options à la carte. Ils forment un cercle où chacun conditionne les autres :
- Sans préventive, la corrective explose — Un site non surveillé accumule les failles, les plugins obsolètes, les sauvegardes manquantes. Chaque incident devient une urgence parce que rien n’a été anticipé.
- Sans corrective maîtrisée, l’évolutive est risquée — Si l’équipe n’a pas de méthode pour diagnostiquer et résoudre les incidents, chaque évolution (mise à jour majeure, nouveau plugin, migration) devient un pari.
- Sans évolutive, la préventive ne suffit plus — Un site qui ne progresse pas finit par tourner sur des technologies obsolètes. PHP 7.4 est en fin de vie, les anciens protocoles TLS sont dépréciés — ne pas évoluer, c’est régresser.
C’est cette articulation que SL SYSTEM applique dans sa stratégie de maintenance : la préventive tourne en continu, la corrective intervient avec méthode quand nécessaire, et l’évolutive est planifiée en fonction des besoins réels du site — pas des tendances du marché.
FAQ
Mon hébergeur fait déjà les mises à jour WordPress — ai-je besoin de maintenance préventive en plus ?
Les mises à jour automatiques du core WordPress couvrent les patchs de sécurité mineurs. Elles ne couvrent ni les plugins, ni les thèmes, ni le serveur, ni les sauvegardes, ni le monitoring. Un plugin vulnérable sur un WordPress à jour reste un plugin vulnérable. La maintenance préventive couvre l’ensemble de la stack, pas seulement le core.
À quelle fréquence faut-il faire de la maintenance corrective ?
Idéalement, le moins possible — c’est le signe que la préventive fonctionne. En pratique, sur un site WordPress actif avec une dizaine de plugins, il faut compter une à deux interventions correctives par trimestre (conflit de mise à jour, régression fonctionnelle, problème de compatibilité). Au-delà, c’est un signal que quelque chose de structurel doit être corrigé.
La maintenance évolutive est-elle incluse dans un forfait de maintenance ?
Ça dépend de l’ampleur. Les évolutions mineures (ajustement de configuration, optimisation d’un paramètre de cache, mise à jour d’une mention légale) entrent dans le cadre d’un forfait. Les évolutions structurelles (refonte d’un tunnel de conversion, intégration d’un outil métier, migration de serveur) relèvent d’un projet distinct, cadré et chiffré séparément.
Peut-on faire uniquement de la maintenance évolutive sans les deux autres ?
C’est techniquement possible, mais c’est une mauvaise idée. Ajouter des fonctionnalités sur un site dont les fondations ne sont pas maintenues multiplie les points de défaillance. Chaque nouveau plugin ajouté est une dépendance supplémentaire qui nécessite suivi et mises à jour — c’est-à-dire de la préventive.
Vous voulez structurer la maintenance de votre site WordPress autour de ces trois piliers ?