Le répartiteur de charge marque le backend « healthy » : le port 443 répond. Pendant ce temps, PostgreSQL refuse les connexions — chaque requête API renvoie 503. Les utilisateurs voient une panne ; le monitoring hébergeur affiche vert. L'équipe perd vingt minutes à chercher « réseau » alors que le health check ne testait jamais la base.
Ce scénario se répète chaque semaine sur des stacks bien configurées en apparence : certificat TLS valide, processus web actif, sonde TCP qui passe. Le problème n'est pas l'hébergeur — c'est la question posée par la sonde.
Un health check applicatif répond à une question précise : cette instance peut-elle traiter une requête représentative maintenant ? Pas : quelqu'un écoute-t-il sur un port ? La distinction change tout quand une dépendance critique tombe sans que le serveur web s'arrête.
TCP, HTTP léger et vérification approfondie
Les équipes hésitent souvent entre trois niveaux de sonde. Chacun a sa place — mais seul le troisième niveau protège l'utilisateur final.
| Type | Vérifie | Limite |
|---|---|---|
| TCP connect | Process écoute | Rapide, aveugle |
HTTP 200 / | Page d'accueil | Peut être CDN-caché |
HTTP /health/live | Process + runtime | Minimal |
HTTP /health/ready | DB, cache, deps | Retrait trafic si fail |
/health/live sert la liveness (Kubernetes) : pas de base de données — cela évite une boucle de redémarrages quand Postgres est indisponible mais que l'application elle-même tourne encore. /health/ready sert la readiness : inclut les dépendances critiques uniquement — base, cache, file d'attente si indispensable.
Un check qui passe quand la base est morte envoie du trafic vers un gouffre. C'est le cas le plus frustrant : tout est vert côté infra, tout est rouge côté client.
Concevoir des checks rapides et fiables
Un bon endpoint de santé respecte quatre règles. D'abord, un timeout inférieur à une ou deux secondes, aligné entre le répartiteur de charge et le kubelet — un check lent bloque le retrait de trafic au moment où vous en avez le plus besoin.
Ensuite, aucun effet de bord : pas de création de commande test en production, pas d'envoi d'e-mail, pas d'écriture en base. La sonde lit l'état ; elle ne le modifie pas.
Troisièmement, une réponse stable en JSON : { "status": "ok", "checks": { "db": "ok" } } — parseable par le monitoring et lisible par un humain en incident.
Enfin, un cache de deux à cinq secondes en mémoire si les sondes sont agressives. Évitez de réutiliser une page lourde (administration WordPress, tableau de bord complet) comme sonde : vous gaspillez du processeur à chaque poll.
Répartiteur hébergeur, Kubernetes et mutualisé
OVHcloud, Hetzner et Scaleway proposent des répartiteurs avec sonde HTTP configurable. Paramétrez la vérification sur /health/ready, un intervalle raisonnable (cinq à dix secondes) et des seuils d'échecs et de succès consécutifs pour éviter les bascules permanentes.
Sur Kubernetes, alignez les chemins des probes avec le répartiteur externe — une double vérification incohérente provoque des bascules permanentes entre healthy et unhealthy.
En mutualisé sans sonde personnalisée, surveillez une URL externe (UptimeRobot, etc.) avec alerte. C'est un complément, pas un substitut à une sonde interne qui teste les dépendances.
Sécurité et fuite d'information
Un /health public listant versions, environnement et nom de cluster est une invitation. Rate-limit, réseau interne, liste blanche IP. En infrastructure sensible, authentification mTLS entre répartiteur et application.
Un attaquant qui sonde /health découvre parfois l'état de votre base, la version de votre framework ou la topologie interne — autant d'informations utiles pour cibler une attaque.
Le sommet : vert sur le monitoring, rouge pour le client
La sonde doit coller au parcours utilisateur minimal — pas à la couche transport.
Décider et avancer sans angle mort
Implémentez des endpoints live et ready séparés, chacun avec une responsabilité claire : le premier décide si le processus doit être redémarré, le second si l'instance peut recevoir du trafic. Incluez uniquement les dépendances critiques dans ready — pas toute la stack métier. Sécurisez l'endpoint sur réseau interne ou liste blanche IP. Alignez répartiteur de charge et Kubernetes sur les mêmes chemins et seuils. Validez en préproduction : coupez la base → le trafic doit être retiré sans restart massif des pods. Comparez les offres répartiteur via l'annuaire et le comparateur.
Questions fréquentes
Pourquoi un check TCP sur le port 80 suffit rarement ?
Un check TCP vérifie seulement qu'une socket est ouverte — pas que l'application répond correctement, ni que la base de données est joignable. Le port peut être ouvert pendant que PHP-FPM est saturé, que l'application renvoie des erreurs 500 ou que PostgreSQL refuse les connexions. En incident, vous perdez un temps précieux à diagnostiquer « réseau » alors que le problème est applicatif.
Que doit contenir un endpoint /health/ready ?
Des vérifications légères des dépendances critiques : ping base de données, Redis PING, file d'attente si indispensable — sans lancer toute la logique métier. Le timeout doit rester court (une à deux secondes). En cas d'échec, l'instance est retirée du trafic ; elle n'est pas forcément redémarrée, ce qui évite d'aggraver un incident base de données.
Health check public ou interne ?
Privilégiez un endpoint interne — réseau privé, liste blanche IP ou authentification mutuelle. Un /health public non authentifié peut devenir une sonde pour un attaquant ou une fuite d'information (version logicielle, état de la base). Si un endpoint public est inévitable, limitez les informations exposées et appliquez un rate-limit strict.
Comment éviter que le health check surcharge l'app ?
Mettez en cache le résultat quelques secondes en mémoire, limitez les checks parallèles et utilisez un endpoint dédié sans logs verbeux. Sur mutualisé, un répartiteur qui sonde toutes les secondes multiplie la charge — configurez un intervalle de cinq à dix secondes et un endpoint léger.
Healthy signifie « prêt à servir » — pas « le port répond à telnet ».