Une API peut passer tous les tests fonctionnels et échouer en production. Elle renvoie les bonnes données, avec le bon code de statut, conformément au bon schéma, puis elle s'effondre dès qu'un millier d'utilisateurs la sollicitent simultanément. Les tests fonctionnels vous indiquent que l'API est correcte. Les tests de performance vous indiquent qu'elle est correcte et suffisamment rapide pour supporter un trafic réel.
Ce guide explique ce qu'est le test de performance d'API, les types de tests importants, les métriques à surveiller et comment exécuter un test de performance étape par étape dans Apidog.
Qu'est-ce que le test de performance d'API
Le test de performance d'API mesure le comportement d'une API sous charge : sa vitesse de réponse, le nombre de requêtes qu'elle peut gérer et le point où elle se dégrade ou tombe en panne. Il ne s'agit pas de savoir si la réponse est correcte ; c'est le domaine des tests fonctionnels. Il s'agit de savoir si la réponse arrive rapidement et de manière fiable lorsque le système est sous pression.
L'objectif est de trouver les limites avant que vos utilisateurs ne le fassent. Chaque API a un plafond, un point où les temps de réponse augmentent, des erreurs apparaissent ou le service cesse de répondre. Les tests de performance localisent ce plafond dans un environnement contrôlé afin que vous puissiez l'augmenter, planifier la capacité en fonction de celui-ci, ou du moins savoir qu'il existe.
Les API sont une bonne cible pour les tests de performance car elles sont déterministes et rapides à appeler. Il n'y a pas de navigateur à rendre, pas d'interface utilisateur à attendre. Vous envoyez une requête, vous mesurez la réponse. Cela rend les tests de performance d'API moins coûteux à exécuter et plus stables que les tests de charge de bout en bout complets.
Les types de tests de performance
Le "test de performance" est un terme générique. Il englobe plusieurs types de tests distincts, chacun répondant à une question différente.
Le test de charge applique le trafic que vous attendez réellement, votre volume de requêtes normal et de pointe, et confirme que l'API le gère dans des temps de réponse acceptables. C'est le test de base que la plupart des équipes exécutent en premier.
Le test de stress dépasse le trafic attendu, augmentant la charge jusqu'à ce que l'API se dégrade ou tombe en panne. Le but est de trouver le point de rupture et de voir comment elle se brise. Ralentit-elle gracieusement, ou renvoie-t-elle des erreurs et perd-elle des données ?
Le test de pic applique une augmentation soudaine et rapide du trafic, le genre que produit une vente flash ou un moment viral, et vérifie si l'API l'absorbe ou s'effondre. Un système qui gère une charge constante peut quand même échouer à un pic.
Le test d'endurance, également appelé test de vieillissement, maintient une charge modérée pendant une longue période, des heures ou des jours, pour exposer des problèmes lents : fuites de mémoire, épuisement du pool de connexions, fichiers journaux remplissant un disque. Ceux-ci n'apparaissent jamais lors d'un test de charge de cinq minutes.
Le test de fumée est la vérification légère préalable : une petite charge pour confirmer que l'API et la configuration du test fonctionnent avant de s'engager dans une exécution longue et coûteuse.
La plupart des équipes ont besoin de tests de charge, de stress et d'endurance au minimum. Le test de pic est important si votre trafic est irrégulier.
Les métriques qui comptent
Un test de performance produit des chiffres. Ce sont ceux-ci qu'il faut lire.
Le temps de réponse est le temps que l'API met pour recevoir, traiter et renvoyer une requête. Regardez les percentiles, pas seulement la moyenne. La moyenne peut sembler saine tandis que les 95e et 99e percentiles, les 5% et 1% de requêtes les plus lentes, sont inacceptables. Les vrais utilisateurs ressentent la queue.
Le débit est le nombre de requêtes que l'API complète par seconde. Il vous indique la capacité réelle du système, indépendamment du nombre d'utilisateurs connectés.
Les utilisateurs simultanés ou utilisateurs virtuels est le nombre d'appelants simultanés que le test simule. La capacité est souvent exprimée comme la concurrence maximale que l'API maintient avant que les temps de réponse ne dépassent votre budget.
Le taux d'erreur est le pourcentage de requêtes qui échouent sous charge. Une API qui reste rapide mais commence à renvoyer des 500 à haute concurrence a quand même échoué au test.
L'utilisation des ressources, CPU et mémoire sur le serveur, vous indique pourquoi les performances se dégradent. Si les temps de réponse augmentent alors que le CPU est à 100%, vous êtes limité par le calcul ; si le CPU est inactif mais que la latence augmente, le goulot d'étranglement est ailleurs, souvent une base de données ou un appel en aval.
Un bon rapport de performance relie ces éléments : à cette concurrence, le débit a culminé, le temps de réponse au 95e percentile était de tant, et le taux d'erreur était de tant.
Comment exécuter un test de performance d'API dans Apidog
Apidog inclut des tests de charge intégrés dans le même espace de travail où vous concevez et testez fonctionnellement vos API, vous n'avez donc pas besoin d'un outil séparé pour commencer.
Étape 1 : Choisissez le point de terminaison ou le scénario à tester. Choisissez un point de terminaison critique unique, ou un scénario de test multi-étapes qui reflète un flux utilisateur réel, comme la connexion suivie d'une récupération de données. Tester un flux réaliste donne des chiffres plus honnêtes que de marteler un point de terminaison de manière isolée.
Étape 2 : Confirmez qu'il passe d'abord les tests fonctionnels. Exécutez la requête avec ses assertions une fois. Il n'y a aucune valeur à tester la charge d'un point de terminaison qui renvoie des données incorrectes ; corrigez l'exactitude avant de mesurer la vitesse.
Étape 3 : Configurez la charge. Définissez le nombre d'utilisateurs virtuels et la durée du test. Apidog vous permet de monter en charge progressivement, simulant des utilisateurs se joignant au fil du temps plutôt que tous en même temps, ce qui produit une image plus réaliste et aide à identifier le niveau de concurrence où les performances changent.
Étape 4 : Exécutez le test. Apidog exécute la charge et rapporte en direct : temps de réponse, débit, taux d'erreur, et comment chaque métrique évolue à mesure que la concurrence augmente. Surveillez le point d'inflexion où le temps de réponse commence à augmenter plus rapidement que la charge.
Étape 5 : Lisez les résultats et trouvez le goulot d'étranglement. Si le temps de réponse au 95e percentile dépasse votre budget à 300 utilisateurs simultanés, c'est votre plafond actuel. Croisez les données avec l'utilisation du CPU et de la mémoire du serveur pour comprendre la cause. Réexécutez après une correction pour confirmer que le plafond a bougé.
Étape 6 : Pour des besoins plus lourds, exportez vers JMeter. Lorsque vous avez besoin d'une génération de charge distribuée au-delà d'une seule machine, Apidog peut exporter le scénario vers JMeter, afin que vous conserviez la même définition de test tout en faisant évoluer la source de charge.
Téléchargez Apidog pour exécuter votre premier test de charge sur un point de terminaison que vous avez déjà.
Lecture d'un résultat de performance réel
Les chiffres sans interprétation sont du bruit. Prenons une exécution concrète : vous testez la charge de GET /products avec des utilisateurs virtuels augmentant de 0 à 500 sur cinq minutes.
Pour les 200 premiers utilisateurs, le temps de réponse au 95e percentile reste stable autour de 180 ms et le débit augmente en même temps que la charge. C'est la zone saine ; l'API tient le coup. À environ 280 utilisateurs, le temps au 95e percentile commence à augmenter, 240 ms, puis 400 ms, puis 900 ms, tandis que le débit se stabilise au lieu d'augmenter. Cette stabilisation est le signal : l'API a atteint son plafond. L'ajout de plus d'utilisateurs produit maintenant des réponses plus lentes, pas plus de travail terminé. Au-delà de 420 utilisateurs, le taux d'erreur dépasse 1% car les requêtes commencent à expirer.
Le verdict est concret. Cette API gère confortablement environ 250 utilisateurs simultanés avec un budget de 200 ms. Son plafond pratique est proche de 280, et elle commence à échouer autour de 420. Si vous attendez un trafic de pointe de 200 utilisateurs simultanés, vous avez de la marge. Si vous en attendez 350, vous avez un problème à résoudre avant le lancement, pas après.
C'est ce qu'un test de performance fournit : non pas "réussi" ou "échoué", mais une carte claire de là où l'API est à l'aise, où elle peine et où elle se brise.
Goulots d'étranglement courants des performances d'API
Lorsqu'un test expose un plafond, la cause est généralement l'un de ces coupables familiers.
Les requêtes de base de données lentes sont les plus courantes. Une colonne non indexée, un modèle de requête N+1, ou une limite de requête manquante rend un point de terminaison rapide lent dès que le volume de données ou la concurrence augmente. Si la latence augmente alors que le CPU du serveur reste faible, suspectez d'abord la base de données.
Les appels externes bloquants ralentissent un point de terminaison à la vitesse de sa dépendance la plus lente. Une API qui appelle un fournisseur de paiement ou un service tiers de manière synchrone hérite de la latence et des pannes de ce service.
L'épuisement du pool de connexions apparaît sous une charge soutenue : l'API manque de connexions de base de données ou de clients HTTP et les requêtes s'accumulent en attente. C'est une découverte classique des tests d'endurance.
La sérialisation inefficace de grandes charges utiles de réponse consomme du CPU. Renvoyer plus de données que ce dont le client a besoin rend chaque réponse plus longue à construire et plus lente à transférer.
Un test de performance indique où se trouve le plafond ; le coupler avec des métriques côté serveur vous indique pourquoi.
Intégrer les tests de performance dans votre processus
Un test de performance exécuté une fois avant un grand lancement est utile. Un test de performance exécuté régulièrement est bien plus précieux, car les performances se dégradent silencieusement. Une nouvelle requête de base de données, un appel en aval ajouté ou une colonne non indexée peuvent chacun ajouter une latence qu'aucun test fonctionnel ne remarque.
Définissez un budget de temps de réponse et de taux d'erreur pour vos points de terminaison critiques, et traitez un dépassement comme un échec, de la même manière que vous traitez une assertion rompue. Exécutez un test de charge plus léger dans le cadre de la CI/CD afin qu'une régression apparaisse au niveau de la pull request, et réservez les exécutions intensives de stress et d'endurance pour les tests de pré-version planifiés.
Gardez les tests de performance à côté des tests fonctionnels. Lorsque les deux cohabitent, chaque modification d'API est vérifiée à la fois pour l'exactitude et la vitesse, et "ça marche" et "ça marche assez vite" cessent d'être des questions distinctes, facilement oubliées.
Foire aux questions
Quelle est la différence entre les tests de charge et les tests de stress ? Les tests de charge appliquent le trafic que vous attendez et confirment que l'API le gère. Les tests de stress vont au-delà pour trouver le point de rupture. Les tests de charge vérifient le fonctionnement normal ; les tests de stress cartographient le mode de défaillance.
Dois-je regarder les temps de réponse moyens ou les percentiles ? Les percentiles. La moyenne masque la queue lente. Les 95e et 99e percentiles montrent ce que vos utilisateurs les moins chanceux vivent réellement, et c'est ce qui génère les plaintes.
Puis-je tester les performances d'une API avant que le backend ne soit terminé ? Vous pouvez tester le contrat et la conception, mais des chiffres de latence significatifs nécessitent une infrastructure réelle. Utilisez un serveur simulé pour les travaux fonctionnels précoces, et exécutez des tests de charge contre l'implémentation réelle.
À quelle fréquence les tests de performance doivent-ils être exécutés ? Exécutez un test de charge léger en CI à chaque modification des points de terminaison critiques, et des tests de stress et d'endurance complets avant chaque version majeure. Les performances se dégradent silencieusement, donc des vérifications régulières sont préférables à une seule exécution massive avant le lancement.