Le débat REST vs GraphQL est l’un des plus polarisés du dev web. Les fans de GraphQL parlent de REST comme d’un truc dépassé. Les défenseurs du REST trouvent GraphQL inutilement complexe. Les deux exagèrent.
Voilà comment je tranche en 2026, sur les projets que je prends.
Ce que fait chaque approche
REST, c’est le standard historique. Vous avez des endpoints (URLs) qui correspondent à des ressources : /users, /products, /orders. Chaque endpoint a des verbes (GET, POST, PUT, DELETE) qui correspondent à des actions. Le serveur renvoie ce qu’il décide ; le client prend ce qu’il reçoit.
GraphQL, c’est plus récent (initialement créé par Facebook en 2015). Vous avez un seul endpoint, mais vous décrivez précisément, dans la requête, ce que vous voulez recevoir. Le client demande exactement ce dont il a besoin. Pas plus, pas moins.
Les deux marchent. Les deux sont mûrs. Le choix dépend du projet.
Quand REST est meilleur
REST est mon choix par défaut sur 70 % des projets que je prends. Plusieurs raisons.
Sur des cas simples (une API qui sert quelques tables, des opérations CRUD basiques), REST est plus rapide à mettre en place, plus facile à comprendre pour les développeurs juniors, plus simple à debugger.
Pour des APIs publiques destinées à être consommées par des tiers, REST est plus universel : plus d’outils, plus de documentation, plus de gens qui le maîtrisent. Si vous publiez une API pour des partenaires, REST diminue la friction.
Pour des projets WordPress (qui propose nativement une API REST) ou Supabase (qui propose une API REST automatique sur PostgreSQL), tout est déjà prêt. Pas besoin de réinventer.
Le caching est plus naturel en REST : chaque endpoint peut être cachable indépendamment, par URL. C’est natif au protocole HTTP. En GraphQL, c’est plus compliqué.
Quand GraphQL est meilleur
GraphQL devient pertinent quand le projet a certaines caractéristiques précises.
Vous avez plusieurs clients différents (web, mobile iOS, mobile Android, watch app) qui ont besoin de données différentes. Avec REST, soit vous faites plusieurs versions de l’API, soit vous renvoyez plus de données que nécessaire. Avec GraphQL, chaque client demande ce qu’il veut.
Vos données ont beaucoup de relations imbriquées. Une requête GraphQL peut récupérer en une fois l’utilisateur, ses commandes, les produits dans chaque commande, les avis sur chaque produit. En REST, ce serait plusieurs requêtes en cascade.
Votre application est très dynamique côté client (un dashboard React qui affiche des données très variées sur des composants nombreux). GraphQL réduit la latence en fusionnant les requêtes.
J’ai utilisé GraphQL sur un SaaS B2B en 2024, et c’était clairement le bon choix. L’app web et l’app mobile partageaient le même backend, avec des besoins de données différents selon les écrans. GraphQL nous a évité de maintenir deux séries d’endpoints REST différents.
Les inconvénients de GraphQL qu’on oublie
GraphQL n’est pas magique. Il introduit des problèmes que REST n’a pas.
Le caching est complexe : impossible d’utiliser le cache HTTP standard. Il faut implémenter Apollo Client côté front, ou des outils spécifiques côté back. C’est faisable, mais ça ajoute du code.
Le risque de surcharge serveur est réel. Un client malveillant peut écrire une requête GraphQL très imbriquée qui tue votre serveur. Il faut mettre en place des limites (depth limiting, complexity analysis), ce qui complexifie l’API.
La courbe d’apprentissage est plus raide. Un dev junior REST est productif en quelques jours. Un dev junior GraphQL met deux à trois semaines à comprendre proprement le découpage queries / mutations / fragments / resolvers.
Pour des cas simples, GraphQL est de l’over-engineering. Vous ajoutez de la complexité pour des bénéfices nuls.
Mon arbre de décision
Trois questions, dans cet ordre.
Combien de clients différents votre API doit-elle servir avec des besoins de données différents ?
Si la réponse est un seul (votre site web), REST suffit. Si la réponse est plus de deux (web, mobile, watch, partenaires), GraphQL devient pertinent.
Vos données sont-elles fortement relationnelles avec besoin fréquent de récupérer plusieurs niveaux d’imbrication ?
Si oui, GraphQL apporte un vrai gain. Si non, REST suffit.
Avez-vous une équipe qui maîtrise déjà GraphQL ?
Si oui, choisissez selon les critères techniques. Si non, REST reste plus accessible et moins risqué pour la maintenance future.
En 2026, l’usage réel
Sur les projets que je prends à Lille et alentour : 70 % en REST. La grande majorité des sites WordPress, des e-commerces Shopify ou WooCommerce, des MVP SaaS, des outils internes. REST suffit largement et est plus simple à transmettre.
20 % en GraphQL. Projets multi-clients, gros SaaS, applications très dynamiques avec beaucoup de relations. Apollo en frontend, Hasura ou un schema custom en backend.
10 % en mode hybride. Une partie REST pour les interactions simples, une partie GraphQL pour les écrans qui en bénéficient le plus. Le projet décide, pas le dogme.
Le piège à éviter
Choisir GraphQL parce que c’est plus moderne. Si votre projet n’a pas les caractéristiques qui justifient GraphQL, vous payez la complexité sans en récolter les bénéfices.
Choisir REST parce que GraphQL c’est compliqué. Si votre projet a vraiment besoin de GraphQL (multi-clients, données très imbriquées), refuser cette technologie vous coûtera plus cher en maintenance future.
Le bon choix, c’est celui qui correspond à votre projet, pas celui qui sonne mieux dans une conférence.