Technique

Lire les logs serveur de son site web pour diagnostiquer une panne

Mis à jour le 2 novembre 2026 · 9 minutes de lecture

« Le site a eu un problème hier vers 14h, mais ça fonctionne de nouveau. » C'est le genre de panne qui échappe à tout diagnostic si vous ne savez pas où chercher. Les logs de votre serveur ont pourtant enregistré, seconde par seconde, exactement ce qui s'est passé.

Qu'est-ce qu'un log, concrètement

Un log est un simple fichier texte dans lequel le serveur ajoute une ligne à chaque événement : une page visitée, une erreur rencontrée, une connexion refusée. Chaque ligne porte un horodatage précis, ce qui en fait la seule source fiable pour reconstituer le déroulé exact d'un incident — bien plus fiable que la mémoire de « vers 14h, à peu près ».

Sur un site web classique, trois types de logs coexistent :

• L'access log (ou « journal d'accès ») : une ligne pour chaque requête reçue, qu'elle réussisse ou non.
• L'error log (ou « journal d'erreurs ») : uniquement les dysfonctionnements côté serveur web.
• Les logs applicatifs : propres à votre CMS ou votre langage (PHP, Node.js), ils détaillent les erreurs de code.

Où trouver ses logs selon son type d'hébergement

Hébergement mutualisé (le plus courant pour les TPE/PME)

Depuis votre panneau d'administration (cPanel, Plesk ou l'interface propre à votre hébergeur), cherchez une rubrique nommée « Logs », « Journaux » ou « Statistiques ». Vous y trouverez généralement un lien de téléchargement des logs bruts, parfois une visionneuse intégrée, et souvent un journal d'erreurs PHP distinct accessible depuis la gestion de votre domaine.

VPS ou serveur dédié

Si vous administrez votre serveur, les emplacements standards sont :

Logs applicatifs (WordPress et consorts)

Sur WordPress, activer le mode débogage (WP_DEBUG_LOG dans wp-config.php) crée un fichier debug.log dans le dossier wp-content, qui consigne les erreurs PHP générées par le thème ou les extensions — souvent plus parlant que l'error log brut du serveur pour un site planté après une mise à jour.

Lire une ligne d'access log

Une ligne au format standard (« combined ») ressemble à ceci :

203.0.113.42 - - [02/Nov/2026:14:17:03 +0400] "GET /panier HTTP/1.1" 502 612 "https://votresite.fr/produit" "Mozilla/5.0..."

Chaque champ a un sens précis :

• Adresse IP du visiteur ou du robot ayant fait la requête.
• Horodatage exact, à la seconde.
• Méthode et URL demandée (ici, la page /panier).
• Code de statut renvoyé (ici, 502 : passerelle défaillante).
• Taille de la réponse en octets, et la page d'origine (« referer »).

En filtrant uniquement les lignes dont le code commence par 5 (erreurs serveur), vous isolez immédiatement les requêtes qui ont échoué, et leur horodatage vous indique le début exact de l'incident — un repère bien plus fiable que « ça a planté dans l'après-midi ».

Les commandes essentielles pour aller vite

Pas besoin d'ouvrir un fichier de plusieurs centaines de milliers de lignes dans un éditeur. Quelques commandes suffisent, en ligne de commande (SSH) ou via le terminal intégré de certains panneaux d'hébergement :

• tail -f access.log — suit le log en direct, ligne par ligne, pendant que vous reproduisez le problème.
• grep " 500 " access.log — n'affiche que les requêtes ayant renvoyé une erreur 500.
• grep "14:1[0-9]:" access.log — isole une plage horaire précise autour de l'heure signalée par un client.
• awk '{print $1}' access.log | sort | uniq -c | sort -nr | head — classe les adresses IP par nombre de requêtes, utile pour repérer un bot agressif ou une attaque.

Trois cas pratiques de diagnostic

Cas 1 : des erreurs 502 ou 504 groupées sur quelques minutes

C'est la signature d'un serveur d'application (PHP-FPM, Node.js) qui a saturé ou redémarré. Croisez l'horodatage avec vos logs applicatifs : une erreur fatale PHP juste avant la série de 502 indique souvent qu'un script a consommé toute la mémoire disponible et fait tomber le processus pour les requêtes suivantes.

Cas 2 : un pic soudain d'erreurs 429 ou 503

Comptez les requêtes par adresse IP sur la période concernée. Si une poignée d'IP concentrent des milliers de requêtes en quelques secondes, vous avez affaire à un bot mal configuré, un scraper agressif, voire une tentative d'attaque par déni de service plutôt qu'à un problème d'infrastructure classique.

Cas 3 : le site répond, mais une fonctionnalité précise échoue

Filtrez l'access log sur l'URL concernée uniquement (grep "/paiement" access.log). Si les requêtes vers cette URL précise renvoient des erreurs alors que le reste du site répond normalement en code 200, le problème vient d'un composant applicatif isolé (API de paiement, base de données, formulaire) — pas d'une panne générale du serveur.

Les pièges fréquents

• Décalage horaire. Les logs sont souvent horodatés en UTC ou dans le fuseau du serveur, pas forcément le vôtre. Vérifiez toujours le fuseau avant de chercher une heure précise.
• Rotation des logs. Beaucoup d'hébergeurs purgent ou compressent les anciens logs après quelques jours (access.log.1.gz). Si l'incident date d'il y a une semaine, il peut déjà avoir disparu.
• Confondre cause et conséquence. Une erreur 500 sur la page d'accueil peut être la conséquence d'une base de données saturée ailleurs, pas sa cause première. Remontez toujours à la première ligne anormale, pas à la plus visible.
• Oublier les logs du CDN ou du pare-feu. Si vous utilisez un CDN ou un WAF, une partie des requêtes peut être bloquée avant même d'atteindre votre serveur — et n'apparaîtra donc jamais dans vos logs d'origine.

Pourquoi les logs ne remplacent pas une surveillance active

Les logs sont excellents pour comprendre après coup ce qui s'est passé. Mais ils ne préviennent personne en temps réel : il faut penser à les consulter, savoir qu'un incident a eu lieu, et souvent attendre qu'un client se plaigne pour avoir une raison d'aller y regarder.

Une surveillance externe fait l'inverse : elle teste votre site depuis l'extérieur à intervalles réguliers et vous alerte dès la première anomalie, avant même que vous ayez ouvert un seul fichier de log. Les deux approches sont complémentaires : l'alerte vous dit qu'il y a un problème et quand il a commencé ; les logs vous disent pourquoi.

Questions fréquentes