Nous contacter
Vous testez votre API, et vous obtenez un temps de réponse moyen de ~230 ms.
🎉 Bonne nouvelle, c’est (presque) satisfaisant !
Sauf que… en regardant de plus près :
- 90% des requêtes répondent en moins de 50 ms
- 9% prennent 1 seconde
- Et 1% explosent à 10 secondes !
💥 Votre API est en réalité catastrophique pour une partie des utilisateurs.
La moyenne vous a menti. Voici pourquoi (et comment l’éviter).
La moyenne masque les pires cas (là où ça fait mal)
Prenons un exemple simple :
| Requêtes | Temps de réponse (ms) |
|---|---|
| 190 | < 50 |
| 10 | > 5000 |
La moyenne est de ~215 ms, mais est-ce que ça reflète la réalité ?
- Pour 19 requêtes sur 20, le temps de réponse est ok.
- Mais pour 1 requête sur 20 (soit 5% des requêtes), c’est une catastrophe.
Une requête ≠ un utilisateur: La moyenne ne reflète pas l’expérience utilisateur réelle
Un utilisateur ne se contente pas d’une seule requête. S’il en effectue plusieurs et qu’une seule d’entre elles est lente, son expérience est dégradée.
Dans le cas d’une API, une transaction métier repose souvent sur plusieurs appels :
- Authentification
- Récupération d’un produit
- Création d’un élément
- Validation d’une action
(Et dans le cas des listes de données, il est courant qu’un utilisateur recupère plusieurs pages de données).
🚨 Les services qui s’appuient sur votre API ont souvent des règles de timeout. Si votre réponse est trop lente, ils coupent la connexion.
Et s’ils n’ont pas mis de mécanisme de retry, vous risquez d’interrompre une transaction entière, même si cela ne concerne qu’un faible pourcentage de requêtes.
💡 Les pires cas peuvent toucher bien plus de transactions que ce que la moyenne laisse penser.
🎯 Exemple concret :
Imaginez un site e-commerce.
- 95% des utilisateurs naviguent sans souci (P95 = 200 ms).
- Mais les 5% restants subissent des latences de 5 à 10 secondes !
- Devinez quoi ? Ce sont souvent ceux qui veulent finaliser leur achat…
Sachant qu’une navigation sur un site e-commerce c’est souvent plusieurs requêtes par page. Il n’est pas impossible qu’au cours de votre navigation, vous rencontriez au moins une fois des lenteurs à cause d’une ou deux requêtes (vous savez, votre 5% qui flanche).
Si une seule requête traîne, c’est toute l’expérience utilisateur qui en pâtit. Les utilisateurs ne ressentent pas “un temps de réponse moyen”, ils vivent chaque requête de façon unique.
💡 Les pires cas (P95/P99) impactent directement le business (taux de conversion, frustration client, abandon du panier…).
Que faut-il regarder à la place ? (Les percentiles !)
Plutôt que la moyenne, utilisez les percentiles :
- P50 (médiane) : 50% des requêtes sont plus rapides que cette valeur.
- P90 : 90% des requêtes sont sous ce seuil (les 10% les plus lents commencent à apparaître).
- P95 : 5% des requêtes sont plus lentes que cette valeur (celles qui commencent à vraiment impacter les utilisateurs).
- P99 : 1% des requêtes les plus lentes (celles qui font rager les clients, et encore, ce n’est pas forcément suffisant: cf. Youtube: “How to Not Measure Latency”, by Gil Tene)
💡 Si votre P95 explose à 5 secondes, vous avez un réel problème, même si votre moyenne est belle.
La moyenne ne marche pas bien quand il y a de l’instabilité.
Un autre piège de la moyenne : elle ne capture pas la variance.
Exemple :
| Test 1 | Test 2 | Test 3 | Test 4 | Test 5 | Test 6 | Test 7 |
|---|---|---|---|---|---|---|
| 100 ms | 200 ms | 300 ms | 50 ms | 5 000 ms | 500 ms | 45 ms |
Moyenne = 885 ms ❌ (Ce qui est déjà vraiment mauvais)
Mais que nous dit le P95 ?
👉 5 000 ms… soit une expérience (vraiment) désastreuse pour certains utilisateurs !
D’où peut venir cette variance ?
- Accès exclusifs à des ressources critiques (ex. : lock sur certains éléments des bases de données).
- Dépendances tierces instables (API externes, quotas dépassés, timeouts).
- Batchs qui s’exécutent à des moments de forte charge, monopolisant des ressources.
💡 Regardez la distribution complète des temps de réponse, pas juste une valeur unique ! L’étude de la variance est un premier signal de fumée pour aller plus loin dans les investigations.
En résumé : la moyenne, ça ne veut rien dire !
- Elle masque les pires cas (là où les vrais problèmes sont)
- Elle ne reflète pas l’expérience utilisateur réelle
- Elle ne montre pas la variabilité / écarts des performances
Comment analyser ça correctement ?
- Toujours utiliser (à minima) les percentiles (P90, P95, P99)
- Regarder la distribution des temps de réponse (histogrammes, box plots)
- Surveiller la latence en fonction de la charge (scalabilité)
- Corréler avec l’expérience utilisateur (temps de chargement perçu)
/in/cedriccf/