Axum vs Actix-web : quel framework pour un backend Rust en production ?

Axum et Actix-web tournent tous deux sur Tokio, le runtime asynchrone de référence en Rust. Le README d'Actix-web l'affirme sans détour — « Full Tokio compatibility » — et son exemple officiel de code n'utilise aucun acteur du framework actix historique : un handler async fn classique, annoté #[get(...)], suffit. La confusion « Actix-web nécessite obligatoirement des acteurs » ne correspond plus à l'API actuelle.

Axum, lui, est né dans l'orbite directe de Tokio : le dépôt appartient à l'organisation GitHub tokio-rs, et sa documentation officielle est sans ambiguïté — « axum is designed to work with tokio and hyper. Runtime and transport layer independence is not a goal, at least for the time being. »

Ce n'est donc pas un choix entre deux runtimes concurrents, mais entre deux façons de construire une API HTTP au-dessus du même moteur async. Cette comparaison couvre quatre terrains vérifiables — modèle de middleware, sécurité mémoire déclarée, surface HTTP native, adoption mesurée sur crates.io et GitHub — puis explique, code à l'appui, pourquoi le cœur Rust d'Aurabase a choisi Axum.

Axum ne construit aucun système de middleware propriétaire. Il s'appuie entièrement sur tower::Service : timeouts, tracing, compression, autorisation — tout arrive « gratuitement » via l'écosystème Tower, selon son propre README. Un middleware écrit pour une application Hyper ou Tonic se réutilise tel quel dans une application Axum, sans adaptation.

Actix-web prend le chemin inverse : il embarque son propre système de middlewares (Logger, Session, CORS…), documentés dans son guide utilisateur, avec son propre client HTTP associé (awc). C'est une plateforme plus intégrée — moins de pièces à assembler, mais aussi moins de réutilisation directe avec le reste de l'écosystème Rust async générique.

Le routage suit la même logique de composition explicite. Axum revendique une « API sans macro » pour déclarer les routes — Router::new().route(...) reste une valeur Rust ordinaire — là où Actix-web s'appuie sur des macros dédiées par méthode HTTP (#[get(...)]) posées directement au-dessus du handler. Deux styles de déclaration, pas une différence de capacité.

Axum revendique #![forbid(unsafe_code)] dans son code source : 100 % du framework est écrit en Rust sûr, sans échappatoire. Actix-web ne fait pas de déclaration équivalente dans son README — cela ne signifie pas que le framework est dangereux, seulement qu'aucune garantie de ce type n'est publiquement affichée par le projet.

Les deux frameworks fixent une version minimale de Rust différente : Axum est compatible à partir de Rust 1.80, Actix-web exige Rust 1.88. Une fenêtre plus étroite pour Actix-web, qui peut compter si votre chaîne d'outils est figée sur une version plus ancienne.

Actix-web liste une surface HTTP large directement dans son crate : HTTP/1.x et HTTP/2, WebSockets, compression transparente (br, gzip, deflate, zstd), TLS via OpenSSL ou Rustls. Tout est livré ensemble, sans dépendance supplémentaire à choisir.

Axum reste volontairement minimal : routage, extracteurs, gestion d'erreurs — le reste (compression, CORS, limitation de requête, traçage) vient de tower-http, un crate compagnon du même écosystème. Aurabase, par exemple, n'active que les fonctionnalités cors, trace, compression-gzip, request-id, timeout et limit de tower-http — une sélection délibérée, pas la totalité du paquet.

Actix-web revendique sa vitesse en citant une source externe précise : « One of the fastest web frameworks available according to the TechEmpower Framework Benchmark » (round r21, composite), avec un lien direct vers techempower.com dans son propre README. C'est le type de citation qu'on peut vérifier soi-même.

Axum ne fait pas de revendication comparable. Son README se limite à une affirmation plus modeste — « axum is a relatively thin layer on top of hyper and adds very little overhead » — avec deux liens vers des benchmarks communautaires tiers, pas un chiffre officiel du projet.

Sur crates.io, Axum cumule 436 464 896 téléchargements au total, dont 109 000 226 sur les 90 derniers jours. Actix-web cumule 78 074 020 téléchargements au total, dont 9 730 975 sur la même fenêtre récente (crates.io, consulté le 23 août 2026). Sur ce point, l'écart est net : Axum reçoit aujourd'hui environ 11 fois plus de téléchargements récents qu'Actix-web.

Le paradoxe : Actix-web est le plus ancien des deux, publié sur crates.io depuis octobre 2017, contre juillet 2021 pour Axum. Sur GitHub, l'écart de popularité est plus resserré — 26 931 étoiles pour tokio-rs/axum contre 24 793 pour actix/actix-web (GitHub, consulté le 23 août 2026) — et Actix-web garde plus de forks (1 880 contre 1 462), signe d'une base de contributeurs historiques toujours active.

Actix-web reste loin d'être à l'abandon : sa version 4.15.0 a été publiée le 21 août 2026, trois jours avant la rédaction de cet article. Sur la file d'issues GitHub, Axum affiche 75 tickets ouverts contre 192 pour Actix-web — un signal d'entretien à lire avec prudence : un historique près de quatre ans plus long mécanise une file plus longue, ce n'est pas la preuve d'un projet moins soigné.

Le workspace Cargo racine d'Aurabase compte onze services. Dix dépendent directement d'Axum — de la passerelle API (aura-gateway) au moteur d'IA native (aura-ai), en passant par l'authentification et le stockage. Le onzième, aura-migrator, est un outil CLI de migration sans serveur HTTP : il n'a simplement rien à choisir. Aucun Cargo.toml du dépôt — ni aucune entrée du Cargo.lock racine — ne déclare actix-web, même en dépendance transitive ; et aucun fichier .rs ne contient d'instruction use actix_web::.

axum       = { version = "0.8", features = ["ws", "multipart", "macros"] }
tower      = { version = "0.5", features = ["full"] }
tower-http = { version = "0.6", features = ["cors", "trace", "compression-gzip", "request-id", "timeout", "limit"] }
hyper      = { version = "1", features = ["full"] }

Ce choix n'est pas cosmétique : la passerelle Aurabase (aura-gateway) empile ses middlewares avec tower::ServiceBuilder et des Layer Tower — TraceLayer, TimeoutLayer, RequestBodyLimitLayer — complétés par des couches maison via axum::middleware::from_fn pour l'identifiant de requête, l'authentification et les en-têtes de sécurité. C'est exactement le modèle de composition que le README d'Axum met en avant : un middleware Tower s'empile, se teste et se réutilise indépendamment du reste du routeur.

Sources : crates.io API (/api/v1/crates/axum, /api/v1/crates/actix-web) et GitHub API, consultées le 23 août 2026. READMEs officiels tokio-rs/axum et actix/actix-web pour le reste.

Vous démarrez un backend Rust modulaire, multi-services. Axum s'aligne naturellement — sa composition Tower facilite le partage de middlewares entre services, comme le fait Aurabase entre ses dix services HTTP.

Vous avez une base de code Actix-web existante et fonctionnelle. Il n'y a pas d'urgence à migrer. Actix-web reste maintenu activement et couvre HTTP/2, WebSockets et compression nativement, sans dépendance supplémentaire.

Vous voulez un maximum de fonctionnalités HTTP livrées en un seul crate, sans assembler tower-http vous-même. Actix-web répond directement à ce besoin.

Vous partagez déjà des middlewares Tower avec d'autres services Hyper ou Tonic (gRPC). Axum réutilise ces couches telles quelles — c'est l'argument qui a pesé chez Aurabase.