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
Déterminer la zone touchée
Tout le site est-il vide, une seule page ou l’éditeur ? Comparez connexion, fenêtre privée et autre appareil. Notez les changements et un éventuel statut HTTP 500.
02
Comprendre Recovery Mode
Pour certaines erreurs PHP fatales, WordPress peut envoyer un lien à l’administrateur. Vérifiez les indésirables. Il suspend des composants pour votre session, sans réparation publique automatique. Gardez ce lien confidentiel.
03
Tester extensions et thème
Si l’administration fonctionne, testez le composant récemment modifié. La désactivation peut toucher des fonctions critiques. Préférez une copie pour changer de thème ou rechercher des conflits ; ne supprimez pas le thème initial.
04
Utiliser les journaux PHP
Demandez le journal correspondant à l’incident. Fichier, ligne et message orientent l’enquête. Réservez WP_DEBUG, WP_DEBUG_LOG et WP_DEBUG_DISPLAY aux interventions maîtrisées et temporaires, de préférence sur test ; masquez les erreurs publiques et protégez les logs.
05
Vérifier mémoire et code
Une erreur mémoire nécessite d’examiner consommation et limites. PHP doit être compatible avec les composants. Comparez le code récemment modifié à une version connue au lieu d’enchaîner les mises à jour.
É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.