Go ou Rust pour un backend ? Comment choisir quand on aime les deux

Un langage ne se choisit pas dans l’absolu. Il se choisit contre des contraintes. Voici le projet, et les quatre contraintes qui ont fait tout le travail.

Une application mobile, et ses trois publics

Le projet est une application mobile native, pour iOS et Android. Son backend fait ce que font la plupart des backends : authentifier, stocker, synchroniser, notifier. Rien d’exotique, et c’est justement ce qui rend le choix intéressant : ni Go ni Rust n’est disqualifié d’office. Ce backend sert trois publics :

L’application est de loin le plus gros consommateur, et elle parle depuis un réseau mobile qui va et vient. Gardez ce schéma en tête : il reviendra au § 2.

Quatre contraintes, qui tirent chacune de leur côté

La batterie se joue dans le contrat, pas dans le langage

Arrêtons-nous sur la batterie, parce que c’est là que se cache l’argument le plus contre-intuitif de l’article. Après chaque échange, la radio cellulaire, l’un des composants les plus gourmands du téléphone, ne se rendort pas tout de suite : elle reste éveillée plusieurs secondes, au cas où d’autres données arriveraient (les chercheurs parlent de « queue », tail). Dix petites requêtes espacées coûtent donc bien plus cher qu’une seule, même pour le même volume :

Relisez la liste de ce que la batterie demande au backend : messages compacts, peu d’allers-retours, connexion réutilisée, pousser plutôt qu’être interrogé. Le langage du backend n’y apparaît nulle part. Ce qui y apparaît, c’est le protocole. Voilà pourquoi j’ai choisi le protocole avant le langage, et pourquoi ce premier choix a pesé lourd dans le second.

Ce que le projet n’est pas

Dans un ADR, ce qu’on exclut compte autant que ce qu’on retient. Trois « non » ont beaucoup pesé :

Si l’un de ces trois « non » avait été un « oui », cet article aurait probablement une autre conclusion. Je vous montrerai lequel au § 4, curseurs à l’appui.

Avant de choisir le langage, il fallait choisir comment l’application parlerait à son serveur. Sur le moment, je n’ai même pas réfléchi : j’ai pris REST, comme toujours. C’est en le confrontant aux contraintes du § 1 que j’ai commencé à douter.

Le réflexe : REST

REST, je l’ai utilisé dans presque tous mes projets, et c’est sans doute votre cas aussi. Le rappel tient en une image :

Simple, universel, compris par tous les outils, du navigateur à curl. Mais quand j’ai relu ce que la batterie demande au backend, aucune case n’était cochée d’office :

• Des messages compacts ? Le JSON répète le nom de chaque champ, dans chaque message.
• Un contrat partagé par le serveur et les deux applications ? OpenAPI existe, mais il est facultatif, et souvent écrit après coup.
• Un serveur qui prévient quand quelque chose change ? Par défaut, c’est l’application qui doit demander.

Rien d’insurmontable : on peut compresser, générer les clients, ajouter une WebSocket. Mais chaque fois, c’est une brique de plus, à poser soi-même, des deux côtés. Je me suis donc demandé s’il existait un protocole qui fasse tout cela par construction.

Ce que j’ai trouvé à côté

Deux noms revenaient sans cesse.

GraphQL résolvait surtout un problème de forme des données, que je n’avais pas. gRPC, je le connaissais mal : je suis allé voir de plus près.

gRPC, en deux minutes

gRPC vient de RPC, pour Remote Procedure Call, l’appel de procédure à distance : au lieu de construire une requête HTTP, l’application appelle une fonction, et c’est le serveur qui l’exécute. Tout part d’un contrat, un fichier .proto, qui décrit au même endroit les données et les fonctions :

syntax = "proto3";
package app.sync.v1;

// Un seul fichier décrit tout le contrat : les données ET les appels.

// ── 1. Les messages : les données échangées, champ par champ ──
message SyncRequest {
  string device_id = 1;        // chaque champ a un type…
  int64 since_version = 2;     // …et un numéro : c’est lui, pas le nom, qui voyage
  repeated Change changes = 3; // une liste de changements
}

message SyncResponse {
  int64 version = 1;
  repeated Change changes = 2;
}
// (Change, WatchRequest et Event se déclarent de la même façon.)

