REST ou gRPC : quand choisir l'un ou l'autre, et pourquoi votre système central ne parle ni l'un ni l'autre

La question « REST ou gRPC ? » est souvent posée comme s'il fallait choisir un camp pour toute l'architecture. En pratique, on ne la tranche presque jamais une seule fois : elle se tranche à chaque frontière. Une API reçue par des tiers, un appel entre deux services de la même équipe et la connexion avec un système vieux de vingt ans appellent des réponses différentes.

Cet article approfondit la branche « en ligne » de notre article sur le choix entre en ligne et asynchrone : celui-ci décide quand il convient de répondre à l'instant, et celui-là avec quel protocole le faire, et que faire quand le système du fond ne le peut pas.

Il s'adresse à l'équipe technique qui doit prendre ces décisions : architectes, responsables de développement et personnes qui intègrent des systèmes dans des banques, des assureurs, des fintechs ou des chaînes de distribution. Il propose un critère qui tient en une phrase :

REST à la frontière, gRPC au cœur, adaptateur pour le legacy.

C'est un critère, pas une règle ; la fin de l'article présente les cas où il convient de le rompre.

Qu'est-ce que gRPC, en cinq idées

gRPC est un cadre d'appels de procédure distante (RPC, remote procedure call). Au lieu de penser en ressources et en URL, on pense en services dotés de méthodes que l'on invoque à distance comme s'ils étaient locaux. Cinq idées le définissent :

1. Le contrat vient en premier. Le service et ses messages sont décrits dans un fichier .proto. Par défaut, gRPC utilise Protocol Buffers (Protobuf) comme langage de définition d'interface, tant pour le service que pour la structure des messages [1]. À partir du .proto, on génère le client et la base du serveur, typés, dans les langages qu'utilise l'équipe [4].
2. Il passe par HTTP/2 et circule en binaire. gRPC est conçu pour HTTP/2 (la version du protocole web qui offre le format binaire, la compression et le multiplexage de plusieurs appels sur une seule connexion TCP). Protobuf produit des messages compacts et se sérialise rapidement. Une nuance à ne pas perdre : HTTP/2 n'est pas propre à gRPC ; une API HTTP avec JSON peut aussi l'utiliser [4].
3. Le streaming comme fonction de base. Outre l'appel simple (une requête, une réponse), il existe le streaming du serveur vers le client, du client vers le serveur et le streaming bidirectionnel. gRPC conserve l'ordre des messages au sein d'un même appel [1]. Il sert à la télémétrie, aux cotations en direct ou aux notifications.
4. Des délais (deadlines) explicites. Le client indique combien de temps il accepte d'attendre ; si le délai expire, l'appel se termine par l'erreur DEADLINE_EXCEEDED [1]. Par défaut, gRPC ne fixe aucun délai, de sorte qu'un client peut rester à attendre pratiquement indéfiniment [2]. À l'expiration du délai, gRPC annule l'appel, mais l'application doit détecter cette annulation et interrompre le travail qu'elle a lancé [2]. Le délai peut se propager aux appels que ce service fait à d'autres, pour ne pas dépenser de ressources sur une réponse que plus personne n'attend [2][4].
5. Des états d'erreur avec un vocabulaire propre. Chaque appel se termine par un code d'état issu d'un catalogue de 17 valeurs, dont INVALID_ARGUMENT, NOT_FOUND, PERMISSION_DENIED, UNAUTHENTICATED, RESOURCE_EXHAUSTED et UNAVAILABLE [3]. La page officielle des codes ne définit pas d'équivalence avec les codes HTTP. Quiconque expose le service vers l'extérieur doit décider par écrit de cette traduction.

gRPC n'est pas un « REST plus rapide » : c'est un autre modèle, avec un contrat obligatoire et une spécification stricte qui, selon Microsoft, évite le débat sur le format des URL, des verbes et des codes de réponse [4]. Si l'on expose en plus du HTTP/JSON, ces routes, ces verbes et ces erreurs doivent quand même être définis. Et ce n'est pas gratuit : le format binaire ne se lit pas à l'œil nu et exige le contrat pour être interprété [4].

Quand REST

REST est un style de conception sur HTTP orienté vers les ressources, les verbes et les représentations, presque toujours en JSON. C'est l'option par défaut à la frontière : là où votre système rencontre quelqu'un qu'il ne contrôle pas.

