🔝 Retour au Sommaire
Les sections précédentes ont couvert les outils (extern "C", cxx, autocxx) et la stratégie (migration progressive, build system mixte, formation). Cette section ferme la boucle en examinant ce qui s'est réellement passé dans l'industrie. Les retours d'expérience des grandes organisations qui ont introduit Rust dans leurs bases de code C/C++ existantes sont la meilleure source d'enseignements — ils révèlent les gains réels, les coûts cachés, les succès et les échecs que la théorie ne capture pas.
L'année 2025 a constitué un point d'inflexion : Rust est passé du stade de "langage prometteur en évaluation" à "langage en production à grande échelle" dans plusieurs des plus grandes bases de code du monde. Fin 2025 et début 2026, les données concrètes disponibles permettent de tirer des conclusions fondées, au-delà des opinions et des débats idéologiques.
Le cas Android est le plus documenté et le plus convaincant statistiquement. Google a commencé à écrire le nouveau code Android en Rust à partir de 2019, avec un engagement public en 2021. La stratégie est exactement celle décrite en section 43.3.4 : pas de réécriture de l'existant, mais tout nouveau code exposé aux données non fiables est développé en langage memory-safe.
Les résultats publiés par l'équipe sécurité Android sont remarquables. La proportion de vulnérabilités liées à la sécurité mémoire dans Android est passée de 76 % en 2019 à moins de 24 % en 2024, puis sous la barre des 20 % en 2025. Le nombre absolu de vulnérabilités mémoire est passé de 223 en 2019 à moins de 50 en 2024. Et cette baisse s'est produite sans réécrire le code C/C++ existant — simplement en s'assurant que le nouveau code était memory-safe.
En novembre 2025, Google a publié des métriques de productivité encore plus frappantes : le code Rust dans Android présente une densité de vulnérabilités mémoire environ 1000 fois inférieure à celle du code C/C++ existant, un taux de rollback (retour en arrière d'urgence après un bug) environ 4 fois inférieur à celui du C++ pour les changements moyens et importants, et environ 25 % de temps en moins passé en revue de code. Ce dernier point est contre-intuitif — on pourrait s'attendre à ce qu'un nouveau langage ralentisse les revues — mais il s'explique par le fait que le compilateur Rust détecte des catégories entières de bugs avant la revue humaine.
En production, les appareils Android 16 basés sur le noyau Linux 6.12 embarquent le sous-système de mémoire partagée anonyme (ashmem) entièrement écrit en Rust, déployé sur des millions d'appareils. Google a également commencé à remplacer les parsers de formats sensibles dans Chromium (PNG, JSON, polices web) par des implémentations Rust.
L'approche de Google pour Chromium diffère de celle d'Android. Chromium est une base de code C++ massive et hautement couplée — son équipe a explicitement reconnu que les défis d'interopérabilité C++/Rust y sont plus complexes que dans la plupart des projets.
L'équipe Chromium utilise cxx comme outil principal d'interopérabilité. Leur analyse de l'API interne "base" (1768 fonctions) a montré qu'environ 60 % des signatures étaient directement compatibles avec les types supportés par cxx. L'approche initiale est unidirectionnelle : le nouveau code Rust appelle le code C++ existant, mais pas l'inverse — ce qui permet de contrôler la forme du graphe de dépendances.
Google a également investi dans des outils d'interopérabilité propriétaires, notamment crubit, un outil de génération bidirectionnelle de bindings C++/Rust qui vise à dépasser les limites de cxx et autocxx pour les bases de code de l'échelle de Chromium. L'objectif à terme est que le code Rust puisse appeler les API C++ de Chromium sans redéclaration manuelle — une ambition qui, si elle aboutit, changerait fondamentalement l'ergonomie de l'interopérabilité C++/Rust.
- La réécriture n'est pas nécessaire. La baisse de 76 % à moins de 20 % de vulnérabilités mémoire a été obtenue en écrivant le nouveau code en Rust, pas en réécrivant l'ancien.
- Les vulnérabilités décroissent exponentiellement. Le code mature et se stabilise avec le temps. Les vulnérabilités se concentrent dans le code nouveau ou récemment modifié.
- Les métriques de productivité sont positives. Contrairement aux craintes, le Rust n'a pas ralenti le développement — les rollbacks moins fréquents et les revues plus rapides compensent la courbe d'apprentissage.
Microsoft a suivi un parcours progressif vers Rust, jalonné de déclarations de plus en plus explicites. En 2022, le CTO d'Azure Mark Russinovich recommandait publiquement de ne plus démarrer de nouveaux projets en C/C++. En 2023, Microsoft annonçait la réécriture de portions du noyau Windows en Rust. En septembre 2025, lors de RustConf, Russinovich a détaillé les résultats concrets.
Le fichier win32kbase_rs.sys — un composant Rust du sous-système Win32k qui gère les graphiques et les fenêtres — est présent dans les installations Windows actuelles. Win32k est historiquement l'une des principales sources de vulnérabilités d'élévation de privilèges dans Windows. Russinovich a décrit ce module comme "un réservoir souterrain qui fuitait régulièrement" en C++. En Rust, un bug dans le même composant a provoqué un écran bleu déterministe plutôt qu'une vulnérabilité d'élévation de privilèges — un crash reproductible et sans conséquence sécuritaire au lieu d'une exploitation possible.
Microsoft a également investi dans 36 000 lignes de Rust dans le noyau Windows et 152 000 lignes dans DirectWrite (le moteur de rendu de texte).
L'équipe Surface a franchi un cap en 2025 en livrant des appareils commerciaux avec des drivers écrits en Rust, construits avec le framework open-source windows-drivers-rs. Plusieurs modèles Surface Laptop et Surface Pro sont livrés avec ces drivers Rust en production. L'outil cargo-wdk permet aux développeurs tiers de créer des projets de drivers Windows en Rust avec le linkage, les étapes de build et les dépendances pré-configurés.
Les drivers Rust pour Windows utilisent toujours des blocs unsafe pour interagir avec les API du système d'exploitation (exactement comme en FFI — le noyau Windows étant écrit en C), mais la logique métier du driver bénéficie des garanties de Rust. Microsoft a indiqué que la publication de wrappers safe officiels pour les API kernel est en cours.
Fin 2025, un ingénieur distingué de Microsoft, Galen Hunt, a publié un objectif de recherche visant à éliminer tout le code C/C++ de Microsoft d'ici 2030, en combinant IA et algorithmes pour traduire automatiquement le code. Cet objectif a rapidement été requalifié en "projet de recherche" et non en stratégie officielle pour Windows. Néanmoins, il reflète la direction prise par l'organisation : Rust est considéré en interne comme l'alternative de référence au C/C++ pour les composants système.
- Les composants à haut risque sont les premiers migrés. Win32k, les drivers — les zones historiquement les plus vulnérables.
- Un bug Rust est un crash, pas une exploitation. Le changement qualitatif est aussi important que le changement quantitatif.
- L'interopérabilité FFI est le mécanisme principal. Les drivers Rust interagissent avec le noyau C via
unsafeFFI — le pattern décrit en section 43.3.1. - La réécriture automatisée par IA reste expérimentale. À ce stade, la migration manuelle composant par composant reste la voie de production.
Le projet "Rust for Linux", mené par Miguel Ojeda, a atteint un jalon historique en décembre 2025 lors du Kernel Maintainer Summit à Tokyo : Rust n'est plus expérimental dans le noyau Linux. Le langage est désormais un composant permanent du noyau, aux côtés de C et de l'assembleur. Linus Torvalds avait préparé cette transition en déclarant au Linux Foundation Open Source Summit Korea 2025 que Rust était "véritablement devenu partie intégrante du noyau".
Les premiers drivers Rust avaient été acceptés dans le noyau en décembre 2023 (version 6.8). En avril 2025, le noyau contenait environ 25 000 lignes de Rust sur 34 millions de lignes de C. Cette proportion reste marginale, mais les projets en cours suggèrent une accélération.
Plusieurs drivers et sous-systèmes Rust sont en développement actif ou en production :
- ashmem — allocateur de mémoire partagée anonyme, déployé dans Android 16.
- NOVA — driver GPU NVIDIA en Rust, successeur de Nouveau, ciblant les GPU RTX 20 (Turing) et ultérieurs avec support GSP. Son code initial a été soumis pour le noyau 6.15.
- Tyr — driver ARM Mali en Rust, capable de faire tourner GNOME et des jeux basiques dans le noyau 6.18.
- Drivers réseau — Realtek et ASIX, servants de drivers de référence.
- Le driver rnull et le gestionnaire de panic QR code en DRM.
Dave Airlie, mainteneur du sous-système DRM (graphique), a indiqué en 2025 que le projet DRM était à environ un an de rendre Rust obligatoire et d'interdire le C pour les nouveaux drivers. Greg Kroah-Hartman, mainteneur de la branche stable, a confirmé que les drivers Rust se révélaient plus sûrs que leurs équivalents C, et que les problèmes d'interaction entre code Rust et noyau C étaient moins fréquents que prévu.
L'intégration de Rust dans le noyau n'a pas été sans friction. Certains mainteneurs historiques du noyau ont exprimé des réserves, principalement sur la maintenabilité d'un noyau bilingue et la charge que cela impose aux mainteneurs qui ne connaissent pas Rust. Christoph Hellwig, mainteneur des helpers DMA mapping, a quitté ce rôle suite à un désaccord sur les bindings Rust pour son sous-système. Ted Ts'o (mainteneur ext4) a soulevé des préoccupations techniques sur des régressions de performance cachées dans les couches d'abstraction Rust pour les chemins d'I/O.
Ces tensions sont instructives pour toute organisation introduisant Rust dans un projet C existant : le défi n'est pas seulement technique, il est humain et organisationnel. La politique définie par le projet Rust for Linux — laisser chaque sous-système décider indépendamment s'il accepte du Rust, avec plusieurs modèles de co-maintenance possibles — est un exemple de gestion pragmatique de cette transition.
- L'adoption incrémentale fonctionne. Commencer par les drivers "feuille" (réseau, stockage) qui ont une interface claire avec le reste du noyau.
- La dimension humaine est aussi importante que la technique. Former les mainteneurs, respecter les réticences, permettre aux sous-systèmes de progresser à leur rythme.
- Le tooling évolue avec l'adoption. bindgen, Coccinelle pour Rust, gccrs (implémentation Rust sur GCC),
rustc_codegen_gcc— l'écosystème s'adapte aux besoins spécifiques du noyau. - Le DRM comme sous-système d'adoption démontre que le Rust peut pénétrer des couches profondes du noyau, pas seulement les périphériques.
Mozilla est le berceau de Rust — le langage a été créé en 2006 par Graydon Hoare chez Mozilla Research. Firefox a été le premier projet industriel majeur à intégrer Rust dans une base de code C++ de grande taille, avec le moteur de rendu CSS Stylo (2017) et le moteur de rendu WebRender.
L'expérience de Mozilla a démontré que Rust et C++ pouvaient coexister dans une application complexe (un navigateur web avec des millions de lignes de code). Stylo a éliminé une classe entière de bugs de concurrence dans le rendu CSS — des bugs qui existaient depuis des années dans le moteur Gecko C++ et qui résistaient aux techniques de débogage classiques.
L'expérience Firefox, bien qu'antérieure à la période 2025-2026, reste pertinente car elle a défini les patterns que les autres organisations suivent aujourd'hui : composant isolé avec frontière claire, interopérabilité via FFI C, wrapper safe encapsulant le unsafe, tests d'intégration couvrant la frontière. Le moteur Stylo a prouvé que le gain de sécurité était réel en production, pas seulement en théorie.
Le projet Debian a annoncé que Rust deviendrait une dépendance requise dans APT (Advanced Package Tool) à partir de mai 2026. Cette décision signifie que la toolchain Rust sera présente sur chaque système Debian et dérivé (Ubuntu, etc.) — une normalisation qui réduit la barrière d'entrée pour les projets souhaitant inclure des composants Rust.
Le Rust Survey 2025 et diverses sources de l'industrie rapportent une adoption croissante en production. Les domaines où l'interopérabilité C++/Rust est la plus active sont la sécurité réseau (firewalls, proxies, TLS), l'infrastructure cloud (composants bas niveau chez AWS, Google Cloud, Azure), les systèmes embarqués (firmware, IoT), et le traitement multimédia (codecs, parsers de formats).
L'écosystème d'outils a mûri entre 2024 et 2026 :
| Outil | État mars 2026 |
|---|---|
| cxx | Stable, largement adopté (Chromium, Android, nombreux projets open-source) |
| autocxx | Production-ready pour les cas documentés, utilisé chez Google |
| bindgen | Très mature pour les API C, support C++ partiel |
| crubit | Développé par Google, expérimental, vise l'interopérabilité Chromium-scale |
| diplomat | Spécialisé dans la génération de bindings pour les bibliothèques exposant des API stables |
| corrosion | Intégration CMake/Cargo stable, largement utilisée |
| cargo-wdk | Microsoft, pour les drivers Windows en Rust |
| gccrs | Implémentation Rust sur GCC, priorité pour le noyau Linux, travail en cours |
La stratégie "nouveau code en Rust, ancien code maintenu en C++". C'est la constante dans tous les cas étudiés — Google, Microsoft, le noyau Linux. Aucune organisation n'a réécrit massivement son code C++ existant. Toutes ont obtenu des résultats mesurables en appliquant Rust au nouveau code, en particulier aux composants exposés aux données non fiables.
Les composants "feuille" comme point d'entrée. Parsers, drivers, modules de sérialisation, bibliothèques de cryptographie — les composants avec une frontière claire et une surface d'attaque élevée sont systématiquement les premiers migrés.
La mesure d'impact comme levier de décision. Google publie des métriques détaillées (pourcentage de CVE mémoire, taux de rollback, densité de vulnérabilités). Ces données factuelles sont le meilleur argument pour élargir l'adoption — bien plus efficace que les débats théoriques.
L'interopérabilité via cxx comme standard de facto. cxx est l'outil choisi par Chromium, utilisé dans de nombreux projets industriels, et la base sur laquelle autocxx s'appuie. Son modèle de bridge déclaratif avec vérification au compile-time est devenu le standard de l'industrie.
Les bases de code fortement couplées. Chromium a explicitement reconnu que l'interopérabilité C++/Rust y est plus complexe que dans d'autres projets, en raison du couplage profond entre les composants. L'outil crubit est une réponse à ce problème, mais il n'est pas encore généralement disponible.
La dimension humaine. Les tensions dans le noyau Linux montrent que l'introduction de Rust dans une communauté C établie est un défi social autant que technique. Les mainteneurs qui ne connaissent pas Rust ressentent une pression et une perte de contrôle. La gestion de cette transition humaine est au moins aussi importante que le choix des outils.
Le build system mixte. La coordination entre CMake (ou Bazel, ou Make) et Cargo reste un point de friction. Corrosion et les outils similaires réduisent la douleur mais ne l'éliminent pas. Chaque projet invente encore ses propres conventions.
Les abstractions Rust sur les API C. Encapsuler des API C/C++ dans des wrappers Rust safe est un travail considérable. Le noyau Linux a des centaines d'API internes qui doivent chacune recevoir un wrapper Rust. Ce travail est nécessaire mais ingrat, et il avance lentement.
La réécriture automatisée reste lointaine. L'ambition de Microsoft de traduire automatiquement le code C++ en Rust via IA est fascinante mais exploratoire. En mars 2026, la traduction automatique ne produit pas de code Rust idiomatique et sûr à l'échelle industrielle. La migration manuelle composant par composant reste la seule approche éprouvée.
Rust n'est pas une menace pour les développeurs C++. Aucune des organisations étudiées n'a abandonné le C++. Toutes continuent de maintenir et de développer du C++. Ce qui change, c'est que la compétence "interopérabilité C++/Rust" devient un avantage professionnel significatif.
Savoir faire cohabiter les deux langages est un différenciateur. Les organisations recrutent des développeurs capables de travailler aux frontières — comprendre les contraintes FFI, concevoir des interfaces propres entre les deux langages, écrire des wrappers safe, gérer un build system mixte. Cette compétence est plus rare et plus recherchée que la maîtrise d'un seul langage.
Les patterns sont stabilisés. Les outils (cxx, autocxx, corrosion), les stratégies (migration progressive, composants feuille d'abord), et les conventions (wrapper safe, architecture en couches) sont désormais bien documentés et éprouvés en production. Le développeur qui aborde l'interopérabilité C++/Rust en 2026 peut s'appuyer sur un corpus de retours d'expérience solide — ce n'est plus un territoire inconnu.
Le C++ continue d'évoluer en réponse. Les Safety Profiles C++ (section 45.6), les contrats C++26 (section 12.14.1), les sanitizers de plus en plus performants — l'écosystème C++ ne reste pas immobile. La pression exercée par Rust pousse le C++ à se renforcer sur la sécurité mémoire. Le développeur C++ qui maîtrise à la fois les outils de durcissement C++ et l'interopérabilité Rust est dans la meilleure position possible.
| Organisation | Stratégie | Résultat clé (2025-2026) |
|---|---|---|
| Google (Android) | Nouveau code en Rust, pas de réécriture | Vulnérabilités mémoire < 20 %, densité 1000× inférieure en Rust |
| Google (Chromium) | cxx + crubit, unidirectionnel d'abord | ~60 % de l'API compatible cxx, parsers migrés en Rust |
| Microsoft (Windows) | Composants kernel + drivers en Rust | win32kbase_rs.sys en production, Surface avec drivers Rust |
| Microsoft (Azure) | Rust pour l'infrastructure critique | Engagement "all-in" du CTO, recherche sur traduction IA |
| Noyau Linux | Rust officiel, drivers feuille d'abord | Statut non-expérimental, NOVA/Tyr/ashmem, DRM bientôt Rust-only |
| Mozilla (Firefox) | Composants isolés (Stylo, WebRender) | Précurseur, patterns repris par l'industrie |
| Debian | Rust requis dans APT | Normalisation de la toolchain sur les systèmes Linux |
La conclusion transversale est claire : l'interopérabilité C++/Rust en production n'est plus une expérimentation — c'est une réalité industrielle. Les outils sont matures, les stratégies sont éprouvées, et les résultats mesurables justifient l'investissement dans les contextes appropriés. Le développeur C++ qui comprend cette dynamique et sait y participer dispose d'un avantage professionnel durable.
📎 Ce chapitre sur l'interopérabilité se poursuit avec la section 43.4, qui aborde la compilation C++ vers WebAssembly avec Emscripten — un autre axe d'interopérabilité où le C++ dépasse les frontières de sa plateforme d'exécution native.