// ── 2. Le service : les fonctions que l’application peut appeler ──
service SyncService {
  // Envoyer ses changements et recevoir ceux du serveur, en un seul aller-retour.
  rpc Sync(SyncRequest) returns (SyncResponse);
  // Tant que l’application est au premier plan, le serveur pousse ce qui change.
  rpc Watch(WatchRequest) returns (stream Event);
}

De ce seul fichier, des générateurs tirent le code de chaque côté :

À l’exécution, l’application appelle la fonction comme si elle était locale. Le code généré s’occupe du réseau : un format binaire compact, Protocol Buffers, sur une connexion HTTP/2 ouverte une fois.

Ce qui m’a convaincu

Ce n’est pas la vitesse qu’on prête à gRPC qui m’a arrêté. C’est le contrat. Un champ renommé casse la compilation, pas la production. Et les règles de compatibilité de Protocol Buffers (on ajoute des champs, on ne réutilise jamais un numéro) laissent évoluer l’API sans casser les anciennes versions de l’application, qui resteront installées des mois sur certains téléphones.

Restait à le confronter aux contraintes du § 1. Premier test, la taille des messages :

Le reste tient dans un tableau. Sur presque chaque ligne, gRPC fait par construction ce que REST demande d’ajouter :

GraphQL gardait un atout, la liberté du client. Mais mon problème, c’était la batterie, et sur ce terrain, gRPC partait avec plusieurs longueurs d’avance.

Ce que gRPC coûte

Je me méfie des articles qui présentent gRPC comme une évidence. J’ai donc regardé l’envers du décor :

Le vrai problème : les navigateurs

Restait le panneau d’administration. Il vit dans un navigateur, et un navigateur ne donne pas au JavaScript le contrôle d’HTTP/2 dont gRPC a besoin : il faut passer par gRPC-Web ou par le protocole Connect, avec un proxy ou un serveur compatible. Faisable, mais je voulais le bon outil à chaque endroit, pas un outil qu’on tord pour qu’il aille partout.

Or, dans un navigateur, le bon outil, c’est REST : du JSON lisible, curl pour tester, OpenAPI pour documenter. Même constat pour les services tiers, qui envoient leurs webhooks en JSON et ne parleront jamais notre protobuf.

gRPC d’abord, REST là où il le faut

C’est la réponse que j’ai retenue. Reprenons le schéma du § 1, avec les deux protocoles :

L’application parle gRPC : c’est presque tout le trafic. REST garde ce qui parle HTTP par nature : le navigateur, les webhooks, et quelques besoins des téléphones eux-mêmes, comme les fichiers des liens universels ou le téléversement de gros fichiers.

gRPC, pour l’application

Côté application, le contrat tient dans les deux appels du .proto : Sync regroupe tout en un aller-retour, Watch laisse le serveur pousser. Leur rythme suit celui de l’application :

1. Au premier planWatch est ouvert

   Le serveur pousse ce qui change. Fini le « y a-t-il du nouveau ? » toutes les trente secondes.

2. En arrière-planLe système suspend l’application

   Le flux finit par se fermer. Si quelque chose d’important arrive, une notification push (APNs, FCM) prend le relais.

3. Au retourSync, puis Watch

   Un seul aller-retour rattrape ce qui a été manqué, et le flux reprend.

Pourquoi ce mélange pèse sur le choix du langage

C’est ici que le protocole rattrape le langage :

• gRPC est le cœur, donc son écosystème devient le critère numéro un. Les deux langages ont une bibliothèque gRPC. La vraie question : est-elle officielle, complète, et sera-t-elle encore la même dans trois ans ?
• REST est secondaire et banal, donc il ne départage presque rien. Les deux langages servent très bien du JSON. C’est un critère qu’on vérifie, pas un critère qui décide.
• Un seul port, donc il faut marier les deux proprement. Un seul service à déployer, un seul certificat, une seule sonde de santé, une seule ligne sur la facture : c’est la contrainte de coûts qui parle. Il faut savoir servir gRPC et REST sur la même adresse, sans proxy de plus.

Je ne vais pas refaire le comparatif qu’on trouve partout, avec ses tableaux de benchmarks et ses listes de fonctionnalités. Voici ce que je regarde, moi, quand je compare deux langages pour un service qui doit vivre longtemps, et pourquoi.

Ce que je ne compare pas

Ce que je compare

Le même code, deux philosophies

Rien ne vaut un exemple. Voici la même fonction métier dans les deux langages : récupérer le profil d’un utilisateur, en refusant les comptes supprimés.

