API REST vs GraphQL : le bon choix en 2026

Le débat qui dure depuis dix ans

À chaque nouveau projet, la même question revient sur la table : REST ou GraphQL ? Et à chaque fois, quelqu'un dans l'équipe a une opinion très tranchée. C'est normal — les deux approches ont des philosophies différentes, des forces réelles, et des cas où elles deviennent franchement pénibles.

On va pas faire semblant que la réponse est universelle. Spoiler : c'est du ça dépend, mais un ça dépend documenté, avec des arguments solides. En 2026, le débat s'est affiné — et on va vous dire ce qu'on pense vraiment, nous qui construisons des APIs au quotidien avec Next.js et Prisma.

---

REST : la valeur sûre qui tient la route

REST (Representational State Transfer) c'est l'architecture dominante du web depuis des années. Le principe est simple : chaque ressource a une URL, et on interagit avec via les verbes HTTP standards.

GET    /api/projets          → liste tous les projets
GET    /api/projets/42       → récupère le projet #42
POST   /api/projets          → crée un nouveau projet
PUT    /api/projets/42       → met à jour le projet #42
DELETE /api/projets/42       → supprime le projet #42

Ce qui rend REST solide

• Stateless : chaque requête est indépendante, le serveur ne garde aucun état de session. Ça simplifie le scaling horizontal.
• Cacheable : les réponses GET se cachent naturellement (CDN, browser cache, Redis). Un Cache-Control bien configuré et votre API tient la charge.
• Universel : n'importe quel client — mobile, web, CLI, Postman — comprend HTTP. Zéro friction.
• Lisible : GET /api/clients/12/factures dit exactement ce qu'il fait. Pas besoin de documentation pour comprendre.

La force de REST c'est sa convention partagée. Tout le monde sait à quoi s'attendre. Les équipes changent, les conventions restent.

---

GraphQL : la puissance avec le bon prix

GraphQL c'est un langage de requête inventé par Facebook en 2015, puis open-sourcé. Plutôt qu'une collection d'endpoints, vous avez un seul point d'entrée (/graphql) et le client demande exactement ce qu'il veut.

# Le client demande uniquement les champs dont il a besoin
query {
  projet(id: "42") {
    titre
    categorie
    client {
      nom
      email
    }
    metriques {
      conversionRate
    }
  }
}

Le serveur répond précisément avec ces champs, pas plus, pas moins.

Le schéma : contrat entre client et serveur

GraphQL fonctionne autour d'un schéma typé qui décrit toutes les données disponibles :

type Projet {
  id: ID!
  titre: String!
  categorie: String!
  client: Client
  metriques: Metriques
}

type Query {
  projet(id: ID!): Projet
  projets: [Projet!]!
}

type Mutation {
  creerProjet(input: ProjetInput!): Projet!
}

Les resolvers font le lien entre le schéma et la vraie source de données (BDD, autre API, etc.). C'est là que Prisma entre en jeu si on travaille en TypeScript.

---

Le vrai problème : over-fetching et under-fetching

C'est le coeur du débat, et là GraphQL a une vraie réponse à un vrai problème.

Over-fetching avec REST

// GET /api/projets/42
// On veut juste le titre — mais on reçoit tout ça :
{
  "id": 42,
  "titre": "L'Île Vagabonde",
  "description": "Bar-restaurant flottant...",
  "categorie": "Web & Branding",
  "technos": ["Next.js", "Prisma", "Cloudinary"],
  "annee": 2024,
  "metriques": { ... },
  "images": ["url1", "url2", "url3"],
  "paragraphes": ["...", "...", "..."]
}

On transfère 10x plus de données que nécessaire. Sur mobile avec une connexion moyenne, ça se ressent.

Under-fetching avec REST

À l'inverse, pour afficher une facture avec les infos client + les lignes de détail, on doit souvent faire plusieurs requêtes successives :

GET /api/factures/99        → infos de la facture
GET /api/clients/12         → infos du client
GET /api/factures/99/lignes → lignes de détail

Trois aller-retours réseau pour une seule vue. GraphQL règle ça en une seule query.

---

Quand choisir REST

REST reste le bon choix dans la majorité des cas. Voici quand y aller sans hésiter :

• CRUD simple et prévisible : si vos ressources sont claires et que les besoins clients ne varient pas, REST est plus rapide à mettre en place et à maintenir.
• API publique : les développeurs tiers comprennent REST sans apprendre un nouveau langage de requête. La documentation est plus intuitive.
• Caching intensif : contenu statique ou semi-statique, forte charge en lecture — REST + CDN est imbattable.
• Équipe junior ou mixte : courbe d'apprentissage quasi nulle, conventions claires, moins de magie.
• Microservices : chaque service expose ses propres endpoints REST, c'est simple à monitorer et à debugger.

