Avis sur le langage de programmation Rust : vaut-il la peine de l'apprendre ?

Demande à deux développeurs Rust expérimentés si apprendre Rust valait l'effort, et tu peux obtenir des réponses complètement opposées. L'un te dira peut-être que ça n'a rien apporté à sa carrière ; l'autre dira peut-être que c'est l'une des meilleures décisions techniques qu'il ait prises. Les deux peuvent avoir raison.

C'est dans cette contradiction que se trouve vraiment la question « faut-il apprendre Rust ? », et c'est pour ça qu'un oui général ne te sert à rien. Rust est un langage compilé dont le sous-ensemble sûr impose des règles de sécurité mémoire à la compilation, sans avoir besoin d'un ramasse-miettes à l'exécution.

Je vais donc m'engager sur une réponse, nommer la condition dont elle dépend et te montrer ce que coûte cette condition.

La version courte

Rust vaut la peine d'être appris si tu construis quelque chose de durable où un compilateur qui attrape toute une classe de bugs vaut son prix. C'est le mauvais choix si tu dois livrer une app CRUD ce mois-ci, si tu apprends à programmer ou si tu comptes les offres d'emploi. 4 sur 5, pénalisé pour ce qu'il coûte avant de rapporter.

• Ce que tu achètes : en Rust sûr, les règles de propriété et d'emprunt transforment les bugs de use-after-free, de double-free, de référence invalide et de data race en erreurs de compilation plutôt qu'en incidents de production. C'est tout l'argument, et il est bon.
• Ce que tu paies : le compilateur t'oblige à écrire noir sur blanc des décisions mémoire que ton langage actuel prend en silence, et au début, on a l'impression que l'outil fait des difficultés.
• La question de la durabilité est tranchée. Les mainteneurs du noyau ont conclu l'expérience Rust au Maintainers Summit de décembre 2025, et l'étiquette « expérimental » a disparu dans Linux 7.0.
• La question de la mode ne l'est pas, et c'est une autre question. Rust est à la 10e place de l'index TIOBE de septembre 2026, contre la 18e un an plus tôt.
• Mon service Rust de test demandait bien plus de mémoire pour compiler que pour tourner : il a culminé près de 1 Go pendant la compilation et restait à environ 3,5 Mo au repos une fois lancé.
• C'est pour toi si tu livres déjà dans un autre langage et construis quelque chose où un bug mémoire coûterait cher, ou si tu travailles près des logiciels système. Ce n'est pas pour toi si tu as une échéance, tu pars de zéro ou tu cherches le langage qui a le plus d'offres d'emploi.

Comment ce test a été réalisé : les chiffres de compilation et d'exécution sont les miens. J'ai installé Rust 1.98.1, écrit un petit service web avec Axum, et mesuré ce qu'il fallait pour le compiler et pour le faire tourner. Le tout a tourné dans un conteneur isolé, pas sur du matériel dédié, et c'est un seul projet : prends donc les chiffres comme un point de données, pas comme une loi. Tout le reste vient de sources primaires ou faisant autorité : le patch du noyau et le compte rendu qu'en a fait LWN, les billets de sécurité Android de Google, l'index de TIOBE lui-même (avec le commentaire d'avril tel que Slashdot l'a rapporté), Phoronix sur la fenêtre de fusion de Linux 7.0, les fiches CVE du noyau Linux pour la vulnérabilité de Binder, la déclaration de Canonical elle-même et le sondage Stack Overflow 2025. J'ai lu le patch du noyau. Je n'ai pas audité le code Rust du noyau. Et je n'écris pas du Rust depuis des années : là où ce test juge le langage lui-même, il s'appuie sur des praticiens qui en écrivent, et il les nomme.

Ce que le compilateur t'apporte

Donne à deux threads une référence mutable vers le même vecteur en Rust, et le code ne compile pas. Pas un avertissement. Pas un lint qu'on peut désactiver quand on est pressé. Ça ne compile pas. C'est ce refus que tu achètes avec le Rust sûr : les bugs de use-after-free, de double-free, de référence invalide et de data race deviennent des erreurs de compilation au lieu d'incidents de production. La porte de sortie de Rust (unsafe) peut contourner certaines de ces garanties, donc ce n'est pas une promesse absolue pour toute base de code Rust.

