Vue normale

Reçu — 23 décembre 2025 Actualités numériques

[MàJ] Conversion du code en Rust : Microsoft rétropédale

24 décembre 2025 à 10:13
Modern C
[MàJ] Conversion du code en Rust : Microsoft rétropédale

Galen Hunt, l’un des principaux ingénieurs de Microsoft, a publié une offre d’emploi détonante : l’entreprise recherche un ingénieur pour aider à la transition intégrale du code C/C++ vers Rust, qui doit être achevée en à peine cinq ans. Il a cependant rétropédalé, évoquant des « lectures spéculatives ».

Mise à jour du 24 décembre : Dans une mise à jour, Galen Hunt indique : « Il semble que mon post ait suscité bien plus d’attention que je ne l’avais prévu… Avec beaucoup de lectures spéculatives entre les lignes. Juste pour clarifier… Windows n’est *PAS* en train d’être réécrit dans Rust avec l’IA ». Et d’ajouter qu’il s’agit d’un projet de recherche : le développement de « technologies pour rendre possible la migration d’un langage à un autre ».

Difficile pourtant de parler de « lectures spéculatives », car le texte initial (toujours disponible) était clair, notamment : « Mon objectif est d’éliminer toutes les lignes de C et C++ de Microsoft d’ici 2030 ». Des termes clairs, d’autant plus quand ils sont prononcés par l’un des principaux ingénieurs dans l’entreprise.

Dans un commentaire, Wolfgang Grieskamp, un autre ingénieur de Microsoft, indique que la traduction automatique vers Rust ne donne de toute façon pas de bons résultats. Le code obtenu est « unsafe, au sens de Rust », car il est nécessaire de penser le projet avec le langage dès le départ, modifiant largement la manière dont les données sont gérées.


Article original du 23 décembre :

Microsoft n’a jamais caché son intérêt pour le Rust. Il a été question un temps d’attendre que l’outillage s’adapte et soit plus mature, mais la version 24H2 de Windows 11 a été la première à introduire du code Rust dans son noyau. Signe clair que la situation avait largement évolué. En février 2025, Paul Thurrott rapportait que la consigne avait été donnée en interne de ne commencer aucun nouveau projet en C ou C++, seulement en Rust.

Le langage, créé initialement par Mozilla, est depuis longtemps géré par une fondation indépendante. Microsoft en était d’ailleurs l’un des principaux membres fondateurs. Le Rust est observé de près par de nombreuses entreprises, particulièrement pour tout ce qui touche à la programmation système. On en trouve d’ailleurs dans le noyau Linux, bien que cette intégration ne se soit pas faite sans heurts. Comme nous l’expliquait récemment Sylvestre Ledru de Mozilla, Firefox en intègre également plusieurs millions de lignes de code, tout comme Chrome.

Mais Microsoft vient de donner un sérieux coup d’accélérateur : la firme veut remplacer tout son code C/C++ d’ici 2030.

Un projet titanesque

L’annonce n’a pas fait l’objet d’un billet ou d’un communiqué de presse. Elle est présente dans une offre d’emploi publiée par Galen Hunt, l’un des plus anciens ingénieurs logiciels de l’entreprise. L’offre est pour un ingénieur logiciel principal, en présentiel à Redmond.

Elle est cependant vite évacuée au profit d’une déclaration fracassante : « Mon objectif est d’éliminer toutes les lignes de C et C++ de Microsoft d’ici 2030 ». Galen Hunt indique que la stratégie consiste à mêler IA et algorithmes, et que « l’étoile polaire » est d’atteindre « 1 ingénieur, 1 mois, 1 million de lignes de code ». La tâche est décrite comme « inimaginable jusqu’ici ».

L’infrastructure algorithmique de l’entreprise est utilisée actuellement pour créer « un graphe évolutif sur le code source à grande échelle ». Après quoi, des agents IA, « guidés par des algorithmes », effectuent les modifications, également à grande échelle. Galen Hunt assure que le « cœur de cette infrastructure fonctionne déjà à grande échelle sur des problèmes tels que la compréhension du code ».

Une expérience en programmation système de qualité production est exigée. Galen Hunt enchaine sur d’autres paramètres de l’offre et un descriptif de l’équipe travaillant sur ce projet.

Le Rust, toujours le Rust

Plusieurs personnes sont venues témoigner de leur étonnement dans les commentaires. Sur le choix du Rust par exemple : pourquoi ne pas avoir choisi C#, qui présente lui aussi certaines caractéristiques intéressantes pour la sécurité ?