func (s *Service) Profile(ctx context.Context, id string) (*Profile, error) {
	u, err := s.users.Get(ctx, id)
	if err != nil {
		return nil, fmt.Errorf("profil %s : %w", id, err)
	}
	if u.Status == StatusDeleted {
		return nil, ErrNotFound
	}
	// Un nouveau statut ajouté demain ?
	// Rien ne m’obligera à revenir ici.
	return toProfile(u), nil
}

async fn profile(&self, id: UserId) -> Result<Profile, AppError> {
    let user = self.users.get(id).await?; // l’erreur remonte
    match user.status {
        Status::Active => Ok(Profile::from(user)),
        Status::Deleted => Err(AppError::NotFound),
        // Un nouveau statut ajouté demain ?
        // Le code ne compile plus tant
        // qu’on ne l’a pas traité ici.
    }
}

Le code Go est plus long, et tout est sous vos yeux : chaque erreur, chaque retour. Un développeur qui n’a jamais écrit de Go le comprend en le lisant. Le code Rust est plus dense et plus sûr : l’erreur est typée, l’oubli d’un cas est impossible. Mais une partie du travail est ailleurs (la conversion des erreurs vers AppError, définie une fois pour toutes), et il faut connaître le langage pour la voir.

Aucun des deux n’est « meilleur ». Go optimise pour la personne qui lit le code sans le connaître. Rust optimise pour la personne qui le modifie dans six mois sans tout se rappeler. Les deux ont raison ; la question est de savoir laquelle de ces deux personnes votre projet a le plus besoin de protéger. Et pour moi, un critère récent a fait pencher la réponse.

On n’écrit jamais un backend avec un langage seul. On l’écrit avec un compilateur, des bibliothèques, des outils, des habitudes et des gens. C’est cet ensemble que j’ai comparé, critère par critère, avec une question simple à chaque fois : lequel sert le mieux ce projet ?

Le résumé, sur une page

Vu comme ça, Go semble gagner largement. C’est trompeur : un tableau compte les lignes, il ne les pèse pas. Or tout le débat est là. Si la latence et la modélisation comptent deux fois plus que le reste pour vous, le tableau ne veut plus rien dire. D’où l’outil ci-dessous.

Avec mes poids, Go l’emporte d’une demi-douzaine de points : une vraie avance, pas un écrasement. Cochez maintenant la case : un seul critère qui bouge d’un point, et l’écart fond de moitié. Voilà, en une case à cocher, pourquoi la décision n’a pas été facile. Voilà aussi pourquoi je la réexaminerai.

Pourquoi Go

1. Le meilleur support de gRPC, aujourd’hui

   C’est la raison qui a fait basculer la balance. gRPC est le cœur du backend, et grpc-go est officiel, complet et stable depuis des années, avec tout l’écosystème qui va autour. Côté Rust, la qualité est là, mais la bibliothèque de référence change de mains. Je ne voulais pas bâtir le cœur du projet sur une transition.

2. Recruter, intégrer, transmettre

   L’équipe va grandir. Avec Go, un bon développeur backend, quel que soit son langage d’origine, sera utile très vite, et la base de code restera lisible par tous, y compris ce que son assistant d’IA y ajoutera. Un projet ne vit pas seulement avec ceux qui l’ont commencé : il vit avec ceux qui le reprennent.

3. Une boucle de retour courte

   Compiler, tester, relancer : en Go, c’est quasi instantané. Au début d’un produit, on change d’avis tous les jours, et la vitesse à laquelle on peut se tromper puis corriger compte plus que la vitesse du binaire.

4. Une surface d’attaque réduite

   TLS, cryptographie, serveur HTTP, tests : la bibliothèque standard couvre l’essentiel. Moins de dépendances, c’est moins de choses à auditer, à mettre à jour, et moins de portes pour une attaque par la chaîne d’approvisionnement. govulncheck fait le reste.

5. Une exploitation sans surprise

   Un binaire statique, une image minuscule, la compilation croisée en une variable d’environnement, le profilage intégré, et une promesse de compatibilité qui me garantit que la montée de version ne sera pas un chantier. Pour une petite équipe, c’est de l’astreinte en moins.

6. Assez rapide, et de mieux en mieux

   Le service attend surtout la base de données. Pour ce profil, Go est largement assez rapide, et son ramasse-miettes s’améliore à chaque version. « Assez rapide » n’est pas une excuse : c’est un critère, à condition de l’avoir vérifié sur sa propre charge plutôt que sur un benchmark.

