Quel framework Rust choisir ? Quand aucun ne s’impose

Une application backend a une mission principale : recevoir des requêtes, les traiter, et répondre. Ces requêtes arrivent presque toujours en HTTP, le protocole du web : c’est le cas d’une API REST, appelée par un navigateur ou une application mobile.

Prenons un exemple qui nous suivra tout l’article : mon-api, un petit service fictif écrit en Rust. Il sert des articles. Un client lui demande l’article n° 42. Suivons sa requête, de son arrivée à la réponse :

Les étapes 1 à 4 se ressemblent d’une application à l’autre, et personne n’a envie de les réécrire à chaque fois. C’est le rôle du framework :

Dans le schéma, pourtant, une seule étape porte la couleur du framework. Les trois premières sont fournies par des fondations : des bibliothèques partagées par presque tous les frameworks Rust, et que la bibliothèque standard, elle, ne fournit pas. Comparons avec Java, où c’est le framework qui fait tout :

Où vivent ces couches : les crates

Ce qu’on peut confier au framework

Tous les frameworks n’en font pas autant. Les plus minimalistes s’arrêtent au routage et à la lecture des requêtes ; les plus intégrés décident aussi de la base de données, des tâches de fond, voire de l’interface. Chaque décision qu’il prend est une décision que vous n’aurez pas à prendre, et une décision que vous ne pourrez plus prendre autrement.

Ces deux idées, ce que le framework remplace dans les fondations et ce qu’on lui confie au-dessus, deviendront les deux premiers critères de la partie 3.

L’absence d’un grand framework en Rust n’est ni un retard ni un accident. Elle découle de choix faits par le langage, et d’une histoire mouvementée. Les deux expliquent pourquoi, dans le trajet de la partie 1, ce sont les fondations qui font l’essentiel du travail.

Une bibliothèque standard qui s’arrête avant le réseau

La partie 1 l’a montré : la bibliothèque standard de Rust ne fournit aucune étape du trajet. Comparez-la à celle de Go, l’autre langage où aucun framework ne s’est imposé :

C’est un choix assumé : ce qui entre dans la bibliothèque standard de Rust y reste pour toujours, avec une promesse de compatibilité sans date de fin. Or HTTP bouge (HTTP/2, puis HTTP/3), et la bonne façon d’exécuter du code asynchrone dépend de la machine, du serveur au microcontrôleur. Rust a donc laissé tout cela aux crates. Et dès qu’il y a dépendance, il y a choix.

L’asynchrone est arrivé tard, et son moteur est resté dehors

Les mots-clés async et await ne sont stables en Rust que depuis novembre 2019 (version 1.39). Le langage définit ce qu’est une tâche asynchrone, mais pas qui l’exécute : il faut un runtime, et pendant des années, deux se sont disputé la place, tokio et async-std. Une bibliothèque écrite pour l’un ne marchait pas toujours avec l’autre, et chaque framework devait parier.

tokio a gagné : version 1.0 en décembre 2020, puis adoption générale. En février 2025, async-std a été officiellement arrêté. Tide, le framework web bâti dessus, n’a plus publié de version depuis décembre 2021 : retenez ce nom, il reviendra comme une leçon.

Les fondations ne sont stables que depuis peu : hyper, la bibliothèque HTTP de presque tout le monde, n’a publié sa 1.0 qu’en novembre 2023. Spring Boot a été bâti sur une plateforme Java vieille de près de vingt ans ; les frameworks Rust, pendant que le sol bougeait encore. Aucun n’a eu le temps d’écraser les autres.

Pas de réflexion, donc pas de magie à l’exécution

La puissance de Spring repose en grande partie sur la réflexion : la capacité d’un programme Java à s’inspecter pendant qu’il tourne. Au démarrage, Spring parcourt vos classes, lit leurs annotations et injecte les dépendances là où vous les avez demandées. On annote, et ça marche.

Rust n’a pas de réflexion à l’exécution : un framework ne peut pas « découvrir » votre code au démarrage. Tout se résout à la compilation, par les types, les traits et les macros. Comparez :

@RestController
class ArticleController {
    // injecté au démarrage, par réflexion
    @Autowired ArticleRepository repo;

    @GetMapping("/articles/{id}")
    Article get(@PathVariable long id) {
        return repo.findById(id).orElseThrow();
    }
}

// une fonction ordinaire : ses paramètres disent
// ce qu’elle attend, et le compilateur le vérifie
async fn article(
    State(db): State<Db>,
    Path(id): Path<u64>,
) -> Result<Json<Article>, StatusCode> {
    db.find(id).await.map(Json).ok_or(StatusCode::NOT_FOUND)
}
// … et c’est vous qui passez l’état au routeur :
// Router::new().route(…).with_state(db)

