ElectroTech · 19 October 2026

RISC-V en 2026 : des cartes et des laptops qui arrivent vraiment — ce que les benchmarks disent, et ce qu’ils cachent

Les premiers laptops RISC-V quittent réellement les entrepôts, les SBC se comptent désormais par dizaines, et les scores Geekbench circulent partout. Mais derrière les tableaux de chiffres se cache une réalité d’ingénieur plus rugueuse : des toolchains non documentées, des root complexes capricieux, des pilotes GPU en blob et une absence presque totale de mesures au mur. Voici l’état des lieux honnête.

2026, l’année où le RISC-V sort du carton de démo (mais pas encore du labo)

Pendant des années, le débat sur RISC-V ressemblait à une conversation entre commerciaux : on comparait des annonces à des annonces, des slides à des slides. Ce cycle est en train de se rompre. En janvier 2026, le module StarFive VisionFive 3, bâti sur le SoC JH8100 à quatre cœurs RISC-V cadencés à 2,0 GHz, a commencé à être expédié aux développeurs. En mars 2026, Milk-V a annoncé son Titan autour du SoC SG2380 (huit cœurs à 2,4 GHz) à 499 dollars, avec des livraisons en juin. Fin 2025, Sipeed a mis sur le marché son MangoPi MQ-Pro Laptop Kit, un format DIY qui assume son statut de kit d’expérimentation plutôt que de machine de production.

Ces trois dates suffisent à changer la nature du problème. On ne discute plus de l’existence hypothétique d’un laptop RISC-V : on discute de ce qu’il fait réellement quand on lui demande de compiler du code. Et c’est là que le bât blesse, parce que la matière indépendante manque encore cruellement. Les chiffres qui circulent — ceux que nous citerons plus bas — proviennent pour l’essentiel d’un blog tiers, aioapex.com, sans méthodologie publiée, sans lien vers des runs Geekbench publics, sans version de toolchain ni de noyau. Un second guide, Big Iron, apporte un contrepoint qualitatif précieux mais pas de mesures. Et RISC-V International a bien publié un test de cinq SBC, mais le détail n’est pas exploitable dans notre corpus.

Il faut donc poser la méthode d’emblée, parce qu’elle conditionne tout ce qui suit. Nous croisons trois types de sources : les tests tiers (CNX Software, Phoronix, RISC-V International), les retours makers et les blogs spécialisés, et les documents marketing des fabricants. Les limites sont réelles : les données ne sont pas recoupées, les benchmarks canoniques — SPEC CPU 2017, CoreMark, OpenSSL, 7-Zip, STREAM, compilation noyau — sont absents du corpus. Autrement dit, nous pouvons dire ce que les machines font sur Geekbench et sur une compilation busybox, et pas grand-chose de plus. C’est déjà beaucoup, à condition de lire ces chiffres avec les précautions que nous détaillerons.

La question centrale de ce panorama tient en une phrase : où se situe l’écart entre le discours marketing — RVA23, cœurs applicatifs, « prêt pour le poste de développeur » — et les chiffres réellement mesurés ? La réponse n’est ni « c’est prêt » ni « c’est une farce ». Elle est plus intéressante : le silicium progresse plus vite que l’écosystème logiciel, et l’écart entre deux cartes au même SoC peut être plus grand que l’écart entre deux générations de SoC.

Qui fabrique quoi : la carte d’identité des puces RISC-V réellement en volume

Le premier tri à faire est celui entre les cœurs réellement siliconés et expédiés, et ceux qui restent des annonces ou des échantillons développeurs. Le corpus dont nous disposons est mince sur ce point, et nous préférons le dire clairement plutôt que de combler les trous avec des souvenirs. Les familles que cite le cadrage — SiFive P670/P870, Ventana Veyron V2, Tenstorrent Ascalon, SpacemiT K1/K3, StarFive JH7110/JH8100, T-Head C910/C920, Sophgo SG2042/SG2380 — ne sont documentées dans nos sources que pour une poignée d’entre elles.

