La latence vient rarement de la gateway

C'est un rituel d'incident : la latence d'un service monte, l'appel passe par la plateforme, donc « c'est la gateway ». L'équipe plateforme passe deux heures à prouver son innocence, le vrai coupable court pendant ce temps, et la scène se rejouera au prochain incident.

Ce réflexe a une explication simple : la gateway est le seul composant que tous les appels traversent, donc le seul que tout le monde peut accuser sans connaître le dossier. Il a aussi un coût élevé, qui se mesure en heures d'incident perdues sur la mauvaise piste.

Ce qu'une gateway coûte vraiment

Une gateway correctement dimensionnée ajoute deux à cinq millisecondes : la terminaison TLS, la validation du jeton, les policies, le saut réseau. Sur un appel qui en prend 300, elle pèse un à deux pour cent.

Quand une latence double, la cause est presque toujours ailleurs. Voici les suspects, dans l'ordre des fréquences constatées en mission.

Le backend, évidemment. Le cas majoritaire et le moins regardé, précisément parce que la gateway offre un coupable plus commode. Une requête SQL qui a cessé d'utiliser son index, un GC qui s'emballe, un pool de threads saturé.

Le pool de connexions vers le backend. Le suspect le plus fréquent côté plateforme, et le plus discret : la gateway attend une connexion disponible avant même d'envoyer la requête. Le backend affiche des temps normaux, le client mesure le double, et la différence dort dans une file d'attente que personne ne supervise.

Le fournisseur d'identité. La validation d'un jeton est locale et rapide, sauf quand elle ne l'est plus : cache de clés expiré, appel d'introspection synchrone, quota atteint chez un IdP SaaS. Symptôme typique : latence en marches d'escalier, corrélée aux expirations de cache.

Le DNS et la découverte de service. Résolutions qui passent de 1 ms à cinq secondes sur un délai d’expiration du résolveur, valeur par défaut de la glibc, et jusqu’à trente quand plusieurs serveurs sont injoignables. Ou des domaines de recherche parcourus avant le bon nom. Rare, spectaculaire, et invisible dans tous les tableaux de bord applicatifs.

Un seul consommateur. La latence moyenne monte parce qu'un consommateur s'est mis à envoyer des requêtes pathologiques : pages de 10 000 éléments, filtres non indexés. La moyenne accuse la plateforme, la ventilation par consommateur désigne le coupable en une requête.

Les policies qui coûtent, et celles qui ne coûtent rien

La gateway est rarement en cause, mais elle peut le devenir : tout dépend de ce qu’on lui a demandé. Les policies n’ont pas le même prix, et l’écart entre les moins chères et les plus chères est de plusieurs ordres de grandeur.

Aucun appel réseau synchrone dans une policy. Interroger un service d’autorisation, enrichir depuis un référentiel, vérifier une révocation à distance : chacun ajoute sa latence et son mode de panne au chemin de tous les appels. Si l’information est nécessaire, elle se met en cache avec une durée de validité assumée.

La validation de jeton se paie une fois. Le cache de clés doit être local et se rafraîchir en arrière-plan. Une plateforme qui va chercher les clés du fournisseur d’identité à chaque appel a converti une vérification en microsecondes en un aller-retour réseau.

La validation de schéma se dimensionne. Elle est précieuse, et son coût suit la taille du corps. Sur des charges utiles volumineuses, la limiter aux points d’entrée exposés à l’extérieur, plutôt que de l’appliquer partout par principe.

Le réflexe qui manque presque toujours : mesurer le temps propre de la gateway policy par policy, en environnement d’essai, avant de les empiler en production. Une demi-journée de mesure évite des mois de soupçon.

La méthode : découper l'appel

Le diagnostic revient toujours à la même question : où le temps passe-t-il ? Un appel traversant une plateforme se découpe en cinq segments, chacun mesurable :

1. réseau client vers gateway.
2. traitement gateway, policies comprises.
3. attente d'une connexion sortante.
4. backend, du premier octet envoyé au dernier reçu.
5. retour vers le client.

Si votre plateforme sait donner ces cinq chiffres pour un appel donné, tout incident de latence commence par une lecture de trace et s’oriente en minutes. Si elle ne sait pas, le diagnostic se fait par accusation réciproque entre équipes, et c'est le signe que votre observabilité s'est arrêtée aux tableaux de bord de volumétrie.

L'instrument s'appelle une trace distribuée, le standard est W3C Trace Context avec l'instrumentation OpenTelemetry, et toutes les gateways récentes savent propager le contexte. Le chantier est rarement technique : il consiste à décider que les cinq segments sont mesurés, exportés vers votre outillage, et conservés assez longtemps pour couvrir un incident détecté tard.

L'indicateur à publier

Une équipe plateforme qui veut sortir du rituel de l'accusation a intérêt à publier elle-même, en continu, son propre poids : le temps de traversée de la gateway, en centiles, par API. Public, opposable, historisé.

Encore faut-il annoncer les valeurs qui rendent cette publication utilisable, sinon elle ne fait que déplacer la discussion. Un ordre de grandeur défendable, à valider chez vous avant de l'afficher : deux à cinq millisecondes au centile 50 pour une chaîne de policies ordinaire, une quinzaine au centile 99.

La règle de lecture est dans l'écart entre les deux, pas dans leur valeur absolue. Un centile 99 à plus de dix fois la médiane ne raconte pas une gateway lente, il raconte une file d'attente : connexions sortantes saturées, pauses du moteur d'exécution, renégociations TLS. C'est le seul motif qui justifie d'ouvrir le sujet côté plateforme.

Le jour où la latence monte, la conversation ne commence plus par « c'est la plateforme », elle commence par deux chiffres et un écart. Et les deux heures d'innocence à prouver redeviennent deux heures de diagnostic sur la vraie piste.