gRPC (Google Remote Procedure Call)

gRPC est un framework open source de Remote Procedure Call (RPC) haute performance développé par Google, qui utilise HTTP/2 comme protocole de transport et Protocol Buffers (protobuf) comme format de sérialisation binaire, permettant aux services de communiquer entre eux comme s’ils appelaient des fonctions locales.

Si REST est le langage universel des API web, gRPC est le langage des communications internes haute performance. Là où REST envoie du JSON lisible par un humain via HTTP/1.1, gRPC envoie des messages binaires compacts via HTTP/2 avec multiplexing. Le résultat : des payloads 30 à 70% plus petits, une sérialisation/désérialisation plus rapide, et un streaming bidirectionnel natif. Dans les benchmarks, gRPC est typiquement 7 à 10x plus rapide que REST/JSON pour le même payload. C’est le choix standard pour la communication inter-services dans les architectures microservices.

Catégorie: Framework RPC haute performance
Créateur: Google, open-source 2015
Version: gRPC Core 1.78 (mars 2026)
Transport: HTTP/2
Sérialisation: Protocol Buffers (protobuf, binaire)
Langages: C++, Java, Python, Go, C#, Node.js, Ruby, Dart, Kotlin, Swift
URL: grpc.io

Comment fonctionne gRPC

gRPC repose sur deux piliers technologiques : Protocol Buffers pour la définition du contrat et la sérialisation, et HTTP/2 pour le transport.

Protocol Buffers (protobuf)

Protobuf est un langage de description d’interface (IDL) et un format de sérialisation binaire développé par Google. Vous définissez la structure de vos données et de vos services dans un fichier .proto, puis l’outil protoc génère automatiquement le code client et serveur dans le langage de votre choix.

syntax = "proto3";

package ml.serving;

// Définition du service
service ModelService {
  // Appel unaire : une requête, une réponse
  rpc Predict(PredictRequest) returns (PredictResponse);
  
  // Server streaming : une requête, flux de réponses
  rpc StreamPredict(PredictRequest) returns (stream PredictResponse);
  
  // Bidirectionnel : flux dans les deux sens
  rpc Chat(stream ChatMessage) returns (stream ChatMessage);
}

// Messages (structures de données typées)
message PredictRequest {
  string model_id = 1;
  repeated float features = 2;
  map<string, string> metadata = 3;
}

message PredictResponse {
  repeated float predictions = 1;
  float confidence = 2;
  int64 latency_ms = 3;
}

Ce fichier .proto est le contrat entre le client et le serveur. À partir de ce fichier, protoc génère des stubs clients (les méthodes que vous appelez comme des fonctions locales) et des squelettes serveur (les interfaces que vous implémentez) dans n’importe quel langage supporté. Un service Go peut appeler un service Python comme s’il invoquait une fonction locale.

Les messages protobuf sont sérialisés en format binaire, ce qui les rend compacts (30 à 70% plus petits que JSON) et rapides à parser. Chaque champ est identifié par un numéro (pas un nom textuel), ce qui accélère la sérialisation et permet l’évolution du schema sans casser la compatibilité.

HTTP/2

gRPC utilise HTTP/2 comme transport, ce qui apporte des avantages majeurs par rapport à HTTP/1.1 (utilisé par la plupart des REST API) :

Multiplexing. Plusieurs appels RPC partagent une seule connexion TCP et s’exécutent en parallèle. Une réponse lente ne bloque pas les autres (pas de head-of-line blocking).

Compression des headers. HTTP/2 compresse les headers avec HPACK, réduisant l’overhead réseau des appels répétés.

Streaming natif. HTTP/2 supporte nativement les flux bidirectionnels, ce qui permet les quatre patterns de communication gRPC.

Les quatre patterns de communication

Pattern	Description	Cas d’usage
Unaire	1 requête → 1 réponse (comme REST)	Prédiction ML, lookup, CRUD
Server streaming	1 requête → flux de réponses	Génération LLM (token par token), flux de données temps réel
Client streaming	Flux de requêtes → 1 réponse	Upload de données, agrégation de métriques
Bidirectionnel	Flux dans les deux sens, indépendamment	Chat, suivi de position temps réel, coordination d’agents

