Surveillance des sites web par type d’erreur : DNS, TCP, TLS et HTTP

Quand un site web tombe, la panne ressemble souvent à une boîte noire. Les visiteurs voient une roue de chargement, un code d’erreur cryptique ou une page blanche. Pour les personnes responsables de garder ce site en ligne, la première question est toujours la même : qu’est-ce qui a cassé ?

La vérité, c’est qu’il n’existe pas une seule façon pour un site de « tomber ». Une requête d’un navigateur passe par plusieurs étapes : résolution DNS, connexion TCP, négociation TLS et réponse HTTP. Chaque étape dépend de la précédente. Et à chaque étape, des choses différentes peuvent échouer.

C’est pourquoi une surveillance intelligente de la disponibilité ne se contente pas de vous dire que le site est « indisponible ». Elle vous dit où dans la chaîne la panne est survenue. Les erreurs DNS pointent dans une direction. Les erreurs TCP dans une autre. Les erreurs TLS/SSL indiquent une cause racine différente des 5xx HTTP. Si vous savez quelle couche a échoué, vous savez quel équipe ou fournisseur contacter, et vous pouvez réduire drastiquement le temps de résolution.

Cet article parcourt chaque type d’erreur dans l’ordre où un navigateur charge réellement un site : DNS, TCP, TLS et HTTP. Pour chacun, nous expliquerons ce que fait l’étape, ce qui peut mal tourner, et comment la surveillance peut détecter les problèmes avant vos clients.

Erreurs DNS

Le DNS est le point de départ de toute requête web. Quand un utilisateur saisit votre domaine dans un navigateur, la première chose qui se produit est une requête pour résoudre ce domaine en une adresse IP. Si cette étape échoue, rien d’autre n’a d’importance — aucune connexion ne peut être établie, aucun certificat ne peut être vérifié et aucune réponse HTTP n’arrivera. C’est pourquoi les erreurs DNS sont souvent les signaux les plus précoces et les plus critiques d’une interruption.

Erreurs DNS courantes

Voici quelques pannes DNS fréquentes :

• NXDOMAIN — Cela signifie que le nom de domaine n’existe tout simplement pas. En pratique, cela provient généralement d’enregistrements expirés, de zones mal configurées ou de fautes de frappe dans les enregistrements. Un domaine expiré peut mettre tout votre site hors ligne instantanément, tandis qu’un enregistrement mal saisi peut n’impacter qu’un sous-domaine ou un service.
• SERVFAIL — Une erreur serveur indiquant que le serveur DNS faisant autorité n’a pas pu traiter la requête. Cela pointe souvent vers des fichiers de zone corrompus, des enregistrements glue manquants ou des problèmes de validation DNSSEC. Les SERVFAIL apparaissent souvent soudainement après des changements de configuration, ce qui en fait un signal d’alerte utile pour des déploiements problématiques.
• Timeouts — Quand aucune réponse ne revient dans les limites attendues, le client finit par abandonner. Les timeouts sont souvent causés par des serveurs de noms surchargés, des pannes réseau ou des attaques DDoS saturant le résolveur. Comme les requêtes DNS se produisent avant la mise en cache, même de petites hausses de latence ici peuvent se répercuter sur des temps de chargement plus lents pour l’ensemble de vos utilisateurs.

Comment surveiller le DNS

Surveiller la santé du DNS va au-delà de vérifier si votre domaine se résout une fois. Il faut tester les chemins de résolution comme les utilisateurs réels les vivent :