Côté Spring, le framework fait un travail énorme et invisible. Côté Rust, pas de conteneur d’injection : l’état est passé explicitement, et la signature de la fonction est le contrat. Si un paramètre ne peut pas être extrait de la requête, le code ne compile pas. D’où l’idée la plus importante de cette partie :

En Rust, le système de types fait une partie du travail qu’un framework fait ailleurs. Le framework n’a plus besoin d’être une plateforme : il peut se contenter d’être un routeur bien typé.

Une culture de la composition

L’écosystème Rust a pris très tôt l’habitude des petites crates qui font une seule chose, très bien : serde pour sérialiser, tracing pour les journaux et les traces, sqlx pour la base de données. Aucune n’appartient à un framework, et c’est voulu. Faiblesse, parce qu’il faut assembler soi-même ; force rare, parce qu’on remplace une brique sans changer de maison. Le reste de l’article consiste à savoir laquelle des deux compte le plus pour vous.

Ce que cette histoire a produit : des fondations communes

Résultat : dans presque tout backend Rust en production, on retrouve les mêmes étages, ceux des étapes 1 à 4 du trajet. Le framework se pose dessus, et ce n’est pas lui le plus épais. Le schéma ci-dessous les montre pour chaque framework, avec les couleurs de la partie 1 :

pub trait Service<Request> {
    type Response;
    type Error;
    type Future: Future<Output = Result<Self::Response, Self::Error>>;