Le streaming bidirectionnel est la fonctionnalité la plus différenciante de gRPC. Les deux côtés envoient et reçoivent des messages indépendamment sur le même flux, avec du backpressure intégré (si un côté ralentit, le flux s’adapte au lieu d’accumuler en mémoire).

gRPC vs REST

Aspect	gRPC	REST
Transport	HTTP/2 (connexion persistante, multiplexing)	HTTP/1.1 ou HTTP/2
Format	Protocol Buffers (binaire, compact)	JSON (texte, lisible)
Taille payload	30-70% plus petit que JSON	Plus volumineux (noms de champs textuels)
Performance	7-10x plus rapide (sérialisation)	Plus lent mais suffisant pour la plupart des cas
Typage	Fort (contrat .proto, vérification compile-time)	Optionnel (OpenAPI, validation runtime)
Streaming	Natif (4 patterns)	Limité (SSE, chunked transfer)
Code generation	Automatique (stubs client/serveur)	Optionnel (via OpenAPI generators)
Debugging	Difficile (binaire, outils spécialisés)	Facile (JSON lisible, curl, Postman)
Navigateur	Non natif (gRPC-Web + proxy requis)	Natif
Cas d’usage	Inter-services, haute perf, polyglot	API publiques, web, intégrations simples

Le pattern courant en production : gRPC entre les microservices internes (haute performance, typage fort), REST/JSON à la périphérie (API publiques, navigateurs, partenaires). Un API gateway ou un service mesh (Envoy, Istio) peut faire la traduction gRPC ↔ REST quand nécessaire.

gRPC dans l’IA et le ML

gRPC est omniprésent dans l’infrastructure d’inférence ML :

Model serving

Les principaux runtimes de model serving supportent gRPC nativement. NVIDIA Triton expose ses endpoints d’inférence en gRPC (en plus de REST). KServe utilise gRPC pour la communication entre le transformer (pre-processing) et le predictor (inférence). TorchServe et TensorFlow Serving supportent gRPC comme protocole principal.

Pour le serving ML, gRPC apporte deux avantages décisifs : la sérialisation binaire réduit la latence sur les données numériques volumineuses (tenseurs, embeddings), et le multiplexing HTTP/2 permet de servir des centaines de requêtes concurrentes sans l’overhead de connexions multiples.

Streaming de réponses LLM

Le server streaming gRPC est idéal pour la génération de texte token par token. Le client envoie un prompt (une requête), le serveur streame les tokens générés au fil de la génération. C’est une alternative au SSE (Server-Sent Events) utilisé par les API REST des fournisseurs LLM, avec l’avantage du typage fort et du backpressure intégré.

Communication inter-services ML

Dans un pipeline ML en production, les services communiquent fréquemment : le service de preprocessing envoie les features au service d’inférence, qui envoie les résultats au service de post-processing. gRPC est le choix naturel pour ces communications internes à haute fréquence et faible latence.

TensorFlow Serving et le standard KServe

TensorFlow Serving, l’un des premiers runtimes de model serving, a standardisé une API gRPC pour l’inférence. KServe a adopté une API similaire (V2 Inference Protocol) qui est maintenant supportée par Triton, TorchServe et d’autres runtimes. Ce standard permet de remplacer un runtime par un autre sans modifier le code client.

gRPC et service mesh

gRPC s’intègre nativement avec les service meshes (Envoy, Istio, Linkerd). De plus, gRPC supporte xDS, le protocole de contrôle utilisé par Envoy, ce qui permet le « proxyless service mesh » : les clients gRPC gèrent directement le service discovery, le load balancing, le circuit breaking et le traffic shifting sans proxy sidecar. Cela réduit la latence et la complexité par rapport à un service mesh traditionnel avec proxy.

Implémenter un service gRPC en Python

# Installation
pip install grpcio grpcio-tools

# Génération du code depuis le fichier .proto
python -m grpc_tools.protoc 
  -I. --python_out=. --grpc_python_out=. 
  model_service.proto

# Serveur gRPC minimal
import grpc
from concurrent import futures
import model_service_pb2 as pb2
import model_service_pb2_grpc as pb2_grpc

class ModelServicer(pb2_grpc.ModelServiceServicer):
    def Predict(self, request, context):
        # Votre logique d'inférence ici
        predictions = run_model(request.model_id, request.features)
        return pb2.PredictResponse(
            predictions=predictions,
            confidence=0.95,
            latency_ms=12
        )