• Contrôles globaux : des agents de monitoring synthétique doivent exécuter des requêtes DNS depuis plusieurs géographies et réseaux. Un enregistrement peut se résoudre correctement depuis votre bureau mais échouer en Asie ou en Amérique du Sud à cause de problèmes d’acheminement anycast ou d’indisponibilités régionales chez votre fournisseur.
• Conscience du TTL : chaque enregistrement porte une valeur time-to-live (TTL) qui régit la mise en cache. Des TTL longs accélèrent la navigation normale mais peuvent retarder la propagation après des changements. La surveillance doit valider que les nouvelles valeurs sont effectivement reflétées dans les requêtes en direct et que le cache obsolète ne persiste pas.
• Alerte sur anomalies : les signaux les plus exploitables viennent des tendances. Une hausse soudaine des réponses NXDOMAIN ou SERVFAIL, ou un pic de latence de résolution, est souvent le premier indice que quelque chose ne va pas — avant même que les clients ne commencent à se plaindre.

Quand la surveillance DNS échoue, elle vous donne aussi la certitude de ce que n’est pas le problème. Si les résolutions ne fonctionnent pas, les vérifications TCP, TLS et HTTP n’ont même pas été tentées. Cela resserre rapidement le triage. Dans la plupart des cas, les corrections impliquent votre fournisseur d’hébergement DNS, votre registrar ou la personne qui gère le fichier de zone. Les équipes matures construisent des relations et des chemins d’escalade avec ces fournisseurs pour que les problèmes puissent être remontés et résolus rapidement.

Échecs de connexion TCP

Une fois que le DNS a résolu une adresse IP, l’étape suivante est le handshake TCP. C’est l’équivalent numérique d’une poignée de main : le client envoie un SYN, le serveur répond par un SYN-ACK, et le client acquitte par un ACK. Ce n’est qu’après cet échange qu’un canal de communication est établi.

Si le TCP échoue, le navigateur sait où le serveur devrait être mais ne peut pas réellement lui parler. Le résultat ressemble à un trou noir — les pages restent bloquées, les sockets ne s’ouvrent jamais et les utilisateurs voient des roues de chargement infinies. Contrairement aux erreurs DNS, qui sont généralement rapides et évidentes, les échecs TCP créent souvent des pannes partielles confuses où le site est accessible pour certains mais pas pour d’autres.

Erreurs TCP courantes

• Connection refused — Le client a atteint l’hôte, mais rien n’écoutait sur le port attendu. Cela se produit souvent lorsque des services plantent, des conteneurs meurent ou des load balancers sont mal configurés. Un serveur web qui a oublié de binder le port 443 est invisible même si la machine elle-même est en bon état.
• Connection timed out — Des paquets sont perdus quelque part sur le chemin. Cela peut être un pare-feu bloquant silencieusement le trafic, une mauvaise configuration de routage ou une congestion en amont. Les timeouts sont particulièrement frustrants car ils ne fournissent aucun retour — juste le silence jusqu’à ce que le client abandonne.
• Connection reset — Ici le handshake se complète mais est interrompu presque immédiatement. Les resets pointent généralement vers des proxies surchargés, des timeouts inactifs agressifs ou des middleboxes (comme des WAF) qui terminent ce qu’ils considèrent comme des sessions suspectes.

Comment surveiller le TCP

Les vérifications basiques d’uptime ne suffisent pas ici. Les pings ICMP peuvent réussir tandis que les handshakes TCP échouent, donnant une fausse impression de santé. Une surveillance TCP adéquate se concentre sur le comportement de la connexion :

• Validation du handshake : les outils doivent tenter explicitement un échange SYN/SYN-ACK/ACK sur le port réel du service. Cela garantit que le listener est atteignable et répond.
• Analyse du chemin : des traceroutes ou MTRs depuis différentes régions peuvent révéler où les connexions se bloquent — à l’intérieur de votre data center, au bord de votre CDN ou chez un ISP upstream.
• Parité des protocoles : si vous supportez IPv4 et IPv6, surveillez les deux. De nombreux incidents réels n’affectent qu’un seul, créant des problèmes visibles pour les clients qui passent inaperçus si vous ne testez que l’autre.