    // « Es-tu prêt à recevoir une requête ? » : la contre-pression fait partie du contrat.
    fn poll_ready(&mut self, cx: &mut Context<'_>) -> Poll<Result<(), Self::Error>>;

    // Traiter la requête : la réponse arrivera plus tard.
    fn call(&mut self, req: Request) -> Self::Future;
}

La conséquence est décisive : dans le monde tower, un middleware est simplement un service qui en enveloppe un autre (une Layer). Écrite une fois, une couche enveloppe n’importe quel service, quel que soit le framework :

let app = Router::new()
    .route("/articles/{id}", get(article))
    .layer(CompressionLayer::new())      // tower-http : gzip, brotli…
    .layer(CorsLayer::permissive())      // tower-http : en-têtes CORS
    .layer(TraceLayer::new_for_http());  // tower-http : une trace par requête, via tracing
// Les mêmes couches peuvent envelopper un serveur gRPC tonic.

Voilà le secret de l’ascension d’axum, publié en 2021 seulement : il est arrivé sur un écosystème qui existait déjà, et qui n’attendait qu’un routeur. axum n’est pas un framework qui a créé son écosystème : c’est un écosystème qui a trouvé son framework.

Deux familles, et quelques indépendants

Selon les étages que chaque framework réutilise ou réinvente, le paysage se range en deux familles : la famille tower, qui partage ses middlewares avec tout l’écosystème, et les indépendants, qui ont chacun leur propre modèle, parfois très réussi, mais à part.

Ce tableau n’a l’air de rien. Il contient pourtant le critère le plus structurant de cet article, et le moins discuté. On y revient dans la partie 3.

Ce que ça change pour vous

Pour comparer des outils aussi différents, il faut une grille. Huit critères la composent. Les deux premiers découlent directement de la partie 2 et dessinent la carte des candidats ; les six autres la précisent. Et celui qu’on cite toujours en premier, la vitesse, n’en fait presque pas partie.

1. 1La distance aux fondations communes
2. 2Le niveau d’intégration
3. 3La maintenance
4. 4La stabilité de l’API
5. 5Le modèle d’exécution
6. 6Les erreurs de compilation
7. 7Le contrat d’API
8. 8L’équipe
9. ✕La vitesse brute

1La distance aux fondations communes, le critère par excellence

L’écosystème Rust s’est unifié sous le framework, dans tokio, hyper et tower. Un framework Rust se juge donc d’abord à ce qu’il en garde :

Cette distance a deux prix :

Le jour du départ arrive plus souvent qu’on ne le croit. C’est ce qui est arrivé à Tide :

Comment la mesurer : le modèle de middleware

La distance se lit en une ligne, à l’étape 3 du trajet : ce qu’il faut implémenter pour écrire un middleware. Le contrat commun de tower, ou un modèle maison ? Voici la réponse de chaque framework :

Voici ce que cela change pour deux projets identiques, l’un écrit avec axum, l’autre avec Actix Web, au moment de les quitter :

Ce n’est pas un défaut : c’est un échange. Mais il se décide le premier jour, pas le jour du départ.

2Le niveau d’intégration, le second axe

Rust vous livre le backend en kit. Certains frameworks vous livrent les pièces et la notice ; d’autres, le meuble déjà monté. Ce sont les huit décisions de la partie 1, posées sur une ligne :

Vers la droite, on gagne du temps au début, et l’on dépend des choix de quelqu’un d’autre : Loco a choisi SeaORM pour vous, un cadeau si vous n’aviez pas d’avis, une contrainte si vous préfériez sqlx. Vers la gauche, on écrit plus de code d’assemblage, mais ce code est le vôtre. Et les deux axes sont indépendants : Loco est loin sur celui-ci, mais tout près des fondations sur le premier, puisqu’il est bâti sur axum.

Les six autres critères

Une fois ces deux axes posés, reste à savoir ce que vaut chaque framework au quotidien. Six critères le disent.

Et la vitesse ?

Tous ces frameworks sont très rapides. Sur un serveur qui renvoie une chaîne de caractères, Actix Web tire souvent un léger avantage de son runtime par cœur ; sur un vrai service, qui interroge une base et sérialise du JSON, ces écarts se noient dans le reste. La vitesse brute rejoint donc ce qui ne devrait pas peser :

Si la performance compte vraiment, une seule méthode : un prototype de l’endpoint le plus chargé, dans deux frameworks, avec la vraie base et une charge réaliste. Une journée de travail, qui vaut mieux que cent benchmarks lus sur Internet.

Avec ces critères en main, on peut reformuler la question de départ.

La première question n’a pas de réponse : les comparatifs alignent des benchmarks et concluent par « ça dépend », sans jamais dire de quoi. La seconde en a une, différente pour chaque projet. Je dirai aussi lequel j’aime le plus, et pourquoi.

Chaque moitié de la bonne question se pèse avec les critères de la partie 3 :

Pour l’appliquer, sept questions concrètes, à poser en équipe avant d’écrire la première route. Les réponses désignent presque toujours le bon candidat :

1. Qu’est-ce que les fondations ne me donnent pas ?critères 2 à 8Faites-en la liste, par écrit. Si elle est courte, axum et quelques crates suffisent peut-être.
2. Combien de décisions voulons-nous confier au framework ?critère 2Configuration, base de données, tâches de fond, e-mails : une équipe pressée gagne à les déléguer, une équipe qui a des avis gagne à les garder.
3. Aurons-nous besoin de gRPC, du serverless, d’un middleware que nous n’écrirons pas ?critère 1Si la réponse est « peut-être », la famille tower est une assurance qui ne coûte presque rien.
4. Qui consomme cette API ?critère 7Vos propres applications, ou des partenaires ? Si un contrat publié est un livrable, il peut choisir le framework à votre place.
5. Qui maintiendra ce code ?critères 5, 6 et 8Pas l’équipe d’aujourd’hui : celle de dans trois ans. Ce qu’elle sait de Rust, et ce qu’elle trouvera facilement en ligne.
6. Qui maintient l’outil, et à quel rythme casse-t-il ?critères 3 et 4Date de la dernière version, nombre de mainteneurs actifs, numéro de version : 0.x ou 1.0.
7. Mon code métier importe-t-il le framework ?critère 1La réponse doit être non, quel que soit l’outil choisi. C’est la seule règle qui vaut pour tous les candidats.

Six candidats, rangés du plus proche des fondations communes au plus lointain. Pour chacun : une présentation, sa position sur les huit critères, les situations où il est le plus à sa place, ses défis et ses risques, et mon verdict.

Dans chaque fiche, le même endpoint, replié : GET /articles/{id}, qui lit un article dans une base partagée et renvoie du JSON, ou une 404. Le type Db est le même partout : seul le framework change.

async fn article(
    State(db): State<Arc<Db>>,
    Path(id): Path<u64>,
) -> Result<Json<Article>, StatusCode> {
    db.find(id).await.map(Json).ok_or(StatusCode::NOT_FOUND)
}

#[tokio::main]
async fn main() {
    let app = Router::new()
        .route("/articles/{id}", get(article))
        .with_state(Arc::new(Db::connect().await));
    let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await.unwrap();
    axum::serve(listener, app).await.unwrap();
}

# installer l’outil, puis créer le projet (il pose quelques questions : base, type d’application)
cargo install loco
loco new

# générer le modèle, la migration, le contrôleur et ses routes
cargo loco generate scaffold article titre:string! contenu:text --api
cargo loco start

#[handler]
async fn article(Data(db): Data<&Arc<Db>>, Path(id): Path<u64>) -> poem::Result<Json<Article>> {
    db.find(id).await.map(Json).ok_or_else(|| Error::from_status(StatusCode::NOT_FOUND))
}

#[tokio::main]
async fn main() -> Result<(), std::io::Error> {
    let app = Route::new()
        .at("/articles/:id", get(article))
        .data(Arc::new(Db::connect().await));
    Server::new(TcpListener::bind("0.0.0.0:3000")).run(app).await
}

#[handler]
async fn article(req: &mut Request, depot: &mut Depot) -> Result<Json<Article>, StatusError> {
    let id: u64 = req.param("id").ok_or_else(StatusError::bad_request)?;
    let db = depot.obtain::<Arc<Db>>().map_err(|_| StatusError::internal_server_error())?;
    db.find(id).await.map(Json).ok_or_else(StatusError::not_found)
}

#[tokio::main]
async fn main() {
    let db = Arc::new(Db::connect().await);
    let router = Router::new()
        .hoop(affix_state::inject(db))
        .push(Router::with_path("articles/{id}").get(article));
    let acceptor = TcpListener::new("0.0.0.0:3000").bind().await;
    Server::new(acceptor).serve(router).await;
}

#[get("/articles/<id>")]
async fn article(db: &State<Db>, id: u64) -> Option<Json<Article>> {
    db.find(id).await.map(Json)
}

#[launch]
async fn rocket() -> _ {
    rocket::build()
        .manage(Db::connect().await)
        .mount("/", routes![article])
}

#[get("/articles/{id}")]
async fn article(db: web::Data<Db>, id: web::Path<u64>) -> impl Responder {
    match db.find(id.into_inner()).await {
        Some(a) => HttpResponse::Ok().json(a),
        None => HttpResponse::NotFound().finish(),
    }
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let db = web::Data::new(Db::connect().await);
    HttpServer::new(move || App::new().app_data(db.clone()).service(article))
        .bind(("0.0.0.0", 3000))?
        .run()
        .await
}

Les autres, à connaître

Avant d’adopter un outil hors de cette liste, regardez trois choses : la date de sa dernière version, le nombre de personnes qui fusionnent les contributions, et ce qu’il faut implémenter pour écrire un middleware.

Les téléchargements mentent un peu

Reste la question que tout le monde se pose : qui est le plus utilisé ? crates.io publie le nombre de téléchargements de chaque crate sur les quatre-vingt-dix derniers jours. Le résultat est sans appel, en apparence :

Ces chiffres mesurent l’écosystème plus que le choix. tonic, le framework gRPC, embarque axum par défaut, et pèse à lui seul 102,7 millions de téléchargements ; les méta-frameworks l’embarquent aussi. Retirez tout tonic, ce qui exagère la correction : il reste environ 41 millions, plus de trois fois Actix Web. L’écart est réel, mais moindre qu’il n’y paraît. Il dit surtout qu’axum est devenu une infrastructure, pas seulement un framework.

Les fiches partent des candidats ; la boussole fait le chemin inverse. Elle part de votre projet, pose quatre questions et propose un point de départ : un framework, une alternative, et le bloc [dependencies] de votre Cargo.toml. Elle ne remplace pas le raisonnement des parties précédentes : elle le résume.

Jouez avec les réponses : la ligne du framework change d’un cas à l’autre, les fondations presque jamais. C’est exactement ce que disait la partie 2.

Si vous ne deviez garder qu’une page de cet article, ce serait celle-ci.

1. En Rust, les fondations font l’essentiel

