Oui, l’IA agentique accélère le passage à Rust, mais attention aux déconvenues

L’IA peut faciliter les réécritures en Rust

Le problème, c’est que la réécriture d’applications en Rust peut s’avérer difficile. Le langage souffre d’une courbe d’apprentissage abrupte. Cela pousse certaines équipes à se tourner vers les LLM et les agents IA pour se charger du travail fastidieux et profiter de ses avantages.

C’est ce qu’a fait 37Signals, le développeur de messagerie HEY, pour réécrire certaines parties de son back-end en Rust.

« C’est un langage de programmation absolument épouvantable quand on oblige des humains à l’écrire », avance David Heinemeier Hansson, copropriétaire et directeur technique de l’éditeur 37signals, lors de son discours d’ouverture à la conférence Rails World en septembre.

Heureusement, « les agents IA aiment Rust. Parfait ! », s’exclame-t-il. Les développeurs peuvent écrire leur spécification en langage naturel et [laisser] les agents écrire le code. « Quelle belle répartition des tâches », plaisante-t-il.  

Bien qu’« épouvantable », Rust permet au backend de Hey de consommer 99 % de ressources CPU et 95 % de RAM en moins.

D’autres entreprises, notamment Bun, Google et GitHub, se sont lancées dans des réécritures en Rust ces derniers mois. Certains de ces nouveaux adeptes ont également reconnu que l’IA a facilité un processus de réécriture manuelle qui, sans cela, aurait été très laborieux.

David Strauss, directeur produit chez Amutable, une start-up spécialisée dans la cybersécurité faisait partie des sceptiques. Il ne pensait pas que le passage à Rust « en valait la chandelle ».

« Je suis devenu un fervent partisan de Rust à mesure que l’IA a évolué, car une grande partie du défi avec Rust résidait dans la productivité du développeur », souligne-t-il. « Si je laisse l’IA s’en charger, notamment avec certains de ces modèles de pointe, l’utilisation de Rust n’entraîne qu’un surcoût minime par rapport à d’autres langages ».

Désormais, la plupart des logiciels d’Amutable sont écrits en Go ou en Rust. Ces deux langages garantissent la sécurité de la mémoire. Une caractéristique importante pour un spécialiste de l’intégrité des OS Linux.

« Il existe des raisons pratiques pour lesquelles [Rust et Go] ne pourraient pas convenir, mais si vous développez un logiciel destiné à être déployé dans le cloud, vous devriez vraiment utiliser un langage garantissant la sécurité de la mémoire », recommande le dirigeant.

Pourquoi il faut encore des experts derrière le terminal

Justement, ces distinctions sont nécessaires, juge Rohini Ramegowda, ingénieure firmware chez Torus, un fabricant de systèmes de stockage d’électricité sur batterie.

Par le passé, alors qu’elle travaillait pour une grande marque d’électroménager, l’ingénieure a œuvré sur la migration d’un firmware écrit en C vers Rust. Dans un même temps, le fabricant changeait de famille de microcontrôleurs. Les outils d’IA agentique n’existaient pas encore.

Au cours de la refonte, son équipe est passée d’une architecture à une autre, qui séparait les fonctionnalités de la plateforme de celles spécifiques au produit. Cela a nécessité de démêler et de réorganiser la base de code.

« Le portage de la couche application aurait sans doute été plus simple. L’IA aurait sans doute bien géré une traduction directe. Mais cela ne règle pas les problèmes d’architecture. Vous avez toujours besoin d’un ingénieur pour comprendre le système », insiste-t-elle.

Le déterminisme constitue un autre problème que Rust n’a pas complètement résolu. « Une tâche sans risque pour la mémoire, qui dépasse sa durée, est tout de même considérée comme une erreur », note Rohini Ramegowda.

Rust était également moins connu des auditeurs chargés de la conformité.

« Le développement de systèmes de sécurité nécessite une chaîne d’outils qualifiée, et l’histoire de la certification de Rust est bien plus récente que celle de la certification du C. Ainsi, on peut réécrire le code, gagner véritablement en sécurité, et pourtant se retrouver encore plus loin de la réussite d’un audit », remarque-t-elle.

Conformité, sécurité, interopérabilité : l’IA ne fait pas de miracle

En ce cas précis, la réécriture à l’IA n’est pas la solution. Elle génère une « montagne de revues de code ». « La génération s’accélère, pas la vérification », souligne-t-elle.

L’IA pourrait faciliter la traduction du C vers Rust. Cependant le logiciel ainsi obtenu doit tout de même s’exécuter sur le matériel et les plateformes dont dépendent ses utilisateurs. Contourner les problèmes de compatibilité nécessite parfois d’utiliser du code susceptible de réintroduire des failles de sécurité dans un système multilingue, poursuit Rohini Ramegowda.

« On ne peut pas éluder la question de l’interopérabilité. 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 », lâche-t-elle.

La prise en charge limitée de la chaîne d’outils Rust complique son adoption dans les logiciels fonctionnant sur différentes plateformes, confirme David Strauss.

« Lorsque nous avons envisagé d’utiliser Rust pour certaines parties de systemd, nous avons dû tenir compte du fait que systemd s’exécute sur des appareils embarqués, qui ne disposent pas encore toujours d’une prise en charge complète de la chaîne d’outils Rust. Il en va de même pour le kernel Linux », rappelle-t-il.

David Strauss est co-responsable du projet systemd et d’autres services Linux. Il explique que ce projet « doit fonctionner dans de nombreux environnements où la chaîne d’outils Rust n’est pas encore entièrement prise en charge. Il a fallu l’adapter ».

Enfin, Rust n’est pas une rustine pour d’autres catégories de failles, indique Neil Carpenter, conseiller chez Trent AI, éditeur de logiciels de sécurité agentique basé à Londres.

« [Rust] ne résout pas les problèmes d’authentification et d’autorisation insuffisantes. Il ne va pas non plus résoudre toutes les autres catégories de failles de sécurité », martèle-t-il. « Il existe encore de nombreuses erreurs que les développeurs peuvent commettre. Elles sont aussi graves sinon pires que les problèmes réglés par [Rust]. Si vous ne maîtrisez pas déjà ces autres aspects, vous continuerez à commettre toutes ces autres erreurs ».

Cet article est l’adaptation d’un reportage paru en anglais sur TechTarget.com, une publication sœur du MagIT.