La surveillance TCP apporte la certitude que les serveurs ne sont pas seulement en ligne, mais prêts à accepter du trafic. Et elle réduit le triage : si le TCP échoue, la résolution DNS a déjà fonctionné, donc le problème se situe chez l’hôte ou sur le chemin réseau. Cette clarté empêche les équipes de poursuivre de fausses pistes au niveau applicatif quand le vrai problème est une règle de pare-feu ou un pool de load balancing qui a silencieusement perdu son dernier nœud sain.

Erreurs TLS/SSL

Aujourd’hui, presque tous les sites fonctionnent en HTTPS (comparé aux années précédentes où SSL n’était pas si commun). Cela signifie qu’après le handshake TCP, le navigateur et le serveur doivent négocier une session TLS (Transport Layer Security). TLS effectue deux tâches à la fois : il chiffre les données en transit et prouve que le serveur est bien celui qu’il prétend être via des certificats numériques.

Cette confiance apporte de la complexité. Si les certificats expirent, ne correspondent pas au nom d’hôte ou ne peuvent pas être validés, les utilisateurs verront des avertissements du navigateur — ou la page refusera de se charger. En pratique, les erreurs TLS sont parmi les incidents les plus visibles et embarrassants qu’un site puisse avoir, car elles arrêtent les utilisateurs à la porte avec une alerte qu’ils ne peuvent pas contourner en toute sécurité.

Erreurs TLS/SSL courantes :

• Certificat expiré — La fenêtre de validité du certificat est dépassée. C’est l’un des pannes les plus fréquentes parce que l’automatisation n’est pas en place ou le renouvellement ne s’est pas propagé partout.
• Mismatch de nom d’hôte — Le certificat a été émis pour www.example.com, mais l’utilisateur a visité api.example.com. Cela survient souvent après l’ajout de nouveaux sous-domaines ou le déplacement de services derrière un CDN.
• Autorité de certification non fiable — Le navigateur ne reconnaît pas la CA émettrice, généralement parce que le certificat est auto-signé ou chaîné à une racine privée non installée sur les dispositifs clients.
• Échec du handshake — La négociation cryptographique elle-même échoue. Les causes vont de suites de chiffrement non supportées, de versions de protocole obsolètes, ou d’une chaîne de certificats corrompue.

Comment surveiller le TLS :

La surveillance TLS doit être proactive et continue. Les certificats ne tombent pas en panne en douceur — ils fonctionnent un jour et bloquent l’accès le lendemain. Une bonne surveillance devrait :

• Suivre la validité des certificats et déclencher des alertes bien avant l’expiration — idéalement avec plusieurs seuils (30 jours, 7 jours, 1 jour).
• Valider la chaîne complète de certificats depuis plusieurs régions, car des intermédiaires manquants ou des problèmes régionaux de CA peuvent casser la confiance différemment selon le monde.
• Vérifier la compatibilité des protocoles et des suites de chiffrement, en s’assurant que le site reste compatible alors que les navigateurs déprécient progressivement d’anciennes versions comme TLS 1.0 et 1.1.
• Surveiller les pics d’erreurs de handshake, qui coïncident souvent avec des mauvaises configurations de load balancer ou des déploiements CDN.

Quand des pannes TLS apparaissent dans la surveillance, elles apportent aussi du contexte : la résolution DNS a réussi, la connectivité TCP était correcte, mais le canal sécurisé n’a pas pu être établi. Cela réduit immédiatement le diagnostic. La correction se situe généralement au niveau du renouvellement des certificats, de la configuration du load balancer ou de la terminaison en bordure, pas dans le code applicatif.

Pour beaucoup d’équipes, la leçon opérationnelle est simple : traitez les certificats comme du code. Automatisez l’émission et le renouvellement, surveillez l’expiration avec la même rigueur que l’espace disque et répétez les rotations pour que des certificats expirants ne deviennent jamais des pannes publiques sérieuses.

Erreurs HTTP

