Les équipes d'ingénierie passent encore des après-midi entiers à débattre pour savoir si REST est mort ou si gRPC a rendu tout le reste obsolète. Ce débat passe à côté de l'essentiel. Vous ne choisissez pas le meilleur protocole. Vous choisissez la bonne frontière. Un protocole qui fonctionne à merveille au sein de votre cluster Kubernetes étouffera lorsque vous le confierez à un millier de développeurs externes. Un protocole qui économise la précieuse bande passante de votre application mobile ruinera votre infrastructure si vous l'ouvrez à des requêtes publiques arbitraires. Considérez cette décision comme un concours de popularité technologique, et vous cimenterez une dette architecturale qui survivra à chaque membre actuel de votre équipe.
Le principe de la frontière
L'architecture est une question de compromis, pas de champions. La bonne question n'est jamais « Lequel est le plus rapide ? » ou « Lequel est le plus récent ? ». C'est : « Qui se trouve de l'autre côté du câble, et que contrôle-t-il ? ». Les protocoles sont des objets de frontière. Choisir le mauvais ne fait pas que vous ralentir. Cela grave des erreurs dans votre système pour des années.
API publiques : REST n'est pas ennuyeux, il est responsable
Lorsque votre consommateur est un développeur externe que vous n'avez jamais rencontré, votre API est un produit, pas seulement une interface. Ce développeur débogue à deux heures du matin avec pour seuls outils curl et une collection Postman. S'il doit installer une bibliothèque cliente personnalisée ou apprendre un langage de schéma avant son premier appel réussi, vous l'avez déjà perdu.
REST survit ici parce qu'il est le web lui-même. Les méthodes HTTP, les codes d'état et le JSON sont la langue commune. La mise en cache n'est pas une réflexion après coup ; c'est une infrastructure qui existe déjà. Les navigateurs, les CDN et les caches de bordure (edge caches) comprennent nativement les en-têtes Cache-Control et la validation ETag. Vous pouvez placer une API REST derrière un CDN standard et obtenir des économies de bande passante immédiates sans écrire une seule ligne de logique de mise en cache. Cela compte lorsque le trafic public est imprévisible et que vous payez pour chaque gigaoctet qui quitte votre cloud.
GraphQL, en revanche, impose une taxe lourde à une frontière publique. Les points de terminaison (endpoints) GraphQL publics nécessitent une analyse du coût des requêtes, une limitation de la profondeur et un score de complexité pour éviter qu'une seule requête négligente ou malveillante n'écrase votre base de données. Vous ne livrez pas seulement une API ; vous construisez un moteur d'exécution de requêtes, une stratégie de limitation de débit (rate-limiting) et un modèle de facturation de calcul. À moins d'avoir la puissance opérationnelle des plus grandes plateformes, cette surcharge est imprudente pour une surface d'exposition publique. REST définit des garde-fous par défaut. Chaque endpoint fait une seule chose. Les consommateurs récupèrent exactement ce que vous proposez, et non tout ce qu'ils peuvent imaginer.
Services internes : maîtrisez tout le tuyau
À l'intérieur de votre organisation, le débat change. Vous contrôlez à la fois le client et le serveur. Vous pouvez dicter la pile technologique pour chaque service de la chaîne d'appels. C'est là que gRPC justifie son existence.
D'abord, arrêtez de traiter le JSON comme quelque chose de sacré. Protocol Buffers sérialise environ trois fois plus vite que JSON. Les charges utiles (payloads) sont plus petites car le format est binaire. Sur un réseau interne chargé, ces millisecondes et ces mégaoctets se transforment en argent réel et réduisent la latence de queue (tail latency). Plus important encore, Protobuf vous offre un contrat strict. Lorsque vous changez un type de champ ou renommez un message, la rupture se produit au moment de la compilation, et non à trois heures du matin en production lorsqu'un service en aval commence à renvoyer des exceptions d'analyse (parse exceptions).
gRPC fonctionne sur HTTP/2, vous bénéficiez donc de la compression d'en-tête, des flux multiplexés et d'une véritable sémantique de streaming. Si vous transmettez des événements à haut débit entre des services ou si vous poussez des mises à jour en temps réel, le streaming côté serveur et bidirectionnel sont des fonctionnalités natives, et non des solutions de contournement par long-polling scotchées sur un framework de requête-réponse.
Il y a un piège majeur : ne pointez pas gRPC directement vers un navigateur. Les modèles de mise en réseau des navigateurs ne parlent pas HTTP/2 de la manière dont gRPC l'attend. Vous finirez par greffer grpc-web et un proxy comme Envoy sur votre pile juste pour qu'un navigateur puisse parler à un backend. Ce n'est pas un bug ; c'est un signal de frontière. Gardez gRPC derrière votre pare-feu, entre des services qui se font confiance, et considérez sa complexité de débogage comme le prix de la vitesse. Les charges utiles binaires ne se lisent pas aussi facilement dans un fichier log que le JSON.
UI complexes et mobile : la niche de GraphQL
Les écrans mobiles modernes sont des mosaïques. Une vue peut avoir besoin d'un profil utilisateur,