Rust généré par LLM : sept catégories de bugs cachés qui échappent au compilateur

Pendant six mois, un développeur a utilisé Claude, GPT et Cursor comme un véritable second programmeur Rust sur du code en production. Il a méticuleusement consigné les erreurs rencontrées et en a tiré une liste éloquente : sept catégories de bugs que les LLM produisent de manière systématique. Le plus gênant : ces erreurs passent le compilateur, les tests unitaires et même l'analyseur statique clippy. Pourtant, elles corrompent la mémoire ou détruisent l'architecture de l'application.

Sept types de bugs cachés

Voici les catégories sur lesquelles les LLM trébuchent encore et encore :

• Lifetime laundering — des variables vivent plus longtemps que ne l'autorise le système de types de Rust. Résultat : un use-after-free au runtime.
• Mutex à travers un await — un verrou reste détenu pendant une attente asynchrone. Deadlock garanti.
• Drop dans les transactions — le modèle oublie d'appeler drop au moment où il faut libérer une ressource (fermer un fichier, annuler une transaction). La ressource fuit.
• Unaligned read — un déréférencement de mémoire mal alignée. Le processeur plante sur ARM et casse silencieusement sur x86.
• Async cancellation — une annulation incorrecte des opérations asynchrones, qui laisse des états en suspens.
• Orphan rule — une violation de la règle orphan lors de l'implémentation de traits. Le code compile dans un projet, puis casse dès qu'on ajoute une dépendance.
• Tableaux sur la pile — l'allocation d'énormes tableaux sur la stack (au lieu du heap). Débordement de pile, segfault.

Pourquoi c'est dangereux en production

Tout l'intérêt de Rust tient à ce que le compilateur intercepte les erreurs pendant le développement, et non en production. Mais ces sept erreurs lui échappent, car elles ne violent ni la syntaxe ni les règles formelles de typage.

Résultat : le code compile sans warnings, passe les tests unitaires, franchit clippy et part en production. C'est là que tout casse, mais il est déjà trop tard. C'est pire qu'une erreur de compilation explicite, car le développeur est persuadé que tout va bien.

Pourquoi les LLM se trompent

Rust reste marginal dans les datasets des LLM. Python, JavaScript et Java représentent 70 % du code sur lequel les modèles ont été entraînés. Rust, peut-être 2-3 %. Or Rust exige une compréhension fine de l'ownership, des lifetimes et du système de types, que les LLM ne saisissent qu'en surface.

Les modèles repèrent des patterns et les recopient. Ils savent qu'« en général, on écrit ça comme ça », mais ignorent pourquoi cela fonctionne en Java et casse en Rust. Ils reproduisent donc ces patterns de travers, avec l'illusion d'un code qui compile.

Rust met les LLM en échec parce que c'est un langage où il faut

réfléchir, pas simplement recopier des patterns.

Conclusions pratiques

Le développeur ne recommande pas d'abandonner complètement les LLM, mais conseille de :

• Ne pas s'appuyer sur les LLM pour les parties critiques : cryptographie, gestion de la mémoire, concurrence
• Exiger une code review formelle, même si le compilateur ne signale rien
• Utiliser Miri, un interpréteur qui détecte les undefined behavior pendant le développement
• Maîtriser suffisamment Rust pour écrire le code soi-même ou savoir repérer les bugs dans le code généré par un LLM

Ce que cela signifie

Les LLM sont un outil utile, mais ne remplacent pas un humain. Ils fonctionnent bien avec les langages dynamiques (Python, JavaScript), car les règles à comprendre intuitivement y sont moins nombreuses. En Rust, il faut soit vérifier chaque ligne, soit garder un humain dans la boucle de décision.

Pour des frameworks comme Next.js ou Django, un assistant LLM accélère considérablement le travail. Pour du Rust en production, il fait davantage office de brouillon à soumettre à une relecture humaine que de véritable collègue.