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
Comparer navigateur et réseau
Essayez une fenêtre privée, un autre appareil et un autre réseau. Si une seule vue échoue, examinez cache et extensions. DNS, TLS et WordPress demandent des vérifications différentes.
02
Reconnaître le symptôme
HTTP 500 signale un échec côté serveur. 502, 503 et 504 peuvent concerner des services intermédiaires ou ressources. Pour une erreur de base de données, vérifiez sa disponibilité avec l’hébergeur sans réécrire les accès au hasard.
03
Examiner les dernières modifications
Un événement proche n’est pas une preuve. Si l’administration fonctionne, testez l’extension suspecte de façon contrôlée. Évitez d’autres mises à jour groupées ; utilisez une copie pour les conflits étendus.
04
Si la connexion échoue aussi
Cherchez un lien de récupération dans la messagerie administrateur et les indésirables. Recovery Mode suspend des composants pour votre session ; il ne répare pas automatiquement le site public. Faites accompagner les interventions sur fichiers.
05
Vérifier hébergement et caches
Demandez les journaux PHP et serveur à l’heure précise, ainsi que les contrôles d’espace, domaine, DNS et certificat. Purger un cache peut retirer une ancienne page d’erreur, pas corriger PHP ou la base.
É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.