RISC-V : une architecture ouverte rend-elle une puce indépendante ?

RISC-V ouvre l’accès à une spécification de jeu d’instructions, c’est-à-dire une partie du contrat entre logiciel et processeur. Cette ouverture permet de créer différentes implémentations, ouvertes ou propriétaires. Elle ne fournit pas automatiquement le dessin d’un cœur, les outils nécessaires à sa conception, une usine capable de le produire ni les moyens de l’assembler. Une puce RISC-V peut donc réduire certaines dépendances tout en en conservant d’autres. Pour parler d’indépendance avec précision, il faut identifier la couche concernée et vérifier ce que l’organisation peut réellement utiliser, modifier, remplacer et faire fabriquer.

Le jeu d’instructions est un contrat

Un logiciel compilé en instructions machine demande au processeur d’effectuer des opérations définies. Le jeu d’instructions, ou ISA pour Instruction Set Architecture, décrit ces opérations et les comportements auxquels le logiciel peut se fier. Il ne décrit pas nécessairement la manière dont les circuits internes sont organisés pour les réaliser.

Deux processeurs peuvent donc respecter une même ISA et avoir des architectures internes différentes. Leurs performances, leur consommation et leurs possibilités d’intégration peuvent diverger. L’ouverture du contrat ne rend pas les implémentations identiques. Elle donne un point commun à partir duquel des concepteurs peuvent travailler.

RISC-V International l’explique explicitement dans sa présentation du standard ouvert : l’organisation produit des spécifications et ne fournit pas d’implémentation matérielle. Les réalisations compatibles peuvent être ouvertes ou commerciales. Cette séparation est le premier repère à garder lorsqu’une annonce associe RISC-V et souveraineté.

L’analogie avec une langue commune est utile : connaître la langue permet de comprendre des messages, mais ne fournit ni le bâtiment où ils seront traités ni l’organisation du travail. Elle reste imparfaite, car une ISA comporte des règles techniques précises et vérifiables. Son intérêt est de montrer qu’un langage partagé n’est pas le produit complet.

Une spécification ouverte n’est pas forcément un cœur ouvert

Le cœur est une réalisation concrète capable d’exécuter les instructions. Son code de description matérielle, ses tests et ses paramètres peuvent être disponibles sous une licence ouverte ou fournis dans le cadre d’un contrat commercial. Ces conditions doivent être examinées indépendamment de celles de l’ISA.

Une entreprise peut choisir un cœur déjà développé plutôt que le concevoir elle-même. Elle gagne alors du temps sur certaines tâches, mais dépend des droits d’utilisation, du support et des possibilités de modification associés à ce cœur. Dire « le processeur utilise RISC-V » ne renseigne pas suffisamment sur ces aspects.

Inversement, disposer d’un cœur ouvert n’élimine pas le travail d’ingénierie. Il faut comprendre le projet, vérifier qu’il répond aux besoins et maintenir les compétences nécessaires. Le droit de modifier et la capacité effective de modifier sont deux ressources distinctes. Une organisation qui n’a ni équipe ni documentation maîtrisée peut rester dépendante d’un prestataire même lorsque les fichiers sont accessibles.

La bonne question devient alors très concrète : si le fournisseur disparaît ou change ses conditions, que peut-on continuer à faire ? Compiler les fichiers, corriger un défaut, adapter une interface et relancer une fabrication ne demandent pas les mêmes moyens. Une réponse globale d’indépendance doit être décomposée en capacités vérifiables.

Autour du cœur, un système entier subsiste

Un processeur utile n’est pas seulement un moteur d’exécution d’instructions. Il communique avec des mémoires et des périphériques, démarre avec des logiciels et s’intègre dans un ensemble. Les fonctions qui l’entourent peuvent provenir d’autres fournisseurs et relever d’autres contrats. Leur présence doit être incluse dans la cartographie des dépendances.

