GraphQL : le moteur de requêtes qui libère votre front-end e-commerce
Définition
GraphQL est un langage de requête pour API et un environnement d’exécution côté serveur, créé par Meta (Facebook) en 2012 puis open-sourcé en 2015. Contrairement à une API REST classique où chaque endpoint renvoie une structure de données figée, GraphQL permet au client — votre front-end, votre app mobile ou votre middleware — de demander exactement les champs dont il a besoin, ni plus, ni moins.
Dans une architecture e-commerce headless (Shopify Hydrogen, Commercetools, Saleor, Medusa, etc.), GraphQL joue le rôle de contrat unique entre votre back-end (PIM, ERP, moteur de catalogue) et vos canaux de vente (site DTC, app, marketplace, borne retail). Une seule requête peut récupérer un produit, ses variantes, son stock, ses avis, et les promotions associées — là où REST exigerait 4 à 6 appels distincts.
Analogie
Imaginez un restaurant.
- REST, c’est le menu à formule fixe : « Plat + entrée + dessert, point barre ». Si vous voulez juste la sauce, on vous apporte l’assiette entière. Si vous voulez deux desserts, il faut commander deux menus.
- GraphQL, c’est le chef qui vous tend une feuille blanche : vous listez précisément les ingrédients, les quantités et l’ordre de service. Le serveur prépare exactement votre assiette, en une seule fois.
Pour un site DTC, cela signifie : votre page produit ne télécharge plus 380 Ko de JSON inutile (attributs SEO, champs admin, historiques) pour afficher 12 champs. Elle demande 12 champs. Résultat : LCP plus rapide, bande passante économisée, expérience mobile fluide.
Formule
GraphQL ne se résout pas par une équation unique, mais son coût de requête se modélise ainsi :
Coût total = Σ (champs résolus × profondeur) + coût des resolvers
Et le taux d’efficacité payload :
Efficacité = (poids des données utiles / poids total de la réponse) × 100
Exemple concret : une requête REST renvoie 48 Ko pour 9 Ko utiles → efficacité = 18,75 %. La même requête GraphQL renvoie 9,4 Ko pour 9 Ko utiles → efficacité = 95,7 %. Sur 100 000 sessions/mois, l’économie dépasse 3,8 Go de transfert mobile.
Tableau comparatif : REST vs GraphQL en DTC
| Critère | REST | GraphQL | Impact DTC |
|---|---|---|---|
| Nombre d’appels pour une PDP | 4 à 7 | 1 | -70 % de latence perçue |
| Taille moyenne réponse | 42 Ko | 11 Ko | -74 % de data mobile |
| Versioning API | /v1, /v2… | Évolution par champs | Déploiements front sans casser le back |
| Over-fetching | Fréquent | Quasi nul | Meilleur TTFB |
| Under-fetching | Fréquent (waterfalls) | Résolu par requête unique | Moins de spinners |
| Cache CDN | Simple (URL) | Complexe (POST + persisted queries) | Nécessite Apollo/URQL + edge cache |
| Courbe d’apprentissage | Faible | Moyenne à élevée | +2 à 4 semaines pour une équipe front |
Application en e-commerce DTC
1. Page produit headless — Une requête product(id:) récupère titre, prix, 6 variantes, stock temps réel, 3 avis vérifiés et le badge « livraison offerte dès 49 € ». Un seul aller-retour serveur.
2. Panier multi-canal — Le même schéma GraphQL alimente le site web, l’app iOS et le chatbot WhatsApp. Le panier reste synchronisé sans duplication de logique.
3. Personnalisation — Requête conditionnelle : si le client est identifié VIP, on ajoute le champ earlyAccess et loyaltyPoints. Sinon, on ne le demande pas. Le payload s’adapte au segment.
4. Checkout Shopify — L’API Storefront GraphQL expose cartCreate, cartLinesAdd, cartDiscountCodesUpdate. Vous orchestrez le tunnel sans toucher au thème Liquid.
5. Reporting merchandising — Une requête agrégée interroge 12 000 SKU, filtre par marge > 40 % et stock < 5, et renvoie les 50 produits à pousser en home page. REST aurait nécessité une pagination lourde.
Common misconceptions (idées fausses)
- « GraphQL remplace la base de données. » Faux. GraphQL est une couche d’API. Derrière, vous avez toujours PostgreSQL, Algolia, un PIM ou un ERP.
- « GraphQL est toujours plus rapide que REST. » Faux. Une requête mal écrite (profondeur 8, N+1 resolvers) peut être plus lente qu’un REST optimisé. La performance vient du DataLoader et de la persisted query.
- « GraphQL, c’est que pour les gros sites. » Faux. Un DTC à 500 SKU sur Medusa ou Saleor bénéficie déjà du gain de payload et de la flexibilité front.
- « Pas besoin de cache avec GraphQL. » Faux. Sans cache CDN ni @cacheControl, vous perdez 30 à 50 % de vos gains de performance.
- « GraphQL est un standard officiel. » Nuance. C’est une spécification open source, pas un organisme type W3C. L’écosystème (Apollo, GraphQL Yoga, Hasura) est mature mais fragmenté.
Termes liés
- Headless commerce — Architecture où le front est découplé du back, souvent via GraphQL.
- Storefront API — API GraphQL exposée par Shopify, BigCommerce ou Commercetools pour le front.
- Resolver — Fonction qui retourne la donnée d’un champ GraphQL.
- DataLoader — Utilitaire de batch et cache pour éviter les requêtes N+1.
- Persisted Query — Requête GraphQL hashée et stockée côté serveur, pour alléger le réseau et sécuriser l’API.
- Schema Stitching / Federation — Agrégation de plusieurs services GraphQL en un seul point d’entrée.
- REST — Architecture API classique, à comparer selon le use case.
- Apollo Client / URQL — Bibliothèques front pour consommer GraphQL avec cache normalisé.
En résumé pour votre DTC : GraphQL n’est pas une mode de dev. C’est un levier de conversion. Moins de data téléchargée = mobile plus rapide = panier moyen plus élevé. Sur un site à 1,2 M de sessions/an, passer de REST à GraphQL sur les pages produit et panier représente souvent +4 à 9 % de taux de conversion et -35 % de coûts d’infrastructure API. À condition de maîtriser les resolvers, le cache et la sécurité des requêtes.
