Rust en 2026 : pourquoi les géants de la tech réécrivent leur C++, et quand vous devriez le faire

Quand j’ai commencé à écrire du Rust, il y a six ou sept ans, on me disait en plaisantant que je n’aurais bientôt plus un seul ami dans le métier. La plaisanterie n’avait pas tort. Rust était le langage que tout le monde admirait dans les sondages et que presque personne n’était payé pour écrire. (Il reste d’ailleurs le plus admiré : dans le sondage Stack Overflow 2025, il arrive en tête de ce classement pour la dixième année consécutive, avec 72 %.) Ma propre question était plus sérieuse que les blagues : Rust serait-il un jour adopté largement ? Réécrire un logiciel existant coûte un temps et un argent considérables, et « le nouveau langage est plus sûr » n’a jamais suffi, à lui seul, à convaincre une entreprise de payer.

En 2026, la question a sa réponse. Microsoft, Cloudflare, Meta et GitHub migrent des parties de leurs systèmes vers Rust, et l’IA a rendu les grandes migrations bien plus réalistes que je ne l’imaginais à l’époque. J’ai vu la direction tôt, mais j’ai eu de la chance sur le calendrier. Cet article parle de ce qui a changé, de ce que les grandes migrations enseignent vraiment, et de la manière de décider si tout cela s’applique à votre système.

Pourquoi j’ai choisi Rust, et pourquoi les sceptiques avaient raison

Les arguments en faveur de Rust étaient clairs dès le départ. Il offre les performances du C et du C++ sans ramasse-miettes, et son compilateur élimine des catégories entières de bugs (use-after-free, dépassements de tampon, accès concurrents aux données) avant même que le code ne s’exécute. Ce ne sont pas des bugs exotiques. Dans les grandes bases de code C et C++, ils sont à l’origine de la plupart des correctifs de sécurité sérieux, année après année. Un langage qui les supprime dès la compilation n’est pas une préférence de style : c’est une autre courbe de coût pour posséder un logiciel.

Les sceptiques avaient pourtant raison sur le coût. Réécrire un système qui fonctionne, c’est un projet sans nouvelle fonctionnalité à montrer pendant des mois. L’écosystème était jeune, la courbe d’apprentissage bien réelle, et le recrutement difficile. Tous les CTO avec qui j’en parlais reconnaissaient que Rust était meilleur, puis, de façon parfaitement rationnelle, ne faisaient rien. Avoir raison sur une technologie ne coûte rien. Avoir raison sur le moment où une industrie peut se permettre de l’adopter, c’est là que tout se joue.

Ce qui a changé : Microsoft, Cloudflare, Meta et GitHub

Microsoft livre du Rust dans le noyau de Windows 11 depuis 2023 - le code des régions GDI, danswin32kbase_rs.sys - et, fin 2025, le Distinguished Engineer Galen Hunt a décrit l’objectif d’éliminer le C et le C++ des plus grandes bases de code de Microsoft d’ici 2030, en combinant IA et algorithmes, avec pour cap « 1 engineer, 1 month, 1 million lines of code » (un ingénieur, un mois, un million de lignes de code). Il a ensuite précisé qu’il s’agit d’un effort de recherche pour construire des outils de migration, et non d’un plan pour réécrire Windows du jour au lendemain. La nuance compte, mais la direction aussi : l’entreprise qui possède l’un des plus grands parcs de C++ au monde investit pour en sortir.

Cloudflare a reconstruit en Rust le proxy central placé devant des millions de sites web. Le nouveau système, FL2, a rendu les sites clients jusqu’à 25 % plus rapides et consomme moins de la moitié du CPU et de la mémoire de la plateforme qu’il remplace, en grande partie parce qu’il ne fait plus transiter les données entre des couches écrites en C, en Lua et en Rust.

