API REST vs GraphQL : lequel choisir pour votre projet ?

#API REST vs GraphQL : lequel choisir pour votre projet ?

TL;DR — REST couvre 80 % des besoins API en 2026 avec un coût d'entrée minimal. GraphQL prend l'avantage quand plusieurs clients consomment la même API avec des besoins de données différents, ou quand l'agrégation de sources multiples est nécessaire. Le choix n'est pas binaire : l'architecture hybride (BFF GraphQL + microservices REST) est le pattern dominant chez les scale-ups.

---

Quand un développeur dit « on a besoin d'une API », la question qui suit immédiatement est : REST ou GraphQL ? Ce choix architectural a des consequences durables sur la complexité du développement, la performance de l'application, la maintenabilite du code et la capacité a évoluer.

REST (Representational State Transfer) est le standard de facto des API web depuis le milieu des années 2000. Simple, base sur les verbes HTTP (GET, POST, PUT, DELETE), supporte par tous les langages et frameworks, il a fait ses preuves sur des milliards d'API en production.

GraphQL, cree par Facebook en 2012 et open-source en 2015, prend le problème différemment. Au lieu d'exposer des endpoints prédéfinis, il expose un schema type que le client interroge avec un langage de requête flexible. Le client demande exactement les données dont il a besoin — ni plus, ni moins.

En 2026, la réalité du marche est que REST reste largement dominant (plus de 80 % des API publiques selon Postman State of APIs 2025), mais GraphQL a conquis des niches significatives : applications multi-clients (web + mobile + partenaires), agrégation de données de sources multiples, et experiences front-end complexes.

Cet article compare les deux approches sur 8 dimensions techniques et vous donne une matrice de décision claire. L'objectif n'est pas de prouver la supériorité de l'un sur l'autre — c'est de vous aider à choisir l'API adaptée à votre contexte.

#Over-fetching et under-fetching : le problème fondamental

Le problème avec REST

Une API REST expose des endpoints qui retournent des ressources completes. L'endpoint /api/users/42 retourne toutes les propriétés de l'utilisateur : nom, email, adresse, historique des commandes, preferences, avatar. Si votre page d'accueil n'a besoin que du nom et de l'avatar, vous recevez quand même toutes les données — c'est l'over-fetching.

L'inverse existe aussi : si votre page de profil a besoin de l'utilisateur ET de ses 10 dernières commandes, vous devez faire 2 appels API séparés (/api/users/42 puis /api/users/42/orders) — c'est l'under-fetching, qui multiplie les requêtes réseau.

Sur un réseau rapide (fibre, WiFi), l'impact est négligeable. Sur un réseau mobile 4G avec 100 ms de latence par requête, chaque appel supplémentaire se paie en temps de chargement perceptible par l'utilisateur.

La solution GraphQL

GraphQL résout ces deux problèmes élégamment. Le client specifie exactement les champs dont il a besoin dans sa requête. Pour obtenir le nom, l'avatar et les 10 dernières commandes d'un utilisateur, une seule requête GraphQL suffit — et elle ne retourne que ces champs, rien de plus.

Cette flexibilité est particulièrement précieuse quand plusieurs clients consomment la même API avec des besoins différents. L'application mobile a besoin d'un sous-ensemble leger des données. L'application desktop a besoin de données enrichies. Le dashboard admin a besoin de tout. Avec REST, il faut soit créer des endpoints spécifiques par client, soit accepter l'over-fetching. Avec GraphQL, chaque client formule la requête adaptée à son besoin.

Le contrepoint

REST n'est pas démuni face à ce problème. Les query parameters (?fields=name,avatar), la pagination, et les patterns comme JSON:API permettent de contrôler partiellement les données retournées. C'est moins elegant que GraphQL, mais ca fonctionne. Et surtout, ca ne necessite pas d'apprendre un nouveau langage de requête.

#Schema type et introspection : la force de GraphQL

Le schema GraphQL

GraphQL impose un schema type qui décrit exhaustivement les types de données, les relations entre eux, et les opérations disponibles (queries, mutations, subscriptions). Ce schema est le contrat entre le serveur et le client — il est versionne, documente et verifiable a la compilation.

L'introspection native permet a n'importe quel client d'interroger le schema pour découvrir les types disponibles, les champs, les arguments et les descriptions. Des outils comme GraphiQL ou Apollo Studio exploitent cette introspection pour offrir une auto-completion en temps réel, une documentation interactive, et une validation des requêtes avant envoi.

Pour les equipes de développement, c'est un gain de productivité majeur. Le développeur front-end n'a pas besoin de lire la documentation API (qui est souvent obsolete) — il explore le schema directement dans son IDE. Les erreurs de typage sont détectées a la compilation, pas en production.

