Développement Rust et migration C/C++, un module à la fois
Nous écrivons du Rust depuis bien avant qu'il soit à la mode. Nous l'utilisons là où il se justifie : les services où la latence et le coût d'infrastructure comptent, le code sensible en matière de sécurité, et le C et le C++ hérités qu'il faut sécuriser sans arrêter l'activité. Partout ailleurs, nous vous dirons qu'un langage plus mainstream est le meilleur choix.
Nos raisons de le choisir
Des critères d'ingénierie, pas de mode : le même test que doit passer chaque outil de notre stack.
La sécurité mémoire sans ramasse-miettes
Le compilateur écarte les use-after-free, les dépassements de tampon et les accès concurrents aux données avant la mise en production : les catégories de bugs à l'origine de la plupart des correctifs de sécurité dans les grandes bases de code C et C++.
Des performances de niveau C, une latence prévisible
Aucune pause d'exécution, aucune allocation cachée. Un service Rust consomme en général une fraction du CPU et de la mémoire du système qu'il remplace, et cela se voit directement sur la facture cloud.
Dix ans de stabilité, et désormais mainstream
Rust 1.0 est sorti en 2015. Microsoft, Cloudflare, Meta et GitHub l'exploitent en production à grande échelle : il passe le même test de longévité que tous les autres outils de notre stack.
Des refontes en toute confiance
Un système de types strict et un compilateur qui explique ses erreurs : les changements d'ampleur passent sans régression. C'est la propriété qui rend les systèmes de longue durée moins chers à posséder.
Les cas où nous le déconseillons
Un outil que l'on recommande pour tout est un outil auquel on a cessé de réfléchir. Trois situations où la réponse est autre chose.
Un produit CRUD ou un portail classique
Formulaires, tableaux de bord et processus métier atteignent rarement les limites que Rust fait sauter. TypeScript ou .NET les livrent plus vite, et vos futures recrues les connaissent déjà : voir Next.js et .NET.
Un système stable que personne n'a besoin de modifier
Réécrire du C++ qui fonctionne, pour le plaisir de réécrire, est rarement rentable. Si le code est stable, suffisamment sûr et peu coûteux à exploiter, laissez-le en place, et n'écrivez de nouveaux modules en Rust que lorsqu'une raison vous amène à toucher cette zone.
Une réécriture d'un seul bloc
Tout remplacer d'un coup, c'est ainsi que meurent les migrations. Nous avançons un module à la fois, derrière une interface stable : la même approche que nos missions de modernisation de l'existant.
Ce que nous construisons en Rust
Les formes sous lesquelles le travail Rust arrive le plus souvent, chacune rattachée à un service que nous connaissons bien.
Services backend à fort débit →
API, processeurs d'événements et pipelines de données où la latence et le coût par requête comptent : construits en Rust, intégrés au reste de votre stack.
Migration C/C++ progressive →
Chemins critiques et modules sensibles réécrits en Rust derrière des frontières FFI, avec les tests existants pour prouver que le comportement reste identique.
Moteurs temps réel →
Moteurs de tarification, d'appariement et de règlement où chaque milliseconde et chaque décimale exacte comptent.
Infrastructure IA →
Passerelles d'inférence, traitement documentaire et tout l'outillage autour des modèles auto-hébergés : rapides, prévisibles en mémoire et sûrs sous charge.
CLI et outillage développeur →
Des outils en un seul binaire pour vos ingénieurs et vos équipes d'exploitation : rapides au démarrage, faciles à distribuer, aucun runtime à installer.
Faut-il migrer vers Rust ? →
Le regard de notre fondateur après sept ans de Rust : ce qu'enseignent les grandes migrations, et comment décider pour votre propre système.
Le déroulé d'une migration
Tout commence par un diagnostic : nous identifions les modules à l'origine des plantages, des correctifs de sécurité et du coût cloud, puis nous les classons par délai d'amortissement. Chaque module passe ensuite derrière une interface stable, et les tests existants, complétés de nouveaux, prouvent que le comportement est inchangé avant toute bascule du trafic. La traduction assistée par IA accélère la partie mécanique ; les ingénieurs gardent la main sur les interfaces, les frontières unsafe et la relecture. La facturation suit les jalons acceptés, comme pour chaque projet.
Questions fréquentes
Faut-il réécrire notre base de code C++ en Rust ?
En général, pas d'un seul coup. Commencez par les modules qui génèrent le plus de correctifs de sécurité, de plantages ou de coût d'infrastructure, réécrivez-les derrière une interface stable, et laissez les résultats décider jusqu'où aller.
Combien de temps dure une migration vers Rust ?
Un module ou un service prend généralement quelques semaines, pas des années. La traduction assistée par IA a nettement accéléré la partie mécanique ; le temps passe dans les tests, les interfaces et la vérification que le comportement n'a pas changé.
Rust peut-il cohabiter avec notre code existant ?
Oui. Rust appelle du C et du C++, et peut être appelé par eux, via FFI ; il tourne aussi comme service séparé à côté de n'importe quelle autre technologie. L'essentiel de nos missions Rust se déroule dans des systèmes majoritairement écrits dans d'autres langages.
Sera-t-il difficile de recruter des développeurs Rust plus tard ?
Le vivier est plus restreint que pour TypeScript ou Java, mais il croît vite, et Rust arrive depuis des années en tête des sondages de développeurs comme le langage le plus apprécié. Nous documentons tout ce que nous transmettons, pour que votre équipe puisse en prendre la responsabilité.
Rust en vaut-il la peine pour votre système ?
Le diagnostic est gratuit : nous examinons le code, classons les candidats et vous disons franchement si la bonne réponse est de ne rien toucher.