Un jeu d’instructions ouvert, des processeurs personnalisables, moins de dépendance à un fournisseur unique : RISC-V a tout pour séduire les industriels et les États soucieux de souveraineté numérique. Mais entre télécharger une spécification et livrer une puce fiable, le parcours reste long, coûteux et encombré de dépendances. L’ouverture donne une liberté de conception ; elle ne livre pas l’indépendance en kit. À l’horizon de septembre 2026, c’est sur cette distinction que se jouera la crédibilité des promesses. Les trajectoires évoquées ici restent prospectives, fondées sur les développements déjà établis.
Ce qui est ouvert, et ce qui ne l’est pas
Né à l’université de Californie à Berkeley en 2010, RISC-V est une architecture de jeu d’instructions, ou ISA. Autrement dit, le vocabulaire élémentaire qu’un logiciel utilise pour demander à un processeur de calculer, déplacer des données ou effectuer un branchement. Cette interface ne décrit pas tous les rouages internes de la machine : deux processeurs compatibles peuvent avoir des performances, des consommations et des organisations très différentes.
La spécification RISC-V peut être utilisée sans payer de redevance pour le jeu d’instructions lui-même. Sa gouvernance relève de RISC-V International, association établie en Suisse. Contrairement à une confusion fréquente, cela ne rend pas automatiquement libres les processeurs qui l’implémentent. Un cœur RISC-V peut être commercialisé sous licence propriétaire, avec un contrat, des restrictions d’accès et une facture. D’autres sont publiés sous licence ouverte, sans garantir pour autant leur maturité industrielle.
Une liberté qui intéresse déjà l’industrie
L’intérêt n’est pas théorique. Des entreprises comme SiFive et Andes commercialisent des cœurs RISC-V. Espressif en a intégré dans plusieurs microcontrôleurs de sa famille ESP32. Le projet européen PULP explore des architectures ouvertes et sobres en énergie. En 2023, Qualcomm, Bosch, Infineon, Nordic Semiconductor et NXP ont annoncé une entreprise commune consacrée à RISC-V, devenue Quintauris, avec l’automobile comme premier terrain.
Ces initiatives illustrent un avantage concret : choisir une architecture commune tout en adaptant le processeur à une tâche. Un contrôleur de capteur n’a pas les mêmes besoins qu’un accélérateur de calcul. RISC-V offre une base modulaire et autorise des extensions spécialisées. Pour un industriel, cette latitude peut réduire certaines contraintes contractuelles et faciliter une stratégie de long terme. Elle ne garantit cependant ni un meilleur rendement énergétique ni un coût inférieur : tout dépend de l’implémentation.
Le vrai prix commence après la spécification
Imaginons une PME qui veut concevoir un processeur pour une caméra industrielle. Le jeu d’instructions constitue seulement son point de départ. Il faut sélectionner ou développer un cœur, organiser la mémoire, ajouter des interfaces, sécuriser le démarrage, puis vérifier que tout fonctionne ensemble. Une erreur rare, déclenchée par une combinaison particulière d’événements, peut devenir catastrophique une fois des milliers d’équipements déployés.
La vérification mobilise donc des équipes et des moyens considérables : simulations, tests de conformité, méthodes formelles, prototypes. Viennent ensuite la conception physique, l’analyse de consommation et la préparation à la fabrication. Les outils d’automatisation électronique restent dominés par des acteurs comme Synopsys, Cadence et Siemens EDA. Des alternatives ouvertes existent, notamment autour d’OpenROAD, mais leur adéquation dépend du procédé industriel et de la complexité du projet.
À ces dépenses s’ajoutent les blocs de propriété intellectuelle périphériques : contrôleurs mémoire, interfaces rapides, fonctions analogiques. Ils peuvent être propriétaires même lorsque le cœur est ouvert. Économiser une licence d’architecture ne signifie donc pas supprimer les licences, encore moins les salaires, les délais de développement ou le risque d’une nouvelle fabrication après correction.
L’usine reste le passage obligé
Une puce RISC-V doit être gravée quelque part. Elle dépend, comme les autres, des capacités de fonderie, des équipements, des matériaux et des prestations d’assemblage et de test. Pour les procédés les plus avancés, les possibilités restent concentrées autour d’un petit nombre d’industriels, dont TSMC, Samsung et Intel, selon les technologies et les offres disponibles. Changer de jeu d’instructions ne change pas cette géographie.
Il existe toutefois une nuance essentielle : toutes les applications n’exigent pas les gravures les plus fines. Un microcontrôleur industriel peut privilégier un procédé éprouvé, disponible longtemps et adapté à ses contraintes. RISC-V peut alors accompagner une stratégie de production plus locale. Mais cette possibilité dépend de l’existence d’une filière complète, pas d’une propriété magique de l’architecture.
Les restrictions commerciales et les contrôles à l’exportation peuvent aussi toucher les outils, les machines ou la fabrication. Une spécification accessible ne les neutralise pas. Pour un État, RISC-V peut diversifier une dépendance située en amont, sans supprimer celles qui subsistent en aval.
Le logiciel, chantier moins visible mais décisif
Un processeur n’existe vraiment pour son utilisateur que lorsque ses programmes tournent correctement. RISC-V dispose déjà d’appuis solides dans Linux, GCC et LLVM. C’est un socle important, mais la présence d’un compilateur et d’un noyau ne suffit pas. Il faut aussi des pilotes, des bibliothèques optimisées, des outils de débogage et des mécanismes de mise à jour robustes.
Dans un objet embarqué, le fabricant maîtrise souvent une petite pile logicielle : la migration peut rester circonscrite. Sur un ordinateur personnel ou dans un serveur généraliste, le défi change d’échelle. Les applications propriétaires, les moteurs d’exécution et les logiciels historiques constituent autant de chantiers. La compatibilité avec RISC-V ne dit pas, à elle seule, si un programme exploite efficacement un processeur donné.
La modularité crée également un risque de fragmentation. Une extension spécifique peut accélérer une fonction, mais compliquer la portabilité si elle devient indispensable au logiciel. Les profils et les extensions standardisés cherchent précisément à donner des cibles communes aux développeurs. La liberté de personnaliser doit cohabiter avec la discipline de standardiser.
Mesurer l’autonomie plutôt que la proclamer
Pour un acheteur public ou un industriel, la bonne question n’est donc pas seulement : « Est-ce du RISC-V ? » Il faut demander qui possède la description du matériel, qui peut la modifier, qui assure la maintenance et quelles solutions existent si un prestataire disparaît. Un cœur ouvert sans documentation exploitable ni compétences internes peut rester une dépendance très concrète.
L’audit doit aussi couvrir la sécurité. L’ouverture facilite l’inspection lorsque le code matériel est effectivement accessible ; elle ne prouve pas l’absence de vulnérabilités. La qualité dépend des examens réalisés, des protections intégrées et de la capacité à corriger les défauts. Comparer des offres exige enfin de considérer le coût complet : développement, certification, portage logiciel, fabrication et support pendant toute la durée de vie.
Et maintenant ? À l’horizon de septembre 2026, la progression la plus plausible de RISC-V serait sélective : davantage de contrôleurs, de systèmes embarqués et de composants spécialisés, plutôt qu’un remplacement uniforme des architectures établies. Son apport majeur pourrait être de rendre certains choix négociables et certaines conceptions maîtrisables. Pour transformer cette ouverture en autonomie durable, il faudra investir dans les compétences, les outils, la production et la maintenance logicielle. Le jeu d’instructions ouvre une porte ; toute la chaîne industrielle reste à construire ou à sécuriser.
