Pourquoi la latence moyenne est la mauvaise métrique pour les agents IA

Le temps de réponse moyen est la mauvaise métrique à optimiser pour les agents IA, car il dissimule précisément les requêtes qui brisent la confiance : l'appel d'outil lent, l'étape LLM relancée, la requête qui a expiré et s'est silencieusement rabattue sur une alternative. Suivez plutôt la latence p95 et p99 par étape, et exigez les mêmes données de tout prestataire avant de signer un contrat.

Le problème de la moyenne

Supposons que votre agent réponde en 800ms en moyenne. C'est satisfaisant en apparence. Mais si 90 % des requêtes se terminent en 400ms et que les 10 % restantes prennent 6 secondes parce qu'elles déclenchent une relance, une limite de débit ou un appel API lent en aval, la moyenne ensevelit précisément la partie de la distribution que vos utilisateurs ressentent. Personne n'expérimente la moyenne. Chacun vit sa propre requête — et pour un utilisateur sur dix, cette requête est 15x plus lente que ce que votre tableau de bord laisse entendre.

Ce n'est pas une idée nouvelle dans les systèmes distribués : c'est précisément pourquoi le livre SRE de Google considère la latence en percentiles (p50, p95, p99) comme la norme de supervision, et non la moyenne. Les agents IA aggravent ce phénomène par rapport aux services web classiques, car la queue est plus épaisse : le temps d'inférence d'un LLM est lui-même variable, les appels d'outils peuvent se bloquer, et les agents enchaînent souvent plusieurs appels où un seul maillon lent paralyse toute la requête.

L'origine de la queue dans les systèmes agentiques

Un appel LLM bien délimité n'a qu'une source de variance de latence : le temps d'inférence du modèle, plus le réseau. Un agent qui enchaîne des étapes — récupérer du contexte, appeler un outil, rappeler le modèle, valider la sortie, rappeler le modèle une troisième fois — multiplie cette variance à chaque passage. Chaque étape porte aussi sa propre probabilité d'échec et de relance, et les relances n'ajoutent pas de la latence de façon uniforme : elles l'ajoutent de façon irrégulière. Une requête qui nécessite une seule relance à l'étape 3 peut prendre deux fois plus de temps qu'une requête qui passe sans accroc — et c'est précisément cette irrégularité que les moyennes effacent.

Nous l'avons constaté directement en construisant notre propre outil de prospection, qui analyse le site d'un prospect et rédige un e-mail personnalisé. Les premières versions reposaient sur une chaîne en trois étapes : extraire les informations de la page scrapée, rédiger l'e-mail, puis l'affiner. L'étape d'extraction était à la merci du serveur tiers — certains sites de prospects se chargeaient rapidement, d'autres étaient lents ou saturés de scripts de tracking — et le temps de chargement de cette page devenait un plancher pour tout ce qui suivait, puisque la rédaction ne pouvait démarrer qu'une fois l'extraction terminée. La moyenne semblait correcte parce que la plupart des sites de prospects sont rapides. La queue était difficile parce que les sites lents n'étaient pas rares — ils étaient simplement répartis de façon inégale — et chacun produisait un blocage complet qu'une moyenne rapide ne révélait jamais. Fusionner l'extraction et la rédaction en un seul appel bien conçu n'a pas accéléré le chargement des sites individuels, mais a supprimé la dépendance séquentielle : il y avait une transition de moins pour qu'un chargement lent vienne bloquer le reste. Si vous hésitez entre une chaîne agentique et un appel unique pour votre propre produit, ce compromis mérite réflexion avant de construire quoi que ce soit — consultez notre analyse de l'appel unique vs les chaînes agentiques.

Ce qu'il faut mesurer à la place

Pour tout agent IA, que vous le construisiez ou que vous évaluiez l'offre d'un prestataire, demandez ces chiffres ventilés par étape, et non uniquement pour la requête dans son ensemble :

• p50 (médiane) : ce que ressent une requête typique.
• p95 : ce qu'un utilisateur sur vingt expérimente. C'est généralement là que commencent les vraies plaintes produit.
• p99 : votre queue au pire des cas. Pour un bot de support qui traite des milliers de conversations par jour, le p99 n'est pas un cas marginal — ce sont des dizaines de vraies conversations chaque jour.
• Temps jusqu'au premier token vs. temps de complétion total : si l'agent diffuse la sortie en streaming, les utilisateurs tolèrent bien mieux un temps total plus long qu'un démarrage lent. Mesurez les deux séparément.
• Taux de relance et localisation des relances : un taux de relance de 2 % sur une étape paraît faible, jusqu'à ce que ce soit l'étape dont dépend chaque requête.

Des outils comme OpenTelemetry existent précisément pour tracer la latence à travers chaque étape d'un appel distribué — y compris les chaînes agentiques — plutôt que de ne voir que le total. Si votre stack actuel (ou celui d'un prestataire) ne peut pas vous fournir des traces par étape, c'est déjà en soi une information utile.

Ce que cela révèle dans les échanges avec les prestataires

Si vous évaluez une équipe externe pour construire ou opérer un agent IA, les déclarations de performance sont l'un des endroits où un discours commercial peut le plus facilement surestimer la réalité. « Réponses en moins d'une seconde » est presque toujours une affirmation sur la moyenne — et c'est exactement le type de chiffre qui masquait le blocage dans notre propre outil de prospection jusqu'à ce que nous le décomposions par étape. Les bonnes questions de relance sont :

• Quels sont les p95 et p99 sous une charge concurrente réaliste, et non lors d'une seule requête bien préchauffée en démo ?
• Quelle est l'étape la plus lente du pipeline, et comment évolue-t-elle sous charge ?
• Que se passe-t-il quand un appel en aval (une base de données, un index de recherche, une autre API — ou dans notre cas le site web du prospect lui-même) est lent ? L'agent dégrade-t-il gracieusement ou se bloque-t-il ?

Ces questions ont leur place dans la même conversation que la tarification et les conditions de support. Nous couvrons le reste de cette évaluation — y compris les questions sans aucun rapport avec la vitesse — dans notre checklist d'évaluation de prestataires d'agents IA.

Latence et coût, c'est la même conversation

Il convient de noter que la même chaîne qui produit un mauvais p99 génère généralement aussi une mauvaise facture. Des étapes supplémentaires signifient des tokens supplémentaires, des relances signifient payer deux fois pour le même travail, et des appels modèles supplémentaires signifient payer pour une surcharge de coordination qui n'apporte aucune valeur à la sortie. Si vous auditez déjà la latence, auditez les coûts en même temps. Notre guide sur l'optimisation des coûts LLM parcourt le même exercice de réduction depuis l'angle des coûts — et en pratique, les correctifs se recoupent : moins d'appels mieux délimités surpassent des appels plus nombreux et plus petits sur les deux dimensions.

La conclusion pratique

Ne laissez pas « ça paraît rapide en démo » ou « temps de réponse moyen : 800ms » remplacer une vraie mesure. Avant de mettre un agent en production — ou avant de valider celui que quelqu'un d'autre a construit pour vous — obtenez les chiffres p95 et p99 sous charge, ventilés par étape. Si personne ne peut produire ces chiffres, vous avez votre réponse sur la réalité des tests effectués.

Si vous construisez un agent IA et souhaitez un regard extérieur sur l'architecture avant que la latence ne devienne un problème en production, parlons-en.