Il a suffit d’un message publié sur LinkedIn par un ingénieur de haut niveau de Microsoft pour provoquer une vague de réactions et une rumeur. Il y était question d’éliminer le C et le C++ d’ici à 2030 grâce à l’IA. Beaucoup ont compris que Windows allait être réécrit.
Il y a un article toujours en ligne qui laisse entendre encore cette fausse information. Je mets ici l’intégralité du copier/coller au cas où il serait enlevé. L’information a de quoi convaincre :
« 1 ingénieur, 1 mois, 1 million de lignes de code », Microsoft veut éliminer toute trace de C et C++ de ses outils en moins de 5 ans
Un message sur LinkedIn et une offre d’emploi publiés le 20 décembre 2025 ont mis en lumière une ambition pour le moins audacieuse des équipes techniques de Microsoft : se débarrasser de tout le code écrit en C ou C++ pour le remplacer par du Rust. L’objectif de cette transition est notamment lié aux garanties de sécurité offertes par ce langage de programmation.
Galen Hunt travaille chez Microsoft depuis près de 30 ans. Trois décennies durant lesquelles il a sans doute connu des projets aux ambitions techniques immenses, et ça ne semble pas prêt de s’arrêter.
Sur LinkedIn, cet ingénieur informatique aguerri a partagé le 20 décembre 2025 une offre d’emploi de Microsoft, accompagnée d’un message qui dévoile une partie des objectifs de recherche du géant américain à moyen terme : « Nous développons une technologie pour rendre possible la migration d’un langage de programmation à un autre », explique‑t‑il. « Notre stratégie consiste à combiner l’intelligence artificielle et les algorithmes afin de réécrire les plus grands codebases de Microsoft. »
Pour atteindre cet objectif, le futur employé pourra s’appuyer sur une infrastructure de traitement du code déjà mise en place par les équipes de Galen Hunt.
Soutenu par la mise en place d’agents d’IA, ce nouvel outil serait déjà capable d’analyser en profondeur du code à grande échelle et vise désormais un objectif clair : remplacer chaque ligne de C et de C++ par du Rust, et ce, d’ici à 2030.
Une transition attendue
Cette ambition n’est pas nouvelle et répond à des attentes accrues en matière de cybersécurité pour Microsoft. En effet, contrairement à C et C++, Rust est un langage de programmation à gestion de la mémoire sécurisée, c’est‑à‑dire qu’il utilise une gestion automatique de la mémoire pour éviter les accès mémoire hors limites et les erreurs d’utilisation après libération.
Ces deux types d’erreurs, liées à la gestion manuelle de la mémoire caractéristique de C et C++, sont à l’origine de nombreuses cyberattaques, car elles offrent aux attaquants la possibilité de prendre le contrôle des systèmes. Rust, lui, affiche un message d’erreur à la compilation au moindre défaut dans la gestion de la mémoire.
Un avantage dont Microsoft, comme l’ensemble de l’écosystème cyber, a pleinement conscience. Ces dernières années, les institutions américaines ont régulièrement plaidé pour l’adoption généralisée de langages à gestion de la mémoire sécurisée, et notamment de Rust, afin d’améliorer la sécurité des logiciels.
Si Microsoft a déjà entrepris, depuis 2022, de faire de Rust le langage par défaut pour les nouveaux projets, il reste encore de très nombreuses lignes de code en C et C++ disséminées dans l’immense amas d’outils qui composent l’architecture Microsoft.
Microsoft à la recherche d’un ingénieur logiciel principal
S’il ne s’agit pour l’heure que d’un travail de recherche, la charge est colossale, et Galen Hunt en a bien conscience. Il dévoile d’ailleurs une feuille de route limpide pour ses futures équipes : « 1 ingénieur, 1 mois, 1 million de lignes de code ».
De quoi donner le tournis, mais la rémunération en vaut peut‑être la chandelle. Pour ce poste d’ingénieur logiciel principal, basé au siège de Redmond et non éligible au télétravail, la rémunération annuelle annoncée se situe entre 140 000 et 300 000 dollars par an, selon le profil. L’offre est, à ce jour, , toujours disponible sur le site de Microsoft.https://careerhub.microsoft.com/careers/job?domain=microsoft.com&pid=1970393556639051.
1 « J'aime »
Damage control…
J’ai le sentiment que beaucoup d’entreprises sont en train de surinvestir dans leurs attentes au sujet Rust.
On peut comprendre le raisonnement tenu, à savoir que si l’outil impose plus de rigueur, cela limitera le besoin d’investir dans la compétence ou la coordination des équipes. Ecrire plus vite un code plus sûr, c’est parlant dans un monde ou le temps, c’est de l’argent.
Mais attention aux illusions. Est ce que la réalité est si simple ? Est ce que les failles et le code très mal écrit n’existent pas en Java, C# ou PHP ?
Au passage, pour ceux qui écrivent aujourd’hui du C/C++, on est très loin du style « très unsafe » du C d’antan (pour ceux qui se souviennent comment le C s’écrivait à une époque lointaine).
Voilà pourquoi la recherche et l’ingénierie doivent se faire en étroite collaboration avec les laboratoires universitaires.
Dans ce sujet, remplacer C/C++ par RUSt , Les principes fondamentaux de la science sont bafoués
Chez les scientifiques, on adopte un nouveau concept que s’il améliore l’existant.
Commençons par la syntaxe.
En quoi la syntaxe Rust est une amélioration du C++? Rien qu’à ce niveau, la majorité conclut que c’est une régression. Les concepteurs de Java avaient respecté cette règle.
Ce que propose RUST n’est pas nouveau. La gestion de la mémoire. Fait dans Java. Mais les fuites mémoire existent dans Java et sont incontrôlables (contrairement à C++). Le pour rappel : C++ moderne propose des mécanismes efficaces de gestion mémoire.
En résumé : RUST, un langage imaginé par un développeur, propulsé par le marketing en violation de l’éthique scientifique
Malgré les commentaires precedents, j’ai la nette impression qu’un projet naissant sera développé en rust de preference à C/C++(voire go); évidemment il y a des « exceptions »: Expedition 33 a dû faire du C++(UE5) …
Et dans plein d’autres. Mais au détriment des performances. Contrairement à Rust.
Je suis une quiche en codage, je n’y connais presque rien, mais j’avais cru comprendre que C/C++ sont des langages de programmation de « bas » niveau, en dessous ce sont les 0 et les 1 qui ont pignon sur rue, déjà corrige moi sur ça si je me trompe.
Deuxième question, rust est-il de même « niveau » que C ?
Et c’est sensé être mieux en quoi ?
(J’en entends parler régulièrement de ce rust alors je me pose des questions)
Tiens je vais aller wikicheck pour la peine.
Rust, c’est à peu près du même niveau que C/C++.
Mais le compilateur est beaucoup plus strict, ce qui améliore la sécurité du code, notamment en ajoutant plus de contrôles sur la propriété des données pour garantir leur intégrité (par exemple, une fonction qui reçoit une structure « appartenant » à une autre fonction ne pourra modifier son contenu que si ça a été explicitement autorisé par la fonction appelante) et avec une gestion de la mémoire également mieux contrôlée (pas possible d’allouer de la mémoire sans la desallouer par la suite).
Ça garanti plus ou moins qu’un programme rust ne crashera pas à l’exécution (attention, ça ne veut pas dire qu’il marchera ! Juste qu’il ne va pas crasher lamentablement à cause par exemple d’un accès à une mauvaise adresse mémoire).
Comme beaucoup de langages modernes il a aussi son gestionnaire de paquets, qui facilite pas mal le partage et l’utilisation de libs, et un style d’écriture de référence qui permet d’assurer une certaine cohérence de l’ensemble des codebases (je ne sais plus par contre si ces règles de style sont juste une recommandation, comme en Python, ou une obligation, comme en Go).
Il existe aussi des moyens de faire la même chose en C/C++, mais comme c’est pas natif dans le language c’est plus compliqué et pas standard, il peut y avoir une multitude d’outils pour la même fonctionnalité avec des comportements légèrement différents (typiquement, pour le style du code, ça peut parfois être un peu la jungle sur les langages anciens).
2 « J'aime »
Dommage!
Ce qui est encore plus dommage ce sont toutes les réactions septique pour ne pas dire hostile, alors que c’est exactement ce dont Windows aurait besoin: une réécriture ambitieuse des couches techniques les plus basses. Celles la même qui ne sont sans doute presque jamais touchées puisque leurs modifications n’aurait pas de visibilité directe et mesurable par l’utilisateur.
Si tout est transformé en Rust au passage, tant mieux.
OK, du coup pourquoi les mecs sont si hostiles ?
Peur du changement ?
La peur du changement, en partie. La syntaxe Rust est assez différente.
Mais aussi pour quelqu’un qui a fait suffisamment d’effort pour apprendre, et être bon, dans le développement en C ou C++, il est sans doute assez vexant et même angoissant d’entendre dire que son domaine d’expertise est lié à une technologie décrite comme étant depreciée.
Le C++ est déjà un langage de haut niveau, dans la mesure ou il intègre des concepts (des constructions mentales pour faciliter le travail des développeurs, qui n’ont pas de réalité au niveau de la machine). Le C est plus proche de la machine mais introduit tout de même des concepts. Le plus proche de la machine reste l’assembleur, qui est une version plus lisible (en texte) du code machine (binaire). Au final, tout programme exécuté sur une machine est en langage machine, seul flux qu’un CPU peut exécuter (des 0 et des 1, qui actionnent des circuits complexes à base de transistors MOSFET en mode commutation), quelles que soient les multiples couches d’abstraction (« niveau ») qui existent entre la machine et le code source du programme.
En plus de concevoir le hardware, je n’ai toujours été que programmeur système et embarqué en C et assembleur depuis la fin des années 70 (j’ai même débuté en BCPL, l’ancêtre du C), même si j’ai fait quelques incartades dans des langages haut niveau. J’ai débuté à une époque ou l’on pouvait programmer des jeux entièrement en assembleur. Puis le C a dominé le marché pendant des décennies, et reste aujourd’hui le 2e langage le plus utilisé après le Python d’après l’index TIOBE. Jusque dans les années 90, on programmait les OS, les logiciels et les jeux en C et assembleur. Le C++ est arrivé au milieu des années 80, mais il a véritablement été plus largement adopté à partir des années 90. De mon point de vue, les langages à partir du C++ ont dédouané les programmeurs de leurs obligations de rigueur et d’optimisation, entrainant une surenchère de code inefficace, de gaspillage mémoire et de stockage. C’est le prix à payer de l’abstraction, on produit plus rapidement, mais cela a des externalités. Prenons un exemple rapide très parlant : si je veux faire un programme très simple qui affiche l’activité du disque système sous la forme d’une icône, je peux le faire en C de façon très économe en utilisant les API du système (mon programme occupera quelques Ko, consommera une quantité de RAM insignifiante et ne nécessitera rien d’autre que le système de base), ou je peux le faire dans un langage haut niveau via la dernière couche d’abstraction du système (par exemple .NET sous Windows), et là, ce ne sera pas la même. Alors oui, en C# j’aurais bien moins de code qu’en C, mais mon programme nécessitera que l’utilisateur ait / installe une runtime énorme, dont 99% sera inutilisé dans le cas présenté. C’est un choix.
L’idéal ne serait pas que l’IA réécrive en rust mais en langage machine ça serait beaucoup plus performant. Mais du vrai langage machine, les compilateurs ce n’est pas du vrai langage machine puisque le résultat dépend de l’OS.
L’idéal serait une double réécriture en langage machine pour l’exécution et revenir en C pour le débogage.
Ça n’a strictement aucun sens ce que tu écris là…
Déjà, non, produire en langage machine n’est pas du tout idéal. Ne serait ce que parce que aujourd’hui l’écrasante majorité du code a besoin de pouvoir s’exécuter sur différentes familles de processeur.
Par ailleurs, écrire en langage machine n’est pas forcément plus performant que d’écrire en C ou en Rust. Au contraire même, certaines optimisations sont difficilement faisables et maintenables (pour des questions de complexité technique et de lisibilité) en étant écrite directement en langage machine qu’en étant gérées par un compilateur (petite expérience rigolote dans mes années d’étude : un simple Fibonacci écrit en assembleur d’une façon qui pour absolument tout le monde semblait optimale, était plus lent que le même écrit en C et compilé avec GCC… Une fois désassemblé, on a constaté que le code assembleur produit par GCC était 4-5 fois plus volumineux, mais permettait de déclencher des mécanismes de gestion de cache du CPU que la version assembleur naïve ne déclenchait pas).
Ensuite, transpiler dans un autre langage de niveau plus élevé pour déboguer n’a aucun sens, puisque ce n’est alors plus le programme d’origine que tu débogues…
Et bien sûr que si, les compilateurs peuvent produire du vrai langage machine, et le font. Le fait qu’un binaire soit dépendant d’un OS, ce n’est pas parce qu’il n’est pas en langage machine, mais parce qu’un binaire ne contient pas tout ce qui est nécessaire à son exécution : il y a des fonctions qui sont fournies par l’OS et qui sont appelées depuis le code de ce binaire.
On veut toujours réécrire les vieux logiciels. Ça réussit pas si souvent…
Le gros gros débat il est surtout chez Linux. La chez Microsoft c’est juste une embauche qui fait parler. Chez Linux le débat est ouvert s’il t’intéresse.
Globalement le Rust est plutôt meilleur mais pas parfait, et très neuf.
Ensuite la migration de base de code est tellement énorme que ça fragmente juste les langages utilisés
Et ça met de côté les expert historiques.
En gros rust est memory safe et thread safe. Mais y’a moyen d’utiliser C++ pour qu’il le soit aussi. Donc c’est un arbitrage. Pour un nouveau projet Rust est à priori mieux, mais pour un vieux projet la difficulté de migration rend l’arbitrage délicat.
Bon après si tu veux mon avis, au delà du technique Rust a déjà gagné. L’industrie est entrain de migrer. Et effectivement toute l’idée de cette embauche c’était d’automatiser la migration avec des IAs. On y est pas mais les IA se débrouillent bien pour migrer les code base donc on peut imaginer que dans quelques années des codebase historique puissent envisager de migrer.
Oh non mais la… Si quelqu’un lis ça svp mettez le dans la corbeille de votre esprit. C’est tellement dénué de sens que ça ne vaut pas le coup de répondre.
@Bombing_Basta
Linus Torvalds a donné son accord pour une adoption de Rust pour les nouveaux pilotes et modules du noyaux mais il faut préciser qu’il est impossible de tout réécrire en Rust. On ne peut pas réécrire le noyau Linux en Rust. Cette transition ne concernerait que les futurs développements. Et puis on peut pas réécrire une bonne partie du reste par manque de documentation libre qui puisse le permettre en l’état actuel.
La peur du changement, en partie. La syntaxe Rust est assez différente.
Mais aussi pour quelqu’un qui a fait suffisamment d’effort pour apprendre, et être bon, dans le développement en C ou C++, il est sans doute assez vexant et même angoissant d’entendre dire que son domaine d’expertise est lié à une technologie décrite comme étant depreciée.
Ca n’est pas aussi simple.
Je sais que les jeunes aimeraient trouver LE langage unique et magique pour ne pas avoir à en apprendre… pleins. Mais dans la vraie vie, ce raisonnement ne fonctionne pas.
Rust possède de grandes qualités sur le papier. Mais aussi de gros défauts : il peut apporter beaucoup de complexité à gérer sur de gros projets. Le jeu n’en vaut pas forcément la chandelle pour tout. La souplesse de C/C++ restera toujours un gros point fort. Ce langage aura toujours l’avantage de faire ce que le programmeur VEUT, comme il le veut sans lui casser les pieds. C’est en même temps sa force et sa faiblesse.
Nombreux sont les langages à avoir prétendu au titre de remplaçant de C/C++ depuis sa création (fort lointaine). Certains ont réussi à s’imposer dans l’usage courant. Aucun n’a pour autan rendu le C/C++ obsolète.
D’autant que C/C++ évolue rapidement et pourrait bien intégrer dans quelques années certaines caractéristiques de Rust, voir même une IA qui détectera les erreurs en amont… ce qui compliquera encore le débat.
Le thème « sécurité versus contrôle » est un très vieux débat, pas sûr qu’on le tranchera un jour.
Mais IMHO, Rust trouvera bien sa place en tant que langage spécialisé : il est plus adapté que C/C++ a la création de petits composants critiques : drivers, coeur de navigateur web, composants de sécurité, aéronautique, etc. Il ne fait aucun doute que Rust est le futur pour ces projets qui ont besoin de fortes garanties de sécurité et dont le management à besoin de se rassurer.
Quand aux développeurs C/C++, ils n’ont absolument aucun souci à se faire. Cela fait déjà bien longtemps que ce langage n’est plus le « tout venant » du quotidien. Le gros des projets dans ce langage sont des projets matures et stables : Ils n’ont a redouter aucun changement rapide vers Rust. Et C/C++ restera le langage de prédilection… la ou il est le mieux.
Pour ceux qui en doutent, parlez en à un programmeur Cobol 
Et pour finir, un programmeur C/C++ est certainement parmi les mieux placés pour faire du Rust. Et beaucoup le feront certainement.
L’idéal ne serait pas que l’IA réécrive en rust mais en langage machine ça serait beaucoup plus performant. Mais du vrai langage machine, les compilateurs ce n’est pas du vrai langage machine puisque le résultat dépend de l’OS.
L’idéal serait une double réécriture en langage machine pour l’exécution et revenir en C pour le débogage.
Les compilateurs produisent bien du « Vrai » langage machine. Le fait que le code généré dépendent… de plein de facteurs n’y change rien.
De toute manière, un processeur ne sait exécuter pas exécuter du « faux langage machine », si les compilateurs n’en produisaient pas du vrai, les programmes ne tourneraient même pas.
Par ailleurs, écrire en langage machine n’est pas forcément plus performant que d’écrire en C ou en Rust. Au contraire même, certaines optimisations sont difficilement faisables et maintenables (pour des questions de complexité technique et de lisibilité) en étant écrite directement en langage machine qu’en étant gérées par un compilateur (petite expérience rigolote dans mes années d’étude : un simple Fibonacci écrit en assembleur d’une façon qui pour absolument tout le monde semblait optimale, était plus lent que le même écrit en C et compilé avec GCC… Une fois désassemblé, on a constaté que le code assembleur produit par GCC était 4-5 fois plus volumineux, mais permettait de déclencher des mécanismes de gestion de cache du CPU que la version assembleur naïve ne déclenchait pas).
Effectivement, les compilateurs modernes sont si intelligents qu’il est très difficile d’écrire du code plus performant. Et même du code aussi performant. Elle est bien loin l’époque ou il était courant d’inclure des « routines assembleur » dans son programme.
Cela dit, c’est possible, voire même indispensable dans certains cas de figure. Par exemple le « coeur » des encodeurs vidéo. Mais c’est possible au prix d’un très gros travail et c’est fait uniquement sur de petits bouts de code.
Contrairement à une idée reçue, on programme encore en assembleur de nos jours et c’est pour de bonnes raisons. Par exemple, pour maitriser très finement le timing sur un microcontrôleur, vous pouvez oublier les autres langages.
Bien sûr, ce sont des exemples rares, mais néanmoins existants.