Quand vient le moment de connecter vos outils métier – un ERP, un CRM, un gestionnaire de stocks – la question de l'API se pose tôt ou tard. Et c'est là qu'on vous parle REST, GraphQL, webhooks... sans toujours clarifier ce qui change vraiment pour votre activité. Spoiler : ce n'est pas un débat technique abstrait. Le choix impacte directement votre charge serveur, vos coûts cloud et la facilité de maintenance.

Comprendre REST : le standard qui a fait ses preuves

Une API REST fonctionne simplement : vous demandez une ressource à une adresse précise (un endpoint), et le serveur vous répond avec tout ce qu'il a sur cette ressource. Un client veut les données d'un devis ? Il appelle /api/devis/12345 et reçoit le devis complet : numéro, client, articles, montants, dates.

Le confort de REST, c'est sa prévisibilité. Chaque endpoint correspond à une action claire. Les développeurs comprennent vite. Les outils de monitoring fonctionnent bien. Et surtout, les serveurs savent gérer le cache facilement : une réponse REST peut être stockée et réutilisée sans retraitement.

Le problème ? Vous récupérez souvent plus d'info que nécessaire. Votre mobile fait une requête pour afficher un client, mais reçoit aussi toute l'historique commercial, les notes internes, les contacts... ça pèse sur la bande passante et ralentit l'app.

GraphQL : la précision au prix de la complexité

GraphQL renverse la logique. Au lieu que le serveur décide ce qu'il envoie, c'est le client qui demande exactement ce qu'il veut. Votre app mobile veut juste le nom et l'email du client ? Elle demande ça, rien de plus. Votre tableau de bord backend veut tous les détails ? Il les demande. Une seule requête GraphQL peut remplacer 5 ou 10 requêtes REST.

En théorie, c'est efficace : moins de données transitent, moins de latence perçue, surtout sur mobile. En pratique, GraphQL ajoute une couche de complexité au serveur. Il faut parser la requête, valider la syntaxe, vérifier les permissions pour chaque champ (pas seulement par endpoint), construire la réponse sur mesure. Et mettre en cache une requête GraphQL ? C'est ardu, parce que chaque requête est unique.

Quel choix pour votre PME ?

Vous devriez rester en REST si :

  • Votre équipe est petite et doit livrer vite. REST = moins d'infrastructure à maintenir.
  • Vous avez surtout des clients lourd (desktop, web) qui ne sont pas en 3G précaire.
  • Vos requêtes sont prévisibles : la plupart de vos clients demandent les mêmes infos.
  • Vous utilisez un ERP ou système existant dont l'API REST est déjà stable.
  • La bande passante ne vous coûte pas cher (accès illimité en interne, peu d'appels mobiles).

Envisagez GraphQL si :

  • Vous avez plusieurs clients distincts (mobile, web, app partenaire) avec des besoins de données très différents.
  • Vous visez une audience mobile à l'international, sur connexion lente.
  • Vous gérez un SaaS multi-tenant où l'efficacité des requêtes est un atout de vente.
  • Votre équipe maîtrise déjà GraphQL et les outils d'introspection (Apollo, Yoga).
  • Vous avez les ressources pour maintenir un schéma GraphQL robuste et bien documenté.

La vraie considération : l'hybride en pratique

Dans nos projets chez Planéo Dev, on voit de plus en plus d'équipes adopter une approche mixte : une API REST classique pour les cas courants (créer une commande, récupérer un client standard), et quelques endpoints GraphQL ciblés pour les cas complexes (tableaux de bord avec agrégations, exports spécialisés). C'est honnête et pragmatique.

Si vous connectez Dolibarr à un outil tiers ou construisez une application mobile légère, REST suffit souvent. Si vous construisez une plateforme avec des clients très hétérogènes ou si vous devez supporter l'automatisation de centaines d'intégrations, GraphQL peut justifier son surcoût.

Points concrets à vérifier avant de décider

Testabilité. REST gagne aisément : un curl ou Postman, et c'est bon. GraphQL demande des outils spécialisés comme GraphQL Playground ou Insomnia.

Performance en production. REST = cache HTTP natif, CDN compatible d'office. GraphQL = vous devez prévoir une couche de cache applicatif (Redis, DataLoader). Ça coûte en infra.

Sécurité des données. En REST, vous cachez les données sensibles à l'endpoint. En GraphQL, tout le schéma est introspectable : un utilisateur peut explorer ce qui existe. Il faut contrôler l'accès au niveau de chaque champ.

Coûts d'opération. REST = simple à monitorer, simple à scaler horizontalement. GraphQL = demande une vigilance particulière sur les requêtes coûteuses (une requête mal ficelée peut traverser 50 tables).

Avant de trancher, posez-vous les vraies questions : avez-vous vraiment besoin de la flexibilité de GraphQL, ou vous la construisez pour construire ? Qui va maintenir cette API dans 2 ans ? Votre stack cloud peut-elle supporter les surcoûts d'exécution ?

Si vous démarrez un projet web sur mesure et que l'équipe n'a jamais touché à GraphQL, commencez par REST. Vous pourrez toujours ajouter du GraphQL après si vraiment le besoin s'impose. À l'inverse, réarchitecturer une API GraphQL qui s'avère surdimensionnée, c'est bien plus coûteux.

Questions fréquentes

REST est le choix pragmatique. C'est plus facile à comprendre, à tester et à debugger sans expertise profonde. Si vous travaillez avec une agence, elle peut maintenir une API REST avec peu de complications futures. GraphQL vaut surtout si vous avez plusieurs clients distincts demandant des formats de données très différents.

Oui, et c'est courant. Vous pouvez garder vos endpoints REST pour les opérations standard (CRUD simples) et ajouter des routes GraphQL pour les cas complexes ou les clients mobiles. Attention toutefois à ne pas fragmenter la documentation et les permissions : qui peut accéder à quoi doit être clair dans les deux cas.

Oui, en théorie : vous ne téléchargez que les données demandées. Mais en pratique, ce gain est visible surtout si vos requêtes REST renvoient énormément de champs inutiles. Si vous avez déjà optimisé vos endpoints REST (requêtes spécialisées, pagination), la différence diminue. Et GraphQL ajoute du surcoût d'exécution côté serveur, qui peut annuler l'économie de bande passante. Mesurez avant de décider.