La surveillance synthétique, définie simplement
La surveillance synthétique consiste à exécuter des requêtes automatisées et scriptées contre vos systèmes en production, à intervalle fixe — chaque minute, toutes les cinq minutes — et à en évaluer les résultats exactement comme le ferait un utilisateur réel ou une application cliente. Le « synthétique » désigne le trafic : il est généré par un robot de surveillance, pas par un humain. Mais tout ce qu'il touche est réel : le vrai endpoint de production, la vraie négociation TLS, la vraie base de données derrière l'API, le vrai payload de réponse.
Voyez-le comme un testeur infatigable qui vérifie vos parcours les plus importants 24 h/24, depuis plusieurs endroits du monde, et lève immédiatement la main quand quelque chose casse. Parce que les checks tournent selon un planning au lieu d'attendre du trafic réel, la surveillance synthétique est proactive : elle détecte la panne à 3 h 04, pas quand le premier client la subit à 7 h 30. Cette différence — l'apprendre par vos outils plutôt que par vos utilisateurs — est toute la proposition de valeur.
Surveillance synthétique vs Real User Monitoring (RUM)
La surveillance synthétique est souvent opposée au Real User Monitoring (RUM), qui instrumente les sessions de vos utilisateurs réels et rapporte ce qu'ils ont vécu. Les deux répondent à des questions différentes et sont complémentaires, pas concurrents.
Le RUM vous dit ce qui est réellement arrivé à de vraies personnes : quelles pages étaient lentes, dans quel navigateur, sur quel réseau, dans quel pays. Sa faiblesse est structurelle — il lui faut du trafic. Si personne n'utilise votre checkout à 3 h du matin, le RUM reste muet pendant que votre checkout est cassé, et votre première donnée arrive avec votre premier client mécontent. La surveillance synthétique inverse cela : elle génère son propre trafic, donc la couverture est constante, que les utilisateurs soient actifs ou non. Sa faiblesse est le miroir inverse — elle ne teste que les chemins que vous avez scriptés, et ne dit rien des mille combinaisons réelles de navigateurs et de réseaux que voit le RUM.
La règle pratique : la surveillance synthétique pour la disponibilité et la justesse (« le chemin critique fonctionne-t-il en ce moment ? ») et le RUM pour l'analyse d'expérience (« à quel point est-ce rapide pour de vrais utilisateurs ? »). Pour les API — qui n'ont pas de session navigateur à instrumenter — la surveillance synthétique n'est pas seulement le meilleur choix ; c'est généralement le seul.
Ce qu'un bon check synthétique valide réellement
Un check synthétique minimal envoie une requête HTTP et vérifie le code de statut. Cela attrape déjà les pannes franches, mais une surveillance synthétique mature valide plusieurs couches à chaque exécution :
Joignabilité et TLS : la connexion aboutit, le certificat est valide et pas sur le point d'expirer. Statut et latence : le code de réponse est celui attendu, et le temps de réponse reste sous un seuil défini — un 200 OK en 8 secondes doit compter comme un échec pour une API orientée utilisateur. Justesse du contenu : des assertions sur le corps de la réponse confirment que l'API a renvoyé de vraies données, pas un tableau vide ou un token null derrière un statut vert. Parcours complets : les scénarios multi-étapes enchaînent les requêtes — s'authentifier, créer, vérifier — en passant les valeurs d'une étape à l'autre comme un vrai client, ce qui attrape les défaillances d'intégration entre services individuellement sains.
Chaque couche attrape une classe d'échec invisible pour la précédente. Les équipes qui s'arrêtent aux codes de statut découvrent régulièrement les incidents « up mais cassé » par les tickets support plutôt que par leurs moniteurs.
Pourquoi la localisation compte : les checks multi-régions
Un check synthétique s'exécute depuis quelque part, et ce quelque part compte plus que la plupart des équipes ne l'imaginent. Un moniteur tournant dans la même région cloud que votre API ne teste presque rien du chemin réseau que prennent vos vrais utilisateurs : la résolution DNS, les nœuds CDN, le routage et les incidents cloud régionaux sont tous invisibles depuis le même datacenter.
Exécuter le même check depuis plusieurs régions géographiques transforme la localisation d'angle mort en outil de diagnostic. Quand toutes les régions échouent simultanément, votre origine est en panne — réveillez l'astreinte. Quand une région échoue pendant que les autres passent, vous êtes face à un problème CDN, DNS ou de routage touchant une partie de vos utilisateurs — un problème différent, une escalade différente, et surtout un problème que vous n'auriez jamais vu depuis un point d'observation unique. La comparaison entre régions est en elle-même le diagnostic.
Les comparaisons de latence fonctionnent pareil : une réponse en 80 ms depuis Amsterdam et 4 secondes depuis Singapour n'est pas « up » pour vos clients asiatiques, même si un moniteur mono-région en Europe rapporterait une santé parfaite.
Configurer la surveillance synthétique sans le bruit
Le mode d'échec le plus courant de la surveillance synthétique n'est pas de rater des pannes — c'est la fatigue d'alerte. Un moniteur qui bipe l'équipe à chaque micro-coupure réseau apprend à tout le monde à l'ignorer en un mois. Quelques principes de configuration gardent le signal propre :
Exiger des échecs consécutifs avant d'alerter. Un check raté suivi d'un succès immédiat est une micro-coupure ; deux ou trois échecs consécutifs sont un incident. Adapter la fréquence à la criticité. Les endpoints critiques pour le chiffre d'affaires méritent des checks à la minute ; un site de documentation se contente de 5 ou 10 minutes. Commencer par le chemin critique, pas par tout. Surveillez la connexion, le checkout, l'opération API centrale — les trois parcours dont l'échec vous coûte de l'argent — avant de couvrir chaque endpoint. Toujours envoyer des notifications de rétablissement pour que personne ne continue à déboguer un problème résolu.
Configurée ainsi, une alerte synthétique retrouve son sens : quand elle sonne, quelque chose de réel est cassé, et vous l'avez appris avant vos utilisateurs. C'est tout l'intérêt.
