GraphQL est une façon pour une application de demander des données à un serveur en décrivant précisément ce qu'elle veut. Au lieu d'appeler plusieurs adresses et de recevoir des blocs de données entiers, l'application envoie une seule requête qui liste les champs nécessaires, et le serveur renvoie exactement cette forme, rien de plus.

Facebook a créé GraphQL en 2012 pour ses applications mobiles et l'a rendu public en 2015. Aujourd'hui, de nombreuses plateformes e-commerce et installations headless le proposent. Si une agence vous propose une boutique sur mesure ou une application mobile, ou si un outil met en avant son « API GraphQL », cette page vous explique ce que cela implique pour votre budget et vos choix.

Qu'est-ce que GraphQL ?

GraphQL est un langage de requête pour les API et un ensemble de règles pour le serveur qui y répond. Trois notions suffisent pour comprendre :

  • Schéma : une description typée de tout ce que l'API propose. Il indique qu'un produit a un titre, un prix, des variantes et des images, qu'une commande a des lignes et un client, et comment tout cela est relié.
  • Requête (query) : une demande de lecture. Le client écrit les champs qu'il veut, imbriqués aussi profondément que nécessaire. Par exemple : « les 10 dernières commandes, avec le total, le prénom du client et le titre du produit de chaque ligne ».
  • Mutation : une demande de modification, comme créer un panier, ajouter une ligne ou appliquer un code promo.

Tout passe en général par une seule adresse web, souvent terminée par /graphql. La réponse arrive en JSON et reprend exactement la forme de la requête.

GraphQL n'est pas une base de données. Le mot « graph » vient du fait qu'il voit les données comme des objets reliés, mais il se place devant le stockage du serveur, quel qu'il soit. Il ne remplace ni HTTPS ni la sécurité, et n'est lié à aucun langage. Ce n'est pas non plus REST. Avec REST, le serveur décide de ce que renvoie chaque adresse. Avec GraphQL, c'est le client qui choisit les champs qu'il reçoit.

Autres mots que vous entendrez : subscription, une fonction GraphQL pour recevoir des mises à jour en direct ; resolver, le code serveur qui va chercher chaque champ ; introspection, la possibilité de demander à l'API de décrire son propre schéma.

Pourquoi c'est important

GraphQL compte surtout quand quelqu'un construit une interface sur mesure, comme une vitrine headless ou une application mobile, au-dessus d'un back-office e-commerce.

Voici le gain concret. Imaginez une page produit qui affiche le produit, ses 6 variantes avec leur stock, 3 avis et 4 produits associés. Avec une API REST classique, l'interface peut faire 4 ou 5 appels et recevoir bien plus de données qu'elle n'en affiche. Sur un téléphone avec une connexion faible, chaque aller-retour supplémentaire ajoute 200 à 400 millisecondes. Avec GraphQL, une seule requête récupère exactement ces données. Gagner une demi-seconde sur une page produit mobile compte, car une page lente convertit moins.

GraphQL accélère aussi le développement. Les développeurs front peuvent changer ce qu'affiche un écran sans attendre qu'un développeur back crée un nouvel endpoint. Sur un projet sur mesure où un développeur coûte 600 € par jour, éviter 5 jours d'allers-retours sur la durée du projet fait économiser 3 000 €.

Les contreparties sont réelles. GraphQL se met plus difficilement en cache que REST, ce qui peut augmenter les coûts serveur à fort trafic. Des requêtes mal conçues peuvent demander d'énormes volumes de données d'un coup, d'où les limites de coût imposées par les fournisseurs. Et moins de freelances maîtrisent GraphQL que REST, ce qui peut faire monter les tarifs. Pour une intégration simple, comme envoyer les commandes payées vers un logiciel comptable, GraphQL apporte peu par rapport à REST.

Comment ça marche

Un échange GraphQL suit ces étapes :

  • Le schéma est publié. Le serveur décrit ses types et ses champs. Les développeurs l'explorent avec des outils qui lisent le schéma et suggèrent les champs pendant la saisie.
  • Le client écrit une requête ou une mutation. Il liste exactement les champs nécessaires, y compris imbriqués, comme un panier avec ses lignes, la variante de chaque ligne et le prix de chaque variante.
  • La demande part vers une adresse unique. En général un POST sur /graphql, avec un jeton d'accès dans les en-têtes.
  • Le serveur valide la requête par rapport au schéma. Les champs inconnus ou les mauvais types sont rejetés avant tout travail.
  • Le serveur évalue le coût. Beaucoup de fournisseurs notent chaque requête selon la quantité de données touchées et refusent celles qui dépassent une limite.
  • Les resolvers vont chercher les données. Chaque champ est rempli depuis la base de données ou d'autres services.
  • La réponse reprend la forme de la requête. Le client reçoit du JSON exactement dans la forme demandée, avec une liste d'erreurs si une partie a échoué.

