tjmetre.fr — Benchmark TJM freelance — Imprimé le 09/08/2026Questions fréquentes
Le Cyber Resilience Act impose-t-il d'utiliser Rust ?
Non. Le CRA n'impose aucun langage. Il impose un résultat : à partir du 11 décembre 2027, tout produit avec des éléments numériques doit être mis sur le marché sans vulnérabilité exploitable connue et avec une configuration sécurisée par défaut (Annexe I). Rust est l'un des moyens les plus efficaces d'atteindre ce résultat, car il élimine à la compilation la classe de failles la plus répandue — celles de sécurité mémoire — mais il reste un choix technique, pas une obligation légale.
Pourquoi la sécurité mémoire est-elle si importante ?
Parce qu'elle représente environ 70 % des failles de sécurité graves. Microsoft comme le projet Chromium de Google rapportent que ~70 % de leurs vulnérabilités sont des problèmes de sécurité mémoire (buffer overflow, use-after-free). Sur Android, ces failles étaient plus sévères et plus souvent exploitables à distance que les autres. Éliminer cette classe entière, c'est traiter la cause racine de la majorité des vulnérabilités zero-day.
Apprendre Rust augmente-t-il le TJM d'un freelance ?
Indirectement, oui. Rust est le langage le plus admiré du secteur depuis dix ans mais reste peu répandu : c'est une compétence rare. Or, sur le marché freelance, les compétences rares et en forte demande se facturent 40 à 60 % de plus qu'un profil générique (baromètre Malt). Avec le CRA qui pousse à la sécurité mémoire, la demande de développeurs Rust pour les systèmes critiques est structurellement orientée à la hausse.
Rust en 2026 : le rempart contre l'insécurité logicielle (et un levier de TJM)
Avec le Cyber Resilience Act, une faille mémoire n'est plus un simple bug : c'est une faute de conformité. Pourquoi Rust s'impose comme décision de gouvernance — et ce que ça change pour votre tarif de freelance.
À jour au 9/08/2026 · Sources : Commission européenne (CRA), Google Security Blog, CISA, Stack Overflow, Malt
- Le CRA change la donne : dès le 11 décembre 2027, un produit numérique doit être vendu sans vulnérabilité exploitable connue. Un bug mémoire devient un risque de conformité, pas juste technique.
- ~70 % des failles graves sont des problèmes de sécurité mémoire (Microsoft, Chromium). Rust les élimine à la compilation.
- La preuve terrain : sur Android, la part des failles mémoire est passée de 76 % (2019) à 24 % (2024) en misant sur les langages memory-safe pour le code neuf.
- Pour les freelances : Rust est rare, admiré et de plus en plus demandé. Une compétence rare + une demande réglementaire = un levier de TJM.
En cette mi-2026, deux réalités se télescopent. D'un côté, une IA générative partout, qui produit du code à un rythme inédit. De l'autre, une pression réglementaire sans précédent sur la sécurité des logiciels. Au centre de cette collision, une question très concrète pour les entreprises — et donc pour les freelances qui les servent : comment construire du logiciel qui tienne, à la fois techniquement et légalement ? C'est là que Rust cesse d'être un langage « à la mode » pour devenir un choix de gouvernance.
Le CRA transforme un bug en faute de conformité
Le Cyber Resilience Act (règlement européen 2024/2847) est entré en vigueur le 10 décembre 2024. Il impose des exigences de cybersécurité à tout « produit avec des éléments numériques » vendu dans l'UE — du logiciel embarqué à l'application SaaS. Son calendrier est désormais engagé :
Le cœur de la contrainte tient en une phrase de l'Annexe I : les produits « doivent être mis à disposition sur le marché sans vulnérabilité exploitable connue et avec une configuration sécurisée par défaut ». S'y ajoutent la réduction de la surface d'attaque, la protection de l'intégrité et un processus documenté de traitement des vulnérabilités. Ce ne sont pas des recommandations : le non-respect bloque le marquage CE et expose à des amendes allant jusqu'à 15 M€ ou 2,5 % du chiffre d'affaires mondial.
💡 Le glissement de sens. Hier, un buffer overflow ou un use-after-free était un défaut technique à corriger un jour. Demain, sur un produit régulé, c'est une vulnérabilité exploitable qui met en cause la conformité du produit et la responsabilité du fabricant. La sécurité mémoire quitte le terrain de l'ingénierie pour celui de la gouvernance et du risque juridique.
Pourquoi la mémoire ? Parce que c'est 70 % du problème
Depuis des années, les mêmes chiffres reviennent chez ceux qui ont le plus de code en production. Microsoft a établi que ~70 % des CVE qu'il publie chaque année sont des problèmes de sécurité mémoire. Le projet Chromium (Google) arrive au même constat : environ 70 % de ses bugs de sécurité graves sont des failles mémoire. Sur Android, la proportion a historiquement grimpé jusqu'à 90 %.
Ces failles ne sont pas des bugs comme les autres : elles sont plus sévères et plus souvent exploitables à distance. Ce sont elles qui alimentent la majorité des zero-day réellement dangereux. C'est pourquoi la CISA (agence américaine de cybersécurité), la NSA et le FBI recommandent depuis 2023 le passage aux langages à sécurité mémoire garantie, et pourquoi la CISA a fixé au 1er janvier 2026 l'échéance pour que les organisations publient une feuille de route « memory safety ».
La preuve par Android : de 76 % à 24 % en cinq ans
Le cas le plus documenté vient de Google. En 2019, 76 % des failles d'Android étaient des problèmes de sécurité mémoire. En 2024, elles n'en représentaient plus que 24 % — « bien en dessous de la norme de 70 % de l'industrie », note l'équipe sécurité.
Le plus instructif, c'est comment. Google n'a pas réécrit ses millions de lignes de C/C++. Il a fait un choix contre-intuitif : écrire le nouveau code dans des langages memory-safe (dont Rust), et laisser l'ancien vieillir. Or le code « mûrit » : une base de 5 ans présente une densité de vulnérabilités 3 à 7 fois plus faible que du code neuf. En déplaçant le risque — là où naissent les failles — vers des langages sûrs, la part de bugs mémoire s'effondre mécaniquement. Bonus mesuré : le taux de rollback des changements en Rust est inférieur de moitié à celui du C++. Moins de retours en arrière, donc du code plus stable dès la première fois.
Comment Rust élimine la faille à la racine
La force de Rust tient à un concept : la propriété (ownership). Chaque donnée a un propriétaire unique, et le compilateur — via le borrow checker — vérifie avant même l'exécution que personne n'accède à une mémoire libérée, ne dépasse les bornes d'un tableau, ni ne provoque de course de données entre threads. Ce qui, en C++, produit un crash aléatoire en production (ou une faille exploitable) devient en Rust une erreur de compilation : le programme ne compile tout simplement pas.
Autrement dit, Rust ne « détecte » pas les bugs mémoire : il rend leur écriture impossible dans le code sûr, sans passer par un ramasse-miettes (garbage collector) et donc sans sacrifier la performance. C'est ce qui le rend crédible là où C et C++ régnaient : systèmes, drivers, moteurs, embarqué.
⚠️ Rust n'est pas une baguette magique. Il élimine la classe des failles mémoire, pas les bugs de logique métier, ni les failles de conception ou de dépendances. Le mot-clé unsafe permet d'ailleurs de sortir des garde-fous quand c'est nécessaire — à isoler et auditer. Comme le résume Google : « Rust ne réglera pas tout. » Mais supprimer 70 % du problème à la source, c'est déjà considérable.
Dette technique : l'obsolescence est devenue un risque de sécurité
Longtemps, l'obsolescence logicielle était surtout fonctionnelle : un vieux système faisait moins bien le travail. Avec le CRA, elle devient sécuritaire et réglementaire. Une base C/C++ non maintenue, non auditable, truffée de failles mémoire potentielles, ce n'est plus seulement de la dette technique — c'est un passif de conformité qui coûtera de plus en plus cher à assurer et à maintenir sur le marché européen.
Migrer les composants critiques vers Rust, c'est investir dans la longévité : grâce à sa gestion déterministe des ressources et à des garanties vérifiées par le compilateur, le code est plus robuste, plus facile à auditer et à reprendre. Ce n'est pas un hasard si l'adoption s'accélère au cœur des systèmes les plus exigeants :
- Linux : fin 2025, le noyau a tranché un débat de cinq ans — Rust n'est plus expérimental, c'est un langage cœur permanent aux côtés du C.
- Android 16 embarque un allocateur mémoire en Rust : des millions de téléphones font déjà tourner du Rust au niveau noyau.
- Ubuntu 25.10 livre ses coreutils en Rust par défaut (les commandes
ls,cp,mv…).
Performance et sobriété : l'argument qui parle aux directions
Dans un contexte de coûts d'infrastructure élevés et d'exigences environnementales croissantes, Rust coche une dernière case. L'étude de référence de Pereira et al. sur l'efficience énergétique des langages place C et Rust au sommet : les langages compilés sont les plus sobres, loin devant les langages interprétés comme Python. En vitesse, Rust est au coude-à-coude avec le C++, et il consomme généralement moins de mémoire.
🎯 Ce qu'on peut affirmer sans exagérer. Rust n'est pas « plus rapide que le C++ » de façon générale — sur le pur temps d'exécution, C++ reste souvent devant d'un cheveu. En revanche, à performance quasi égale, Rust offre la sécurité mémoire en prime, une empreinte mémoire souvent inférieure, et une efficience énergétique de premier plan. Pour une architecture cloud-native soucieuse de ses coûts et de son empreinte carbone, c'est le meilleur des deux mondes.
Ce que ça change pour vous, freelance
Voici le point qui nous intéresse chez Le TJMètre : cette bascule réglementaire et technique crée une opportunité de positionnement. Rust est, depuis dix ans d'affilée, le langage le plus admiré des développeurs selon l'enquête Stack Overflow (≈ 72 % en 2025). Mais il reste relativement peu répandu en production. Cet écart entre désir et diffusion, c'est la définition même d'une compétence rare.
Or, sur le marché du freelance, la rareté se paie. Selon le baromètre Malt 2026, un développeur facture en moyenne 350 à 600 €/jour, mais les profils rares et très demandés — dont Rust et Go sont explicitement cités — dépassent régulièrement ce plafond, avec des primes de 40 à 60 % par rapport à un profil générique. Ajoutez-y une demande dopée par le CRA sur les systèmes critiques, et vous obtenez une compétence dont la valeur est structurellement orientée à la hausse.
La logique est la même que celle que nous documentons pour l'IA dans « l'IA, nouveau levier de TJM » : ce qui protège et augmente votre tarif, ce n'est pas la technologie « à la mode », c'est de maîtriser tôt une compétence que le marché va s'arracher. Rust coche cette case pour la décennie qui vient.
- Rust = compétence rare + admirée + réglementairement portée → argument de TJM.
- Cible : missions systèmes, embarqué, backend haute-perf, sécurité, mise en conformité CRA.
- Angle de vente : vous ne vendez pas « du Rust », vous vendez de la conformité et de la robustesse — un enjeu de direction, pas d'ingénieur.
Par où commencer, concrètement
- Montez en compétence sur un vrai projet : réécrivez un composant critique (parsing, service réseau, CLI) en Rust plutôt que de suivre un énième tutoriel.
- Positionnez l'angle conformité : sachez expliquer à un client non-technique pourquoi le CRA fait de la sécurité mémoire un sujet de gouvernance. C'est ce discours qui se facture.
- Visez la migration pragmatique : proposez la stratégie Google — nouveau code en Rust, ancien code isolé et surveillé — plutôt qu'une réécriture big-bang irréaliste.
- Réévaluez votre tarif : si vous ajoutez une compétence rare et demandée, votre TJM doit suivre. Calculez le TJM qui correspond à votre nouveau positionnement.
Et pour savoir où vous vous situez aujourd'hui : comparez votre TJM au marché en 30 secondes, puis mesurez l'écart à combler à mesure que votre profil se spécialise.
FAQ
Sources
- Commission européenne — Cyber Resilience Act, résumé et calendrier
- CRA — Annexe I, exigences essentielles de cybersécurité
- Google Security Blog — Eliminating Memory Safety Vulnerabilities at the Source
- CISA — The Urgent Need for Memory Safety in Software Products
- Prossimo (ISRG) — What is memory safety and why does it matter
- Stack Overflow Developer Survey 2025 — langage le plus admiré
- Pereira et al. — Ranking Programming Languages by Energy Efficiency
- Malt — Baromètre des tarifs freelances tech 2026
Une compétence rare mérite un TJM à la hauteur
Comparez votre tarif au marché en 30 secondes, gratuitement.
Lancer mon benchmark TJM Calculer mon TJM cible