Un paquet réseau malformé, une image piégée, un pilote trop permissif : les grandes failles commencent souvent dans de petits composants. Pour sécuriser les logiciels critiques, Rust promet de neutraliser une partie des erreurs mémoire qui fragilisent le C et le C++. Mais remplacer des millions de lignes éprouvées serait un chantier risqué. À l’horizon de septembre 2026, la question utile n’est donc pas « faut-il tout réécrire ? », mais « quelle pièce changer d’abord ? ». Les faits présentés ici étaient documentés jusqu’en juin 2024 ; les prolongements vers 2026 relèvent de l’analyse prospective.
La mémoire, ce vieux défaut de construction
Lire au-delà d’un tampon, utiliser un objet déjà libéré, libérer deux fois la même zone : ces erreurs restent une source majeure de vulnérabilités. Elles peuvent provoquer un crash, exposer des données ou permettre l’exécution de code. Dans un navigateur, un système d’exploitation ou un équipement industriel connecté, leurs conséquences dépassent largement le simple bug fonctionnel.
Le C et le C++ donnent aux développeurs un contrôle fin sur la mémoire, précieux pour les performances et le matériel. En contrepartie, une partie importante de la discipline repose sur les programmeurs, les conventions et les outils. Rust déplace plusieurs de ces vérifications vers la compilation, grâce à ses règles de propriété, d’emprunt et de durée de vie.
Ce n’est pas une assurance contre toutes les attaques. Rust n’empêche ni une erreur d’autorisation, ni un algorithme cryptographique mal choisi, ni un épuisement de ressources. Ses garanties supposent aussi que les blocs unsafe et les bibliothèques sous-jacentes respectent leurs obligations. Son intérêt est plus ciblé : éliminer, dans le code sûr, de nombreuses occasions de corruption mémoire.
Une transition déjà engagée, sans table rase
Cette approche n’est pas théorique. Android a introduit Rust dans ses composants natifs, notamment pour du nouveau code. En 2022, Google présentait cette stratégie comme un complément à la sécurisation de l’existant, plutôt qu’une invitation à réécrire systématiquement les bases C et C++. Le principe est pragmatique : empêcher d’abord que la dette de sécurité continue de grossir.
Le noyau Linux a, lui aussi, intégré une infrastructure initiale pour Rust avec la version 6.1, publiée fin 2022. Il s’agissait d’ouvrir une voie, pas de remplacer le noyau historique. Début 2024, le soutien restait en construction, avec des abstractions et des usages encore limités. Cette lenteur apparente reflète les exigences d’un logiciel central, tributaire d’architectures matérielles et d’équipes nombreuses.
Les institutions ont également poussé dans cette direction. La NSA recommandait dès 2022 d’envisager des langages à sûreté mémoire. La CISA et ses partenaires ont ensuite encouragé les fabricants à établir des feuilles de route. En février 2024, un rapport de la Maison-Blanche soutenait cette orientation. Le signal était clair : traiter le problème à la source, sans confondre trajectoire industrielle et bascule instantanée.
La bonne cible : là où entre la donnée hostile
Pour choisir un premier composant, mieux vaut commencer par le modèle de menace que par le nombre de lignes. Quelles données viennent de l’extérieur ? Quel code les interprète ? Avec quels privilèges ? Un petit parseur exposé à Internet peut mériter davantage d’attention qu’un vaste moteur de calcul isolé derrière plusieurs contrôles.
Trois familles à examiner en priorité
- Les décodeurs et parseurs : images, documents, archives, protocoles. Ils transforment des entrées complexes, parfois volontairement malveillantes, en structures internes.
- Les services exposés : passerelles réseau, agents de mise à jour, services d’authentification. Une corruption mémoire peut y ouvrir un accès précieux.
- Les composants privilégiés : certains pilotes et services système. L’impact potentiel est élevé, même si la proximité du matériel complique souvent la migration.
Cette liste n’est pas un classement automatique. Il faut croiser exposition, impact, historique des défauts et faisabilité. Un composant bien délimité, activement modifié et couvert par des tests constitue souvent une meilleure première cible qu’un module plus dangereux mais impossible à isoler proprement. Le bon indicateur n’est pas le pourcentage de Rust : c’est le risque effectivement retiré.
Réécrire peut aussi recréer des problèmes
Une bibliothèque ancienne transporte parfois vingt ans de correctifs et de comportements subtils. Sa remplaçante peut être irréprochable sur la mémoire tout en interprétant mal un protocole, en cassant une compatibilité ou en consommant trop de processeur. La sûreté du langage ne remplace pas la connaissance du métier.
La stratégie la plus solide consiste souvent à écrire les nouvelles fonctionnalités en Rust, puis à remplacer progressivement les composants dont les frontières sont stables. Pour un parseur, on peut comparer l’ancienne et la nouvelle implémentation sur un corpus commun, pratiquer le fuzzing et analyser chaque divergence. Une divergence peut révéler un défaut ancien autant qu’une régression nouvelle.
Le déploiement mérite la même prudence : activation limitée, télémétrie adaptée, possibilité de retour arrière. Dans un système industriel ou embarqué, les contraintes de validation, de temps réel et de certification peuvent peser davantage que le seul effort de développement. La disponibilité d’une chaîne d’outils adaptée doit être vérifiée avant de promettre un calendrier.
L’interface, nouvelle zone de vigilance
Une migration progressive fait cohabiter Rust avec le C ou le C++. Cette frontière devient un point sensible. Qui possède le tampon ? Qui le libère ? Combien de temps un pointeur reste-t-il valide ? Le compilateur Rust ne peut pas deviner les contrats que le code extérieur transgresse.
Il faut donc privilégier des interfaces étroites : peu de fonctions, des tailles explicites, une propriété des données documentée, des erreurs clairement représentées. Les conversions et les appels externes doivent être concentrés dans une couche réduite et auditée. À l’inverse, multiplier les allers-retours et partager des structures internes complexes peut déplacer les risques plutôt que les supprimer.
Lorsque l’architecture le permet, séparer le nouveau composant dans un processus distinct apporte une protection supplémentaire. Rust et le cloisonnement ne sont pas concurrents : l’un réduit certaines fautes de programmation, l’autre limite les conséquences d’une compromission. Il faut néanmoins mesurer les coûts de communication et de copie.
Mesurer le progrès, pas seulement le langage
Un programme de transition crédible suit quelques critères concrets : quantité de code exposé aux entrées non fiables, privilèges nécessaires, défauts détectés, surface des blocs non sûrs et qualité des tests. Les performances, la consommation mémoire et le temps de compilation comptent aussi : une solution impossible à exploiter durablement ne sécurise rien.
La compétence collective est tout aussi décisive. Former les équipes, organiser les revues et maintenir les dépendances évite de créer un îlot incompréhensible à côté du système historique. Une migration réussie laisse derrière elle des contrats plus clairs et des composants mieux isolés, pas seulement une nouvelle extension de fichier.
Et maintenant ? Pour septembre 2026 et au-delà, le scénario le plus plausible est une coexistence durable : du C et du C++ conservés là où leur remplacement apporterait peu, du Rust introduit aux frontières exposées et dans les développements nouveaux. La priorité devrait aller aux composants combinant données hostiles, impact élevé et interfaces maîtrisables. Le progrès se jugera moins à la disparition de l’ancien code qu’à la réduction des chemins par lesquels une entrée malveillante peut prendre le contrôle du système.