Ce que nous pouvons affirmer avec les sources disponibles : StarFive a livré le JH8100 dans le VisionFive 3 en janvier 2026, et Sophgo apparaît à travers le SG2380 qui équipe le Milk-V Titan, annoncé en mars 2026 à 499 dollars pour des livraisons en juin. Le MangoPi MQ-Pro Laptop Kit de Sipeed, sorti fin 2025, complète ce tableau des plateformes effectivement disponibles. Pour les autres — les cœurs applicatifs SiFive de la série P, le Veyron V2 de Ventana, l’Ascalon de Tenstorrent, les SpacemiT K1/K3, le T-Head C920, le SG2042 — le corpus ne fournit ni nœud de gravure, ni volumes, ni dates de disponibilité vérifiées. Nous ne les traiterons donc pas comme des produits, mais comme des jalons industriels à surveiller.

Un critère mérite d’être posé comme boussole de pérennité logicielle : le statut RVA23. C’est le profil d’architecture qui garantit qu’un binaire compilé pour RISC-V moderne exploitera les extensions attendues, vectorisation comprise. Une carte dont le SoC n’est pas RVA23-compatible est une carte qui risque de voir sa distribution perdre progressivement le support des builds génériques. Or, dans notre corpus, aucun document ne confirme le statut RVA23 des SoC cités. C’est un angle mort majeur, et il faut le traiter comme tel : avant d’acheter, exiger du fabricant une déclaration explicite sur RVA23 et sur l’état des patches noyau upstreamés.

Le tri entre promesses 2024-2025 concrétisées et promesses restées lettre morte est, lui aussi, partiel. Ce qui s’est concrétisé : le VisionFive 3, le Titan, le kit MangoPi. Ce qui reste à démontrer : à peu près tout le reste, faute de données. Le lecteur doit comprendre que cette carte d’identité est incomplète non par choix éditorial, mais parce que l’industrie communique encore beaucoup en amont de la disponibilité réelle.

Ce que les benchmarks disent vraiment : des scores Geekbench aux compilations, en passant par les trous

Attaquons les chiffres. Les scores Geekbench 6 cités dans notre corpus donnent, pour le StarFive JH8100, environ 220 en mono-cœur et 780 en multi-cœur. Pour le Milk-V Titan SG2380, environ 310 et 1 950. Mettons-les en face des références : Apple M4 à environ 3 900 / 15 200, Snapdragon X Elite à environ 2 900 / 14 800, Intel Core Ultra 7 165H à environ 2 600 / 13 400. L’écart mono entre le meilleur RISC-V documenté et le M4 est de l’ordre de 10:1 ; en multi, de l’ordre de 8:1. Pour relativiser l’ampleur de ces ratios, notons que l’écart entre un M4 et un M1 est lui-même d’environ 2:1.

La compilation busybox, environ 500 000 lignes, offre un second angle : environ 4 minutes sur Milk-V Titan en make -j8, contre environ 45 secondes sur Snapdragon X Elite. Le rapport est cohérent avec Geekbench multi, ce qui est plutôt rassurant sur la cohérence interne des mesures — mais ne dit rien de leur validité méthodologique, nous y reviendrons.

L’analogie la plus parlante avancée par la source est celle d’un Cortex-A55, cœur efficace de smartphones milieu de gamme de 2022, ou d’un Intel Celeron N de 2019. C’est une comparaison qualitative, non étayée par des mesures IPC publiées, mais elle cadre bien l’expérience : on est sur une machine de bureau d’entrée de gamme d’il y a sept ans, avec un écosystème logiciel de 2026.

Chiffres issus d’une source tierce unique, non recoupés, sans méthodologie publiée. À prendre comme ordres de grandeur, pas comme vérités métrologiques.

Et maintenant, le plus important : les trous. Le corpus ne contient aucun résultat SPEC CPU 2017, aucun CoreMark, aucun OpenSSL, aucun 7-Zip, aucun STREAM, aucune compilation de noyau Linux. Ces absences ne sont pas anecdotiques. SPEC CPU 2017 est le seul benchmark qui donne un IPC comparable entre architectures avec une méthodologie auditée. CoreMark donne une idée du débit cœur pur, indépendamment du système. STREAM mesure la bande passante mémoire, qui est précisément le goulot des charges multi-cœurs. OpenSSL et 7-Zip testent des charges réelles mixtes, avec et sans vectorisation. La compilation noyau est le test de référence du développeur embarqué.

Sans ces mesures, on ne peut tirer aucune conclusion solide sur l’IPC réel des cœurs, ni sur le perf/W, ni sur le comportement mémoire. On peut seulement dire : « sur Geekbench 6, dans des conditions inconnues, ces machines obtiennent ces scores ». C’est une base de discussion, pas une base de décision d’achat.

