Une référence utilisée après la libération d’un objet, un accès qui dépasse un tampon : dans un noyau, une erreur minuscule peut devenir une faille majeure. Rust promet d’éliminer une partie de ces pièges avant même l’exécution. Mais Linux n’est pas une page blanche : c’est un édifice immense, écrit principalement en C, entretenu par des équipes aux pratiques éprouvées. Y introduire Rust oblige à négocier chaque frontière technique et humaine. Pour éclairer les enjeux de septembre 2026, cette analyse distingue les jalons historiques établis des perspectives, sans présenter celles-ci comme un bilan vérifié à cette date.
Une porte ouverte, pas une réécriture
Le jalon fondateur est connu : Linux 6.1, publié en décembre 2022, a intégré un premier support de Rust. Il s’agissait d’une infrastructure initiale, optionnelle, et non d’une conversion du noyau. Le projet Rust for Linux, notamment porté par Miguel Ojeda, poursuit une ambition pragmatique : permettre l’écriture de certains composants dans ce langage, tout en conservant leur intégration avec le reste du système.
Cette distinction évite un contresens. L’enjeu n’est pas de réécrire Linux en Rust. Remplacer des millions de lignes de C éprouvées introduirait aussi des régressions, mobiliserait des ressources considérables et ferait perdre une connaissance accumulée pendant des décennies. Le terrain le plus crédible est celui de nouveaux composants et de développements ciblés, lorsque les abstractions nécessaires sont disponibles.
Les pilotes constituent un laboratoire naturel. Ils manipulent des objets à durée de vie complexe, des événements asynchrones, des échanges avec le matériel et des entrées parfois hostiles. Les travaux autour de pilotes graphiques ou d’une implémentation Rust de Binder, mécanisme de communication entre processus utilisé notamment par Android, illustrent cet intérêt. Leur existence ne signifie toutefois pas que tous ces développements ont été intégrés au noyau principal.
Ce que Rust sécurise réellement
En C, le programmeur doit largement garantir lui-même qu’un pointeur reste valide et qu’un objet n’est pas libéré trop tôt. Rust déplace une partie de cette vérification vers le compilateur. Son système de propriété et d’emprunts encadre les accès aux données et leur durée de vie. En Rust sûr, certaines erreurs de mémoire deviennent impossibles à exprimer dans un programme accepté par le compilateur, sous réserve que les fondations utilisées respectent leurs contrats.
Pour un pilote, le bénéfice est concret. Imaginons une requête envoyée au matériel, puis annulée pendant qu’un autre chemin d’exécution traite sa réponse. Qui possède encore la requête ? Qui peut la détruire ? Une interface Rust bien conçue peut contraindre le développeur à représenter explicitement ces situations, plutôt qu’à compter uniquement sur des commentaires et une discipline collective.
Mais sécurité mémoire ne signifie pas sécurité totale. Rust n’empêche pas automatiquement une erreur d’autorisation, un interblocage ou une mauvaise programmation du matériel. Il ne maîtrise pas non plus, à lui seul, les écritures qu’un périphérique effectue directement en mémoire. Son intérêt est de réduire une famille importante de risques, pas de délivrer un certificat d’invulnérabilité.
La vraie frontière passe par le C
Un composant Rust ne vit pas isolé. Il doit allouer de la mémoire, prendre des verrous, enregistrer un périphérique et appeler des fonctions existantes du noyau. Ces opérations traversent souvent une interface avec le C. Or les signatures C décrivent imparfaitement certaines obligations essentielles : ce pointeur peut-il être conservé ? Cette fonction peut-elle dormir ? Quel verrou doit déjà être détenu ?
Le travail décisif consiste donc à construire des abstractions sûres autour d’opérations qui ne le sont pas intrinsèquement. Une couche Rust peut, par exemple, associer l’accès à une donnée à la possession d’un garde de verrou. Elle transforme alors une règle auparavant documentaire en contrainte vérifiable. Encore faut-il que cette traduction soit correcte pour tous les cas d’usage.
C’est là qu’intervient le mot-clé unsafe. Il autorise certaines opérations dont le compilateur ne peut garantir seul la sûreté. Il ne désactive pas toutes les vérifications du langage ; il signale des obligations supplémentaires à démontrer. Dans Linux, ces zones sont inévitables. L’objectif est de les contenir et de les auditer, car une abstraction incorrecte peut exposer du code apparemment sûr à des erreurs mémoire.
Les pilotes posent une question de maintenance
Faire fonctionner un pilote est une étape. Le maintenir pendant des années en est une autre. Les interfaces internes du noyau évoluent : une structure change, une règle de verrouillage est révisée, une fonction disparaît. Contrairement à l’interface offerte aux applications, ces interfaces internes ne bénéficient pas d’une promesse générale de stabilité. Les composants Rust doivent suivre ce mouvement.
Une modification d’un sous-système C peut ainsi imposer une adaptation de ses enveloppes Rust. Qui la réalise ? Le mainteneur du sous-système, l’auteur de l’abstraction ou celui du pilote ? Si la réponse reste floue, le progrès technique se transforme en dette organisationnelle. Les réserves exprimées dans les discussions publiques ne se résument donc pas à une opposition au changement : elles concernent aussi la responsabilité du travail supplémentaire.
Le problème ressemble à un cercle d’amorçage. Sans utilisateurs concrets, une abstraction risque d’être trop théorique. Sans abstractions acceptées, un pilote peine à entrer dans le noyau. La stratégie la plus solide consiste à avancer par ensembles cohérents : un besoin réel, une interface limitée, des tests et des mainteneurs identifiés. C’est moins spectaculaire qu’une annonce de conversion, mais plus durable.
Former des relecteurs, pas seulement des auteurs
Linux repose sur la revue de code. Ajouter un langage exige donc davantage que des développeurs capables de l’écrire : il faut des personnes capables d’en contester les hypothèses. Un spécialiste du C connaît intimement les contraintes matérielles et les conventions du noyau ; il n’identifie pas nécessairement immédiatement une erreur subtile dans les garanties d’une abstraction Rust.
L’apprentissage doit fonctionner dans les deux sens. Les contributeurs Rust doivent comprendre les contextes d’exécution, les interruptions, les contraintes d’allocation et les mécanismes de synchronisation propres au noyau. Les équipes historiques doivent pouvoir lire progressivement les types, les durées de vie et les garanties proposées. Documentation, exemples sobres et commentaires justifiant les opérations non sûres deviennent des outils de maintenance.
La chaîne de compilation compte également. Introduire Rust ajoute un compilateur, des exigences de versions et une couverture d’architectures à gérer. Pour les intégrateurs et les distributions, ces dépendances ont un coût opérationnel. Une adoption réussie suppose que ce coût soit prévisible, plutôt que reporté sur les équipes chargées de produire et de maintenir les systèmes.
Mesurer autre chose que des lignes de code
Dans une lecture prospective pour septembre 2026, le meilleur indicateur ne serait pas le volume de Rust ajouté. Il serait la capacité à maintenir des composants utiles sans dépendre d’une poignée d’experts : qualité des abstractions, réactivité aux changements du C, disponibilité des relecteurs. Évaluer les gains de sécurité demanderait également du recul, plutôt qu’une comparaison brute entre un petit ensemble récent et des décennies de code existant.
Et maintenant ? Le scénario le plus crédible reste une coexistence longue : du C largement dominant, du Rust introduit là où ses garanties justifient l’investissement. Si les interfaces deviennent plus robustes et les responsabilités plus claires, cette progression pourrait réduire durablement certains risques. Le véritable test ne sera pas de prouver que Rust sait entrer dans Linux, mais qu’une communauté entière sait l’y faire vivre.
