Vous testez votre API, et vous obtenez un temps de réponse moyen de ~230 ms.
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 ne vaut pas un utilisateur — la moyenne ne reflète pas l’expérience 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 récupè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.
- Ce sont souvent ceux qui veulent finaliser leur achat…
Sachant qu’une navigation sur un site e-commerce implique 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 (les fameux 5% qui flanchent).
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.
Modifiez le nombre de requêtes par plage de temps pour visualiser l’impact sur la moyenne vs les percentiles :
Distribution des temps de réponse
Et concrètement, quel P95 viser ?
Il n’y a pas de réponse universelle. Les seuils acceptables dépendent de votre contexte : type de service, criticité métier, contraintes réseau, attentes utilisateurs.
L’essentiel est de les définir en amont avec vos équipes, de les suivre en continu, et de les corréler avec votre budget d’erreur (SLA) pour transformer ces seuils en engagements concrets.
Les percentiles sont la base d’un bon suivi de performance. Un test de charge bien construit vous permettra de les mesurer sous des conditions réalistes.
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 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 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)
