Site répond 200 OK mais affiche une erreur

C'est l'un des pièges les plus frustrants du monitoring web : votre outil de surveillance indique "UP" et "200 OK", mais vos utilisateurs voient une page blanche, un message d'erreur, ou du contenu incorrect. Le serveur HTTP considère avoir bien répondu, même si ce qu'il a servi est inutilisable.

Ce problème survient parce que les codes HTTP décrivent le succès de la transmission, pas la validité du contenu métier. Une page d'erreur PHP proprement affichée, une page de maintenance, ou même une page totalement vide peuvent toutes retourner un code 200. Le monitoring HTTP classique est aveugle à ces situations.

La solution est la vérification de contenu : au lieu de vérifier uniquement le code HTTP, on vérifie aussi que des éléments critiques sont présents dans la réponse. MoniTao permet de configurer facilement cette vérification pour détecter les pages cassées invisibles.

Symptômes d'une page 200 défaillante

Voici les signes qui indiquent que votre site retourne 200 mais présente un problème :

• Monitoring vert, utilisateurs mécontents : votre tableau de bord dit "UP" mais le support reçoit des plaintes. L'écart entre ce que le monitoring voit et ce que les utilisateurs expérimentent est un signal d'alarme.
• Page blanche ou message d'erreur : le navigateur affiche une page vide, un message "Erreur de connexion à la base de données", ou une page de maintenance alors que le site devrait fonctionner.
• Fonctionnalité critique manquante : le bouton "Ajouter au panier" a disparu, le formulaire de login ne s'affiche plus, les images ne chargent pas. Le code 200 cache un problème applicatif.
• Contenu obsolète ou incorrect : le CDN sert une version en cache périmée, ou la mauvaise langue s'affiche. La page "fonctionne" mais pas correctement.

Causes courantes du problème 200-mais-erreur

Plusieurs situations peuvent provoquer ce décalage entre code HTTP et contenu réel :

• Erreur applicative avec page d'erreur stylée : l'application catch l'erreur et affiche une belle page "Une erreur s'est produite" au lieu de laisser le serveur retourner une 500. Bon pour l'UX, mauvais pour le monitoring.
• Base de données inaccessible : le serveur web fonctionne mais MySQL/PostgreSQL est down. L'application affiche "Erreur de connexion" avec un 200 car techniquement elle a répondu.
• Cache CDN corrompu ou périmé : Cloudflare, Fastly ou votre CDN sert une version en cache qui n'est plus valide. L'origin est peut-être même down, mais le CDN répond 200 avec du contenu périmé.
• Erreur JavaScript côté client : le HTML se charge (200) mais une erreur JS empêche le rendu de composants critiques. Le monitoring server-side ne voit pas les erreurs client-side.

Diagnostic du problème

Identifier et corriger ces situations invisibles au monitoring classique :

• Identifier les éléments critiques : listez ce qui DOIT être présent sur chaque page critique : logo, texte de footer, bouton CTA, formulaire. Si ces éléments disparaissent, la page est cassée même avec un 200.
• Comparer réponse actuelle vs. attendue : faites un curl de la page et comparez avec une version fonctionnelle. Cherchez les différences de taille, les éléments manquants, les messages d'erreur.
• Tester en conditions réelles : le monitoring voit-il la même chose que les utilisateurs ? Vérifiez les headers, les cookies, le user-agent. Un site peut fonctionner pour les bots mais pas pour les humains.
• Vérifier les logs applicatifs : même si le code HTTP est 200, les logs peuvent révéler des erreurs internes qui ont été catchées et masquées par une page d'erreur "propre".

Exemple de configuration de vérification de contenu

Voici comment vérifier que le contenu attendu est présent sur votre page :

# Avec curl - vérifier qu'un texte est présent
curl -s https://example.com | grep -q "Ajouter au panier" && echo "OK" || echo "FAIL"

# Vérifier la taille minimale de la réponse
SIZE=$(curl -s https://example.com | wc -c)
[ $SIZE -gt 1000 ] && echo "OK: $SIZE bytes" || echo "FAIL: page trop petite"

# Script de monitoring basique
#!/bin/bash
RESPONSE=$(curl -s https://example.com)

if echo "$RESPONSE" | grep -q "Mon Site"; then
    echo "Content check: PASS"
else
    echo "Content check: FAIL - keyword missing"
    # Envoyer alerte
fi

Ces exemples montrent le principe de base. MoniTao automatise cette vérification avec une interface simple : configurez le texte à rechercher, et recevez une alerte si le texte disparaît.

Détection automatique avec MoniTao

MoniTao va au-delà du simple code HTTP pour détecter les vraies pannes :

• Vérification de contenu : configurez un mot-clé ou une phrase qui doit être présent sur la page. Si le texte disparaît (page blanche, erreur, contenu différent), MoniTao vous alerte même si le code est 200.
• Taille minimale de réponse : détectez les pages vides ou anormalement petites. Une page de 50 bytes alors qu'elle fait habituellement 50 KB indique clairement un problème.
• Comparaison de snapshots : identifiez les changements de contenu majeurs en comparant les réponses successives. Utile pour détecter les défacements ou les caches corrompus.
• Alertes multi-conditions : combinez code HTTP + vérification de contenu + temps de réponse pour une détection complète des anomalies.

Questions fréquentes

Au-delà du code HTTP

Le code HTTP 200 signifie "transmission réussie", pas "page fonctionnelle". Cette distinction est cruciale pour un monitoring efficace. Sans vérification de contenu, vous pouvez avoir un site cassé pendant des heures avec un monitoring qui indique "tout va bien".

MoniTao vous permet de configurer facilement des vérifications de contenu pour détecter ces pannes invisibles. Identifiez vos pages critiques, choisissez les éléments à surveiller, et dormez tranquille en sachant que vous serez alerté si quelque chose d'important disparaît.

Prêt à dormir sur vos deux oreilles ?

Commencez gratuitement, sans carte bancaire.

Créer mon compte Voir les tarifs