Comme le schéma est fortement typé, des outils génèrent automatiquement documentation et code, ce qui s'accorde bien avec la conception API-first.

Repères et exemples

Quelques repères :

  • Appels économisés : un écran qui demande 4 à 6 appels REST peut souvent être servi par une seule requête GraphQL.
  • Poids des réponses : ne renvoyer que les champs utiles peut diviser par deux ou plus la taille des réponses sur les pages riches en données.
  • Limites de coût : les fournisseurs e-commerce plafonnent souvent la complexité des requêtes, par requête et par seconde. Récupérer 250 produits avec toutes leurs variantes et images en une fois dépasse souvent la limite, d'où une récupération par pages.
  • Coût de développement : une boutique headless sur mesure reposant sur un back-office GraphQL démarre souvent entre 15 000 et 40 000 €, contre une fraction de ce montant pour une boutique basée sur un thème.

Situations courantes :

  • Une marque de mode avec une application mobile récupère produit, tailles et stock en une requête par écran.
  • Une agence construit une vitrine sur mesure sur l'API GraphQL d'un back-office e-commerce pour obtenir un design unique.
  • Une petite boutique sur un thème standard ne touche jamais à GraphQL, même si la plateforme l'utilise en interne.
  • Une créatrice qui connecte un outil d'emailing passe par une intégration REST, parce que c'est ce que les deux outils proposent.

Erreurs fréquentes

  • Choisir GraphQL parce que c'est moderne. Pour une intégration unique, REST est souvent plus simple et moins cher à maintenir.
  • Passer en headless sans le budget. Une vitrine GraphQL sur mesure vous fait payer chaque fonctionnalité qu'un thème offrait gratuitement, y compris la finition du checkout et les bases du SEO.
  • Ignorer le coût des requêtes. Les requêtes qui récupèrent tout d'un coup sont ralenties ou rejetées sous la charge.
  • Oublier le cache. Sans stratégie de cache, une interface GraphQL peut se révéler plus lente et plus chère que prévu en pic de trafic.
  • Laisser l'introspection ouverte sur une API privée. N'importe qui peut alors cartographier tout votre schéma. Les API e-commerce publiques l'exposent volontairement, les API privées ne devraient pas.

Bonnes pratiques

  • Adaptez l'outil au besoin. GraphQL pour des interfaces riches et sur mesure, REST ou des intégrations toutes faites pour de simples synchronisations.
  • Demandez à votre développeur de vous montrer les requêtes. Il doit pouvoir expliquer en mots simples ce que récupère chaque écran et pourquoi.
  • Prévoyez la maintenance. Une vitrine headless demande des mises à jour quand le schéma du back-office évolue, souvent quelques jours par trimestre.
  • Paginez les grandes listes. Récupérez produits, commandes ou clients par pages pour rester sous les limites.
  • Mesurez la vitesse sur de vrais téléphones. L'intérêt de GraphQL est d'accélérer les écrans : vérifiez les temps de chargement sur un téléphone milieu de gamme en 4G.
  • Restez propriétaire du code. Vérifiez dans le contrat que le code de la vitrine et ses requêtes vous appartiennent.

Dans Roctify

Roctify est un SaaS et une plateforme no-code : vous n'écrivez aucune requête pour vendre. Votre boutique en ligne et votre page lien en bio sont hébergées pour vous, optimisées pour les navigateurs mobiles et servies en HTTPS avec un certificat SSL gratuit. Elles lisent un catalogue partagé de produits, variantes, stock, clients et commandes, ce qui vous donne les pages rapides et cohérentes qu'une interface GraphQL sur mesure cherche à obtenir, sans projet à 20 000 €.

Roctify ne propose pas d'API GraphQL aujourd'hui. Si votre activité a besoin d'une connexion sur mesure avec un autre système, les intégrations sur mesure se discutent dans le cadre du plan Enterprise.

FAQ

GraphQL est-il plus rapide que REST ?

Pas en soi. GraphQL peut accélérer les écrans en réduisant le nombre de requêtes et la quantité de données envoyées. Une API REST bien conçue avec un bon cache peut être tout aussi rapide pour des tâches simples.

Ai-je besoin de GraphQL pour ma boutique en ligne ?

Presque certainement pas si vous utilisez une boutique standard. GraphQL devient pertinent quand vous commandez une interface headless sur mesure ou une application mobile. Même dans ce cas, c'est un choix technique pour votre développeur, pas une fonctionnalité à rechercher.

GraphQL est-il une base de données ?

Non. GraphQL est un langage de requête pour les API. Il se place devant les bases de données et d'autres services et définit la façon dont les clients demandent les données. Les données elles-mêmes peuvent se trouver n'importe où.