Les biais qui faussent la lecture : toolchain, flags, noyau et vectorisation fantôme

Un score bas peut refléter un mauvais build plutôt qu’un mauvais silicium. C’est la première règle de lecture. Sur RISC-V plus qu’ailleurs, parce que la chaîne d’outils est jeune et que les optimisations spécifiques aux cœurs arrivent tard.

Les biais documentés dans notre corpus sont simples à énumérer : les versions de GCC et de Clang utilisées pour les builds benchmarkés ne sont pas précisées ; les flags d’optimisation (-O2, -O3, -march, -mtune) sont inconnus ; les noyaux utilisés ne sont pas identifiés, et l’on ne sait pas s’ils sont vendor ou mainline ; enfin, l’exploitation de l’extension vectorielle RVV dans les builds n’est mentionnée nulle part. Ce dernier point est le plus dommageable. RVV 1.0 est l’une des extensions qui peuvent changer la donne sur les charges de traitement de signal, de chiffrement et de compilation. Un build qui ne l’active pas mesure un RISC-V scalaire, pas un RISC-V moderne.

À cela s’ajoute la fragmentation de l’extension vectorielle entre implémentations, que Big Iron identifie comme problème structurel. Deux SoC qui implémentent RVV différemment peuvent produire des binaires incompatibles ou sous-optimaux selon la cible de compilation. Un score flatteur peut donc venir d’un test taillé pour la puce, compilé avec le bon -march et le bon runtime, quand un score médiocre vient d’un binaire générique mal adapté.

Les règles de lecture à exiger de tout benchmark RISC-V publié sont donc les suivantes : version exacte de la toolchain (GCC 14.x, Clang 19.x, etc.), flags de compilation complets, identification du noyau et de sa provenance, mention explicite de l’activation ou non de RVV, et lien vers le run public quand il s’agit de Geekbench. Sans ces cinq éléments, un chiffre est une opinion. C’est une exigence de méthode, pas de polémique.

Là où ça coince : mémoire, PCIe, USB, Ethernet et le désert des pilotes GPU/VPU

Passons aux goulots réels. Là encore, il faut distinguer ce qui est mesuré de ce qui est documenté. Ce qui est mesuré dans notre corpus : rien, ou presque. Aucune donnée sur la bande passante mémoire (LPDDR4/5, largeur de bus), aucune sur la latence ou le débit PCIe, aucune sur le nombre de lanes réellement exposées et sur le caractère fonctionnel du root complex, aucune sur les contrôleurs USB 3.x et Ethernet, aucune comparaison eMMC vs NVMe, aucune mesure de performance des pilotes GPU/VPU Imagination BXE ou VeriSilicon.

Ce qui est documenté, en revanche, par Big Iron, ce sont les problèmes structurels : fragmentation de l’extension vectorielle, blobs GPU, décodage vidéo manquant, parité de distribution incomplète par rapport à ARM. Ces quatre points dessinent une carte des frictions assez fiable, même sans chiffres à l’appui.

Le décodage vidéo manquant est un point particulièrement sensible pour les usages gateway et media. Un SoC sans décodage matériel exploitable en mainline se retrouve à décoder en logiciel, ce qui consomme du CPU et de l’énergie sur des charges qui, sur un Raspberry Pi 5 ou un Rock 5, sont gratuites. Les blobs GPU sont un autre point de friction : quand le pilote est binaire, la maintenance devient dépendante du bon vouloir du fabricant, et les mises à jour de noyau deviennent des paris.

Le root complex PCIe est le troisième point. Sur un SBC RISC-V, l’exposition de lanes PCIe ne garantit pas que le contrôleur fonctionne correctement en tant que root complex, avec énumération fiable, gestion des interruptions et support des périphériques courants. C’est un domaine où les retours makers sont indispensables et où les fiches techniques sont trompeuses : « PCIe x4 » sur un slide ne veut pas dire « un GPU ou un NVMe s’énumère au boot ».

Enfin, la bande passante mémoire est le goulot silencieux. Sur des charges multi-cœurs (compilation, chiffrement, traitement de flux), c’est souvent la mémoire qui limite, pas les cœurs. Sans STREAM, on ne peut pas savoir où se situe chaque plateforme. C’est précisément pour cela que l’absence de ce benchmark est dommageable.