server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
pb2_grpc.add_ModelServiceServicer_to_server(ModelServicer(), server)
server.add_insecure_port("[::]:50051")
server.start()
server.wait_for_termination()

gRPC-Web pour les navigateurs Les navigateurs ne supportent pas nativement HTTP/2 gRPC (pas d’accès aux frames HTTP/2 de bas niveau). gRPC-Web est un protocole intermédiaire qui fonctionne via un proxy (Envoy, ou le support intégré d’ASP.NET Core). Le proxy traduit entre gRPC-Web (compatible navigateur) et gRPC natif. C’est la solution pour exposer des services gRPC à des frontends web.

Bonnes pratiques

Concevez vos .proto pour l’évolution. Ne réutilisez jamais un numéro de champ supprimé. Ne changez jamais le type d’un champ existant. Ajoutez de nouveaux champs avec de nouveaux numéros. Utilisez reserved pour marquer les champs supprimés. Ces règles garantissent la compatibilité entre versions.

Utilisez des deadlines (timeouts). Chaque appel gRPC doit avoir une deadline. Sans timeout, un service lent peut bloquer l’appelant indéfiniment. Le client fixe la deadline, le serveur la lit depuis le contexte et la propage aux appels en aval.

Implémentez les interceptors. Les interceptors gRPC (équivalent des middlewares REST) centralisent le logging, l’authentification, le tracing et la gestion des erreurs. Ne dupliquez pas cette logique dans chaque handler.

Utilisez les status codes gRPC. gRPC a son propre système de codes d’erreur (OK, INVALID_ARGUMENT, NOT_FOUND, PERMISSION_DENIED, INTERNAL, DEADLINE_EXCEEDED, UNAVAILABLE…). Utilisez-les correctement plutôt que de retourner OK avec un champ d’erreur dans la réponse.

Versionez vos .proto dans un registre. Utilisez un Buf Schema Registry ou un repository dédié pour centraliser les définitions .proto. Les CI bots vérifient la compatibilité ascendante et la conformité aux conventions de nommage avant chaque merge.

Sécurité gRPC

gRPC supporte nativement TLS pour le chiffrement du transport. En production, toujours utiliser TLS (ou mTLS pour la communication inter-services). Les mécanismes d’authentification courants :

Token-based (JWT/OAuth). Le client inclut un token dans les métadonnées gRPC (équivalent des headers HTTP). Le serveur valide le token via un interceptor. C’est l’approche la plus courante pour les API authentifiées.

Mutual TLS (mTLS). Le client et le serveur s’authentifient mutuellement via des certificats TLS. C’est le standard pour la communication Zero Trust entre microservices. Les service meshes (Istio, Linkerd) configurent mTLS automatiquement.

API Key. Un identifiant passé dans les métadonnées. Simple mais moins sécurisé que mTLS ou OAuth. Adapté aux environnements internes à faible risque.

Observabilité

gRPC s’intègre nativement avec OpenTelemetry pour le tracing distribué. Chaque appel RPC est automatiquement tracé avec les métadonnées (service, méthode, durée, code de statut). Les interceptors gRPC ajoutent le tracing sans modifier le code métier.

Les métriques standard à surveiller : latence par méthode (P50, P95, P99), taux d’erreur par code de statut, nombre de requêtes en vol (inflight), et taille des messages. gRPC expose ces métriques nativement via Prometheus dans la plupart des implémentations.

Pour le debugging, les outils comme grpcurl (équivalent de curl pour gRPC), Evans (client gRPC interactif), et Postman (support gRPC ajouté) permettent de tester les services sans écrire de code client. BloomRPC et grpcui offrent des interfaces graphiques.

Quand choisir gRPC

Utilisez gRPC quand : vos microservices communiquent à haute fréquence (des centaines à des milliers d’appels par seconde), vous avez une architecture polyglote (services en Go, Python, Java qui doivent communiquer avec un contrat typé), vous avez besoin de streaming bidirectionnel (chat, tracking temps réel, génération LLM), ou la latence est critique (serving ML, trading, jeux).

Préférez REST quand : l’API est publique et doit être accessible depuis des navigateurs, la simplicité prime sur la performance, votre équipe n’a pas d’expérience avec protobuf, ou le volume d’appels est faible (quelques centaines par minute).