REST et la documentation

REST n'a pas d'équivalent natif. La documentation repose sur des standards comme OpenAPI/Swagger, qui décrivent les endpoints, les parametres et les réponses. C'est efficace, mais la documentation est séparée du code — elle peut diverger si elle n'est pas générée automatiquement. Des outils comme API Platform (Symfony) ou tRPC (TypeScript) réduisent cet écart en générant la documentation automatiquement depuis le code.

Le coût du schema GraphQL

Le schema type est un avantage en maintenabilite, mais un coût en développement initial. Définir un schema GraphQL complet pour une application métier (types, relations, resolveurs, validations, autorisations) prend plus de temps que d'exposer des endpoints REST avec un framework comme API Platform ou Express. Sur un MVP ou un projet a cycle court, ce surcoût peut ne pas être justifie.

#Caching et performance : l'avantage REST

Le caching HTTP natif de REST

REST s'appuie sur le protocole HTTP et beneficie de toute son infrastructure de caching. Les réponses GET peuvent être mises en cache par le navigateur, les CDN (Cloudflare, Fastly), les reverse proxies (Nginx, Varnish) et les caches applicatifs (Redis). Les headers HTTP standards (Cache-Control, ETag, Last-Modified) permettent un controle fin de la durée de vie et de la validation du cache.

Ce caching est transparent : il fonctionne sans code supplémentaire côté client ou serveur. Un endpoint REST qui retourne une liste de produits peut être cache par un CDN pendant 5 minutes, réduisant la charge serveur de 95 % sur les pages a fort trafic.

Le problème du caching GraphQL

GraphQL utilise un seul endpoint POST pour toutes les requêtes. Les CDN et les caches HTTP ne peuvent pas cacher les requêtes POST nativement — chaque requête est considérée comme unique. Le caching GraphQL necessite des solutions spécifiques : cache au niveau du resolveur (DataLoader pour le batching et le caching par requête), cache au niveau du client (Apollo Client avec normalized cache), ou des solutions de caching GraphQL dédiées (Stellate, anciennement GraphCDN).

Ces solutions fonctionnent, mais elles ajoutent de la complexité d'infrastructure et de développement. Pour une API publique a fort trafic (catalogue produit, contenu editorial), l'absence de caching HTTP natif est un desavantage significatif de GraphQL.

Performances brutes

Sur les requêtes simples (un seul type de données, peu de relations), REST est légèrement plus performant — moins d'overhead de parsing de requête, caching HTTP natif. Sur les requêtes complexes (données imbriquées, relations multiples), GraphQL peut être plus performant car il evite les appels multiples — mais le risque de requêtes N+1 côté serveur est reel si les resolveurs ne sont pas optimises.

Le problème N+1 en GraphQL : quand un client demande une liste de 100 utilisateurs avec leurs commandes, un resolveur naif va executer 1 requête pour les utilisateurs + 100 requêtes pour les commandes. DataLoader résout ce problème par le batching, mais il faut le configurer explicitement — ce n'est pas automatique.

#Subscriptions et temps réel : GraphQL natif vs REST + WebSocket

Les subscriptions GraphQL

GraphQL inclut nativement le concept de subscriptions : le client s'abonne a un type d'événement et reçoit les mises à jour en temps réel via WebSocket. La syntaxe est intégrée au schema : les subscriptions sont déclarées comme les queries et mutations, avec le même typage et les mêmes autorisations.

Pour une application qui necessite du temps réel (notifications, mises à jour de tableau de bord, chat, suivi de commande), les subscriptions GraphQL offrent une expérience de développement cohérente : le même langage de requête pour la lecture initiale et les mises à jour en temps réel.

REST et le temps réel

REST ne propose pas de mécanisme de temps réel natif. Les solutions les plus courantes sont les WebSockets (connexion bidirectionnelle), les Server-Sent Events (SSE, flux unidirectionnel du serveur vers le client), et le polling (le client interroge le serveur a intervalle régulier).

Ces solutions fonctionnent, mais elles sont séparées de l'API REST — c'est un autre protocole, une autre couche d'infrastructure, souvent un autre framework. Le contrat de données entre les evenements temps réel et les réponses REST n'est pas unifie.

En pratique

Le besoin de temps réel est souvent surestime dans les projets B2B. Un tableau de bord qui se rafraîchit toutes les 30 secondes par polling REST est suffisant pour 90 % des cas d'usage. Les subscriptions GraphQL sont un avantage différenciant quand le temps réel est au coeur du produit (collaboration en temps réel, monitoring live, trading).

