En 2018, GraphQL allait remplacer REST. En 2026, REST est toujours dominant, GraphQL a trouvé sa niche, et un troisième outsider monte : tRPC. Comment choisir en 2026 ? Pas selon la mode Twitter, mais selon votre projet réel, votre équipe et vos clients. Voici un comparatif pragmatique.
L'état du marché en 2026
REST domine toujours : environ 70 % des nouvelles API en 2026 sont en REST. GraphQL occupe 20 % (apps mobiles complexes, frontends riches, BFFs). gRPC 5 % (microservices internes). tRPC 5 % (apps full-TypeScript). Le « GraphQL va tout remplacer » de 2018 ne s'est jamais réalisé.
Pourquoi REST a survécu
Cinq raisons. 1. Compatible avec tous les outils du web (cache HTTP, CDN, tests, monitoring). 2. Compris par tous les développeurs sans formation. 3. Idéal pour des ressources CRUD avec OpenAPI 3.1. 4. Pas de complexité serveur. 5. Documentation interactive Swagger UI ou Scalar familière à tous.
Pourquoi GraphQL n'a pas tout pris
Trois raisons. 1. Complexité serveur (caching, N+1, autorisation par champ, DataLoader, fédération). 2. Outillage moins mature (Apollo Server v5 a tout cassé, Pothos est complexe). 3. Surenginiering pour 80 % des cas où une API REST fait largement le job.
Quand choisir REST
Sept cas où REST est meilleur. 1. API publique pour intégrateurs externes. 2. CRUD simple sur des ressources. 3. Vous voulez bénéficier du cache HTTP et du CDN. 4. Votre équipe n'a pas de spécialiste GraphQL. 5. Votre client est en TypeScript ou autre, mais le serveur est en Python, Go, PHP. 6. Vous voulez minimiser la complexité serveur. 7. Vous voulez du monitoring standard.
Quand choisir GraphQL
Quatre cas où GraphQL brille. 1. Frontend complexe avec beaucoup de données interdépendantes (tableau de bord, app mobile riche). 2. Multiples consommateurs avec des besoins différents (web + mobile + tablette). 3. Vous voulez minimiser le over-fetching et under-fetching. 4. Vous avez une équipe expérimentée et un budget pour gérer la complexité.
Le challenger 2026 : tRPC
tRPC est conçu pour les projets full-TypeScript (Next.js + Node.js). Il offre une expérience développeur incroyable : appelez les fonctions backend depuis le frontend comme des fonctions normales, avec autocomplétion et type-safety end-to-end. Idéal pour : apps internes ou monolithes Next.js. Limites : ne marche pas si votre frontend ou backend n'est pas en TypeScript.
OpenAPI 3.1 : la spécification REST moderne
OpenAPI (ex-Swagger) est devenu obligatoire pour toute API REST sérieuse en 2026. Il vous donne : 1. Documentation interactive (Swagger UI, Redoc, Scalar). 2. Génération automatique de clients (TypeScript, Python, Go, etc.). 3. Tests de contrat automatiques. 4. Validation des requêtes à la volée. C'est ce qui rend REST aussi puissant que GraphQL en 2026, sans la complexité.
Performance : qui gagne ?
REST est plus rapide sur les requêtes simples (un seul endpoint, un seul aller-retour). GraphQL est plus rapide sur les requêtes complexes qui nécessitent plusieurs ressources interdépendantes (un seul aller-retour vs 5-10 en REST). Pour des scénarios mixtes, le différentiel est minime.
Sécurité : les pièges spécifiques
GraphQL a deux pièges connus. 1. Query depth attacks : un attaquant envoie une requête imbriquée infinie qui plante votre serveur. Solution : limiter la profondeur. 2. Field-level authorization : chaque champ doit vérifier les droits, sinon fuite de données. C'est pourquoi GraphQL demande plus de discipline serveur que REST.
Migration : passer de REST à GraphQL
Si vous avez déjà une API REST en production et que vous envisagez GraphQL, préférez le pattern GraphQL gateway : un serveur GraphQL devant votre API REST existante, qui agrège les données. Vous bénéficiez du meilleur des deux mondes sans tout réécrire. Outils : Apollo Federation, GraphQL Mesh.
Conclusion
En 2026, REST reste le bon choix pour 70 % des projets. GraphQL est excellent pour des cas spécifiques (frontends complexes, multi-consommateurs). tRPC brille pour les stacks full-TypeScript. Choisissez selon votre projet réel, pas selon la mode. Et surtout, documentez votre API correctement (OpenAPI ou GraphQL schema) : c'est ce qui fait toute la différence en production.