Galen Hunt a répondu : C# est « memory safe », mais pas « concurrent safe ». Comprendre que si C# permet d’éliminer certaines classes de failles de sécurité, notamment via un typage fort, Rust va plus loin. Il est jugé plus adapté à la programmation concurrente, quand plusieurs threads, processus ou tâches évoluent en parallèle, avec ou sans zone mémoire commune. Autre raison, attendue : les performances. Rust fonctionne sans ramasse-miettes (garbage collector) et permet d’atteindre les performances du C++.

L’ingénieur évalue à un milliard le nombre de lignes de code concernées chez Microsoft. Pourquoi un projet aussi démesuré ? Pourquoi ne pas garder le code C/C++ ? « Pas de sécurité mémoire. Pas de sécurité sur la concurrence. Bien sûr, pour une seule base de code C ou C++, ces qualités peuvent être atteintes par une discipline et un effort extraordinaires – et disparaître en une seule erreur. Avec Rust, cela peut être prouvé par le compilateur », répond Galen Hunt.

L’annonce a été accueillie avec une certaine incrédulité… y compris dans les rangs mêmes de Microsoft. Rupo Zhang, l’un des responsables de l’ingénierie logicielle de l’entreprise, demande en commentaire sur LinkedIn : « Vous êtes sérieux ? ». La question est restée sans réponse.

Relecture critique

Le projet est en effet pharaonique. « Notre mission est de développer des capacités permettant à Microsoft et à nos clients d’éliminer la dette technique à grande échelle », indiquait Galen Hunt dans l’annonce. Ce qui implique non seulement la conversion de centaines de millions de lignes de code, mais également les nombreux tests devant être réalisés pour en vérifier la fiabilité et les performances.

L’annonce laisse d’ailleurs entendre que le projet est double : convertir tout le code en Rust et finaliser l’infrastructure capable d’accomplir cette opération. Cette dernière impliquerait notamment que l’intégralité du code de Windows serait convertie en Rust, tout en maintenant la rétrocompatibilité, qui est l’une des marques de fabrique de la plateforme. Début septembre, on apprenait notamment que Microsoft voulait encourager le développement de pilotes en Rust, mais que seules les premières briques de l’infrastructure étaient proposées.

Quoi qu’il en soit, Microsoft répète continuellement depuis plus de dix ans que 70 % des failles de sécurité corrigées sont liées à une mauvaise gestion de la mémoire. Le Rust, bien qu’il élimine pratiquement tous les types de failles dans ce contexte, n’est pas non plus une protection absolue contre toutes les menaces. Il faut encore que le code ait été bien écrit. Comme nous le disait récemment l’ingénieur Horacio Gonzalez (Clever Cloud), la relecture critique a toutes les chances de devenir une compétence très recherchée.

[MàJ] Conversion du code en Rust : Microsoft rétropédale

24 décembre 2025 à 10:13
Modern C
[MàJ] Conversion du code en Rust : Microsoft rétropédale

Galen Hunt, l’un des principaux ingénieurs de Microsoft, a publié une offre d’emploi détonante : l’entreprise recherche un ingénieur pour aider à la transition intégrale du code C/C++ vers Rust, qui doit être achevée en à peine cinq ans. Il a cependant rétropédalé, évoquant des « lectures spéculatives ».

Mise à jour du 24 décembre : Dans une mise à jour, Galen Hunt indique : « Il semble que mon post ait suscité bien plus d’attention que je ne l’avais prévu… Avec beaucoup de lectures spéculatives entre les lignes. Juste pour clarifier… Windows n’est *PAS* en train d’être réécrit dans Rust avec l’IA ». Et d’ajouter qu’il s’agit d’un projet de recherche : le développement de « technologies pour rendre possible la migration d’un langage à un autre ».

Difficile pourtant de parler de « lectures spéculatives », car le texte initial (toujours disponible) était clair, notamment : « Mon objectif est d’éliminer toutes les lignes de C et C++ de Microsoft d’ici 2030 ». Des termes clairs, d’autant plus quand ils sont prononcés par l’un des principaux ingénieurs dans l’entreprise.

Dans un commentaire, Wolfgang Grieskamp, un autre ingénieur de Microsoft, indique que la traduction automatique vers Rust ne donne de toute façon pas de bons résultats. Le code obtenu est « unsafe, au sens de Rust », car il est nécessaire de penser le projet avec le langage dès le départ, modifiant largement la manière dont les données sont gérées.


Article original du 23 décembre :