La présentation RISC-V mentionne d’ailleurs des spécifications et des travaux au-delà de l’ISA. Elle cite aussi un écosystème logiciel qui conserve sa propre gouvernance. Le support d’un compilateur ou d’un système d’exploitation n’est donc pas une propriété automatiquement contenue dans le document de l’ISA : il résulte d’implémentations et de versions particulières.

Pour un projet, la compatibilité doit être examinée au niveau réellement utilisé. Une extension personnalisée peut apporter une fonction adaptée, mais elle peut aussi demander des changements dans les outils ou le logiciel. L’ouverture rend certaines adaptations possibles ; elle ne supprime pas le coût de leur maintien ni la nécessité de vérifier leur comportement.

Cela ne constitue pas un argument contre la personnalisation. C’est une invitation à expliciter le compromis. Une extension très utile à une application peut être raisonnable si ses dépendances sont assumées et documentées. Elle devient problématique lorsque l’on promet simultanément une compatibilité immédiate avec tout l’écosystème sans démonstration.

La fabrication reste un métier physique

Même avec une conception entièrement maîtrisée, il faut produire le circuit. La présentation d’ASML sur la fabrication des puces décrit des opérations successives de dépôt, lithographie, transformation, inspection et assemblage. L’ISA ne remplace aucune de ces opérations.

La conception doit être compatible avec les règles du procédé choisi. Les équipements, les matériaux, les capacités de production et les tests forment une chaîne industrielle. Un standard ouvert ne crée pas une usine supplémentaire et ne garantit pas qu’une autre usine puisse reprendre immédiatement un dessin existant.

L’assemblage ajoute encore des questions : boîtier, connexions, dissipation et qualification du produit. Une puce dont le cœur est ouvert peut dépendre d’un fournisseur particulier pour une de ces étapes. Pour analyser la résilience, il faut donc dépasser le niveau du code et examiner ce qui permet la livraison d’un composant conforme.

Cette distinction évite également une lecture géographique trop simple. Le lieu où une spécification est gouvernée, celui où le cœur est conçu et celui où la puce est fabriquée peuvent être différents. Une seule de ces localisations ne décrit pas toute la chaîne. Une analyse sérieuse nomme les étapes et leurs alternatives au lieu d’attribuer une origine unique à un objet complexe.

Le schéma de principe sépare la spécification, son implémentation, les outils, la fabrication et l’assemblage. Les liens signalent des dépendances fonctionnelles. Il ne représente pas une chaîne d’approvisionnement réelle et ne désigne aucun pays comme substitut automatique à un autre.

Les outils sont une dépendance à part entière

Concevoir un circuit exige des moyens pour décrire, simuler, vérifier et préparer sa fabrication. Les licences, les formats, les bibliothèques et les compétences associés à ces outils influencent la liberté pratique du projet. Un fichier accessible n’est utile que si l’on peut l’interpréter et le transformer jusqu’au livrable attendu.

Il faut distinguer l’accès aux outils et la reproductibilité de la chaîne. Une équipe peut disposer d’une licence aujourd’hui sans être capable de reconstruire une ancienne version du produit après une évolution de son environnement. Conserver les versions et les procédures utiles répond à un problème différent de l’ouverture de l’ISA.

Cette observation est une méthode d’analyse, pas un inventaire de produits validés. Nous ne recommandons aucun outil particulier dans ce dossier. Pour un projet réel, la vérification doit porter sur la chaîne effectivement employée, les conditions contractuelles et les moyens disponibles pour traiter un changement ou un défaut.

Le logiciel embarqué doit être examiné de la même manière. Le démarrage, les mises à jour et le support à long terme dépendent de composants dont la gouvernance peut différer. Une promesse d’autonomie qui oublie ces couches peut rester vraie sur le papier du processeur tout en échouant dans l’exploitation du produit.

Une carte de dépendances plus utile qu’une étiquette

Le tableau suivant propose un audit qualitatif. Il n’attribue pas de score de souveraineté : les critères n’ont pas la même importance selon le produit, sa durée de vie et les risques que l’organisation veut réduire.