Enfin, après que DNS, TCP et TLS aient réussi, le navigateur envoie une requête HTTP. Le serveur répond avec un code d’état HTTP — 200 si tout va bien, ou un code d’erreur sinon.

La surveillance HTTP est ce à quoi la plupart des gens pensent quand on parle de « monitoring de disponibilité ». Mais sans le contexte des étapes précédentes, les erreurs HTTP ne racontent qu’une partie de l’histoire.

Erreurs HTTP courantes :

• 404 Not Found – La ressource n’existe pas. Cela peut être un lien cassé, une page supprimée ou une requête mal routée.
• 500 Internal Server Error – Le serveur a rencontré une condition inattendue. Généralement un bug de code ou une mauvaise configuration.
• 502 Bad Gateway – Un proxy ou load balancer n’a pas pu obtenir une réponse valide d’un serveur en amont.
• 503 Service Unavailable – Le serveur est surchargé ou en maintenance.
• 504 Gateway Timeout – Un service en amont a mis trop de temps à répondre.

Comment surveiller le HTTP :

• Exécutez des requêtes synthétiques GET depuis des agents globaux pour vérifier les réponses.
• Capturez les codes de réponse et alertez sur tout ce qui est en dehors de la plage 200–299.
• Surveillez des workflows de transactions, pas seulement des pages isolées (connexion, puis ajout au panier, puis paiement).
• Définissez des seuils pour le temps de réponse, pas seulement pour la disponibilité.

La surveillance HTTP vous indique que la couche applicative est en panne. Contrairement aux problèmes DNS/TCP/TLS, les erreurs HTTP relèvent souvent des équipes de développement ou d’exploitation, pas de fournisseurs externes.

Assembler le tout : une stratégie de monitoring en couches

La valeur de découper les erreurs par type, c’est la clarté. Chaque panne survient en séquence. Si le DNS échoue, rien d’autre ne se produit. Si le TCP échoue, le DNS était correct. Si le TLS échoue, DNS et TCP ont fonctionné. Si le HTTP échoue, tout jusqu’à ce point a fonctionné.

Une approche de monitoring en couches reflète cette séquence :

1. Commencez par des vérifications DNS.
2. Ajoutez la surveillance des connexions TCP.
3. Superposez la surveillance des certificats TLS.
4. Terminez par la surveillance des réponses HTTP.

Ce modèle en couches vous permet d’identifier rapidement la cause racine :

• Erreur DNS ? Appelez votre fournisseur DNS.
• Erreur TCP ? Impliquez votre hébergeur ou ISP.
• Erreur TLS ? Corrigez votre certificat ou la configuration de bord.
• Erreur HTTP ? Parlez à votre équipe web.

Au lieu d’une alerte vague « le site est en panne », vous obtenez une carte précise de ce qui est cassé et qui doit le réparer. Cela réduit le temps moyen de résolution (MTTR) et évite que les équipes se renvoient la responsabilité.

Conclusion

Les sites web ne tombent pas d’une seule manière — ils tombent par couches. DNS, TCP, TLS et HTTP introduisent chacun leurs propres risques et leurs propres signatures d’erreur. Surveiller par type d’erreur transforme cette complexité en clarté.

Avec la bonne stratégie de surveillance (et un outil comme Dotcom-Monitor), vous ne savez pas seulement que le site est en panne : vous savez pourquoi il est en panne. Vous savez s’il faut escalader vers votre hébergeur DNS, votre fournisseur réseau, l’équipe sécurité ou les développeurs. Et vous obtenez cette visibilité rapidement, sans attendre un ticket de support ou la plainte d’un client.

Finalement, surveiller par type d’erreur n’est pas seulement une question de disponibilité. C’est une question de responsabilité et de rapidité. La prochaine fois que votre site tombera, ne vous contentez pas de « quelque chose s’est cassé ». Sachez exactement quelle couche a échoué, ce que cela signifie et comment y remédier.