Canonical sponsorise la traduction IA de C vers Rust - l'open source passe à l'offensive mémoire

Ubuntu derrière un projet de conversion automatique C→Rust assistée par IA. L'objectif : du Rust vraiment sûr, pas juste du code qui compile sans unsafe partout.

Le cas concret

Partez d'un bug classique : un buffer overflow dans un démon système écrit en C. Corrigeable, mais qui risque de réapparaître sous une forme différente six mois plus tard parce que C ne peut pas garantir mécaniquement l'absence de ce type d'erreur. Maintenant imaginez ce même code réécrit en Rust - où le compilateur rend ce bug structurellement impossible. C'est l'ambition que Canonical (éditeur d'Ubuntu) soutient financièrement : traduire automatiquement des millions de lignes de C en Rust sécurisé, avec l'aide de l'IA.

Pourquoi c'est non trivial

La traduction C→Rust automatique existe déjà - l'outil c2rust fait ça depuis des années. Problème : il produit du Rust syntaxiquement valide mais unsafe partout. Ce qui annule exactement l'intérêt du point de vue de la sécurité mémoire. On a changé de syntaxe sans changer les garanties.

Ce que vise le projet soutenu par Canonical, c'est du Rust idiomatique et safe : code qui tire parti du système de types de Rust (ownership, borrowing, lifetimes) pour exprimer et vérifier les invariants de sécurité à la compilation. C'est fondamentalement difficile parce que C et Rust n'ont pas les mêmes modèles mentaux :

// C - correct ou use-after-free selon le contexte d'utilisation
char* get_value(struct Map* m, const char* key) {
 return hashmap_get(m, key); // pointeur potentiellement invalide si m est modifié
}

// Rust - le compilateur interdit la modification de m pendant l'emprunt
fn get_value<'a>(m: &'a HashMap<&str, String>, key: &str) -> Option<&'a String> {
 m.get(key) // validité du lifetime garantie par le compilateur
}

L'IA doit comprendre que ces deux fonctions ne sont pas mécaniquement équivalentes - et qu'une traduction naïve produirait un unsafe block, pas une vraie migration.

Le sous-texte : IA dans l'open source, acte suivant

On retrouve ici l'écho direct du débat qui agite le logiciel libre. Linus Torvalds a tranché pour le noyau Linux : les contributions IA-assistées sont les bienvenues, les opposants peuvent forker. Canonical suit la même logique pragmatique - l'IA comme outil de modernisation de masse, pas comme menace à l'intégrité.

La vraie question reste la validation humaine : qui relit le Rust généré ? Qui garantit que la sémantique du C original est préservée, y compris ses comportements aux limites ? Un outil qui génère 95% de bon Rust et 5% de code subtilement incorrect est plus dangereux qu'un outil 100% unsafe - parce qu'il donne une fausse garantie.

Ce qu'on attend

Si le projet tient ses promesses, c'est une accélération considérable de la transition des couches système vers Rust - mouvement déjà bien engagé (Android, Windows, noyau Linux, OpenSSL). Canonical ciblant Ubuntu, ça touche directement les couches basses de millions de serveurs en production.