Microsoft n’a jamais caché son intérêt pour le Rust. Il a été question un temps d’attendre que l’outillage s’adapte et soit plus mature, mais la version 24H2 de Windows 11 a été la première à introduire du code Rust dans son noyau. Signe clair que la situation avait largement évolué. En février 2025, Paul Thurrott rapportait que la consigne avait été donnée en interne de ne commencer aucun nouveau projet en C ou C++, seulement en Rust.

Le langage, créé initialement par Mozilla, est depuis longtemps géré par une fondation indépendante. Microsoft en était d’ailleurs l’un des principaux membres fondateurs. Le Rust est observé de près par de nombreuses entreprises, particulièrement pour tout ce qui touche à la programmation système. On en trouve d’ailleurs dans le noyau Linux, bien que cette intégration ne se soit pas faite sans heurts. Comme nous l’expliquait récemment Sylvestre Ledru de Mozilla, Firefox en intègre également plusieurs millions de lignes de code, tout comme Chrome.

Mais Microsoft vient de donner un sérieux coup d’accélérateur : la firme veut remplacer tout son code C/C++ d’ici 2030.

Un projet titanesque

L’annonce n’a pas fait l’objet d’un billet ou d’un communiqué de presse. Elle est présente dans une offre d’emploi publiée par Galen Hunt, l’un des plus anciens ingénieurs logiciels de l’entreprise. L’offre est pour un ingénieur logiciel principal, en présentiel à Redmond.

Elle est cependant vite évacuée au profit d’une déclaration fracassante : « Mon objectif est d’éliminer toutes les lignes de C et C++ de Microsoft d’ici 2030 ». Galen Hunt indique que la stratégie consiste à mêler IA et algorithmes, et que « l’étoile polaire » est d’atteindre « 1 ingénieur, 1 mois, 1 million de lignes de code ». La tâche est décrite comme « inimaginable jusqu’ici ».

L’infrastructure algorithmique de l’entreprise est utilisée actuellement pour créer « un graphe évolutif sur le code source à grande échelle ». Après quoi, des agents IA, « guidés par des algorithmes », effectuent les modifications, également à grande échelle. Galen Hunt assure que le « cœur de cette infrastructure fonctionne déjà à grande échelle sur des problèmes tels que la compréhension du code ».

Une expérience en programmation système de qualité production est exigée. Galen Hunt enchaine sur d’autres paramètres de l’offre et un descriptif de l’équipe travaillant sur ce projet.

Le Rust, toujours le Rust

Plusieurs personnes sont venues témoigner de leur étonnement dans les commentaires. Sur le choix du Rust par exemple : pourquoi ne pas avoir choisi C#, qui présente lui aussi certaines caractéristiques intéressantes pour la sécurité ?

Galen Hunt a répondu : C# est « memory safe », mais pas « concurrent safe ». Comprendre que si C# permet d’éliminer certaines classes de failles de sécurité, notamment via un typage fort, Rust va plus loin. Il est jugé plus adapté à la programmation concurrente, quand plusieurs threads, processus ou tâches évoluent en parallèle, avec ou sans zone mémoire commune. Autre raison, attendue : les performances. Rust fonctionne sans ramasse-miettes (garbage collector) et permet d’atteindre les performances du C++.

L’ingénieur évalue à un milliard le nombre de lignes de code concernées chez Microsoft. Pourquoi un projet aussi démesuré ? Pourquoi ne pas garder le code C/C++ ? « Pas de sécurité mémoire. Pas de sécurité sur la concurrence. Bien sûr, pour une seule base de code C ou C++, ces qualités peuvent être atteintes par une discipline et un effort extraordinaires – et disparaître en une seule erreur. Avec Rust, cela peut être prouvé par le compilateur », répond Galen Hunt.

L’annonce a été accueillie avec une certaine incrédulité… y compris dans les rangs mêmes de Microsoft. Rupo Zhang, l’un des responsables de l’ingénierie logicielle de l’entreprise, demande en commentaire sur LinkedIn : « Vous êtes sérieux ? ». La question est restée sans réponse.

Relecture critique

Le projet est en effet pharaonique. « Notre mission est de développer des capacités permettant à Microsoft et à nos clients d’éliminer la dette technique à grande échelle », indiquait Galen Hunt dans l’annonce. Ce qui implique non seulement la conversion de centaines de millions de lignes de code, mais également les nombreux tests devant être réalisés pour en vérifier la fiabilité et les performances.

L’annonce laisse d’ailleurs entendre que le projet est double : convertir tout le code en Rust et finaliser l’infrastructure capable d’accomplir cette opération. Cette dernière impliquerait notamment que l’intégralité du code de Windows serait convertie en Rust, tout en maintenant la rétrocompatibilité, qui est l’une des marques de fabrique de la plateforme. Début septembre, on apprenait notamment que Microsoft voulait encourager le développement de pilotes en Rust, mais que seules les premières briques de l’infrastructure étaient proposées.