• Tiers et intégrateurs. Qui consomme votre API n'a aucune raison d'adopter votre outil de génération de code. REST/JSON réduit la dépendance aux SDK générés et facilite l'inspection et les tests manuels ; un partenaire peut essayer un appel avec curl en une minute.
• Frontend dans le navigateur. Aucun navigateur ne donne le contrôle sur HTTP/2 dont gRPC a besoin ; on ne peut donc pas appeler un service gRPC directement depuis une page [4]. Plus loin, nous voyons que faire quand on veut tout de même gRPC sur le web.
• Débogage humain. Une requête REST se lit, se copie, se colle dans un ticket et se reproduit. Avec gRPC, il faut des outils qui comprennent le format [4].

Quand gRPC

Envisagez gRPC lorsque vous contrôlez le fournisseur et le consommateur, que vous acceptez de gouverner les .proto et que vous avez une contrainte mesurée de latence, de taille de message ou de volume. Les scénarios que recommande la documentation de Microsoft sont les microservices à faible latence et à haut débit, la communication point à point en temps réel, les environnements multilingues, les réseaux à bande passante limitée et la communication entre processus d'une même machine [4].

• Services internes. Entre services d'un même domaine de confiance, le contrat fort et le client généré évitent toute une catégorie d'erreurs : champs qui changent de nom, types interprétés différemment, clients écrits à la main qui se décalent.
• Contrat fort entre équipes. Quand plusieurs équipes et plusieurs langages partagent des services, le .proto fait office d'accord exécutable : s'il ne compile pas, il ne s'intègre pas.
• Volume. Quand on fait beaucoup de petits appels, la taille du message et le multiplexage sur une connexion se remarquent. Mesurez avec votre charge avant de justifier le changement par la vitesse.
• Streaming. Si le cas d'usage est un flux (prix, événements d'appareils, avancement d'un long processus), gRPC l'offre au sein du contrat, non comme un ajout.

Il y a un cas que Microsoft exclut : la diffusion massive vers de nombreux clients connectés ; gRPC n'a pas la notion de « broadcast » et chaque appel transmet séparément [4].

Le navigateur et gRPC-Web

Comme le navigateur ne peut pas parler gRPC natif, il existe gRPC-Web : un protocole adapté, avec un client JavaScript généré et un proxy compatible (le tutoriel officiel utilise Envoy) entre le navigateur et le service gRPC ; il peut aussi exiger une configuration CORS [5].

Il a des limites qu'il convient de connaître avant de décider. Dans le dépôt du projet, le streaming du serveur vers le client n'est pris en charge que dans le mode grpcwebtext, et le streaming du client ainsi que le streaming bidirectionnel ne sont pas pris en charge [6]. Microsoft le range parmi les raisons de préférer un autre cadre lorsque l'API doit être accessible depuis le navigateur : gRPC-Web offre une prise en charge, mais avec des limitations et un proxy serveur supplémentaire [4].

Règle pratique : gRPC-Web si l'application web est la vôtre et que la plateforme utilise déjà Protobuf ; REST/JSON si des tiers la consommeront.

Exposer gRPC comme REST sans écrire deux fois la logique

Il n'est pas nécessaire de choisir entre les deux faces. Le contrat .proto peut porter des annotations HTTP (google.api.http) qui indiquent quelle route et quel verbe correspondent à chaque méthode. Un composant intermédiaire, normalement la passerelle (gateway) ou un proxy, convertit la requête HTTP/JSON en appel gRPC et renvoie la réponse en JSON. Ce mécanisme s'appelle le transcodage (transcoding) [4][7][18] :

Client REST  → passerelle (transcodage) → service gRPC → adaptateur → système central legacy
Client gRPC  ───────────────────────────→ service gRPC → adaptateur → système central legacy

(Schéma : client REST → passerelle (transcodage) → service gRPC → adaptateur → système central hérité ; client gRPC → service gRPC → adaptateur → système central hérité.)

Deux exemples de passerelles qui l'offrent, comme catégorie et non comme recommandation :

• Envoy possède le filtre gRPC-JSON transcoder, qui permet à un client REST avec JSON d'envoyer des requêtes par HTTP et de les faire acheminer vers un service gRPC. Il exige de connaître le descripteur Protobuf du service et les annotations HTTP du contrat [7].
• Apache APISIX possède le plugin grpc-transcode, qui transforme les requêtes et les réponses entre HTTP et gRPC. Les protos s'enregistrent par son API d'administration, sous forme de texte ou de descripteur binaire [8]. La documentation consultée ne mentionne pas le streaming ; vérifiez-le dans votre version.

L'idée : une seule implémentation, deux manières de l'appeler.

Deux précautions que le transcodage ne résout pas à lui seul :

