Définir ce qui doit être suivi entre deux sessions
Le mois est une cadence de revue, pas un délai universel pour intervenir. Une faille annoncée, un formulaire indisponible ou un site en panne appelle une prise en charge selon l’urgence. Les sauvegardes doivent suivre la quantité de données que l’activité peut accepter de perdre : un catalogue rarement modifié et une boutique recevant des commandes n’ont pas les mêmes besoins.
Une session de maintenance est terminée quand les fonctions importantes ont été vérifiées et les changements consignés. La liste des extensions mises à jour ne suffit pas. Cette checklist organise le rendez-vous mensuel d’un site WordPress ; elle doit être adaptée à son activité et aux responsabilités convenues avec l’hébergeur ou le prestataire.
Avant de fixer le planning, désignez la personne qui reçoit les alertes, celle qui décide d’une intervention et celle qui valide la reprise. Les essentiels de la maintenance WordPress posent ce cadre ; la checklist ci-dessous sert à réaliser et documenter chaque session.
Préparer l’intervention
- Relire le journal précédent et les incidents intervenus depuis ; reprendre les anomalies encore ouvertes.
- Vérifier les accès à WordPress, à l’hébergement, aux sauvegardes et aux licences nécessaires.
- Identifier les changements attendus et consulter les informations de compatibilité des composants concernés.
- Choisir une fenêtre adaptée aux commandes, inscriptions ou publications ; prévenir les personnes concernées.
- Définir les critères d’arrêt : erreur fatale, parcours essentiel cassé, données incohérentes ou impossibilité de revenir en arrière.
Ne mélangez pas discrètement maintenance et refonte. Une nouvelle navigation ou une migration PHP mérite son propre périmètre de test. Si l’installation reste mal connue, commencez par un diagnostic plutôt que de traiter les alertes à l’aveugle.
Contrôler la sauvegarde et sa restauration
Vérifiez la présence d’une sauvegarde récente des fichiers et de la base, sa destination, sa rétention et les accès permettant de la récupérer. Préparez une copie supplémentaire avant les changements. Une sauvegarde laissée sur le seul serveur du site ne couvre pas sa perte complète.
Restreignez l’accès à la copie, neutralisez les paiements réels, les courriels automatiques, les webhooks et les synchronisations externes ; utilisez des destinataires de test.
Organisez régulièrement une restauration sur copie isolée et conservez son résultat : ouverture du site, accès administrateur, contenus et médias présents. Sa fréquence dépend du risque et des changements d’architecture. Ne cochez pas « restauration testée » si vous avez seulement consulté le journal de sauvegarde. Le périmètre sécurité et sauvegardes doit préciser qui réalise cet essai.
Mettre à jour avec une recette préparée
Relevez les versions avant intervention. Sur une copie représentative, préparez les mises à jour et respectez les contraintes de compatibilité indiquées par les éditeurs. Aucun ordre unique ne convient à toutes les combinaisons. Avancez par ensembles cohérents, afin de pouvoir rattacher une régression à un changement identifié.
Vérifiez ensuite les pages et fonctions critiques. Si la copie valide les critères prévus, appliquez la procédure de déploiement retenue et recommencez les contrôles sur le site public. Ne recopiez pas une ancienne base sur des commandes ou demandes récentes. Si une fonction casse, arrêtez la série de changements et utilisez le plan de retour convenu.
Pour une procédure centrée sur les extensions, consultez la mise à jour des modules WordPress. Gardez également une trace des mises à jour différées et du motif : dépendance bloquante, licence ou anomalie à qualifier.
Essayer les fonctions qui comptent
Ouvrez les pages en visiteur déconnecté, sur mobile et ordinateur. Contrôlez le menu, la recherche si elle existe, les téléchargements et les liens importants. Pour un formulaire, utilisez un message clairement identifié comme test ; vérifiez les champs obligatoires, le succès affiché et la réception effective. Les contrôles d’un formulaire sécurisé vont au-delà de son apparence.
Pour une boutique ou une réservation, préparez un scénario spécifique en environnement de test : produit, disponibilité, panier, paiement de test et notifications. En production, convenez d’un parcours adapté avec le responsable. Une simple visite de l’accueil ne valide pas ces fonctions.
Revoir sécurité, indexation et mesure
Dans Santé du site, recherchez les nouveaux avertissements et comparez-les au relevé précédent. Examinez les comptes privilégiés, les composants inutiles et les alertes de sécurité. Une suppression doit être décidée après vérification de ses dépendances. Un scan sans alerte ne constitue pas un certificat de sécurité.
Dans Search Console, examinez surtout les changements concernant les URL importantes : page soudainement exclue, canonique inattendue ou erreurs serveur. Une exclusion prévue n’est pas automatiquement un problème. Vérifiez qu’aucune directive de préproduction n’a été transférée au site public.
Pour les statistiques, testez le parcours dans les états de consentement prévus par la configuration et vérifiez les événements attendus dans l’outil de diagnostic utilisé. Distinguez un message envoyé d’un événement mesuré : la présence d’une conversion dans un tableau ne prouve pas la réception d’une demande.
Garder un relevé comparable et fermer la session
Mesurez quelques pages stables avec les mêmes conditions. Conservez l’URL, la date, le type de données et le contexte de cache. Une variation de score appelle une investigation ; elle ne justifie pas à elle seule l’ajout d’un outil d’optimisation. La méthode présentée dans le guide de vitesse web aide à interpréter ces écarts.
Utilisez ce modèle de journal pour chaque session, en ajoutant la date et le nom de l’intervenant. Les cellules indiquent quoi renseigner, pas des résultats déjà obtenus.
| Opération | Avant | Après | Validation |
|---|---|---|---|
| Sauvegarde | Date et référence de la copie disponible. | Référence de la sauvegarde avant intervention. | Copie récupérable ; date et résultat du dernier essai de restauration. |
| Mise à jour | Composant, version et compatibilités à respecter. | Version installée ou motif du report. | Recette passée, réserves ou retour arrière. |
| Formulaire | Scénario et destinataire attendus. | Message affiché et réception constatée. | Parcours validé ou anomalie assignée. |
| Indexation | URL et état attendu. | Statut, canonique et directives relevés. | Conforme ou écart à investiguer. |
| Performance | Mesure de référence et conditions. | Mesure comparable après intervention. | Écart expliqué ou investigation attribuée. |
Pour chaque réserve, indiquez le responsable, l’échéance et le critère de résolution.
Clôturez par un état explicite : validé, validé avec réserves ou retour arrière effectué. Une checklist honnête peut contenir une case non validée, à condition qu’elle débouche sur une décision et un suivi.
Sources officielles
Documentation consultée le 19 octobre 2026.