Pourquoi les moyennes mentent sur la latence
Imaginez une API qui répond à 99 requêtes en 100 ms et à une requête en 10 secondes. Son temps de réponse moyen est d'environ 199 ms — un nombre qui ne décrit précisément aucune des cent requêtes. Les 99 rapides étaient deux fois plus véloces que la moyenne ne le suggère ; la lente était cinquante fois pire. Ce n'est pas un exemple artificiel : les distributions de latence réelles sont fortement asymétriques, avec une longue queue de requêtes lentes causée par les pauses du garbage collector, les caches froids, la contention de verrous et les dépendances surchargées.
Les moyennes cachent cette queue par construction — elles diluent les valeurs extrêmes dans toutes les requêtes rapides jusqu'à ce que tout paraisse normal. Un graphique de latence bâti sur des moyennes peut rester parfaitement plat pendant qu'une fraction croissante de vos utilisateurs fixe des timeouts. C'est pourquoi toute pratique de surveillance sérieuse remplace (ou au minimum complète) la moyenne par des percentiles, qui répondent à une question bien plus honnête : « à quel point est-ce lent pour les X % de requêtes les moins chanceuses ? »
Ce que signifient réellement p50, p95 et p99
Un percentile est une idée simple : triez tous les temps de réponse du plus rapide au plus lent, puis lisez la valeur à une position donnée. Le p50 (la médiane) est la valeur du milieu — la moitié de vos requêtes étaient plus rapides, l'autre moitié plus lentes. Il décrit l'expérience typique et résiste bien mieux que la moyenne, car une poignée de valeurs extrêmes ne peut pas le déplacer.
Le p95 est la valeur sous laquelle tombent 95 % des requêtes — autrement dit, 1 requête sur 20 est plus lente. Il capture l'expérience de vos utilisateurs malchanceux mais pas rares. Le p99 marque le 1 % le plus lent — 1 requête sur 100. Cela semble négligeable jusqu'à faire le calcul : à un million de requêtes par jour, le p99 décrit 10 000 requêtes, chaque jour.
Une lecture saine du trio : le p50 vous dit ce que votre API donne comme sensation, le p95 ce dont vos utilisateurs se plaignent, et le p99 ce que vos systèmes vous cachent. L'écart entre eux compte autant que les valeurs : un p50 de 100 ms avec un p99 de 150 ms est un service serré et prévisible ; un p50 de 100 ms avec un p99 de 4 secondes est une bombe à retardement.
Pourquoi la latence de queue frappe vos meilleurs clients en premier
La propriété contre-intuitive de la latence de queue est qu'elle ne se répartit pas uniformément — elle se concentre sur vos utilisateurs les plus actifs. Un utilisateur qui fait une requête a 1 % de chances de tomber sur votre p99. Un utilisateur dont le chargement de page déclenche 40 appels API a 33 % de chances qu'au moins l'un d'eux atterrisse dans le 1 % le plus lent. Et comme la page n'est jamais plus rapide que son appel le plus lent, vos utilisateurs les plus intensifs — les dashboards, les intégrations, les gros clients — vivent votre latence p99 en routine, pas exceptionnellement.
Cet effet d'éventail explique pourquoi les grandes organisations d'ingénierie sont obsédées par la queue de distribution. En architecture microservices, le problème se compose : si le service A appelle B, qui appelle C, un seul saut lent bloque toute la chaîne, séquestre un thread de travail, et sous charge peut se propager en ralentissement en cascade de services eux-mêmes parfaitement sains. La latence de queue n'est pas une métrique cosmétique — c'est l'indicateur avancé des problèmes de saturation qui deviennent ensuite des pannes.
Sur quel percentile faut-il alerter ?
Alerter sur la moyenne est pire qu'inutile — cela crée une fausse confiance. Mais alerter sur le mauvais percentile crée du bruit. Un schéma pratique :
Alertez sur le p95 ou le p99 pour les endpoints orientés utilisateur. Fixez le seuil depuis votre propre base de référence, pas depuis le folklore : mesurez une semaine normale, puis alertez quand le percentile dépasse durablement, disons, 2 à 3 fois sa référence. Un bref pic de p99 pendant un déploiement est normal ; un p99 qui reste élevé dix minutes est une vraie dégradation. Suivez le p50 pour la dérive, pas pour les alertes. Une médiane qui monte lentement est la signature de jeux de données qui grossissent, d'index manquants ou de payloads qui enflent — passez-la en revue chaque semaine plutôt que de bipper dessus. Suivez l'écart p50/p99. Un écart qui se creuse avec une médiane stable signifie que la queue se dégrade en premier — l'alerte précoce classique d'une dépendance ou d'un pool de connexions surchargé.
Et mesurez là où ça compte : les percentiles calculés depuis vos logs serveur ignorent totalement le DNS, le TLS et le temps réseau. Les checks synthétiques externes depuis plusieurs régions mesurent la latence que vos clients vivent réellement — le nombre sur lequel vos utilisateurs vous jugent.
Les pièges classiques des percentiles
Trois erreurs apparaissent dans presque tous les tableaux de latence. Moyenner des percentiles : la moyenne de cinq p99 par minute n'est pas le p99 de la fenêtre de cinq minutes — les percentiles ne se composent pas. En agrégeant sur des fenêtres de temps ou entre régions, calculez le percentile sur les données fusionnées (ou utilisez une structure fusionnable), jamais une moyenne de percentiles. Ignorer la taille d'échantillon : un p99 calculé sur 50 requêtes est essentiellement une requête malchanceuse déguisée en tendance ; donnez aux endpoints à faible trafic des fenêtres plus larges avant de croire leur queue. Comparer des percentiles sur des mix différents : un p95 qui « s'améliore » après une chute de trafic peut simplement refléter le départ des requêtes lourdes — segmentez par endpoint et type de requête avant de célébrer.
Rien de tout cela n'exige un outillage sophistiqué — cela exige de mesurer en continu, depuis l'extérieur, avec des seuils par moniteur. Un seuil de latence sur un check synthétique est l'implémentation honnête la plus simple : chaque check a respecté votre budget de latence ou non, et une série d'échecs est une dégradation que vous apprenez pendant qu'elle est encore un problème de performance plutôt qu'une panne.