En résumé : si votre API ressemble à des ressources bien délimitées avec des consommateurs qui ont des besoins relativement uniformes, restez sur REST.

---

Quand GraphQL devient intéressant

GraphQL brille vraiment dans des contextes spécifiques. Le utiliser partout parce que c'est "moderne" c'est une erreur.

• Relations de données complexes : tableaux de bord, applications avec des entités fortement liées (projet → client → factures → lignes). Une seule query remplace N appels REST.
• Multiple frontends : une appli mobile qui a besoin de peu de données, une webapp qui en a besoin de beaucoup, un dashboard avec encore autre chose — GraphQL laisse chaque client demander exactement sa slice.
• Rapid prototyping de features : les équipes frontend peuvent avancer sans attendre que le backend crée un nouvel endpoint.
• Gros systèmes avec des équipes différentes : le schéma sert de contrat partagé et auto-documenté (GraphQL Playground, introspection).

Les pièges à éviter

• N+1 queries : sans DataLoader, GraphQL peut exploser votre BDD avec des requêtes en cascade.
• Caching : beaucoup plus complexe qu'avec REST (les requêtes POST ne se cachent pas nativement).
• Complexité opérationnelle : requêtes malformées, profondeur infinie, sécurité par field — il faut des guards.

---

Tableau comparatif

Critère	REST	GraphQL
Courbe d'apprentissage	Faible	Modérée
Caching	Natif (HTTP)	Complexe
Over/Under-fetching	Problème courant	Résolu
Typage	Manuel (OpenAPI)	Natif (schéma)
Flexibilité client	Limitée	Totale
Debugging	Simple	Plus complexe
API publique	Idéal	Possible mais lourd
Relations complexes	Plusieurs requêtes	Une seule query
Sécurité	Intuitive	Requiert attention
Tooling 2026	Mature	Mature

---

Et tRPC alors ?

Impossible d'évoquer ce débat en 2026 sans mentionner tRPC. Si vous travaillez en TypeScript full-stack (Next.js + backend TS), tRPC est une troisième voie très sérieuse.

Le principe : vos procédures serveur sont des fonctions TypeScript typées, et le client appelle ces fonctions directement — sans génération de code, sans schéma à écrire. Le type safety se propage automatiquement de bout en bout.

// Serveur (tRPC router)
const appRouter = router({
  projet: router({
    getById: publicProcedure
      .input(z.object({ id: z.string() }))
      .query(({ input }) => prisma.project.findUnique({ where: { id: input.id } })),
  }),
})

// Client — TypeScript sait exactement ce qu'il reçoit
const projet = await trpc.projet.getById.query({ id: "42" })

tRPC est parfait pour les applications monorepo ou les projets Next.js où le frontend et le backend vivent dans le même repo. Pas de REST, pas de GraphQL — juste des fonctions TypeScript qui s'appellent entre elles avec une sécurité de type totale.

L'inconvénient : ça ne sort pas du contexte TypeScript. Si vous avez des consommateurs externes (application mobile tierce, partenaires), tRPC n'est pas adapté.

---

Ce qu'on utilise chez Var Studio

Soyons directs : on fait du REST-like via les Route Handlers de Next.js, et on assume.

Nos APIs (/api/admin/projets, /api/admin/clients, etc.) suivent les conventions REST — verbes HTTP, ressources nommées, réponses JSON standardisées. Côté BDD, Prisma fait le travail lourd avec un client typé qui génère exactement les requêtes dont on a besoin.

Pourquoi pas GraphQL ? Parce que nos projets ont typiquement un seul frontend (la webapp Next.js), des ressources bien délimitées, et des besoins relativement prévisibles. La complexité supplémentaire de GraphQL ne se justifie pas pour nos cas d'usage — et le caching natif HTTP nous arrange bien pour les pages publiques.

tRPC nous intéresse pour certains projets futurs, notamment dès qu'on a du TypeScript des deux côtés et pas besoin d'API publique.

Notre règle de décision, simple :

• Projet classique avec un frontend → REST (Next.js Route Handlers + Prisma)
• Plusieurs frontends ou mobile avec besoins différents → GraphQL (Apollo ou Pothos)
• Monorepo TypeScript full-stack → tRPC
• API publique consommée par des tiers → REST + OpenAPI spec

---

Conclusion

En 2026, REST n'est pas mort, GraphQL n'est pas universellement supérieur, et tRPC mérite vraiment votre attention si vous êtes dans l'écosystème TypeScript.

Le bon choix, c'est celui qui correspond à vos contraintes réelles : taille de l'équipe, nombre de consommateurs, complexité des données, besoins de caching. Choisir GraphQL parce que c'est dans le CV ou REST parce que "c'est ce qu'on a toujours fait" — c'est exactement le genre de décision qui vous coûtera du temps dans six mois.

Prenez deux heures pour poser vos contraintes sur papier. La technologie suivra d'elle-même.