   Le runtime, le serveur HTTP, les middlewares : tokio, hyper et tower les fournissent à presque tous. Le framework n’est qu’une couche fine par-dessus.

2. Le critère par excellence : la distance

   Plus un framework remplace ces fondations par les siennes, plus il en fait à sa façon, moins il hérite de l’écosystème, et plus la sortie coûte. Son modèle de middleware le dit en une ligne.

3. La plus petite distance qui vous suffit

   Listez ce que les fondations ne vous donnent pas, choisissez ce que vous voulez confier au framework, prenez l’outil le plus proche qui couvre tout cela, et gardez le métier à l’abri.

Le fichier, une fois rempli

Voici, concrètement, mon point de départ par défaut. C’est le Cargo.toml de mon-api, vide au début de l’article, une fois rempli :

[dependencies]
# Les fondations (partie 2) : elles ne changent presque jamais.
tokio = { version = "1", features = ["full"] }
serde = { version = "1", features = ["derive"] }
tracing = "0.1"
tracing-subscriber = { version = "0.3", features = ["env-filter"] }

# Le framework (partie 5) : une ligne, et elle est remplaçable.
axum = "0.8"
tower-http = { version = "0.7", features = ["trace", "cors", "compression-gzip"] }

# Mes briques (partie 3) : ce qu’un framework intégré aurait choisi pour moi.
sqlx = { version = "0.9", features = ["runtime-tokio", "postgres"] }
utoipa = "6"
thiserror = "2"

Regardez où est le framework : une ligne sur neuf. Le reste, ce sont des fondations que vous garderiez avec n’importe quel autre choix, et des briques que vous avez choisies vous-même. C’est pour cela qu’aucun ne s’impose : le vrai choix se joue sous le framework. En Rust, votre framework n’est pas une ligne de ce fichier. C’est le fichier tout entier.

Ce que je surveille

À vous de jouer

Je n’ai donné que ma lecture, et mes préférences. J’aimerais beaucoup connaître les vôtres.