La conclusion de Big Iron mérite d’être citée telle quelle : 2026 n’est pas un step-change par rapport à 2025 pour le homelab, et les SBC RISC-V ne sont toujours pas une alternative générale à un Raspberry Pi 5 ou un Rock 5. Ce n’est pas un réquisitoire, c’est un constat de maturité.

Watts au mur et degrés dans le boîtier : ce qu’on sait, ce qu’on ignore

C’est le trou le plus dommageable pour un ingénieur, et il faut le dire sans détour : aucune donnée mesurée au mur n’est disponible dans notre corpus. Pas de consommation idle, pas de consommation en charge, pas de consommation en veille. Pas de perf/W. Pas de comparaison avec le Raspberry Pi 5, le Rockchip RK3588, l’Intel N100/N150 ou le Snapdragon X. Pas de mesure de throttling. Pas d’évaluation de la qualité des refroidissements passifs ou actifs. Pas d’autonomie réelle pour les laptops RISC-V — ni pour le DeepComputing DC-ROMA, ni pour le mainboard Framework, ni pour le HiFive Premier P550 en poste fixe, qui n’est même pas mentionné dans les extraits.

Pourquoi est-ce le trou le plus grave ? Parce que le perf/W est le critère qui décide, dans l’embarqué, entre deux architectures. Un SoC RISC-V qui consomme 8 W pour un score Geekbench de 310 mono est moins intéressant qu’un SoC ARM qui consomme 3 W pour le même score. Sans mesure au mur, on ne peut pas trancher. Et pour un laptop, l’autonomie est le critère numéro un de l’utilisateur final : sans mesure, le produit n’existe pas commercialement.

Les protocoles de mesure qu’il faudrait exiger sont standards : mesure à la prise avec un wattmètre calibré, en idle après stabilisation thermique, en charge CPU soutenue (par exemple stress-ng sur tous les cœurs pendant trente minutes), en veille S3 ou s2idle, avec relevé de température ambiante et de température de jonction. Pour l’autonomie, un scénario reproductible : navigation web, compilation, lecture vidéo, avec mesure de la capacité batterie initiale et finale. Aucun de ces protocoles n’est documenté dans le corpus, pour aucune plateforme.

C’est un appel : les fabricants qui veulent vendre des laptops RISC-V en 2026 doivent publier ces chiffres, et les médias indépendants doivent les mesurer. Tant que ce n’est pas fait, toute affirmation sur l’efficacité énergétique du RISC-V relève de la foi, pas de l’ingénierie.

Choisir sa carte selon l’usage : edge, contrôle, gateway, poste de dev

Malgré ces lacunes, on peut construire une matrice de décision raisonnable, à condition de l’assumer comme provisoire.

Pour l’edge et le contrôle — temps réel, I/O déterministe, consommation —, le RISC-V a un argument structurel : l’ouverture de l’ISA permet des implémentations sur mesure, et les cœurs sont simples. Mais dans notre corpus, aucune plateforme n’est documentée sur ces critères. Le VisionFive 3, avec ses quatre cœurs à 2,0 GHz, est la plateforme la plus mûre côté écosystème logiciel, ce qui en fait un choix raisonnable pour l’expérimentation et l’apprentissage. Le Milk-V Titan, avec ses huit cœurs à 2,4 GHz et son prix de 499 dollars, est le meilleur candidat pour les charges multi-cœurs à budget contenu, à condition d’accepter l’incertitude sur les pilotes et le support noyau.

Pour la gateway — Ethernet, PCIe, stabilité des pilotes —, la prudence est de mise : sans données sur les contrôleurs Ethernet et sur le root complex, on ne peut pas recommander une plateforme pour cet usage. Le décodage vidéo manquant et les blobs GPU documentés par Big Iron sont des signaux d’alerte.

Pour le poste de développement, le HiFive Premier P550 est cité dans le cadrage comme candidat au poste fixe, mais notre corpus ne le documente pas. Les kits laptop — MangoPi MQ-Pro, DC-ROMA, mainboard Framework — relèvent de l’expérimentation, pas de la production. Personne ne devrait acheter un laptop RISC-V en 2026 pour remplacer sa machine de travail ; en revanche, c’est un excellent outil pour comprendre ce que signifie porter une chaîne de compilation sur une architecture émergente.

