Vous avez déjà entendu un développeur annoncer « on passe à GraphQL » avec ce petit air de celui qui sait ? Derrière le buzzword, il y a pourtant une idée toute simple et une vraie réponse à un problème que vous avez forcément croisé en travaillant avec des API. Voyons ensemble ce que c’est, comment ça marche, ce qui le distingue de REST, et, parce que c’est sans doute ce qui vous intéresse le plus, ce que ça vaut quand on est freelance.
Qu’est-ce que GraphQL ?
Commençons par le début. GraphQL est un langage de requête pour API (GraphQL query language), doublé d’un moteur d’exécution côté serveur (API server-side runtime). Traduction : le client décrit précisément les données qu’il veut, et le serveur lui renvoie exactement ça. Ni plus, ni moins.
Petit retour en arrière. GraphQL naît chez Facebook en 2012, dans la douleur. Les apps mobiles rament, REST n’aide pas, il faut trouver autre chose. La solution maison devient si convaincante qu’ils l’ouvrent au monde en 2015.
Dix ans plus tard, en 2025, GraphQL a soufflé ses dix bougies et publié une nouvelle édition de sa spécification, sous la houlette de la GraphQL Foundation (rattachée à la Linux Foundation).
Un malentendu à dissiper tout de suite : GraphQL n’est ni une base de données, ni un langage de programmation. Il se moque complètement de votre stack. Vous pouvez l’implémenter en JavaScript, Python, Go ou Java, au-dessus d’une base SQL, d’une base NoSQL ou d’une poignée de microservices.
Cette indifférence à ce qu’il y a en dessous, c’est l’une de ses grandes forces.
Le problème que GraphQL cherche à résoudre
Pourquoi se fatiguer à apprendre un nouveau langage alors que REST fait le job depuis vingt ans ? Bonne question. La réponse tient en deux mots un peu barbares : over-fetching et under-fetching.
L’over-fetching, c’est quand vous recevez beaucoup trop de données. Votre écran mobile affiche juste un nom et une photo de profil, mais l’endpoint REST vous balance tout l’objet utilisateur : adresse, historique de commandes, préférences, dernière connexion. Tout ça pour rien.
L’under-fetching, c’est l’inverse, et c’est encore plus pénible. Un seul appel ne suffit pas à remplir votre écran, alors vous enchaînez : un appel pour l’utilisateur, un autre pour ses commandes, un troisième pour le détail de chaque commande. Bienvenue dans l’enfer des allers-retours en cascade.
Ajoutez à ça la rigidité de REST (un nouveau besoin égale souvent un nouvel endpoint, une évolution égale souvent une nouvelle version d’API) et vous comprenez pourquoi les équipes ont cherché mieux.
GraphQL renverse la logique : c’est le client qui décide de la forme des données, plus le serveur. C’est ce qu’on appelle l’efficacité de la récupération de données (data fetching efficiency).
Comment fonctionne GraphQL ?
Maintenant, mettons les mains dans le cambouis. Le fonctionnement de GraphQL repose sur quatre piliers. Rien de sorcier, promis.
1 – Le schéma, colonne vertébrale de l’API
Tout part d’un schéma fortement typé (strongly-typed schema). C’est le contrat. Il décrit, sous forme de types et de champs, tout ce que votre API sait faire. Un type « User » avec ses champs « id », « name », « email », chacun avec son type.
Le serveur sait exactement ce qu’on peut lui demander, et il refuse poliment tout ce qui sort du cadre. Pas de mauvaise surprise en prod.
2 – Un seul point d’entrée
Là où REST éparpille ses URLs façon puzzle, GraphQL n’expose qu’un seul point d’entrée (single endpoint), en général une adresse « /graphql ». Vous frappez toujours à la même porte ; c’est votre requête qui change. Plus simple à retenir, plus simple à sécuriser.
3 – Lire, écrire, écouter : query, mutation, subscription
Trois verbes, trois usages.
La query lit des données. La mutation les modifie, autrement dit créer, mettre à jour ou supprimer. Et la subscription vous branche sur du temps réel : dès qu’un événement se produit côté serveur, vous êtes notifié, typiquement via WebSocket.
Parfait pour un chat, un fil d’actualité ou un dashboard qui se rafraîchit tout seul.
4 – Les resolvers font le vrai boulot
Quand votre requête arrive, le serveur la confronte au schéma, puis appelle les resolvers. Un resolver, c’est une petite fonction collée à un champ, dont le seul job est d’aller chercher la donnée, où qu’elle se cache. Le runtime coordonne tout ce petit monde et vous rend une réponse pile à la forme demandée.
Cerise sur le gâteau : une API GraphQL se documente toute seule (self-documenting APIs). Grâce à l’introspection, elle sait décrire son propre schéma. C’est ce qui alimente l’autocomplétion et la doc interactive dans les outils des devs. Vous voulez savoir ce que l’API propose ? Vous le lui demandez, elle vous répond.
GraphQL vs REST : différences et critères de choix
La grande question, celle qui revient à chaque fois : faut-il jeter REST à la poubelle ? Non. Surtout pas. Les deux peuvent même cohabiter dans le même projet. Mais ils ne raisonnent pas de la même façon.
| Critère | REST | GraphQL |
| Endpoints | Multiples (un par ressource) | Un point d’entrée unique |
| Forme des données | Définie par le serveur | Définie par le client |
| Over et under-fetching | Fréquents | Évités par conception |
| Versioning | Versions explicites (v1, v2) | Évolution continue par dépréciation |
| Typage | Optionnel | Schéma fortement typé natif |
| Mise en cache | Cache HTTP standard | À gérer au niveau applicatif |
Ce que GraphQL vous apporte tient en une phrase : le client obtient exactement ce qu’il demande, en un seul appel, sur un contrat clair et typé. Le front avance plus vite, la communication client-serveur se fluidifie, et les évolutions cassent beaucoup moins de choses.
Mais attention au marteau qui voit des clous partout. REST garde l’avantage quand le cache HTTP est vital, quand vous servez des fichiers ou du binaire, ou quand votre API se résume à du CRUD basique où GraphQL n’ajouterait que de la complexité.
Côté sécurité, GraphQL réclame aussi sa propre vigilance : une requête trop profonde ou trop coûteuse, mal bornée, peut faire très mal. Le bon réflexe ? Choisir selon le besoin, jamais selon la hype.
Cas d’usage et écosystème
Qui s’en sert pour de vrai ? Du beau monde. GitHub a carrément ouvert une API GraphQL publique, et Shopify, Netflix, Airbnb ou Meta l’exploitent à très grande échelle. La tendance n’est pas près de s’inverser : selon une prévision de Gartner, plus de 60 % des entreprises utiliseront GraphQL en production d’ici 2027, contre moins de 30 % en 2024.
GraphQL brille surtout dans trois situations. Les applications mobiles et multi-clients d’abord, quand un même backend doit nourrir des écrans aux besoins très différents. Les architectures d’agrégation ensuite, où GraphQL fait office de couche unifiée (le fameux pattern Backend For Frontend) par-dessus une flopée de microservices. Et tout ce qui touche au temps réel, grâce aux subscriptions.
À l’échelle de l’entreprise, un mot revient partout : la fédération. Le principe ? Chaque équipe expose son bout de graphe, et une passerelle assemble le tout en un graphe unique. Du costaud : Booking.com fait tourner un graphe fédéré qui encaisse plusieurs milliards de requêtes par jour.
Côté outils, Apollo est la référence (Apollo Server, Apollo Client, sa solution de fédération), mais vous croiserez aussi Hot Chocolate, GraphQL Yoga ou Relay selon votre langage. Et si vous suivez l’actu, vous avez vu que GraphQL se positionne désormais comme couche d’accès aux données pour les agents d’IA. Un sujet brûlant !
GraphQL sur le marché du freelance tech
On arrive à la partie qui vous concerne directement si vous êtes indépendant. GraphQL, ça paie ? Réponse honnête : pas tout seul, mais ça pèse.
Première vérité du terrain : vous ne tomberez quasiment jamais sur une mission intitulée « développeur GraphQL ». Dans les annonces, GraphQL apparaît comme compétence d’appoint, glissée à côté de REST, React Native, Node ou Spring Boot. Allez jeter un œil aux missions GraphQL publiées sur les plateformes spécialisées : vous le verrez presque toujours noté en compétence secondaire sur des postes fullstack ou backend, jamais en tête d’affiche.
Le message est clair : GraphQL ne se vend pas comme un métier, il se vend comme un accélérateur de profil.
Deuxième vérité : c’est justement ce genre de compétence qui vous pousse vers les missions qui rapportent (architecture d’API, microservices, applications multi-clients). Pour vous donner un repère chiffré, le Guide TJM de FreelanceRepublik situe un développeur backend autour de 410 € en junior et 560 € en senior, et un fullstack senior vers 562 € par jour.
Une vraie maîtrise des API modernes, GraphQL compris, vous aide à viser le haut de la fourchette plutôt que le bas.
Alors comment la mettre en valeur ? Trois leviers tout simples :
- Montrez un projet où vous avez conçu un schéma et des resolvers, pas seulement consommé une API existante.
- Mettez en avant le combo GraphQL plus fédération si vous visez les grands comptes.
- Et ciblez les missions d’agrégation de données, le terrain de jeu naturel de GraphQL.
Sur un marché aussi concurrentiel, c’est ce type de spécialisation qui justifie un TJM plus élevé. Pas les promesses, les preuves.
Que retenir de GraphQL ?
Au fond, GraphQL ne cherche pas à enterrer REST. Il répond à une question précise : et si c’était au client de décider quelles données il consomme ? Sa neutralité, son schéma typé et son écosystème mûr en font une compétence qui ne se démodera pas de sitôt. Que vous soyez en équipe produit ou en solo sur le marché du freelance, ça vaut le coup de s’y mettre. Et vous, votre prochaine API, vous la ferez en REST ou en GraphQL ?
FAQ – Questions fréquentes sur GraphQL
GraphQL va-t-il remplacer REST ?
Non, et ce n’est pas le but. Les deux approches répondent à des besoins différents et cohabitent très bien dans un même projet. REST reste imbattable pour des API simples et pour tirer parti du cache HTTP ; GraphQL prend l’avantage dès que les clients sont multiples et que les besoins en données deviennent variés. Le bon choix dépend du contexte, pas de la mode.
Faut-il connaître un langage en particulier pour faire du GraphQL ?
Pas du tout. GraphQL est une spécification neutre, indépendante du langage et de la base de données. Vous trouverez des bibliothèques matures en JavaScript, Python, Go, Java, C# et bien d’autres. Vous travaillez donc avec la stack que vous maîtrisez déjà.
GraphQL est-il adapté aux petits projets ?
Pas toujours. Pour une petite API CRUD avec un seul client, REST est souvent plus rapide à mettre en place et la flexibilité de GraphQL n’apporte pas grand-chose. GraphQL devient pertinent quand vous avez plusieurs clients, des données liées et un besoin réel de souplesse côté front.
Apollo est-il obligatoire pour utiliser GraphQL ?
Non. Apollo est l’écosystème le plus populaire (côté serveur comme côté client), mais ce n’est qu’une option parmi d’autres. Hot Chocolate, GraphQL Yoga ou Relay font aussi très bien le travail selon votre langage et vos besoins. GraphQL reste une spécification ouverte que chacun implémente à sa façon.