Quoi qu’il en soit, Microsoft répète continuellement depuis plus de dix ans que 70 % des failles de sécurité corrigées sont liées à une mauvaise gestion de la mémoire. Le Rust, bien qu’il élimine pratiquement tous les types de failles dans ce contexte, n’est pas non plus une protection absolue contre toutes les menaces. Il faut encore que le code ait été bien écrit. Comme nous le disait récemment l’ingénieur Horacio Gonzalez (Clever Cloud), la relecture critique a toutes les chances de devenir une compétence très recherchée.

OpenAI : les injections de prompts resteront « un défi pour de nombreuses années »

23 décembre 2025 à 08:52
Prise de devants
OpenAI : les injections de prompts resteront « un défi pour de nombreuses années »

Dans un billet de blog publié ce 22 décembre, OpenAI a abordé plus en détail la sécurité de son navigateur Atlas. L’entreprise a notamment décrit la formation d’un agent spécialement entrainé pour trouver des failles. Elle reconnait cependant que les injections de prompts resteront possibles pour longtemps.

Le billet d’OpenAI se concentre sur les attaques par injection de prompts, aussi appelées injections rapides. Spécifiques à l’IA générative, elles tablent sur l’exploration par un chatbot de ressources contenant des instructions malveillantes cachées. Une requête peut par exemple envoyer ChatGPT visiter une certaine page sur un site, laquelle abrite un autre prompt, que l’IA va analyser et interpréter comme tel, avant de satisfaire la demande. Le résultat peut être notamment une fuite d’informations personnelles.

« À titre d’exemple hypothétique, un attaquant pourrait envoyer un courriel malveillant tentant de tromper un agent pour qu’il ignore la demande de l’utilisateur et transmette à la place des documents fiscaux sensibles vers une adresse e-mail contrôlée par l’attaquant. Si un utilisateur demande à l’agent de revoir les e-mails non lus et de résumer des points clés, l’agent peut ingérer cet e-mail malveillant pendant le flux de travail. S’il suit les instructions injectées, il peut s’écarter de sa tâche et partager à tort des informations sensibles », explique ainsi OpenAI.

Atlas au premier plan

Problème pour OpenAI : tout ce qu’il est possible de faire avec l’interface classique de ChatGPT l’est avec les agents. Selon les instructions données, ces derniers exécutent même leur mission de manière automatisée. Et puisqu’ils sont au cœur du navigateur Atlas, OpenAI fait le pari de communiquer directement sur la question.

Cette publication se fait à la faveur d’une mise à jour du modèle, décrit comme mieux entrainé et doté de meilleures protections contre les injections. OpenAI ajoute que cette mise à jour a été déployée suite à la détection d’une série d’attaques par sa « red team automatisée interne ». Une « red team » est une équipe chargée de tester les défenses d’un produit. Dans le cas présent, OpenAI évoque un agent spécialement créé et entrainé dans cet objectif.

Reconnaissant que le « mode agent élargit la surface d’attaque », l’entreprise en a formé un pour attaquer son navigateur. Il fonctionne par renforcement et est décrit comme s’adaptant sans cesse pour trouver de nouvelles portes d’entrée. OpenAI indique avoir accès à la liste de toutes les opérations tentées, l’agent étant présenté comme plus rapide dans ses approches qu’aucun humain ne pourra jamais l’être. Il est basé sur un LLM et se comporte comme un pirate survitaminé, selon l’entreprise.

Pour OpenAI, cette méthode a deux gros avantages : l’approche proactive forçant une adaptation rapide et l’analyse du comportement de tous les agents impliqués, aussi bien en attaque qu’en défense. L’agent attaquant peut lui aussi analyser le comportement des agents présents dans Atlas, pour itérer et lancer une boucle de rétroaction : chaque « décision » prise par Atlas est scrutée pour trouver une faille.

Un problème « à long terme »

Si OpenAI veut montrer qu’elle prend le problème des attaques par injection très au sérieux, elle reconnait dans le même temps qu’il ne sera probablement jamais circonscrit.

« Nous nous attendons à ce que nos adversaires continuent de s’adapter. L’injection rapide, tout comme les arnaques et l’ingénierie sociale sur le web, est peu susceptible d’être un jour complètement « résolue ». Mais nous sommes optimistes quant à une boucle de réponse rapide proactive, très réactive et capable de continuer à réduire de manière significative les risques réels au fil du temps », reconnait l’entreprise dans son billet de blog.