Les pièges d’intégration à connaître sont toujours les mêmes : PCIe (root complex fonctionnel ou non), USB (contrôleur xHCI stable ou non), alimentation (qualité du régulateur, comportement en charge), thermique (refroidissement passif suffisant ou non). Sur ces quatre points, la règle est simple : exiger des retours makers documentés avant d’acheter, et privilégier les cartes dont la communauté publie des patches noyau.

Toolchains et support logiciel : le vrai discriminant entre deux cartes au même SoC

Voici le point le plus important de ce panorama, et celui qui est le plus sous-estimé par les acheteurs. Deux cartes au même SoC peuvent diverger radicalement selon la qualité du BSP (board support package) et de la communauté. Une carte avec un noyau vendor figé et des pilotes binaires est une carte qui vieillira mal ; une carte avec des patches upstreamés et une distribution mainline est une carte qui vieillira bien.

L’état des toolchains dans notre corpus est, là encore, mal documenté : aucune information sur le statut des patches SoC dans le noyau Linux mainline pour le JH8100 ou le SG2380, aucune sur l’état de GCC et Clang pour RVA23 et RVV 1.0, aucune sur la disponibilité réelle des distributions (Debian riscv64, Ubuntu ports, Fedora, Arch, Yocto, Buildroot). Ce que Big Iron documente, c’est la fragmentation de RVV et l’incomplétude de la parité de distribution par rapport à ARM.

Les signaux d’alerte à connaître sont : noyau vendor figé (pas de mise à jour de sécurité), pilotes binaires (dépendance au fabricant), absence d’upstream (impossible de suivre le mainline), distribution non mainline (paquets manquants, support communautaire faible). Les bonnes pratiques : privilégier les cartes dont les patches sont publiés et revus sur la liste de diffusion Linux, vérifier la politique de publication des patches du fabricant, et préférer une distribution dont le port riscv64 est officiel.

C’est ici que se joue la différence entre un achat d’ingénieur et un achat de collectionneur. Un SBC RISC-V avec un bon support mainline est un investissement ; un SBC avec un BSP figé est un objet de démonstration.

Ce que 2026 change vraiment — et les signaux faibles à surveiller

Que change réellement 2026 ? Trois choses. D’abord, la disponibilité : on peut acheter un VisionFive 3, un Milk-V Titan, un kit MangoPi. Ensuite, la mesure : on commence à avoir des chiffres, même imparfaits, sur lesquels discuter. Enfin, la comparaison : on peut désormais situer le RISC-V par rapport à ARM et x86 avec des ordres de grandeur, et non plus par rapport à des promesses.

Ce que 2026 ne change pas : le RISC-V n’est pas encore une alternative générale à un Raspberry Pi 5 ou à un Rock 5 pour le homelab, et il ne l’est pas non plus pour le poste de développement. Il devient en revanche un choix légitime pour des usages ciblés — apprentissage, expérimentation, edge sur mesure — et pour les ingénieurs qui veulent comprendre une architecture ouverte de l’intérieur.

Les signaux faibles à surveiller sont clairs : RVA23 comme standard de pérennité, cœurs applicatifs plus larges (SiFive P670/P870, Ventana Veyron V2, Tenstorrent Ascalon), exploitation réelle de RVV dans les builds, root complex PCIe complet, pilotes GPU et VPU ouverts. Chacun de ces signaux, s’il se concrétise, déplace la frontière entre expérimentation et production.

Ce qu’il faudrait voir publier en 2027 pour que le discours rattrape les chiffres : des résultats SPEC CPU 2017, des CoreMark, des STREAM, des mesures au mur, des autonomies réelles. Et surtout, une culture du benchmark reproductible : version de toolchain, flags, noyau, lien vers le run public. C’est la seule manière de transformer un débat d’annonces en débat d’ingénieurs. Le RISC-V mérite mieux que des slides ; il mérite des wattmètres et des logs de compilation.

Sources

• RISC-V SBCs in 2026: The Honest Status Check — Big Iron
• 5 RISC-V Single-Board Computers Tested: Performance, Benchmarks, Features and Insights — RISC-V International
• RISC-V Microcontrollers 2026: Complete Guide — Justlast
• The Evolving RISC-V Architectures — riscv100.top
• CPU-2026-Benchmark — GitHub
• Scores Geekbench 6 et compilation busybox cités par aioapex.com (source tierce unique, non recoupée, méthodologie non publiée)

Article recherché et rédigé automatiquement · Magazine Electrosens