Ce que je sacrifie, et comment je compense

Je ne vais pas faire semblant : en choisissant Go, je renonce à des choses que j’aime vraiment dans Rust. Mais un renoncement assumé se compense. Voici, pour chacun, ce que j’ai mis en place.

Ce qui me ferait changer d’avis

Une décision qu’on ne peut pas remettre en cause n’est pas une décision, c’est un dogme. Voici les trois événements qui me feraient rouvrir cet ADR :

• Un service qui calcule vraiment. Si un jour le chemin critique contient du traitement lourd (médias, cryptographie intensive, moteur de règles en temps réel), ce service-là sera écrit en Rust.
• Une équipe qui parle déjà Rust. Avec deux ou trois développeurs Rust confirmés dans l’équipe, le critère du recrutement s’effondre, et la pesée change de camp.
• Une crate gRPC officielle mûre en Rust. C’est la case à cocher de la pesée. Le jour où elle sera stable et complète, le critère qui a tout fait basculer deviendra une égalité.

Il n’y a pas de meilleur langage

Je le dis sans détour, parce que c’est le cœur de cet article : il n’existe pas de meilleur langage. Il existe des langages qui font des paris différents. Go parie que la simplicité passe à l’échelle des équipes. Rust parie que la rigueur passe à l’échelle des systèmes. Les deux ont raison, et l’histoire le leur a donné. La bonne question n’est jamais « lequel est le meilleur ? », mais « lequel de ces deux paris mon projet a-t-il besoin de gagner ? ».

Si j’avais construit un proxy réseau, une base de données, un moteur de jeu, un logiciel embarqué ou un module WebAssembly, j’aurais choisi Rust, sans même ouvrir d’ADR. Et, petite ironie : si un jour je veux partager de la logique entre les applications iOS et Android, dans le téléphone, c’est encore vers Rust que je me tournerai, avec des outils comme UniFFI de Mozilla, qui génèrent les liaisons Swift et Kotlin.

Une décision d’architecture ne vaut que par sa mise en œuvre. Voici comment s’assemblent les pièces, avec le code qui compte, et les pièges à connaître avant de s’y lancer.

Vue d’ensemble : un port, deux serveurs, une logique

Le contrat d’abord

Tout part des fichiers .proto, rangés dans un dossier à part et versionnés avec le reste. J’utilise Buf plutôt que protoc directement : une configuration lisible pour générer le code Go (et celui des applications), un linter qui impose des conventions de nommage, et surtout une détection des changements incompatibles. C’est elle qui protège les anciennes versions de l’application installées sur les téléphones.

buf lint                                   # conventions du contrat
buf breaking --against '.git#branch=main'    # aucun changement incompatible avec main
buf generate                               # code Go régénéré ; le diff doit être vide

Chi, pour le REST

Pour le REST, j’ai pris Chi, parce qu’il reste 100 % net/http : ses handlers et ses middlewares sont ceux de la bibliothèque standard, et il n’ajoute que ce qui manque (groupes de routes, sous-routeurs, middlewares éprouvés), sans aucune dépendance. Pourquoi lui plutôt que Gin, Echo ou Fiber ? La comparaison mérite un article à elle seule, et je lui en consacrerai un.

func NewRouter(svc *service.Service, auth *Auth) http.Handler {
	r := chi.NewRouter()
	r.Use(middleware.RequestID, middleware.Recoverer, middleware.Timeout(15*time.Second))

	r.Get("/healthz", healthz)                                         // le répartiteur de charge
	r.With(verifySignature).Post("/webhooks/{provider}", webhook(svc))   // les services tiers
	r.With(auth.Mobile).Post("/mobile/v1/uploads", createUpload(svc)) // une URL pré-signée

	r.Route("/admin/api", func(r chi.Router) {                        // le panneau d’administration
		r.Use(auth.Admin, httprate.LimitByIP(120, time.Minute))
		r.Get("/users", listUsers(svc))
		r.Post("/users/{id}/suspend", suspendUser(svc))
	})
	return r
}

Un seul port : cmux