• Erreurs. Le convertisseur traduit des codes, mais la politique de ce que chacun signifie pour un tiers, c'est vous qui la définissez. Un UNAVAILABLE interne s'affiche-t-il comme une erreur de service indisponible, ou est-il d'abord retenté ?
• Sécurité. L'authentification, l'autorisation fine et les quotas relèvent de la passerelle et du service, non du format.

Outils de test : ce qui reste d'actualité

Tester un service gRPC à la main exige un outil qui comprenne Protobuf. Voici l'état que nous avons vérifié le 6 octobre 2026 ; tout changement ultérieur peut le modifier.

La réflexion de serveur permet de découvrir les méthodes sans le .proto, mais elle doit être activée sur le service et, en production, il convient de décider à qui on la montre.

Java : Spring Boot et Quarkus

Java est un cas utile parce que les deux cadres disposent d'un chemin documenté vers gRPC. Les versions ci-dessous sont celles vérifiées le 6 octobre 2026.

Spring Boot. Spring gRPC est un projet officiel de Spring, dont la version 1.0.0 a été publiée le 4 décembre 2025. À la date de relevé, la version stable la plus récente sur GitHub est la 1.1.1 (21 août 2026) [15]. La 1.1.0 (10 juin 2026) a migré l'autoconfiguration vers Spring Boot 4.1.0, et les branches 1.0.x ciblent Boot 4.0 [15]. Pour une base neuve sur Spring Boot 4.1, il existe un chemin officiel ; avec des versions antérieures, vérifiez la compatibilité avec la lignée 1.0.x.

Quarkus. gRPC s'incorpore avec l'extension quarkus-grpc : elle implémente et consomme des services, génère du code à partir du .proto, s'intègre au modèle réactif, prend en charge TLS et TLS mutuel, xDS et la communication en processus [16]. Quarkus recommande le serveur gRPC fondé sur Vert.x parce qu'il est plus flexible et mieux intégré à l'écosystème, et ce serveur peut servir HTTP et gRPC sur le même port, si l'on configure quarkus.grpc.server.use-separate-server=false [16]. Sur Maven Central, la dernière version 3.x de l'extension à la date de relevé est la 3.40.1 (30 septembre 2026) ; il existe aussi une 4.0.0.Beta1 du même mois, qui est une préversion [16].

Les deux fonctionnent : le cadre que l'équipe maîtrise déjà décide.

Quel que soit le cadre, les mêmes pratiques comptent : un dépôt unique de contrats, des intercepteurs pour l'identité et les traces, une politique d'erreurs commune, des health checks et des délais obligatoires dans chaque client.

Évolution des contrats Protobuf : comment ne casser personne

Le contrat est le produit. Le modifier sans précaution casse les clients qui n'ont pas été prévenus. Le guide officiel de Protobuf établit des règles claires [17] :

• Ajouter des champs est sûr. L'ancien code ignore les nouveaux champs à la lecture, et le nouveau utilise des valeurs par défaut avec les anciens messages.
• Ajouter des valeurs à un enum est sûr dans le format binaire ; vérifiez néanmoins que les clients et les règles métier prévoient la nouvelle valeur (dans les langages à enums fermés, comme Java, une valeur inconnue arrive comme un cas à part).
• Le numéro d'un champ ne se change ni ne se réutilise une fois le message en usage, car ce numéro identifie le champ dans le format de transmission.
• Lorsqu'on retire un champ, on réserve son numéro (et, si l'on utilise JSON, son nom aussi) pour que personne ne le réutilise par accident.
• Déplacer des champs vers ou depuis un oneof existant est risqué : de l'information peut se perdre à la sérialisation et à la lecture.

Le guide de conception d'API de Google s'applique à REST comme à RPC et renvoie à ses propositions AIP-180 (compatibilité) et AIP-185 (versions) [18]. La règle opérationnelle est courte :

1. Publier les .proto comme un produit versionné.
2. Valider la compatibilité dans l'intégration continue (avec un outil de détection des changements cassants).
3. Maintenir des tests de contrat entre le service et ses consommateurs.
4. Traiter tout changement non additif comme une nouvelle version de l'API, avec une période de coexistence.

Pourquoi votre système central ne parle ni l'un ni l'autre

Voici le point que presque aucun comparatif de protocoles n'aborde. Les systèmes centraux d'un assureur, d'une banque ou d'un commerce qui a des décennies d'histoire ne parlent généralement ni REST ni gRPC, et leurs limites expliquent pourquoi :

• Ils n'exposent pas d'API que l'on puisse appeler, et ne préviennent pas quand quelque chose change.
• Ils n'acceptent des données que dans une zone d'échange, tables ou fichiers, et les traitent à leur propre rythme, souvent par lots, en déclenchant un processus propre.
• Ils supportent peu de charge : une rafale d'appels en ligne les sature.
• La réponse arrive quand le processus se termine, non quand la requête a été envoyée, et on ne la trouve parfois qu'en relisant une autre table ou un autre fichier.

