GraphQL vs REST : quelle API choisir pour un e-commerce ?

Quand vous concevez ou migrez une plateforme e-commerce, le choix de l'architecture API conditionne trois variables critiques : la vitesse de développement, les performances en production et la capacité de votre frontend à composer des vues riches sans multiplier les appels réseau. REST et GraphQL répondent à ce besoin de façons radicalement différentes. Voici comment les comparer et décider selon votre contexte technique.

REST (Representational State Transfer) est un style architectural formalisé en 2000, fondé sur le protocole HTTP et ses verbes standard — GET pour lire, POST pour créer, PUT et PATCH pour modifier, DELETE pour supprimer. Chaque ressource est identifiée par une URL distincte : /products/42, /orders, /customers/17/addresses.

Chaque endpoint renvoie une représentation complète de la ressource, avec ses propres codes de statut HTTP (200, 201, 404, 422). Le caching HTTP natif — ETags, Cache-Control — fonctionne directement avec les CDN et les reverse proxies. La quasi-totalité des API tierces (Stripe, transporteurs, ERP comme Odoo ou Sage) exposent du REST, ce qui simplifie les intégrations sans couche d'adaptation supplémentaire.

La limite principale est le sur-fetching : une requête sur /products/42 retourne l'intégralité du document produit même si votre storefront mobile n'a besoin que du titre, du prix et d'une image. Son inverse, le sous-fetching, oblige à enchaîner plusieurs appels successifs — panier, produits, promotions — pour afficher une seule page, ce qui pénalise les performances mobiles et augmente la latence perçue.

GraphQL est un langage de requête et un runtime créés par Facebook en 2012, mis en open source en 2015, maintenu depuis par la GraphQL Foundation. Il n'expose qu'un seul endpoint — typiquement /graphql — et laisse le client décrire exactement les champs dont il a besoin, au lieu de recevoir un document entier.

Cette flexibilité élimine le sur-fetching : une seule requête peut agréger des données de plusieurs entités (produit, stock, avis) en ne retournant que les champs demandés. GraphQL dispose également d'un système de typage fort via son schéma SDL (Schema Definition Language), d'une introspection native — les outils de développement lisent le schéma en direct — et de Subscriptions pour les flux temps réel via WebSocket.

Les contreparties : le caching HTTP standard ne fonctionne plus (toutes les requêtes passent par POST), la gestion des erreurs est moins uniforme qu'avec les codes de statut HTTP, et des vecteurs d'attaque spécifiques apparaissent — requêtes imbriquées trop profondes, introspection exposée en production. La courbe d'apprentissage est plus longue pour des équipes habituées au REST.

• Intégrations tierces nombreuses : Stripe, prestataires logistiques, ERP comme Odoo ou Sage imposent leur propre format REST. Un backend REST s'y connecte directement, sans couche d'adaptation.
• API publique pour partenaires : un contrat REST versionné (/v1/, /v2/) est plus facile à documenter et à maintenir pour des partenaires externes ou des places de marché.
• Architecture microservices existante : si vos services internes exposent déjà du REST, ajouter GraphQL représente un coût de migration élevé sans bénéfice immédiat sur les KPIs.
• Contraintes de cache fortes : les CDN et reverse proxies gèrent nativement le cache HTTP REST, ce qui est particulièrement utile pour un catalogue produit à fort trafic avec peu de personnalisation par utilisateur.

• Storefront headless multi-support : une même API sert le site Next.js, l'application mobile et une borne en magasin, chacun ne récupérant que les champs utiles. Pour approfondir ce pattern, notre article sur l'architecture headless commerce détaille la combinaison avec la tokenization.
• Catalogue produit riche et variable : des produits configurables avec des dizaines d'attributs optionnels génèrent des transferts réseau inutiles avec REST. GraphQL ne renvoie que ce qui est réellement affiché à l'écran.
• Itération frontend rapide : les équipes frontend modifient leurs queries sans attendre de nouveaux endpoints backend. Combiné avec l'optimisation JavaScript et CSS, cela réduit le temps de chargement perçu.
• Flux temps réel : suivi de commande, stock en direct, notifications de livraison — les Subscriptions GraphQL sont conçues nativement pour ces cas d'usage, là où REST impose des solutions custom (polling, SSE).

Les deux approches ne s'excluent pas. Une architecture courante consiste à exposer une API GraphQL comme couche d'orchestration, qui agrège en interne des microservices REST existants. Le client ne voit qu'un seul endpoint GraphQL, mais le backend délègue chaque résolveur vers les services REST spécialisés.

Cette approche est particulièrement adaptée aux refontes progressives : vous conservez vos services métier REST (commandes, stock, CRM) et ajoutez une gateway GraphQL — Apollo Federation ou une implémentation custom en Node.js — pour les nouveaux storefronts. Elle permet d'intégrer les données de plateformes comme WooCommerce ou PrestaShop via leur API REST, tout en servant un frontend Next.js avec une seule requête GraphQL composée.

Point de vigilance : les resolvers doivent être optimisés avec du batching (pattern DataLoader) pour éviter le problème N+1 — une requête GraphQL peut sinon déclencher N appels REST en cascade et dégrader significativement les performances.

Quelle que soit l'architecture choisie, certaines pratiques de production sont non négociables.

Pour REST :

• Versionnez votre API dès le départ pour anticiper les évolutions sans casser les intégrations existantes.
• Protégez les endpoints avec OAuth 2.0 ou des jetons à périmètre limité (scopes) — un jeton de lecture ne doit jamais permettre d'écriture.
• Configurez un rate-limiting par clé API pour absorber les pics de charge sans dégrader la disponibilité globale.

Pour GraphQL :

• Désactivez l'introspection en production ou restreignez-la aux adresses IP internes.
• Limitez la profondeur des requêtes imbriquées (depth limiting) et leur complexité calculée pour contrer les requêtes abusives.
• Utilisez des persisted queries pour les clients connus : les requêtes sont pré-enregistrées côté serveur et le client n'envoie qu'un identifiant, ce qui réduit la surface d'attaque.

Dans les deux cas, surveillez le p95 de latence, le taux d'erreur et la taille des payloads. Pour GraphQL, instrumentez aussi le temps de résolution par champ pour identifier les resolvers lents. Notre guide sur le monitoring d'infrastructure e-commerce détaille les métriques à mettre en place.

Si vous démarrez un nouveau projet e-commerce, la tendance actuelle est à l'architecture hybride : REST pour les intégrations tierces et les services internes stables, GraphQL pour les storefronts publics. La clé est de décider tôt — changer d'architecture API en cours de route entraîne un refactoring coûteux et une migration des clients existants.

Pour approfondir votre architecture API et aligner votre stack avec votre roadmap technique, découvrez les expertises Webntricks en développement et architecture. Pour un premier échange sur votre projet, notre page de contact vous permet de nous soumettre votre contexte directement.