La propriété signifie que chaque valeur a exactement un propriétaire chargé de la libérer. L'emprunt signifie que tu peux prêter des références, mais le compilateur suit leur durée de vie et ne laisse aucune d'elles survivre à ce qu'elle pointe, ni un emprunt mutable coexister avec un autre. En Rust sûr, les bugs de use-after-free, de double-free, de référence invalide et de data race sont détectés par le système de propriété et de types avant que le programme ne s'exécute.

Il n'y a pas de ramasse-miettes, et c'est l'autre moitié du marché. Comme la propriété dit déjà qui libère quoi et quand, rien n'a besoin de parcourir ton tas à l'exécution. Tu livres un binaire sans collecteur dedans, et tu n'as pas de temps de pause à régler.

Le prix apparaît au même endroit que la garantie. Chaque décision mémoire que ton langage actuel prend discrètement à ta place, Rust te demande de l'écrire : à qui appartient ceci, combien de temps vit cette référence, si autre chose peut la voir, et si elle franchit une frontière entre threads. Le compilateur ne fait pas de difficultés. Il refuse de deviner.

Donc : c'est la raison pour laquelle on paie ce que Rust demande, et je pense qu'elle tient la route. Si la classe de bugs qu'il élimine ne t'inquiète pas, la suite de ce test ne te fera probablement pas changer d'avis.

Rust est-il encore expérimental, ou fait-il désormais partie de l'infrastructure de production ?

Il a cessé d'être expérimental en décembre 2025, et ceux qui y ont mis fin sont les mainteneurs du noyau eux-mêmes. Au Maintainers Summit 2025, ils ont conclu que Rust avait fait ses preuves dans le noyau, techniquement et humainement. Jonathan Corbet, de LWN, a rapporté le consensus le 10 décembre 2025 : Rust dans le noyau n'est plus expérimental.

Rust est entré dans le Linux mainline avec la v6.1 en 2022 précisément pour mener cette expérience. Le patch de Miguel Ojeda retirant l'étiquette a suivi le Summit de trois jours, et il a été intégré pour la fenêtre de fusion de Linux 7.0.

« Mais l'expérience est terminée, c'est-à-dire que Rust est là pour rester. »

Miguel Ojeda, « rust: conclude the Rust experiment », LKML, 13 décembre 2025

Séparément, et plus tôt : la réécriture en Rust par Google du pilote Binder d'Android, la couche IPC par laquelle les processus d'Android communiquent (en permanence), a été intégrée dans Linux 6.18, sorti le 30 novembre 2025. Ne mélange pas ce jalon avec le consensus du Summit. C'est celui où une entreprise a misé un produit commercialisé sur le Rust du noyau, pas un groupe de mainteneurs qui bénit l'idée. Le Rust du noyau a depuis produit sa première CVE : CVE-2025-68260, une condition de concurrence dans ce même pilote Binder annoncée par Greg Kroah-Hartman le 16 décembre 2025, introduite dans la 6.18 et corrigée dans la 6.18.1. Les premiers rapports parlaient surtout de plantages, mais la notation ultérieure de l'équipe CVE du noyau Linux attribue à CVE-2025-68260 un score de 7,8 (élevé) et décrit une élévation locale de privilèges via une corruption de la mémoire du noyau. Ce même pilote (rust_binder) a aussi accumulé d'autres CVE depuis.

C'est avec Android que les preuves deviennent chiffrées. Le blog sécurité de Google indiquait en décembre 2022 qu'il y avait eu zéro vulnérabilité de sécurité mémoire découverte dans le code Rust d'Android, pour environ 1,5 million de lignes de Rust dans AOSP et environ 21 % de tout le nouveau code natif d'Android 13. C'est une déclaration de 2022 avec un périmètre de 2022. Les billets suivants de Google donnent la tendance plus longue : les problèmes de sécurité mémoire représentaient 76 % des vulnérabilités d'Android en 2019 et 24 % en 2024, le nombre brut passant de plus de 220 à 36 selon les projections. Ces chiffres n'ont de sens que face à la base qu'ils ont remplacée : du C et du C++ écrits par de très bons ingénieurs avec de très bons outils.