Reste la pièce qui fait tenir l’ensemble, celle du losange dans le schéma plus haut. cmux lit le début de chaque connexion sans le consommer, et la remet intacte au bon serveur : gRPC si elle porte content-type: application/grpc, HTTP sinon. Je l’ai choisi pour une raison précise : il laisse grpc-go utiliser son propre transport HTTP/2, optimisé pour gRPC, là où les solutions qui passent par le serveur HTTP standard en changent.

func main() {
	ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
	defer stop()

	svc := service.New(/* accès aux données, configuration… */)
	auth := rest.NewAuth(/* clés, sessions… */)

	lis, err := net.Listen("tcp", ":8080")
	if err != nil {
		slog.Error("écoute impossible", "err", err)
		os.Exit(1)
	}

	// Un seul port, deux serveurs : cmux lit le début de chaque connexion et l’aiguille.
	m := cmux.New(lis)
	grpcL := m.MatchWithWriters(
		cmux.HTTP2MatchHeaderFieldSendSettings("content-type", "application/grpc"),
	)
	httpL := m.Match(cmux.Any()) // tout le reste : REST

	grpcSrv := grpc.NewServer(
		grpc.ChainUnaryInterceptor(grpcapi.Recover, grpcapi.Auth, grpcapi.Log),
		grpc.KeepaliveEnforcementPolicy(keepalive.EnforcementPolicy{MinTime: 5 * time.Minute}),
	)
	grpcapi.Register(grpcSrv, svc)
	healthpb.RegisterHealthServer(grpcSrv, health.NewServer())

	var protos http.Protocols
	protos.SetHTTP1(true)
	protos.SetUnencryptedHTTP2(true) // Go 1.24+ : HTTP/2 sans TLS, derrière le répartiteur
	httpSrv := &http.Server{
		Handler:           rest.NewRouter(svc, auth),
		Protocols:         &protos,
		ReadHeaderTimeout: 5 * time.Second,
	}

	g, ctx := errgroup.WithContext(ctx)
	g.Go(func() error { return grpcSrv.Serve(grpcL) })
	g.Go(func() error { return ignoreClosed(httpSrv.Serve(httpL)) })
	g.Go(func() error { return ignoreClosed(m.Serve()) })
	g.Go(func() error {
		<-ctx.Done() // signal d’arrêt reçu, ou l’un des serveurs est tombé
		grpcSrv.GracefulStop()
		sctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
		defer cancel()
		err := httpSrv.Shutdown(sctx)
		m.Close()
		return err
	})
	if err := g.Wait(); err != nil {
		slog.Error("arrêt sur erreur", "err", err)
		os.Exit(1)
	}
}

// Un serveur qu’on arrête volontairement n’est pas une erreur.
func ignoreClosed(err error) error {
	if errors.Is(err, http.ErrServerClosed) || errors.Is(err, net.ErrClosed) || errors.Is(err, cmux.ErrListenerClosed) {
		return nil
	}
	return err
}

Les pièges à connaître

Les alternatives que j’ai écartées (pour l’instant)

L’arborescence et l’image

backend/
├── proto/            # le contrat : .proto, buf.yaml, buf.gen.yaml
├── gen/              # code généré, jamais modifié à la main
├── cmd/server/       # main.go : un binaire, un port
├── internal/
│   ├── service/      # la logique métier, sans gRPC ni HTTP
│   ├── grpcapi/      # adaptateurs gRPC → service
│   ├── rest/         # Chi : admin, webhooks, mobile
│   └── store/        # accès aux données
└── Dockerfile

FROM golang:1.26 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -trimpath \
    -ldflags="-s -w" -o /server ./cmd/server

FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=build /server /server
EXPOSE 8080
ENTRYPOINT ["/server"]

La règle d’or de cette arborescence tient en une phrase : internal/service ne connaît ni gRPC ni HTTP. Les adaptateurs traduisent les messages protobuf et les requêtes JSON en appels de service, et les erreurs de service en codes gRPC ou HTTP. C’est ce qui permet d’ajouter une porte, ou d’en fermer une, sans toucher au métier. Et c’est aussi ce qui rendrait possible, un jour, de réécrire un service en Rust derrière le même contrat.

Un ADR honnête se termine par ses conséquences, bonnes et mauvaises. C’est la section que relira celui qui voudra, un jour, défaire cette décision. Autant lui faciliter le travail.

À vous de jouer

Je ne prétends pas avoir la seule bonne réponse, seulement la mienne, pour ce projet. Voici les questions que je me pose encore. J’aimerais beaucoup lire les vôtres.