Rust n'est pas une religion, et « on réécrit tout en Rust » n'est pas une stratégie, encore moins une réponse à donner en réunion. C'est un arbitrage, ni plus ni moins. Voici quand cet arbitrage devient rationnel — et surtout, quand il ne l'est pas, parce que c'est souvent là que les ennuis commencent.

Le point de départ : Node et Python sont excellents… jusqu'à un certain mur

Pour démarrer un produit, une stack interprétée (Node.js, Python) reste le bon choix par défaut, et je le dis en connaissance de cause : écosystème énorme, prototypage rapide, viviers de recrutement qui ne tarissent jamais. J'en livre encore régulièrement, ce n'est pas un aveu de faiblesse. Le problème n'apparaît pas au démarrage, il apparaît à l'échelle, et il prend concrètement trois formes :

  • Le coût CPU/RAM par requête. Un runtime interprété avec ramasse-miettes (GC) consomme structurellement plus de ressources pour le même travail utile. À faible trafic, on ne le voit pas. À fort trafic, ça finit par se lire directement sur la facture cloud — et personne n'aime découvrir ça a posteriori.
  • Les à-coups de latence. Le GC introduit des pauses non déterministes. Votre p50 peut être impeccable pendant que votre p99 part en vrille — et c'est précisément le p99 que vos utilisateurs sentent passer.
  • Les bugs qui n'apparaissent qu'en production. Types dynamiques, undefined is not a function, conditions de course : toute une classe d'erreurs que le langage ne vous aide pas à éviter en amont, et qu'on découvre toujours au pire moment.

Ce que Rust/Actix-web change concrètement

1. Des performances qui changent la structure de coûts

Sur mes charges de référence (API REST, JSON, autorisation), une stack Rust/Actix-web encaisse dans les 140 000 req/s, là où une stack Node/Fastify équivalente plafonne plutôt autour de 90 000 — avec une empreinte mémoire divisée par environ 7 (à peu près 12 Mo contre 85 Mo). Traduit en langage business, ça veut dire moins d'instances pour absorber le même trafic. Et sur une infrastructure qui tourne 24/7, ce facteur-là ne s'arrête jamais de se répercuter, mois après mois.

Les chiffres exacts dépendront toujours de votre charge réelle, et je me méfie de quiconque vous promet un multiplicateur universel valable partout. Mais l'ordre de grandeur, lui, reste stable et je le retrouve d'un projet à l'autre.

2. La sécurité mémoire garantie à la compilation

C'est probablement l'apport le plus sous-estimé de tous. Le système d'ownership de Rust élimine, avant même que le code ne tourne, les débordements, les use-after-free et une bonne partie des conditions de course. Ce ne sont pas des bugs qu'on corrige plus vite qu'ailleurs : ce sont des bugs qui n'existent tout simplement pas. Pour un service exposé sur internet, ça se traduit aussi en réduction directe de surface d'attaque — et ça, ce n'est pas rien.

3. La prévisibilité

Pas de GC, donc pas de pause surprise qui débarque sans prévenir. La latence reste stable, le comportement sous charge reste prévisible. Pour tout ce qui touche au temps réel, au streaming ou à des SLA serrés, cette prévisibilité-là vaut souvent plus, à mes yeux, que le pic de débit brut qu'on affiche en slide.

Ce que ça coûte — la partie que les évangélistes oublient toujours

Un article honnête ne s'arrête pas aux avantages, il liste aussi ce qui fait mal :

  • La courbe d'apprentissage est réelle, pas juste théorique. L'ownership et le borrow checker déroutent tout le monde les premières semaines, moi y compris à l'époque. Prévoyez un vrai temps d'adaptation pour une équipe qui vient de JavaScript ou de Python — ça ne se règle pas en un week-end.
  • Les temps de compilation. Rust compile lentement sur les gros projets, c'est un fait qu'on ne me fera pas nier. On finit par dompter ça (compilation incrémentale, sccache, découpage en crates), mais ça reste un coût de confort qu'on paie tous les jours.
  • Un écosystème encore jeune. Très solide côté back-end et système, mais toutes les intégrations « clé en main » qu'on trouve dans npm n'ont pas encore leur équivalent partout.
  • Le recrutement. Il y a mécaniquement moins de développeurs Rust sur le marché — même si, dans mon expérience, ceux qui choisissent Rust sont souvent des profils plus seniors.

Quand il ne faut PAS migrer

Je le dis sans détour à mes clients, parce que c'est mon travail de le dire même quand ça ne m'arrange pas commercialement : il y a plusieurs cas où migrer vers Rust serait carrément une erreur.

  • Vous êtes en phase de recherche de product-market fit : votre priorité, c'est la vitesse d'itération, pas le débit serveur. Restez sur ce qui vous fait avancer vite, le reste attendra.
  • Votre charge est modeste et a toutes les chances de le rester : si vos serveurs s'ennuient la moitié du temps, la performance de Rust ne vous achètera rien de concret.
  • Votre équipe est 100 % JS ou Python et le time-to-market prime sur tout : le coût humain de la bascule dépassera largement le gain technique, et ce n'est pas un pari à prendre à la légère.
  • Le goulot d'étranglement, c'est votre base de données ou un appel réseau externe : réécrire la couche applicative en Rust n'y changera strictement rien. Profilez d'abord, décidez ensuite — jamais l'inverse.

La bonne façon de migrer : progressivement

« On fait une grande réécriture » — si vous entendez cette phrase, c'est déjà mal engagé. L'approche que je recommande, et que j'applique moi-même, c'est le strangler pattern :

  1. Profilez pour trouver le vrai point chaud — le service qui coûte le plus cher ou qui tient le pire p99, pas celui qu'on soupçonne à l'instinct.
  2. Réécrivez ce seul service en Rust, derrière la même interface (API REST, gRPC). Le reste du système continue de tourner sans même s'apercevoir du changement.
  3. Mesurez avant/après sur des métriques réelles : débit, p99, coût d'instance, mémoire. On décide avec des chiffres, pas avec des convictions, aussi séduisantes soient-elles.
  4. Itérez service par service, et seulement là où le gain est démontré noir sur blanc.

Vous gardez un système qui tourne à chaque étape, vous limitez le risque à chaque instant, et vous investissez l'effort Rust exactement là où il rapporte — ni plus, ni ailleurs.

En résumé

Rust n'est pas « meilleur que Node » dans l'absolu — cette phrase-là n'a tout simplement pas de sens, et je me méfie de quiconque la prononce sérieusement. Rust est l'outil adapté à un problème précis : des services critiques, à fort trafic, où la performance, la prévisibilité et la sécurité mémoire ont une valeur qui se mesure en euros ou en incidents évités. Quand ces conditions sont réunies, le retour sur investissement est concret et il dure. Quand elles ne le sont pas, gardez votre énergie pour autre chose.

Le bon réflexe n'est jamais « on réécrit tout en Rust ». C'est plutôt : « où, précisément, est-ce que Rust nous fait gagner de l'argent ou de la fiabilité ? » — et c'est par là qu'on commence, toujours.

Un chantier de migration ou un audit de performance en tête ? Parlons-en concrètement, chiffres à l'appui — je n'ai jamais vendu une migration à quelqu'un qui n'en avait pas besoin.