Deux signaux plus modestes vont dans le même sens. Le pilote GPU Apple AGX d'Asahi Linux est en Rust, écrit par le projet Asahi Linux dans le cadre d'un travail de rétro-ingénierie, et non par Apple. La mise à jour de Canonical sur rust-coreutils indique qu'Ubuntu 26.04 LTS livre rust-coreutils 0.8.0 pour la plupart des utilitaires. Trois restent sur GNU coreutils (cp, mv, rm) parce que huit problèmes TOCTOU étaient encore ouverts le 22 avril 2026 ; Canonical vise la 26.10 pour les utilitaires restants.

C'est l'axe auquel je donnerais la meilleure note, et la raison, c'est le type d'engagement en jeu. Les mainteneurs du noyau ne « dé-concluent » pas une expérience, Google ne défait pas une réécriture de cette taille, et Canonical ne met pas un coreutils réécrit dans une LTS pour voir ce que ça donne. Quoi qu'il arrive à la popularité de Rust, quelqu'un devra maintenir ce code pendant des années.

Rust est-il mort, ou simplement en train de plafonner ?

Non. Rust a égalé sa meilleure position TIOBE, la 13e, en janvier 2026. Trois mois plus tard, il était retombé à la 16e, et le PDG de TIOBE, Paul Jansen, écrivait en avril 2026, dans un commentaire cité à l'époque par Slashdot, que la croissance de la popularité de Rust « semble plafonner » et qu'une place dans le top 10 « paraît maintenant plus lointaine qu'avant ».

Il décrivait Rust atteignant sa meilleure position de tous les temps sur son propre index, une place occupée pour la première fois en juillet 2024, puis la reperdant.

L'index TIOBE de septembre 2026 place Rust à la 10e position, contre la 18e un an plus tôt, au-delà de la 13e place que TIOBE qualifiait de meilleure position de tous les temps en janvier.

Mon avis : le plateau était réel. C'était un trou d'air, pas un plafond. Ça bat la version de chaque camp, parce que « Rust a calé » est désormais faux et que « Rust ne fait que monter » n'a jamais été vrai.

La mise en garde vaut dans les deux sens, et l'article de Slashdot la soulevait déjà à l'époque : les classements ne font-ils que fluctuer avec le bruit d'un mois sur l'autre dans les résultats des moteurs de recherche, qui sont ce que l'index compte ? Si une chute de trois places en un trimestre était une maigre preuve que Rust ralentissait, une montée de six places est une maigre preuve qu'il gagne. Prends-le comme la météo, pas comme le climat.

Le signal le plus fort sur le ressenti, c'est le sondage Stack Overflow, où Rust est une fois de plus le langage de programmation le plus admiré en 2025, avec 72 % : des gens qui l'ont utilisé l'année passée et veulent continuer. C'est une intention de continuer, pas une adoption, et ici c'est un signal plus utile que la popularité brute si tu te demandes si tu prendras plaisir à rester sur ce langage.

La dynamique est ambiguë, et je lui donne moins de poids qu'à la durabilité ci-dessus, parce que tu n'investis pas dans un classement.

Ce que l'apprentissage de Rust te coûte

Le coût tombe tôt et d'un seul coup. Du code que Python, Java ou C# exécuteraient sans broncher est rejeté, encore et encore, pour des raisons qui semblent arbitraires jusqu'à ce que le modèle de propriété fasse tilt, et il n'y a aucun moyen de repousser ça. Tu ne peux pas contourner le borrow checker à force de livrer, comme tu peux le faire quand tu ne comprends pas entièrement ton ORM.

Voici ce qui m'a surpris, et ça va à l'inverse de ce qu'on attendrait. Dans le fil r/rust « Struggling to learn Rust », la réponse qui a eu le plus d'écho présente le problème comme un manque d'habitude, pas une difficulté, et le fil désigne les développeurs expérimentés venant de langages à ramasse-miettes comme ceux qui ont le plus de mal. u/Voxelman le dit simplement : « Rust n'est pas difficile. Il est différent. » Dans le même fil, il décrit son propre parcours : C64 Basic, puis toute une série de langages impératifs, et un premier contact avec Rust qui « n'avait rien de WOW », parce que perdre les vieilles habitudes a pris du temps.

