API lente : identifier ce qui ralentit vos temps de réponse et l'optimiser
Une API lente se ressent partout : application mobile qui affiche des indicateurs de chargement interminables, interface web qui se fige, intégrations partenaires qui expirent, coûts d'infrastructure qui grimpent parce que chaque requête mobilise des ressources trop longtemps. Le problème est souvent progressif et n'apparaît franchement qu'avec la croissance des données ou du trafic.
Les causes se trouvent rarement dans le framework lui-même. Elles sont dans les accès à la base de données (requêtes N+1, index manquants, requêtes non optimisées), dans le volume des réponses, dans l'absence de cache, dans les appels synchrones à des services externes, dans les démarrages à froid des fonctions serverless ou dans des pools de connexions mal dimensionnés.
Cette page décrit comment mesurer précisément où passe le temps, quelles sont les causes les plus fréquentes selon l'architecture (monolithe, microservices, serverless) et les optimisations à appliquer, de l'index SQL au cache HTTP.
Symptômes typiques
- Les temps de réponse au 95e ou 99e percentile sont bien plus élevés que la médiane : la plupart des requêtes sont rapides, mais certaines sont très lentes.
- Les temps de réponse augmentent avec la taille des données (listes, historiques, tableaux de bord) ou avec le nombre d'utilisateurs simultanés.
- Les clients reçoivent des erreurs de délai dépassé (timeout, 504) aux heures de pointe.
- Certains points de terminaison sont lents alors que d'autres, similaires, répondent instantanément.
- La première requête après une période d'inactivité est très lente (démarrage à froid), puis les suivantes sont rapides.
- Le processeur ou la base de données est saturé alors que le trafic est modéré.
Causes possibles
Requêtes N+1
L'ORM charge une liste puis exécute une requête supplémentaire pour chaque élément (auteur, catégorie, prix). Une page de cent éléments génère cent et une requêtes au lieu de deux. C'est la cause la plus fréquente sur Laravel, Django, Rails, Spring Data, Prisma ou TypeORM.
Index manquants ou inadaptés
Une clause WHERE, JOIN ou ORDER BY sur une colonne sans index oblige la base à parcourir toute la table. Le problème passe inaperçu avec peu de données et explose avec la croissance.
Charges utiles trop lourdes
Réponses qui renvoient tous les champs et toutes les relations, sans pagination ni sélection, images encodées en base64, JSON de plusieurs mégaoctets sérialisés à chaque appel.
Absence de cache
Les mêmes données de référence (catalogue, configuration, permissions) sont recalculées à chaque requête alors qu'elles changent rarement. Ni cache applicatif (Redis), ni cache HTTP (ETag, Cache-Control, CDN).
Appels externes synchrones
Chaque requête attend un service tiers (paiement, géocodage, e-mail, autre microservice) sans délai d'expiration court ni parallélisation. La latence de l'API devient la somme des latences de tout le monde.
Démarrages à froid et pools de connexions
Fonctions serverless (AWS Lambda, Cloud Functions) qui initialisent tout à chaque appel, pool de connexions trop petit qui fait attendre les requêtes, ou trop grand qui sature la base de données.
Traitement synchrone de tâches lourdes
Génération de PDF, envoi d'e-mails, redimensionnement d'images ou export exécutés dans la requête HTTP au lieu d'être délégués à une file d'attente.
Contrôles à effectuer
- 1
Mesurer par point de terminaison
Un APM (Datadog, New Relic, Elastic APM, OpenTelemetry avec Grafana Tempo ou Jaeger) montre la répartition du temps entre code, base de données et appels externes pour chaque route, avec les percentiles. Sans APM, les journaux d'accès avec le temps de réponse (Nginx $request_time) donnent une première vue.
- 2
Compter les requêtes SQL par appel
Activez le journal des requêtes de l'ORM (Laravel Debugbar, Django Debug Toolbar, Hibernate show_sql, Prisma log queries) sur un environnement de test : un nombre de requêtes qui croît avec la taille de la liste signale un N+1.
- 3
Activer le journal des requêtes lentes
MySQL : slow_query_log avec long_query_time bas ; PostgreSQL : log_min_duration_statement ou l'extension pg_stat_statements qui classe les requêtes par temps total. Vous obtenez la liste des requêtes à optimiser en priorité.
- 4
Analyser les plans d'exécution
EXPLAIN (MySQL) ou EXPLAIN ANALYZE (PostgreSQL) sur les requêtes lentes : un « Seq Scan » ou « type: ALL » sur une grande table indique un index manquant ; des « rows » très élevés, une jointure mal filtrée.
- 5
Mesurer la taille des réponses
curl -s -o /dev/null -w '%{size_download} %{time_starttransfer} %{time_total}' https://api.example.fr/route affiche le poids et les temps. Comparez avec ce dont le client a réellement besoin.
- 6
Tracer les appels externes
Dans l'APM ou avec des journaux horodatés autour de chaque appel HTTP sortant, mesurez la latence de chaque dépendance et vérifiez qu'un délai d'expiration est configuré.
- 7
Vérifier les pools et les démarrages à froid
Observez les métriques de connexions de la base (pg_stat_activity, Threads_connected) et le temps d'initialisation des fonctions serverless (durée d'init dans CloudWatch). Comparez la latence de la première requête et des suivantes.
Solutions
Éliminer les N+1
Chargement anticipé des relations (with() sur Laravel, select_related et prefetch_related sur Django, JOIN FETCH ou EntityGraph sur JPA, include sur Prisma), ou requêtes agrégées écrites à la main pour les cas complexes.
Ajouter les bons index
Index sur les colonnes filtrées, jointes et triées, index composites dans le bon ordre, index partiels ou couvrants sur PostgreSQL, puis vérification du plan d'exécution après création.
Alléger les réponses
Pagination systématique (par curseur pour les grandes listes), sélection des champs, endpoints dédiés par usage, compression Gzip ou Brotli, et séparation des fichiers binaires servis par un stockage objet.
Mettre en cache intelligemment
Cache Redis pour les données de référence et les calculs coûteux avec invalidation ciblée, en-têtes HTTP (Cache-Control, ETag) pour les réponses publiques, CDN devant les points de terminaison en lecture.
Découpler les appels externes et les tâches lourdes
Délais d'expiration courts, appels en parallèle quand ils sont indépendants, disjoncteurs, et files d'attente (SQS, RabbitMQ, Redis, Sidekiq, BullMQ) pour tout ce qui n'a pas besoin de réponse immédiate.
Dimensionner l'infrastructure
Pool de connexions adapté au nombre d'instances, PgBouncer ou RDS Proxy devant PostgreSQL, concurrence provisionnée ou instances conservées au chaud pour le serverless, mise à l'échelle automatique sur les métriques pertinentes.
Quand contacter un professionnel ?
- Vous n'avez pas d'APM ni de métriques par point de terminaison et ne savez pas par où commencer.
- Les requêtes lentes impliquent des jointures complexes, des agrégations ou un modèle de données que vous ne pouvez pas modifier seul.
- L'API alimente une application mobile ou des partenaires et la lenteur génère des plaintes ou des ruptures de contrat de service.
- Vous préparez une montée en charge (lancement, campagne, nouveau client important) et voulez des garanties.
- Les optimisations classiques ont été faites et les temps restent élevés : il faut examiner l'architecture (découpage, cache distribué, base de données).
L'intervention proposée par Agencei
- 1
Mise en place de l'observabilité
Instrumentation avec OpenTelemetry ou un APM, tableaux de bord par point de terminaison avec percentiles, journal des requêtes lentes et traçage des appels externes.
- 2
Audit de performance
Analyse des routes les plus lentes et les plus appelées, des requêtes SQL et de leurs plans d'exécution, de la sérialisation, du cache et de l'infrastructure.
- 3
Optimisation
Correction des N+1, ajout d'index, refonte des requêtes critiques, pagination, cache applicatif et HTTP, asynchronisation des tâches lourdes, réglage des pools.
- 4
Tests de charge
Scénarios réalistes avec k6, Gatling ou Locust avant et après optimisation pour valider les gains et connaître la capacité réelle.
- 5
Transfert et suivi
Rapport avec les mesures, les changements effectués et les recommandations, alertes sur les temps de réponse, et accompagnement de votre équipe pour maintenir les bonnes pratiques.
Questions fréquentes
Comment savoir si mon API a un problème de N+1 ?
Comptez les requêtes SQL exécutées pour un appel qui renvoie une liste. Si ce nombre augmente avec le nombre d'éléments renvoyés, c'est un N+1. Les barres de débogage des frameworks et les APM le montrent immédiatement.
Ajouter des serveurs va-t-il résoudre la lenteur ?
Seulement si le goulot est le processeur applicatif. Si la base de données est saturée par des requêtes non optimisées, plus d'instances aggravent le problème. La mesure doit précéder le dimensionnement.
Faut-il passer en microservices ou en GraphQL pour être plus rapide ?
Ni l'un ni l'autre n'accélère une API par nature. Les microservices ajoutent de la latence réseau ; GraphQL peut générer des N+1 s'il n'est pas accompagné de DataLoader. La plupart des gains viennent des requêtes, des index et du cache.
Quel temps de réponse viser ?
Cela dépend de l'usage : une API appelée à chaque interaction d'une interface doit répondre en quelques dizaines de millisecondes, un export ou un rapport peut prendre plus longtemps et être traité en asynchrone. L'important est de mesurer aux percentiles élevés, pas seulement en moyenne.
Combien de temps dure une optimisation d'API ?
L'instrumentation et l'audit prennent souvent quelques jours. Les corrections vont de quelques heures pour des index et des N+1 à plusieurs semaines si l'architecture ou le modèle de données doivent évoluer.
Services associés
API et backend
API REST et GraphQL, services backend Node.js, Spring Boot et Python, documentés et sécurisés.
Voir ce serviceOptimisation performance
Diagnostic par profilage et corrections ciblées : Core Web Vitals, requêtes SQL, cache, CDN.
Voir ce serviceAudit technique
Revue indépendante du code, de l'architecture et de l'infrastructure, avec un rapport priorisé.
Voir ce serviceBases de données
Conception, optimisation, administration et sauvegardes de vos bases PostgreSQL, MySQL, MongoDB et Redis.
Voir ce serviceExpertise PostgreSQL
Conception de schéma, optimisation, réplication, montées de version et migration vers PostgreSQL.
Voir ce serviceParlez-nous de votre projet
Décrivez votre besoin en quelques lignes : nous revenons vers vous avec une première analyse et les prochaines étapes.