Ce guide concerne les sites WordPress auto-hébergés. Toute intervention nécessite les droits adaptés et un retour arrière fiable. Sans expérience des fichiers, bases de données et hébergements, coordonnez le diagnostic avec votre hébergeur ou prestataire.
Consigner les observations
Notez l’URL, le message exact, le premier horaire observé avec fuseau et la dernière modification. Comparez accueil, autre page et connexion. Consignez les essais : un seul chargement échoué ne prouve pas une panne générale.
Sauvegarde et retour arrière
Avant intervention, préservez fichiers et base de données si possible, ainsi que les sauvegardes antérieures. Vérifiez dates et restauration. Une copie défectueuse ou infectée peut servir à l’enquête : protégez-la séparément et ne la considérez pas comme saine.
Modifiez un seul élément et retestez la même action. Préférez une copie de test pour les essais de thèmes, extensions et configurations. Désactiver ne signifie pas supprimer ; boutique, formulaires et sécurité peuvent être affectés. Documentez l’état initial et le retour arrière.
Diagnostic ciblé
01
Séparer site public, administration et boutique
Comparez des URL représentatives avec appareil, connexion et horaire identiques. Un cache public rapide ne décrit pas l’éditeur ou le panier. Répétez les mesures et conservez une référence.
02
Distinguer serveur et affichage
Une attente avant le premier octet diffère d’une image tardive ou de scripts bloquants. Consultez la cascade réseau et PageSpeed Insights. Distinguez laboratoire et données réelles disponibles.
03
Adapter images et scripts
Vérifiez images d’entrée, dimensions, compression et espace réservé. Ne retardez pas l’image principale par chargement différé. Analysez les scripts externes ; gardez seulement les gains démontrés sans casse fonctionnelle.
04
Adapter le cache aux fonctions
Vérifiez les caches existants avant d’en ajouter. Plusieurs extensions similaires compliquent l’analyse. Panier, paiement, comptes et contenu personnel nécessitent des exceptions. Contrôlez sessions, prix et formulaires.
05
Examiner application et hébergement
Le travail d’une extension compte davantage que leur nombre. Cherchez requêtes lentes, appels externes et tâches simultanées. Profilez sur une copie ; ne supprimez pas de tables ni de tâches sans preuve.
Core Web Vitals : objectifs des visites réelles
LCP mesure le contenu visible principal, INP la réactivité et CLS les déplacements visuels. Les objectifs s’appliquent au 75e percentile des visites réelles, séparément sur mobile et ordinateur. Un test de laboratoire ne remplace pas ces données.
Évaluer la restauration
Une sauvegarde ne remplace pas l’analyse de la cause. Vérifiez-la d’abord en environnement isolé si possible. Restaurer peut effacer des commandes, demandes et contenus récents. Convenez du périmètre ; après piratage, ne réimportez pas de fichiers actuels sans contrôle.
Tester après correction
Contrôlez l’URL initiale, l’accueil, les autres pages et la connexion. Testez formulaires et boutique en environnement adapté, sans commandes réelles involontaires. Videz uniquement les caches concernés après correction. Consignez cause et résultat.
Quand demander de l’aide
Arrêtez les modifications si la cause reste inconnue, si le retour arrière est incertain ou si des fonctions critiques sont touchées. Les indices malveillants exigent une enquête de sécurité. Ne publiez ni journaux complets, ni accès, clés ou liens de récupération.
Convenir du périmètre et du coût →Maintenance après réparation
Le cœur WordPress, les extensions et les thèmes sont mis à jour chaque semaine, sans laisser les tâches courantes repousser les mises à jour essentielles. Mensuelles, quotidiennes ou horaires : les sauvegardes dépendent de l’offre et sont stockées sur des serveurs dans l’UE.
Les réparations et le nettoyage de sites déjà piratés sont des prestations distinctes. Les licences payantes ne sont pas incluses.