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.
Checklist de mise en place
- Identifier les pages critiques à surveiller (accueil, checkout, login)
- Lister les éléments qui DOIVENT être présents sur chaque page
- Configurer la vérification de contenu dans MoniTao
- Tester en retirant temporairement l'élément (doit déclencher alerte)
- Documenter les textes de vérification utilisés
- Réviser périodiquement si les textes sont toujours pertinents
Questions fréquentes
Pourquoi le serveur retourne 200 si la page est en erreur ?
Les codes HTTP décrivent la réussite de la communication, pas la validité du contenu métier. Si le serveur a bien reçu la requête et a renvoyé une réponse (même une page d'erreur), c'est techniquement un succès HTTP.
Quel texte choisir pour la validation de contenu ?
Choisissez un élément statique et critique : le nom de votre site, un texte de footer présent sur toutes les pages, un bouton d'action principal. Évitez les dates, prix ou contenus dynamiques.
La vérification de contenu ralentit-elle le monitoring ?
Non, la vérification se fait sur la réponse déjà reçue. Cela n'ajoute pas de requête supplémentaire, juste une recherche de texte dans la réponse existante.
Puis-je surveiller plusieurs éléments sur la même page ?
Avec MoniTao, vous pouvez créer plusieurs monitors pour la même URL avec différentes vérifications, ou utiliser des expressions régulières pour des patterns plus complexes.
Mon CDN cache les pages. La vérification fonctionne-t-elle ?
Oui, c'est justement un cas d'usage important. Si le CDN sert une version en cache corrompue ou périmée, la vérification de contenu détectera que le texte attendu n'est plus présent.
Comment gérer les pages multilingues ?
Créez un monitor par langue avec le texte approprié dans chaque langue. Ou utilisez un élément technique présent dans toutes les versions (balise HTML spécifique, data-attribute).
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.