En 2026, les Server-Sent Events (SSE) gagnent en popularité comme alternative légère aux WebSockets pour le temps réel unidirectionnel. Supportes nativement par les navigateurs et compatibles avec HTTP/2, les SSE fonctionnent aussi bien avec REST qu'avec GraphQL.

#Comparatif synthétique : REST vs GraphQL sur 8 dimensions

Dimension	REST	GraphQL
Over-fetching	Oui (contournable avec fields)	Non (requête selective)
Under-fetching	Oui (appels multiples)	Non (requête unique)
Schema type	Non natif (OpenAPI)	Oui natif
Caching HTTP	Natif et transparent	Complexe (endpoint unique POST)
Temps reel	WebSocket/SSE séparés	Subscriptions natives
Courbe d'apprentissage	Faible	Modérée a élevée
Tooling écosystème	Universel	Riche mais specialise
Multi-clients	Endpoints spécifiques ou over-fetching	Un schema, N clients

#Quand choisir REST et quand choisir GraphQL : matrice de décision

Choisissez REST si :

• Votre API est un CRUD simple avec des ressources bien définies et peu de relations imbriquées.
• Votre API est publique ou exposée a des partenaires externes. REST est universellement compris, documentable avec OpenAPI/Swagger.
• Le caching est critique pour votre performance. Les API a fort trafic bénéficient massivement du caching HTTP natif.
• Votre architecture est en microservices. Chaque microservice expose sa propre API REST — c'est le pattern dominant.
• Votre equipe n'a pas d'expérience GraphQL. La courbe d'apprentissage represente un investissement de 2 à 4 semaines.

Choisissez GraphQL si :

• Plusieurs clients consomment la même API avec des besoins différents (web, mobile, partenaires, dashboard).
• Votre application agregre des données de sources multiples. Un BFF GraphQL unifie ces sources derrière un schema unique.
• Votre front-end affiche des données fortement imbriquées avec de nombreuses relations.
• Le temps réel est au coeur de votre produit.
• Votre equipe front-end veut une expérience de développement optimale. L'écosystème GraphQL (Apollo Client, Relay, codegen TypeScript) offre un DX supérieur pour les applications React/Next.js complexes.

La recommandation Nehos

Pour les nouvelles applications B2B, on demarre avec REST (via API Platform sur Symfony ou les route handlers Next.js) sauf si l'un des critères pro-GraphQL est clairement dominant. La raison : REST est plus simple a mettre en oeuvre, plus simple a cacher, plus simple a maintenir, et couvre 80 % des besoins sans compromis. GraphQL est un outil puissant, mais il ajoute de la complexité qui doit être justifiée par un gain concret.

#Cas concret : architecture hybride BFF GraphQL + microservices REST

L'approche que l'on déploie le plus souvent chez Nehos pour les applications B2B a forte complexité front-end est l'architecture BFF (Backend For Frontend). Le principe : un serveur GraphQL côté front-end qui agregre les données de plusieurs microservices REST en backend.

Le front-end React/Next.js interroge le BFF GraphQL avec des requêtes adaptées à chaque page (exactement les champs nécessaires, en une seule requête). Le BFF GraphQL appelle les microservices REST en backend (service utilisateurs, service commandes, service facturation) et assemble la réponse.

Cette architecture combine le meilleur des deux mondes : la flexibilité GraphQL pour le front-end, la simplicité et le caching REST pour les microservices. C'est l'architecture utilisée par Netflix, Shopify et GitHub.

En termes de coût, un BFF GraphQL ajoute 3 a 5 jours de développement initial par rapport à une API REST directe. Mais il economise 20 a 30 % du temps de développement front-end sur le long terme, grâce à la réduction des appels API et a la simplicité de la gestion des données côté client.

#Le verdict 2026

Le choix REST vs GraphQL n'est pas une question de supériorité technique — c'est une question d'adéquation au contexte. Les deux technologies coexistent dans la même architecture, et les meilleurs systèmes en production utilisent chacune la ou elle excelle.

Si vous démarrez un nouveau projet et hésitez, posez-vous une seule question : est-ce que plusieurs clients (web, mobile, partenaires) vont consommer mon API avec des besoins de données significativement différents ? Si oui, GraphQL merite l'investissement. Si non, REST vous emmene plus vite en production avec moins de complexité.

Chez Nehos, on ne choisit jamais par défaut. On analyse le contexte client — architecture existante, competences d'equipe, contraintes de performance, roadmap produit — et on recommande l'approche la plus rentable sur 3 ans. Pas la plus a la mode. Pas la plus flatteuse sur un CV. La plus adaptée au business.