OpenAI parle de « lucidité » sur le compromis entre puissance et surface d’attaque. Cette communication a en outre un autre effet : le sous-texte est que tous les navigateurs agentiques sont concernés, avec des piques invisibles lancées aux concurrents comme Perplexity et son Comet, et surtout Google avec Chrome. Et que dire d’un Windows 11 agentique ?

OpenAI : les injections de prompts resteront « un défi pour de nombreuses années »

23 décembre 2025 à 08:52
Prise de devants
OpenAI : les injections de prompts resteront « un défi pour de nombreuses années »

Dans un billet de blog publié ce 22 décembre, OpenAI a abordé plus en détail la sécurité de son navigateur Atlas. L’entreprise a notamment décrit la formation d’un agent spécialement entrainé pour trouver des failles. Elle reconnait cependant que les injections de prompts resteront possibles pour longtemps.

Le billet d’OpenAI se concentre sur les attaques par injection de prompts, aussi appelées injections rapides. Spécifiques à l’IA générative, elles tablent sur l’exploration par un chatbot de ressources contenant des instructions malveillantes cachées. Une requête peut par exemple envoyer ChatGPT visiter une certaine page sur un site, laquelle abrite un autre prompt, que l’IA va analyser et interpréter comme tel, avant de satisfaire la demande. Le résultat peut être notamment une fuite d’informations personnelles.

« À titre d’exemple hypothétique, un attaquant pourrait envoyer un courriel malveillant tentant de tromper un agent pour qu’il ignore la demande de l’utilisateur et transmette à la place des documents fiscaux sensibles vers une adresse e-mail contrôlée par l’attaquant. Si un utilisateur demande à l’agent de revoir les e-mails non lus et de résumer des points clés, l’agent peut ingérer cet e-mail malveillant pendant le flux de travail. S’il suit les instructions injectées, il peut s’écarter de sa tâche et partager à tort des informations sensibles », explique ainsi OpenAI.

Atlas au premier plan

Problème pour OpenAI : tout ce qu’il est possible de faire avec l’interface classique de ChatGPT l’est avec les agents. Selon les instructions données, ces derniers exécutent même leur mission de manière automatisée. Et puisqu’ils sont au cœur du navigateur Atlas, OpenAI fait le pari de communiquer directement sur la question.

Cette publication se fait à la faveur d’une mise à jour du modèle, décrit comme mieux entrainé et doté de meilleures protections contre les injections. OpenAI ajoute que cette mise à jour a été déployée suite à la détection d’une série d’attaques par sa « red team automatisée interne ». Une « red team » est une équipe chargée de tester les défenses d’un produit. Dans le cas présent, OpenAI évoque un agent spécialement créé et entrainé dans cet objectif.

Reconnaissant que le « mode agent élargit la surface d’attaque », l’entreprise en a formé un pour attaquer son navigateur. Il fonctionne par renforcement et est décrit comme s’adaptant sans cesse pour trouver de nouvelles portes d’entrée. OpenAI indique avoir accès à la liste de toutes les opérations tentées, l’agent étant présenté comme plus rapide dans ses approches qu’aucun humain ne pourra jamais l’être. Il est basé sur un LLM et se comporte comme un pirate survitaminé, selon l’entreprise.

Pour OpenAI, cette méthode a deux gros avantages : l’approche proactive forçant une adaptation rapide et l’analyse du comportement de tous les agents impliqués, aussi bien en attaque qu’en défense. L’agent attaquant peut lui aussi analyser le comportement des agents présents dans Atlas, pour itérer et lancer une boucle de rétroaction : chaque « décision » prise par Atlas est scrutée pour trouver une faille.

Un problème « à long terme »

Si OpenAI veut montrer qu’elle prend le problème des attaques par injection très au sérieux, elle reconnait dans le même temps qu’il ne sera probablement jamais circonscrit.

« Nous nous attendons à ce que nos adversaires continuent de s’adapter. L’injection rapide, tout comme les arnaques et l’ingénierie sociale sur le web, est peu susceptible d’être un jour complètement « résolue ». Mais nous sommes optimistes quant à une boucle de réponse rapide proactive, très réactive et capable de continuer à réduire de manière significative les risques réels au fil du temps », reconnait l’entreprise dans son billet de blog.

OpenAI parle de « lucidité » sur le compromis entre puissance et surface d’attaque. Cette communication a en outre un autre effet : le sous-texte est que tous les navigateurs agentiques sont concernés, avec des piques invisibles lancées aux concurrents comme Perplexity et son Comet, et surtout Google avec Chrome. Et que dire d’un Windows 11 agentique ?

❌