Couche	Question à poser	Preuve utile
ISA	Quelles instructions et extensions sont utilisées ?	Spécification et version identifiées
Cœur	Peut-on étudier et modifier l’implémentation ?	Licence, sources et documentation
Outils	Peut-on reconstruire et vérifier le dessin ?	Versions, droits et procédure reproductible
Fabrication	Quel procédé et quelles alternatives sont qualifiés ?	Dossier de fabrication et qualification
Assemblage	Qui fournit les interfaces et tests finaux ?	Nomenclature et critères de conformité
Logiciel	Qui maintient démarrage, pilotes et mises à jour ?	Versions, responsabilités et support

Pour utiliser cette grille, il vaut mieux commencer par un scénario de rupture précis. Que se passe-t-il si un fournisseur n’assure plus le support ? Si un composant devient indisponible ? Si une modification fonctionnelle est nécessaire ? Les réponses révèlent les dépendances qui comptent réellement pour l’organisation.

Une alternative théorique ne suffit pas. Elle doit être compatible avec les contraintes du produit et accessible dans un délai utile. Si changer de fournisseur demande une nouvelle conception et une nouvelle qualification, l’alternative existe peut-être, mais elle n’est pas immédiate. Cette distinction doit apparaître dans le calendrier et dans les engagements commerciaux.

Ce que l’ouverture apporte, sans lui demander l’impossible

L’ouverture d’une spécification peut élargir les possibilités d’implémentation et éviter que le contrat logiciel-matériel soit contrôlé comme un produit fermé unique. C’est un bénéfice réel de nature architecturale et collective. Il serait dommage de le rendre moins crédible en lui attribuant des effets industriels qu’il ne garantit pas.

Pour une entreprise, l’intérêt se juge en fonction de son besoin. Un projet peut rechercher une capacité de personnalisation, une diversification des fournisseurs ou une meilleure maîtrise d’une couche technique. Il n’est pas nécessaire d’atteindre une indépendance absolue pour que ce choix ait du sens. Il faut simplement décrire le gain au bon niveau et en documenter les conditions.

Tester une possibilité de remplacement

Une manière concrète d’évaluer une dépendance consiste à choisir une modification limitée et à suivre tout son parcours. L’équipe dispose-t-elle des fichiers nécessaires ? Peut-elle comprendre les tests, reproduire le résultat et préparer les livrables attendus par l’étape suivante ? Ce parcours révèle souvent la différence entre une autorisation inscrite dans une licence et une capacité effectivement maîtrisée.

L’essai doit rester proportionné au risque du projet. Il peut porter sur la reconstruction d’une version ou sur une vérification documentaire, sans prétendre relancer une fabrication complète. Le résultat doit préciser les étapes réalisées et celles qui ne l’ont pas été. Réussir une simulation ne prouve pas la possibilité de produire et de qualifier un composant ; cela établit seulement une partie de la chaîne que l’organisation contrôle.

Ce qui compte : RISC-V ouvre une spécification ; l’autonomie d’un produit dépend de toute une chaîne de capacités. Le lecteur peut désormais demander « quelle dépendance est réduite ? » au lieu de se satisfaire d’une étiquette générale.

Ce qui reste à démontrer : aucun produit ni contrat n’a été audité ici. Les conditions de licence, les extensions, la disponibilité industrielle et le support d’un composant donné doivent être vérifiés dans leurs documents actuels. L’article fournit une méthode de lecture, pas une certification de souveraineté.

Sources documentaires

• RISC-V International, RISC-V: An Open Standard Instruction Set Architecture, 24 mai 2023, lecture le 19 octobre 2026, distinction spécification et implémentation.
• ASML, How microchips are made, lecture le 19 octobre 2026, chaîne de fabrication et catégories d’acteurs ; aucune conclusion juridique ou géopolitique déduite de cette source.