6.2Problèmes récurrents (playbook)
L'essentiel en 30 secondes
- Un symptôme d'abord : reproduire et décrire le problème avant de toucher au code ou aux fichiers.
- Une cause probable, pas un pari : le playbook relie chaque symptôme aux causes connues et à l'action ciblée.
- Le filet avant l'action : sauvegarde et environnement de test évitent de transformer une panne en perte de données.
Fil Samir — le carnet d'incidents
Samir tient un carnet d'incidents pour les sites qu'il maintient. Chaque entrée note le symptôme vu par l'utilisateur, la cause probable et l'action qui a réglé le problème. Au fil des mois, les mêmes familles reviennent : page blanche après une mise à jour, erreur 500, contenu mixte, formulaire muet, liens 404 et commande bloquée.
Réflexe : nommer le symptôme, vérifier la cause, appliquer l'action ciblée — et corriger le fondamental derrière un incident qui revient.
Un incident, un symptôme
La première erreur est de corriger au hasard. On commence par reproduire l'incident et le décrire précisément : quelle page, quel formulaire, quel utilisateur, quelles données. Un symptôme clair divise déjà le temps de diagnostic.
Le bon réflexe : le filet
Avant toute manipulation risquée, on sauvegarde et on travaille sur une copie quand c'est possible. Le but n'est pas d'éviter toute erreur, mais de pouvoir revenir en arrière sans perdre les contenus ni les commandes.
Chercher la cause, pas le coupable
Un incident récurrent cache souvent un fondamental manquant : une extension abandonnée, des mises à jour repoussées, des sauvegardes jamais testées. Régler le symptôme ne suffit pas si la cause revient le mois suivant.
| Symptôme | Causes probables | Actions |
|---|---|---|
| Page blanche après une mise à jour | conflit d'extension, thème incompatible ou mémoire PHP insuffisante | restaurer la sauvegarde, désactiver les extensions une à une, lire les logs et augmenter la mémoire si justifié (N3.1, N5.1) |
| Erreur 500 sur tout le site | erreur PHP fatale, fichier .htaccess corrompu ou limite mémoire atteinte | consulter les logs serveur, restaurer le fichier ou la sauvegarde, corriger l'extension fautive (N3.4, N5.1) |
| Contenu mixte après passage en HTTPS | anciennes URL en http dans la base ou dans un modèle | remplacer les URL, forcer HTTPS et vérifier les ressources chargées (N3.4, N5.2) |
| Formulaire de contact muet | envoi mail non configuré, SPF/DKIM absent ou extension en conflit | configurer un SMTP, envoyer un test réel et vérifier les spams (N3.5) |
| Liens 404 après changement de permaliens | règles de réécriture non régénérées ou redirections manquantes | réenregistrer les permaliens, vérifier .htaccess et ajouter les redirections utiles (N1.5, N5.2) |
| Commande bloquée ou paiement refusé | passerelle en mode test, devise ou pays mal réglé, page de commande cassée | vérifier les réglages WooCommerce, les logs de paiement et refaire une commande test (N4.1) |
Script prêt à dire — qualifier un incident (30 s)
« Pouvez-vous me dire sur quelle page, quel formulaire et quel utilisateur le problème apparaît, et depuis quand ? Je reproduis, je vérifie les logs et je corrige la cause avant de tester à nouveau. »
À garder pour cadrer un incident avec un client pressé.
Script prêt à dire — annoncer un retour arrière (20 s)
« Je restaure la sauvegarde pour remettre le site en ligne, puis je cherche la cause sur une copie. Le site public reste stable pendant le diagnostic. »
Rassurer : le retour arrière n'est pas un échec, c'est une protection.
Modèle copier-coller — fiche d'incident
SYMPTÔME : [page / formulaire / message]
UTILISATEUR : [profil]
DEPUIS : [date / heure]
REPRODUIT : oui / non
CAUSE PROBABLE : [extension / serveur / URL / réglage]
ACTION : [description]
TEST APRÈS CORRECTION : oui / non
SAUVEGARDE / RETOUR ARRIÈRE : oui / nonModèle copier-coller — ordre de diagnostic
1. Décrire le symptôme et le reproduire
2. Sauvegarder avant toute action
3. Lire les logs serveur et WordPress
4. Isoler : extension, thème, réglage, serveur
5. Corriger sur une copie si possible
6. Tester le parcours complet
7. Documenter la cause et la solutionSite vitrine
Les incidents les plus fréquents : formulaire, HTTPS, page blanche après mise à jour.
Boutique
Ajouter les commandes, les paiements et les e-mails de confirmation au diagnostic.
Site à fort trafic
Surveiller cache, serveur et base avant de conclure à un problème WordPress.
Sans staging
Sauvegarder systématiquement et intervenir en heures creuses avec un plan de retour arrière.
Défi 48h — appliquez demain
Prenez trois incidents réels ou simulés, remplissez la fiche d'incident et appliquez l'ordre de diagnostic. Notez la cause et le test de non-régression. 30 minutes.
- Je décris un symptôme avant d'agir.
- Je relie le symptôme à une cause probable.
- Je sauvegarde et je teste après correction.
Après une mise à jour, le site affiche une page blanche. Quelle est la première action utile ?
Un incident qui revient n'est pas un accident : c'est le signal d'un fondamental à corriger (extension abandonnée, mises à jour repoussées, sauvegarde non testée).