Meta a fait de Rust un langage serveur officiellement pris en charge en 2022, a depuis migré du C vers Rust la bibliothèque de messagerie centrale que partagent Messenger, Facebook et Instagram, et a réécrit la bibliothèque de traitement des médias de WhatsApp : 160 000 lignes de C++ sont devenues 90 000 lignes de Rust, tests compris. En 2026, le groupe a aussi porté le React Compiler en Rust pour accélérer les builds. GitHub a construit de zéro en Rust son moteur de recherche de code, Blackbird ; il parcourt près de 45 millions de dépôts.

Aucune de ces entreprises n’a tout réécrit. Chacune a commencé par la partie du système où le coût de l’immobilisme était le plus élevé.

C’est la vraie leçon des grandes migrations, et elle est plus utile que les gros titres. Ce ne sont pas des histoires de réécritures héroïques. Ce sont des histoires de réécritures ciblées : un proxy sur le chemin critique, une couche de messagerie avec un passif de sécurité mémoire, un moteur de recherche qui devait être rapide. Le même schéma fonctionne à toutes les échelles : c’est l’approche du remplacement progressif que nous décrivons dans moderniser l’existant sans tout réécrire, appliquée à un changement de langage.

L’IA a changé l’économie de la migration

Ce que je n’avais pas anticipé en 2019, c’est l’IA. La partie coûteuse d’une migration était autrefois la traduction mécanique : des milliers de fonctions réécrites à la main, ligne par ligne, par des ingénieurs qui auraient préféré construire autre chose. Aujourd’hui, les outils d’IA font une grande partie de ce premier passage. Dans nos propres missions, ils excellent à traduire des modules autonomes, à générer l’échafaudage de tests qui prouve que le comportement n’a pas changé, et à expliquer du vieux code que plus personne ne se souvient d’avoir écrit.

Ils restent faibles sur ce qui décide de la réussite d’une migration : tracer les frontières entre l’ancien et le nouveau code, concevoir la gestion de la propriété sans lutter contre le borrow checker, et relire les blocsunsafeoù s’arrêtent les garanties de Rust. Le coût s’est donc déplacé plutôt qu’il n’a disparu : de la saisie vers le jugement. C’est précisément ce déplacement qui transforme une migration, pari sur plusieurs années, en une série de projets de quelques semaines, chacun rentabilisé par lui-même.

Faut-il migrer vers Rust ? Une grille de décision

Pour la plupart des entreprises, la réponse honnête est « une partie, à terme ». Passez votre système en revue module par module et rangez chacun dans l’une des deux colonnes.

Migrez ensuite le haut de la première colonne, un module à la fois. Placez le nouveau code Rust derrière la même interface que l’ancien (une ABI C via FFI, ou un service séparé), faites tourner les deux en parallèle et ne basculez le trafic que lorsque les tests et les métriques de production concordent. Si un module ne se rentabilise pas, arrêtez-vous là : vous avez perdu des semaines, pas une année. Et si les arguments en faveur de Rust se résument à sa popularité, ce ne sont pas des arguments. La même discipline s’applique à tout choix technologique, c’est pourquoi nous avons écrit que la technologie ennuyeuse est un produit de luxe. Dix ans après la version 1.0, Rust est discrètement devenu l’un de ces choix ennuyeux.

La leçon : ne suivez pas la hype

S’il y a une chose que sept ans de Rust m’ont apprise, c’est celle-ci : ne suivez pas la hype, réfléchissez aux problèmes que l’industrie devra résoudre dans plusieurs années. La sécurité mémoire, l’énergie et le coût du cloud, des systèmes à maintenir pendant des décennies par des équipes qui ne cessent de changer : ces problèmes étaient visibles en 2019, et ils n’ont fait que grandir. La technologie qui les résout devait forcément l’emporter ; la seule question était de savoir quand elle deviendrait abordable.

La même question mérite d’être posée à votre propre feuille de route. Quel problème de votre système coûtera cher dans cinq ans, et que coûterait-il de s’y attaquer dès maintenant, un module à la fois ?

Questions fréquentes

Et oui, je me suis fait quelques amis rustacés en chemin. Un peu tard, mais ils sont venus. Si vous envisagez une migration, voici notre approche du développement Rust et de la migration C/C++.