Le pattern recommandé : gRPC en interne entre les services (haute performance, typage fort), un API gateway qui expose REST/JSON aux clients externes. Envoy peut faire la transcoding gRPC ↔ REST automatiquement, vous permettant d’avoir une seule implémentation serveur gRPC qui sert à la fois les clients internes (gRPC natif) et les clients externes (REST via le proxy).

gRPC et Kubernetes Kubernetes supporte nativement les health checks gRPC depuis la version 1.24. Configurez des gRPC health probes dans vos manifests pour que Kubernetes vérifie l’état de vos services gRPC. KServe et les service meshes exploitent gRPC nativement pour le load balancing et le routing de l’inférence ML.

Erreurs courantes

Pas de deadline. L’erreur la plus dangereuse. Sans deadline, un appel à un service qui ne répond jamais bloque votre service pour toujours. Configurez des deadlines sur tous les appels, côté client.

Utiliser gRPC pour les API publiques. Les navigateurs ne supportent pas gRPC nativement, les développeurs ne peuvent pas tester avec curl, et les outils de documentation sont moins matures que pour REST. Gardez gRPC pour l’interne, exposez REST ou GraphQL aux clients externes.

Fichiers .proto non versionnés. Si vos .proto ne sont pas dans Git avec des checks de compatibilité, un changement involontaire peut casser tous les clients. Traitez les .proto comme du code critique.

Ignorer le backpressure en streaming. Si le client consomme plus lentement que le serveur ne produit, les buffers explosent. gRPC gère le flow control automatiquement, mais votre code applicatif doit respecter les signaux de backpressure.

Questions fréquentes sur gRPC

Quelle est la différence entre gRPC et REST ?

REST utilise HTTP/1.1 (ou HTTP/2), JSON texte, et des endpoints basés sur des URL de ressources. gRPC utilise HTTP/2 avec multiplexing, Protocol Buffers binaires, et des appels de procédure typés. gRPC est 7-10x plus rapide en sérialisation, supporte le streaming bidirectionnel natif, et génère automatiquement le code client/serveur. REST est plus simple, lisible, et universellement supporté (navigateurs, curl). En pratique, gRPC est utilisé entre microservices internes, REST pour les API publiques et les frontends.

gRPC est-il utilisé pour le model serving ML ?

Oui, c’est le protocole de choix pour le serving ML haute performance. NVIDIA Triton, TensorFlow Serving, TorchServe et KServe supportent tous gRPC nativement. Le V2 Inference Protocol de KServe définit une API gRPC standard pour l’inférence, compatible entre runtimes. gRPC est préféré à REST pour le serving ML car la sérialisation binaire est plus efficace pour les tenseurs et les embeddings volumineux.

Peut-on utiliser gRPC depuis un navigateur ?

Pas directement. Les navigateurs ne supportent pas les fonctionnalités HTTP/2 de bas niveau requises par gRPC. gRPC-Web est un protocole intermédiaire qui nécessite un proxy (Envoy ou ASP.NET Core) pour traduire entre le navigateur et les services gRPC. Pour les frontends web, REST ou GraphQL restent plus simples. gRPC-Web est une solution viable quand vous voulez un contrat typé unique entre frontend et backend.

Quels langages supportent gRPC ?

gRPC supporte officiellement C++, Java, Python, Go, C#, Node.js, Ruby, Dart, Kotlin, Swift, PHP et Objective-C. Des implémentations communautaires existent pour d’autres langages. L’avantage clé : un fichier .proto unique génère des stubs pour tous ces langages, ce qui en fait le choix naturel pour les architectures polyglotes où des services en Go, Python et Java doivent communiquer.

gRPC est-il plus rapide que REST ?

Oui, significativement pour la sérialisation et le transport. Les payloads protobuf sont 30-70% plus petits que JSON, et la sérialisation binaire est nettement plus rapide que le parsing JSON. Le multiplexing HTTP/2 réduit l’overhead de connexion. Dans les benchmarks, gRPC est typiquement 7-10x plus rapide que REST/JSON pour le même payload. Cependant, la différence est surtout pertinente pour les communications à haute fréquence entre services. Pour une API appelée quelques fois par seconde, la performance brute de gRPC n’est pas un facteur décisif.