Choisir REST ou gRPC pour la couche du dessus ne change rien à cela. Ce qu'il faut au milieu, c'est un adaptateur : un composant qui parle la langue du système central vers l'intérieur et le nouveau contrat vers l'extérieur. Et lorsque le modèle, les erreurs, la sécurité ou les transactions des deux côtés ne coïncident pas, l'adaptateur doit être une couche anticorruption (anti-corruption layer), le patron qu'Eric Evans a décrit dans Domain-Driven Design [19].

C'est une façade entre des sous-systèmes qui ne partagent pas la même sémantique, afin que les dépendances externes ne limitent pas la conception de l'application ; elle peut être un composant interne ou un service indépendant [19].

La différence avec un proxy est importante :

Quatre tâches tombent généralement dans l'adaptateur, et il convient de les écrire avant qu'elles ne se diluent dans le code (critère de conception ; le patron lui-même est décrit en [19]) :

• Traduire les objets de données et valider les invariants à cette frontière, y compris l'assainissement des entrées.
• Normaliser les erreurs : un code de retour propriétaire ou une ligne dans une table d'erreurs devient un état gRPC et, de là, le cas échéant, un code HTTP, avec la politique explicite dont il a été question plus haut.
• Protéger le système central. Un système central a un rythme qu'il supporte. Si une émission massive envoie des milliers de mouvements et que le système en traite quelques dizaines par minute, l'appel en ligne n'est pas la manière de les livrer : il faut une file d'attente ou un mécanisme de nivellement de charge [20], sauf si l'appelant exige une réponse synchrone à faible latence. Une file exige de définir l'idempotence, les reprises, le traitement des messages en échec, l'ordre le cas échéant et la consultation de l'état par identifiant de corrélation [20]. C'est le sujet du prochain article de cette série.
• Observer : un identifiant de corrélation dans chaque appel, pour reconstituer ce qui s'est passé entre le nouveau contrat et le système central, et des journaux structurés pour diagnostiquer les échecs de traduction.

Coûts : plus de latence, un service de plus à exploiter et la décision de savoir si la couche est permanente [19]. Microsoft recommande qu'elle se limite à traduire et ne concentre ni règles métier ni orchestration [19].

Tableau de décision

Quand rompre la phrase directrice

« REST à la frontière, gRPC au cœur, adaptateur pour le legacy » fonctionne comme point de départ. Il y a des cas raisonnables où il convient de s'en écarter :

• Tout en REST. Avec une petite équipe, un volume modéré et sans streaming, Protobuf peut coûter plus qu'il n'apporte.
• gRPC jusqu'à la frontière. Si les consommateurs externes sont peu nombreux et acceptent des SDK générés, on évite une couche.
• Sans adaptateur. Si le système central offre déjà une API moderne et stable, l'adaptateur se réduit à un mappage mince.
• Asynchrone au lieu de synchrone. Si le problème est le rythme du système central et non le protocole, ce qui aide est une file, un événement ou un rappel (callback) avec identifiant de corrélation.

Ce qu'il convient de conserver : décider par frontière, mesurer avant de justifier et écrire le contrat avant d'écrire le code.

Conclusion : ce qu'il convient d'emporter à la prochaine réunion

Avant de choisir un protocole, trois questions ordonnent la discussion : qui consomme l'interface et qui contrôle ses clients, quelle langue parle le système du fond et quel rythme il supporte. Si le système du fond ne parle ni l'un ni l'autre ou va plus lentement que celui qui l'appelle, et que la charge mesurée exige de découpler l'entrée du traitement, il convient de donner la priorité à l'adaptateur et d'envisager une file avant de changer de protocole.

Ce que fait Hábil

Hábil travaille dans l'espace entre les systèmes existants et les nouvelles couches : elle cherche à ce qu'un système central qui ne parle ni REST ni gRPC puisse servir vos canaux et vos partenaires sans freiner l'exploitation. Pour relier vos API et vos canaux, voyez la page Unifier votre activité et vos canaux ; pour faire évoluer le système central à son rythme, Moderniser le système central sans freiner l'activité. La première conversation, sans frais, part de la carte de vos intégrations et des points où un contrat ou un système central au rythme limité pourraient vous coûter de l'argent, du temps ou des preuves. Écrivez-nous sur WhatsApp.

Consultées le 6 octobre 2026. Les versions et les dates des outils et des projets changent ; celles marquées [fournisseur] sont des chiffres ou des états que publie le fournisseur lui-même.