Voilà la forme de la facture. Si tu écris du Python depuis huit ans, tu n'apprends pas un ensemble de règles, tu abandonnes un ensemble d'hypothèses sur qui fait le ménage derrière toi. Quelqu'un qui en sait moins a moins à désapprendre.

Un autre schéma revient souvent dans ce fil, et il transforme une erreur d'ordre en problème de confiance : les gens bloquent non pas sur Rust mais sur le choix d'un framework web, en essayant d'apprendre le langage via Axum ou Actix avant d'avoir assimilé la propriété. Comme l'a dit u/jmartin2683, c'est « comme essayer d'apprendre ruby en apprenant rails. »

À mon sens, la plupart des mises en garde sur le coût visent la mauvaise chose. Prévois une pratique régulière et soutenue, pas un week-end, et ne prends pas la frustration du début pour un verdict sur tes capacités.

Rust a besoin d'une plus grosse machine pour compiler que pour tourner

Voici le résultat auquel je ne m'attendais pas : compiler ce projet Rust a demandé des ordres de grandeur de mémoire de plus que de le faire tourner. J'ai compilé un petit service Axum (Tokio avec la fonctionnalité full activée, serde, serde_json, tower, une route JSON, environ 60 crates dans l'arbre de dépendances) avec rustc et cargo 1.98.1, avec strip = true dans le profil release, puis je l'ai compilé de zéro deux fois :

# constrained: one compile job at a time
cargo build --release --jobs 1
# unconstrained: default parallelism, 4 vCPUs available
cargo build --release

Limité à un seul job de compilation (--jobs 1), le pic de mémoire entre cargo, rustc et l'éditeur de liens se situait entre 464 Mo et 527 Mo selon celle de mes deux méthodes de mesure qu'on retient (j'ai mesuré de deux façons parce que le premier chiffre semblait trop propre), et ça a pris 113 secondes. Avec le parallélisme par défaut sur quatre vCPU, le pic de mémoire a environ doublé, à près de 1 Go, et la compilation s'est terminée en environ 35 secondes. La variable, c'est le parallélisme, pas le projet. Plus de jobs signifie plus de processus rustc en mémoire en même temps, et c'est pourquoi les compilateurs font partie des rares charges de travail qui vont prendre volontiers tous les cœurs que tu leur donnes pendant des minutes d'affilée.

Le programme final pèse 1,3 Mo une fois strippé, et il occupe au repos environ 3,3 à 3,6 Mo de mémoire.

Avec le parallélisme par défaut, ça fait deux à trois cents fois plus de mémoire pour compiler que pour tourner ; limité à un job, c'est encore bien plus de cent fois. Dimensionne un serveur selon ce dont ton service Rust a besoin en production et tu peux te retrouver avec une machine incapable de le compiler, et l'échec n'est pas une erreur propre : c'est l'OOM killer qui abat rustc en pleine compilation, ou un compilateur qui fait swapper la machine pendant vingt minutes. Deux solutions fonctionnent. Compiler quelque part avec de la marge et livrer le binaire, le même principe que garder une machine de build séparée pour le gros travail Docker. Ou compiler sur la machine en lui donnant de la place : pour un service de ce genre, quelques gigaoctets de RAM et deux vCPU suffisent largement. Quand ce n'est pas le cas, la porte de sortie, c'est --jobs 1 (oui, c'est plus lent ; c'est le compromis).

Si la machine sur laquelle tu travailles n'a pas cette marge, notre VPS Linux autogéré te donne un accès root avec facturation à l'heure ou au mois, et un endroit où mettre la compilation puis le rendre quand tu as fini, même si ça reste un serveur que tu administres toi-même et pas un serveur qui s'administre tout seul.

Un projet, une forme, une machine. La machine était un conteneur isolé partagé, pas un serveur dédié, avec environ 2 Go de mémoire disponibles, donc le pic sans limite tournait plus près de son plafond qu'il ne le ferait sur une machine plus grosse. Ce ne sont pas des constantes universelles : si ton arbre de dépendances est quatre fois plus gros ou si ton profil release active l'optimisation à l'édition de liens, attends-toi à d'autres chiffres. Des arbres de dépendances plus gros, l'optimisation à l'édition de liens et du code très générique peuvent faire monter la mémoire de compilation, donc ne prends pas mes mesures pour un plafond universel.

Je classerais ça dans la façon de travailler, pas dans la décision d'apprendre le langage. Sache-le avant de tomber dessus.

Qui devrait apprendre Rust

Trois situations où je te dirais d'y consacrer du temps : un logiciel durable où un bug mémoire coûte cher, un travail proche du système d'exploitation, et l'envie de voir ce que se battre avec le compilateur change à ta façon de penser la mémoire. Pour chacune, il y a une raison pour laquelle ce temps est rentabilisé.

Tu livres déjà dans un autre langage et tu construis quelque chose de durable où un bug mémoire coûterait cher. Un service qui doit rester en ligne. Une bibliothèque dont d'autres équipes dépendent. Tout ce où un use-after-free signifie une revue d'incident, pas une stack trace dans ton terminal. C'est le cas pour lequel toute la garantie a été conçue, et ce que tu paies au départ s'amortit sur la durée de vie de ce que tu construis.

Tu travailles près ou au cœur des logiciels système. Pilotes, travail sur les périphériques, utilitaires du système de base, embarqué, tout ce qui se situe sous un système d'exploitation plutôt qu'au-dessus. L'industrie s'est engagée ici comme elle ne l'a pas fait ailleurs, et c'est ici que les preuves en matière de sécurité mémoire sont les plus solides.

Tu veux l'effet secondaire. Deux commentateurs de ce fil r/rust sont en total désaccord sur la valeur de Rust pour une carrière, et arrivent pourtant au même point ici. u/tyler_church, qui dit que ça n'a eu aucun impact sur sa carrière, lui accorde quand même « peut-être des influences subtiles sur ma façon d'écrire d'autres programmes dans d'autres langages ». u/SirKastic23, payé depuis deux ans pour écrire du Rust, dit que ça a élargi ses compétences en code d'une façon qu'il n'avait jamais imaginée. Deux personnes, pas une étude, mais c'est le bénéfice qui tient même si tu n'écris jamais de Rust professionnellement : un changement dans ta façon de penser, pas une ligne sur un CV.

Qui ne devrait pas apprendre Rust

Trois situations où ce temps serait mieux investi ailleurs : tu as une échéance ce mois-ci, tu apprends tout juste à programmer, ou tu choisis un langage selon le nombre d'offres d'emploi qui le mentionnent. La troisième est celle qui revient le plus souvent dans les questions.

Tu as une échéance ce mois-ci sur une app CRUD ou un prototype. Rust arrive exactement au mauvais moment pour un travail qui doit exister d'ici vendredi. Go est le choix évident à la place si tu veux un langage compilé avec des compilations rapides et une gestion mémoire par ramasse-miettes, et que tu n'as pas besoin des garanties de Rust fondées sur la propriété.

Tu apprends tout juste à programmer. Celle-ci divise vraiment les gens qui écrivent du Rust pour gagner leur vie, et le désaccord dans les fils r/rust va dans les deux sens, donc ma position est que donner à un débutant un pile ou face est un mauvais conseil, quel que soit le côté sur lequel tombe la pièce. Apprends d'abord comment fonctionne une machine dans un environnement plus indulgent, puis reviens et laisse le compilateur resserrer tout ça.

Tu choisis un langage selon le nombre d'offres d'emploi qui le mentionnent. Je ne te donnerai pas de chiffre ici, parce que je n'ai trouvé aucun chiffre de salaire ou d'offres pour Rust qui remonte à une source que je défendrais. Ce que u/crusoe décrit dans ce fil r/rust, c'est un marché avec moins de postes, et plus spécialisés. C'est un commentateur dans un fil, pas des données sur le marché du travail, donc je n'en tirerais pas l'affirmation que les emplois Rust sont rares en général. Si le volume d'offres est ton critère décisif, regarde les offres actuelles sur ton marché cible avant de choisir le langage.

Foire aux questions