Les agents d'IA de code réduisent un frein majeur à la réécriture en Rust, sa courbe d'apprentissage abrupte, et plusieurs entreprises s'en servent pour réécrire des logiciels existants. Rust apporte la sécurité mémoire sans ramasse-miettes, mais ses garanties s'arrêtent aux blocs de code marqués comme non sûrs, et il ne corrige ni l'authentification, ni l'autorisation, ni l'architecture. Un portage écrit par un agent se vérifie donc sur trois plans : l'équivalence fonctionnelle, la frontière avec le code non sûr, et les failles que la sécurité mémoire ne traite pas.
Ce qui s'est passé
Le MagIT a publié le 6 novembre 2026 une enquête, adaptée d'un reportage de TechTarget, sur l'usage des agents IA pour réécrire des logiciels en Rust. Les éléments qu'elle rapporte :
- Le contexte. Microsoft a classé Rust parmi ses langages de niveau 1 début septembre, c'est-à-dire parmi les plus pris en charge pour le développement interne. Rust doit devenir obligatoire pour le développement de Git 3.0, mesure prévue pour avril 2027. Un rapport de l'administration américaine publié en février 2024 plaidait pour le portage d'applications critiques vers ce langage.
- Le chiffre de référence. Adrian Sampson, professeur à l'université Cornell, rappelle qu'une étude de Microsoft a établi, « à un moment donné », qu'environ deux tiers des bugs de sécurité signalés dans ses logiciels étaient liés à la sécurité de la mémoire.
- Les retours d'entreprises. 37signals, éditeur de la messagerie HEY, a réécrit une partie de son back-end en Rust avec des agents IA. Selon Le MagIT, le back-end de HEY consomme désormais 99 % de ressources CPU et 95 % de RAM en moins. Bun, Google et GitHub se sont aussi lancés dans des réécritures, et certains reconnaissent que l'IA a facilité le travail. Chez Amutable, start-up de cybersécurité dont David Strauss est directeur produit, la plupart des logiciels sont désormais écrits en Go ou en Rust.
- Les limites, vues du terrain. Rohini Ramegowda, ingénieure firmware chez Torus, Neil Carpenter, conseiller chez Trent AI, et David Strauss, co-responsable du projet systemd, décrivent les points où la réécriture assistée ne suffit pas. Ils sont détaillés plus bas.
Comment ça fonctionne
Ce que Rust garantit
Une erreur de mémoire survient quand un programme lit ou écrit en dehors de la zone qui lui est allouée, ou utilise une zone déjà libérée. En C et C++, rien n'empêche ces erreurs à la compilation. Les langages à ramasse-miettes (Java, Python, JavaScript, Go) gèrent la mémoire automatiquement, au prix d'une surcharge possible en performance et en RAM. Rust vérifie à la compilation les règles d'accès à la mémoire, sans ramasse-miettes. « Rust est pratiquement le seul à les offrir toutes les deux », résume Adrian Sampson, à propos de la sécurité mémoire et du contrôle bas niveau.
Pourquoi les agents changent l'équation
Pour David Strauss, d'abord sceptique, une grande partie du défi tenait à la productivité des développeurs. Il estime qu'avec les modèles récents l'usage de Rust n'entraîne plus qu'un surcoût minime par rapport à d'autres langages. Dans le schéma décrit par David Heinemeier Hansson, le développeur rédige la spécification en langage naturel et les agents écrivent le code.
Où les garanties s'arrêtent
Les intervenants cités par Le MagIT pointent quatre limites :
- La frontière avec le code non sûr. Un logiciel porté doit continuer à dialoguer avec du matériel et des bibliothèques existantes. Rohini Ramegowda : « On finit par encapsuler les SDK C des fournisseurs dans des blocs non sécurisés, de sorte que les garanties s'appliquent à votre code, mais s'arrêtent à la limite, c'est-à-dire exactement là où réside le code que vous ne pouvez pas voir. » Les SDK sont ici les kits de développement fournis par les fabricants de composants.
- Les autres classes de failles. Neil Carpenter : Rust « ne résout pas les problèmes d'authentification et d'autorisation insuffisantes ». Autrement dit, et c'est notre lecture : un contrôle d'accès absent du code d'origine restera absent de sa traduction.
- L'architecture. Selon Rohini Ramegowda, à propos d'une migration menée avant l'arrivée des agents, l'IA aurait sans doute bien géré une traduction directe. Réorganiser une base de code, séparer ce qui relève de la plateforme et du produit, demande un ingénieur qui comprend le système. Le déterminisme n'est pas réglé non plus : une tâche sans erreur mémoire qui dépasse sa durée reste une erreur, rappelle Rohini Ramegowda.
- La vérification et la conformité. La réécriture génère, selon elle, une « montagne de revues de code » : « La génération s'accélère, pas la vérification. » Pour les systèmes de sûreté, la chaîne d'outils Rust est qualifiée depuis moins longtemps que celle du C : on peut gagner en sécurité et s'éloigner de la réussite d'un audit. David Strauss ajoute que la chaîne d'outils Rust n'est pas encore entièrement prise en charge sur tous les appareils embarqués, ce qui a compliqué son usage dans systemd.
Qui est concerné
- Les équipes qui maintiennent du code C ou C++ exposé : services réseau, analyseurs de fichiers, composants qui traitent des données non fiables.
- Les éditeurs de firmware et de systèmes embarqués, pour qui la question de la chaîne d'outils et de la certification se pose en premier.
- Les équipes qui ont déjà commencé un portage avec un agent de code et doivent organiser la revue.
- Les RSSI (responsables de la sécurité des systèmes d'information) qui verront arriver l'argument « réécrit en Rust, donc sûr » dans les revues de risque.
Sécuriser une réécriture assistée : la méthode
Les étapes ci-dessous sont des bonnes pratiques de migration. Elles ne viennent pas de l'article du MagIT, qui pose le constat.
1. Choisir les cibles par le risque, pas par la facilité
Portez d'abord les composants qui traitent des données non fiables et où les erreurs mémoire ont un impact de sécurité : analyse de formats, protocoles réseau, décompression. Un module interne sans entrée externe gagne moins.
2. Figer le comportement avant de traduire
Avant que l'agent écrive une ligne, constituez une suite de tests qui décrit le comportement actuel : tests unitaires, tests d'intégration, et un corpus d'entrées réelles et malformées. La version Rust doit produire les mêmes sorties sur ce corpus. Bonne pratique : un test différentiel en continu qui envoie les mêmes entrées aux deux versions et signale toute divergence.
3. Recenser et limiter le code non sûr
Exigez la liste de chaque bloc non sûr produit, avec sa justification. Regroupez-les dans un petit nombre de modules d'interface, relus par un humain qui connaît la bibliothèque C appelée. Fixez une règle dans la chaîne d'intégration : tout nouveau bloc non sûr bloque la fusion tant qu'il n'a pas été validé.
4. Relire ce que Rust ne vérifie pas
La revue humaine se concentre sur ce que le compilateur ne voit pas : contrôles d'authentification et d'autorisation, validation des entrées métier, gestion des secrets, journalisation. Comparez ces points entre l'ancienne et la nouvelle version : une traduction peut supprimer un contrôle sans casser un seul test.
5. Tester par fuzzing la frontière
Le fuzzing (envoi massif d'entrées générées automatiquement) est utile sur les fonctions qui traversent la frontière vers le code C. C'est là que les erreurs mémoire restent possibles.
6. Traiter les dépendances comme du code tiers
Un portage ajoute des bibliothèques Rust. Elles entrent dans votre inventaire de composants (SBOM, la nomenclature logicielle), votre veille de vulnérabilités et votre politique de licences, comme toute autre dépendance.
7. Anticiper l'audit
Si votre produit est soumis à une certification de sûreté, vérifiez avant de commencer que la chaîne d'outils Rust visée est acceptée par votre organisme et sur vos cibles matérielles.
Méthode de vérification. Pour chaque module porté, trois indicateurs : taux de divergence nul sur le corpus différentiel, nombre de blocs non sûrs et part relue par un humain, et liste des contrôles de sécurité de l'ancienne version retrouvés un à un dans la nouvelle. Un module qui ne coche pas les trois ne remplace pas l'original en production.
FAQ
Rust élimine-t-il toutes les failles de sécurité ?
Non. Il prévient les erreurs de mémoire dans le code sûr. Il ne traite pas les failles d'authentification, d'autorisation ou de logique, et ses garanties ne couvrent pas les blocs marqués non sûrs ni le code C appelé.
Peut-on confier une migration C vers Rust à un agent IA ?
L'agent peut produire la traduction : 37signals l'a fait pour une partie de son back-end. La vérification reste humaine : tests d'équivalence, revue du code non sûr, revue des contrôles de sécurité, et décisions d'architecture.
Faut-il tout réécrire en Rust ?
Non. Bonne pratique : commencer par les composants en C ou C++ qui traitent des données non fiables. Pour du logiciel cloud, David Strauss recommande un langage qui garantit la sécurité mémoire, comme Go ou Rust.
Rust est-il accepté dans les projets certifiés ?
L'historique de certification de Rust est plus récent que celui du C, selon Rohini Ramegowda. Vérifiez au cas par cas avec votre organisme et votre chaîne d'outils.
Sources
- Le MagIT, Oui, l'IA agentique accélère le passage à Rust, mais attention aux déconvenues, 6 novembre 2026 : https://www.lemagit.fr/actualites/366653933/Oui-lIA-agentique-accelere-le-passage-a-Rust-mais-attention-aux-deconvenues
Pour intégrer la revue des portages assistés par IA à votre chaîne d'intégration, WeeSec accompagne les équipes en DevSecOps.