Un système de systèmes d'exploitation : architecture E/E, OS véhicule et véhicule défini par l'IA

Résumé

« OS véhicule » est devenu un mot que tout constructeur voulant passer pour défini par le logiciel doit posséder. Pourtant, les choses appelées « OS » ne sont pas du tout de même nature. Cet article commence par un nettoyage ontologique : un OS de cockpit n’est pas un OS véhicule, un OS de domaine n’est pas un OS véhicule, et un environnement d’exécution n’est pas un OS. Chaque OS véhicule en production aujourd’hui — MB.OS, NIO SkyOS, Li Auto HaloOS, Pleos Vehicle OS — est un assemblage multi-noyaux gouverné par un unique plan de contrôle à l’échelle du véhicule. Nous décomposons ce plan de contrôle en trois parties observables — contrat, orchestration et cycle de vie — et en déduisons une matrice de capacités de l’OS véhicule (Vehicle OS Capability Matrix, VOCM) à six dimensions, avec laquelle nous donnons une première évaluation de 15 constructeurs, mise en regard des scores AR de D2.

Le cœur de l’article est une structure causale. L’architecture E/E fixe la limite de ce que peut être un OS véhicule ; mais dès que les fonctions deviennent logicielles, la causalité s’inverse — les charges de travail logicielles commencent à concevoir l’architecture E/E suivante (la boucle de coévolution architecture–OS). Sur cette base, nous soutenons que la conduite autonome est le test de résistance qui dit si un OS véhicule est réel ; que l’IA amincit la moitié supérieure de l’OS et épaissit sa moitié inférieure ; et que ce que l’industrie standardise réellement, c’est l’API véhicule, le modèle de données et le contrat d’exécution — pas « un OS automobile ». La conclusion livre trois jugements et un avertissement, avec cinq déclencheurs de révision.

---

Note sur le genre

Cet article appartient à la catégorie Deep Dive, non à celle des Working Papers. La ligne de partage n’est pas la longueur mais le niveau d’engagement :

• Working Papers (D1–D4, DOI Zenodo) = thèses verrouillées. Jamais révisées en silence ; conçues pour résister à cinq ans de citations.
• Deep Dives (cette catégorie) = observations disciplinées. Révisables, réfutables, explicitement étiquetées « voici ce que nous voyons maintenant », hors du système DOI.

Cet article hérite de la discipline épistémique des Working Papers — hiérarchisation des sources, preuves traçables, contre-arguments et modes de défaillance obligatoires — mais pas de leur caractère définitif. Il ne révise aucune conclusion publiée de D1–D4 ; les scores de D2 qu’il cite sont ceux de la version publiée. Les niveaux de preuve sont marqués dans le texte par [T1], [T2], [T3] et [inférence] ; voir l’annexe A. Ses conclusions portent leurs propres déclencheurs de révision (chapitre 10) ; si l’un d’eux se déclenche, une édition révisée sera publiée avec les changements signalés.

---

Introduction : un mot que tout le monde emploie et que personne ne définit

En juin 2025, la première CLA équipée de MB.OS est sortie de l’usine Mercedes-Benz de Rastatt [T1]. À la même période, NIO qualifiait son SkyOS de « système d’exploitation véhicule pleine domaine », Li Auto publiait HaloOS en open source sous Apache 2.0, Toyota lançait Arene avec le nouveau RAV4, et Hyundai scindait Pleos en deux marques, « Vehicle OS » et « Connect ». En 2026, « OS véhicule » était devenu un mot que tout constructeur voulant passer pour défini par le logiciel doit posséder.

Le problème est que les choses appelées « OS » ne sont pas du tout de même nature.

Android Automotive est un OS. BMW Operating System X s’appelle OS. NVIDIA DriveOS s’appelle OS. AUTOSAR est parfois appelé OS à tort. MB.OS, SkyOS, HaloOS et Pleos Vehicle OS sont aussi des OS. Mettez-les dans un même tableau et classez-les, et vous comparez des pommes, des oranges et des vergers.

Cette série de recherche a effleuré ce mot trois fois sans s’arrêter pour le définir. D1 a rangé l’OS en C3 parmi sept points de contrôle architecturaux, a inscrit RTOS, AUTOSAR et middleware dans la couche logicielle de l’architecture E/E, et a soutenu au §3.4 que l’hyperviseur est le pont entre écosystèmes ouverts et temps réel dur. D2, dans son profil de Mercedes, a explicitement séparé MMA (la plateforme matérielle) de MB.OS (le système d’exploitation logiciel) et averti le lecteur de ne pas les confondre. DD-08, Le conducteur s’efface, a soutenu que dès que le conducteur humain quitte la chaîne de repli, le fail-operational passe d’option haut de gamme à condition d’entrée.

Tous trois pointent vers la même case vide : entre « topologie électrique et électronique » et « intelligence », quelle couche transforme un amas de calculateurs en une machine programmable, capable d’évoluer et, à terme, de porter la conduite autonome et l’IA ?

C’est à cette question que répond cet article. Il n’y a qu’une seule question directrice :

À quelles conditions une architecture E/E cesse-t-elle d’être une simple topologie électronique pour devenir la plateforme d’une « voiture programmable » ?

Notre réponse tient en quatre phrases, qui forment aussi le squelette de l’article :

L’E/E est le substrat. Le plan de contrôle est l’OS. L’IA est l’intelligence adaptative. L’autonomie est le test de résistance.

Dépliées, elles donnent six jugements :

• T1 | Définition : l’OS véhicule n’est pas un système d’exploitation unique mais un « système de systèmes d’exploitation » gouverné par un plan de contrôle à l’échelle du véhicule. Plan de contrôle = contrat + orchestration + cycle de vie.
• T2 | Précondition : sans architecture E/E suffisamment découplée, pas d’OS véhicule. Le plafond de l’abstraction logicielle est fixé par l’architecture physique.
• T3 | Inversion : dès que les fonctions deviennent logicielles, la causalité s’inverse — les charges de travail logicielles commencent à concevoir l’architecture E/E suivante. C’est la contribution originale centrale de cet article : la boucle de coévolution architecture–OS.
• T4 | Test de résistance : la conduite autonome n’est pas l’OS véhicule ; c’est la charge de travail qui teste si un « OS véhicule » mérite son nom.
• T5 | Gouvernance : l’IA n’éliminera pas l’OS. Elle amincit sa moitié supérieure et épaissit sa moitié inférieure — l’intelligence probabiliste doit s’exécuter au sein d’une gouvernance déterministe.
• T6 | Point de convergence : ce que l’industrie standardise réellement n’est pas « un OS automobile » mais « API véhicule + modèle de données + contrat d’exécution ». Les noyaux se banalisent, et le point de contrôle C3 est pris en tenaille entre C2 (le silicium) et C4 (le middleware).

Commençons par la tâche la plus élémentaire : nettoyer le mot.

---

1. Le problème du nom : tout ce qui s’appelle « OS » n’est pas un OS

1.1 Un nettoyage ontologique

En informatique, « système d’exploitation » a un sens assez clair : la couche logicielle qui gère les ressources matérielles et offre abstraction et isolation aux programmes situés au-dessus. Linux, QNX et les divers RTOS y correspondent. Le problème, c’est que l’industrie automobile applique le même mot à au moins quatre niveaux différents :

• OS de niveau noyau : QNX, Linux, l’OS Classic AUTOSAR, les RTOS, les micronoyaux. Ils gèrent une puce ou un calculateur.
• Environnement d’exécution et middleware : AUTOSAR Adaptive Platform, SOME/IP, DDS, ROS 2. Ils définissent la communication, la découverte de services et la gestion de l’exécution, mais s’exécutent eux-mêmes au-dessus d’un noyau — le matériel cible de l’Adaptive Platform fait tourner un système d’exploitation conforme à POSIX PSE51, sur lequel AP est construit [T2].
• OS de domaine : Android Automotive, BMW OS X, NVIDIA DriveOS, le cockpit HarmonyOS. Ils gèrent un domaine fonctionnel, comme le cockpit ou le calculateur de conduite.
• Ce que les constructeurs appellent « OS véhicule » : MB.OS, SkyOS, HaloOS, Pleos Vehicle OS. Ils prétendent gérer toute la voiture.

Les trois premiers niveaux ont des frontières techniques claires. Pas le quatrième. C’est un nom de marque, un engagement organisationnel et un corpus logiciel qui enjambe plusieurs noyaux, domaines et puces. Tout cet article est une tentative de donner à ce quatrième niveau une définition vérifiable.

1.2 Trois règles de discrimination

Avant de le définir, nous posons trois règles négatives. Leur rôle est d’écarter ce qui ne compte pas comme OS véhicule.

Règle 1 : OS de cockpit ≠ OS véhicule.

BMW Operating System X repose sur AOSP et gère l’affichage, l’interaction et l’expérience numérique du Panoramic iDrive [T2] ; l’architecture véhicule réelle de la Neue Klasse, ce sont quatre « superbrains » — pour l’infodivertissement, la conduite automatisée, la dynamique de conduite et les fonctions de base — plus des contrôleurs zonaux [T1–T2]. La séparation de Hyundai est encore plus nette : Pleos Connect est un système d’infodivertissement basé sur Android Automotive, prévu pour le deuxième trimestre 2026 ; Pleos Vehicle OS est un OS de contrôle du véhicule bâti sur un calculateur haute performance et des contrôleurs zonaux [T2–T3]. Qu’une entreprise sépare les deux en marques distinctes en est la meilleure preuve : le système le plus beau sur l’écran du cockpit n’est pas le système qui peut piloter la voiture.

Règle 2 : OS de domaine ≠ OS véhicule.

NVIDIA DriveOS est un système d’exploitation et un environnement d’exécution pour le calcul accéléré, l’intégration des capteurs, la conduite automatisée et le cockpit IA ; DriveOS 6.0 a été certifié ISO 26262 ASIL D par TÜV SÜD [T2]. C’est l’un des produits les plus solides de son domaine. Mais ce qu’il gère, c’est le domaine de calcul DRIVE, pas les fonctions à l’échelle du véhicule qui incluent carrosserie, thermique, énergie et châssis.

Règle 3 : environnement d’exécution ≠ OS.

AUTOSAR Adaptive définit des comportements : gestion de l’exécution, communication, stockage, sécurité. Il dépend d’un noyau POSIX en dessous et de l’intégration du constructeur au-dessus. L’appeler « un OS », c’est comme appeler TCP/IP le réseau lui-même.

Les trois règles partagent une implication : le nom n’est pas un critère. Ce qui s’appelle OS n’est pas forcément un OS véhicule (BMW OS X n’en est pas un) ; ce qui ne s’appelle pas OS peut être de fait une plateforme à l’échelle du véhicule (Tesla n’a jamais donné de marque d’OS à sa pile logicielle, Rivian non plus). Le vocabulaire changeant de Toyota aiguise le propos : en avril 2023, Toyota décrivait officiellement Arene comme « a comprehensive software platform and vehicle operating system » [T1] ; lorsqu’il est entré en production avec le nouveau RAV4 en 2025, Toyota et la presse parlaient plus souvent de « software development platform » [T2]. Ce n’est pas un jeu de mots. Cela soulève une question à laquelle revient le chapitre 4 : le point de contrôle d’un OS véhicule se situe-t-il dans l’environnement d’exécution ou dans le cycle de vie logiciel ?

1.3 La taxonomie chinoise : une réponse adossée à des normes nationales

Sur la question de la définition, la Chine est allée plus loin que toute autre région, car elle a inscrit la réponse dans des normes nationales.

En 2019, le Comité technique national de normalisation automobile a publié le Système de normes pour les systèmes d’exploitation de véhicules, qui répartit les OS de véhicules en deux classes : OS de contrôle du véhicule et OS embarqués [T1]. Les OS de contrôle du véhicule se subdivisent en OS de contrôle de sécurité (groupe motopropulseur, châssis, carrosserie — avec les exigences de temps réel et de sécurité les plus strictes) et OS de conduite intelligente (pour les contrôleurs de domaine de conduite) ; les OS embarqués servent la console centrale, le combiné d’instruments et le T-box.

Le 31 mars 2026, cette taxonomie est devenue deux normes nationales recommandées, en vigueur depuis le 1er juillet de la même année [T1] :

• GB/T 47351-2026 : OS de contrôle du véhicule, définissant le type I (OS de conduite intelligente) et le type II (OS de contrôle de sécurité).
• GB/T 47341-2026 : exigences techniques et méthodes d’essai des OS embarqués. D’après des extraits d’une traduction commerciale, elle définit l’OS embarqué comme « l’ensemble des logiciels qui fournissent aux véhicules intelligents connectés des services autres que la mise en œuvre des fonctions d’automatisation de la conduite », et recommande ASIL B ou plus pour les OS embarqués prenant en charge des scénarios à forte contrainte temps réel comme les alertes du combiné [T3 : traduction commerciale, pas le texte de la norme].

Selon des informations publiques, la liste des organismes rédacteurs est en soi une carte de l’industrie : Huawei (Yinwang), Horizon Robotics, Qualcomm, NIO, BYD, Li Auto, Mercedes-Benz Chine et Volkswagen Chine en font partie [T2].

La valeur des normes nationales est qu’elles découpent les OS selon l’attribut de sécurité fonctionnelle plutôt que selon la marque. Mais elles laissent aussi un vide : il y a un OS de contrôle du véhicule et un OS embarqué, mais pas d’« OS véhicule ». Dans la partition en quatre courante dans la recherche et l’industrie — OS de contrôle de sécurité, OS de conduite intelligente, OS de cockpit intelligent et « OS de calcul central » interdomaines —, la quatrième catégorie n’a pas d’équivalent dans les normes. [inférence] Ce vide est précisément l’endroit où vit le concept marketing d’« OS véhicule », et précisément ce que cet article entend cerner avec l’idée de plan de contrôle.

1.4 L’OS véhicule est-il donc une fausse question ?

Posons d’abord l’objection la plus tranchante : retirez la couche de marque et le soi-disant OS véhicule n’est plus que QNX + Linux + AUTOSAR + un hyperviseur + un tas de middleware — tout cela existait il y a dix ans. Que reste-t-il ?

Notre réponse : en tant que marque, il est surestimé ; en tant qu’entité technique, il est réel. Ce qui reste n’est pas un noyau particulier, mais ce qui organise plusieurs noyaux, domaines et puces en une seule voiture — un contrat de service unifié, une orchestration entre niveaux de criticité, et un système de mise à jour et de validation couvrant toute la vie du véhicule. Le chapitre suivant le démonte.

---

2. Un système de systèmes d’exploitation : démonter un « OS véhicule »

2.1 Tout OS véhicule en production est un assemblage multi-noyaux

Ouvrez n’importe quel OS véhicule en production et vous trouvez non pas un noyau, mais une famille.

NIO SkyOS adopte une structure « 1+4+N » [T2] : le « 1 » est SkyOS-H, un hyperviseur gérant des ressources de calcul hétérogènes ; les « 4 » sont quatre noyaux pour différents scénarios — le noyau de contrôle du véhicule repose sur le micronoyau seL4, formellement vérifié, et le noyau du cockpit sur un Android profondément personnalisé ; les « N » sont des composants middleware maison pour la coordination interdomaines et les mises à jour de cycle de vie. [T3 : les sources divergent sur la répartition exacte des rôles entre les autres sous-noyaux ; nous ne la détaillons pas ici.] SkyOS a été déployé intégralement le 27 juillet 2024 et fonctionne dans toute son étendue sur les modèles de la plateforme NT3 [T2].

Li Auto HaloOS est un ensemble en trois parties : un OS de contrôle du véhicule, un OS de conduite intelligente et un middleware de communication [T2]. Le 27 mars 2025, Li Auto a annoncé son passage en open source ; il a publié la 0.1.0 en avril (RTOS temps réel de sécurité plus un bus de communication léger), la 1.0.0 le 30 juin, puis a ouvert son moteur de virtualisation [T2]. Li Auto indique y avoir consacré plus de 200 personnes et plus d’un milliard de RMB, avoir livré la première version de série en 2024 et réduit l’adaptation à une nouvelle puce de 3–6 mois à quatre semaines [T2, déclaration de l’entreprise].

Hyundai Pleos sépare OS de contrôle du véhicule et OS de cockpit en deux marques (voir 1.2). GB/T 47351 sépare l’OS de contrôle du véhicule lui-même en type I et type II.

Il n’y a qu’une conclusion, et c’est la première thèse de l’article :

T1 | L’OS véhicule n’est pas un système d’exploitation unique, mais un « système de systèmes d’exploitation » gouverné par un plan de contrôle à l’échelle du véhicule.

2.2 Un modèle de pile à six couches : S0–S5

Pour réunir les produits de différents fournisseurs dans une même image, nous proposons un modèle de pile à six couches (figure 2.1).

Autour se trouve un anneau extérieur, qui n’est pas dans le véhicule mais décide de ce que le véhicule peut faire : le cloud, l’OTA, la boucle de données, le DevSecOps et le cycle de vie des modèles, nouvellement apparu.

Figure 2.1 — Un système de systèmes d’exploitation : la pile S0–S5 et l’anneau extérieur. Note de lecture : l’OS véhicule n’est aucune des couches de la figure, mais la gouvernance unifiée de S1–S3 par S4 ; S0 décide de l’étendue de ce que S4 peut gouverner ; l’anneau extérieur décide si S4 peut continuer d’évoluer après la vente de la voiture.

2.3 Les trois parties du plan de contrôle : contrat, orchestration, cycle de vie

« Plan de contrôle » est emprunté à l’ingénierie réseau : le plan de données achemine chaque paquet, le plan de contrôle décide où les paquets doivent aller. Dans une voiture, le plan de données, ce sont les processus, tâches et signaux qui s’exécutent réellement dans S1–S3 ; le plan de contrôle est la couche qui décide qui peut s’exécuter où, avec quelle priorité, via quelle interface et à quelles conditions il peut être remplacé.

Nous décomposons le plan de contrôle du véhicule en trois parties :

1. Contrat : interfaces de service, API véhicule, sémantique des signaux et des données. Il promet que « les fonctions sont découplées de l’emplacement physique des calculateurs » — un service de climatisation n’a pas à se soucier de la puce sur laquelle il finira par s’exécuter.
2. Orchestration : ordonnancement à criticité mixte, preuve d’isolation (freedom from interference), migration de fonctions, arbitrage des ressources. Elle décide comment une fonction de freinage ASIL D et la lecture musicale de niveau QM partagent une puce sans interférer.
3. Cycle de vie : OTA, retour arrière, diagnostic, DevSecOps, et désormais cycle de vie des modèles. Il décide à quel point la voiture peut encore être modifiée après sa sortie d’usine, à quelle vitesse et sous quel argumentaire de sécurité.

Vues à travers ces trois parties, les règles de 1.2 deviennent beaucoup plus claires : un OS de cockpit n’a de contrat que pour le domaine cockpit ; un OS de domaine a une orchestration forte, mais au sein d’un seul domaine ; un environnement d’exécution spécifie des contrats sans assumer l’orchestration ni le cycle de vie à l’échelle du véhicule. Nous n’appelons OS véhicule que ce dont le contrat, l’orchestration et le cycle de vie couvrent ensemble les principaux domaines du véhicule.

Cette définition présente un avantage immédiat : elle est observable. Si un constructeur affirme avoir un OS véhicule, il suffit de poser trois questions — quels domaines son API véhicule couvre-t-elle ? Quel niveau de certification son intégration à criticité mixte a-t-elle atteint ? Quels domaines son OTA peut-il mettre à jour ? La notation VOCM du chapitre 5 déplie ces trois questions en six dimensions.

2.4 Un fait sous-estimé : concentration extrême en bas, fragmentation extrême en haut

Projetez les produits de chaque fournisseur sur S0–S5 et un tableau saisissant apparaît :

• En S1, le marché est extrêmement concentré. Le rapport annuel de BlackBerry pour l’exercice 2026 indique que QNX est embarqué dans plus de 275 millions de véhicules, soit 20 millions de plus sur un an, en travaillant avec plus de 45 constructeurs et en couvrant les 10 premiers OEM et 24 des 25 premiers OEM de véhicules électriques [T1]. QNX OS for Safety et QNX Hypervisor for Safety sont tous deux certifiés ISO 26262 ASIL D [T1].
• En S4, le marché est extrêmement fragmenté. Plus de dix constructeurs revendiquent chacun leur propre OS véhicule, aucun n’étant compatible avec les autres.

C’est le modèle à deux couches convergence–divergence de D1 qui réapparaît au niveau logiciel : l’infrastructure converge en bas, la sémantique de contrôle diverge en haut. Cela annonce aussi la lutte qu’aborde le chapitre 7 — si S1 et S2 sont voués à se banaliser, où va la valeur ?

---

3. La route avant la voiture : l’E/E fixe la limite de ce que peut être un OS

3.1 Pourquoi aucun OS véhicule ne pousse sur une architecture distribuée

Imaginez une voiture conventionnelle à 100 calculateurs. Chacun fait tourner son propre OSEK ou Classic AUTOSAR, chacun provient d’un fournisseur de rang 1 différent, chacun a sa propre version logicielle, ses données de calibration et son processus de flashage. Dans une telle voiture, un OS véhicule est physiquement impossible — il n’existe aucun endroit où un environnement d’exécution unifié pourrait résider, ni aucun canal assez large pour qu’un contrat de service franchisse les frontières des calculateurs.

C’est la deuxième thèse de l’article :

T2 | Sans architecture E/E suffisamment découplée, pas d’OS véhicule. Le plafond de l’abstraction logicielle est fixé par l’architecture physique.

3.2 Cinq catalyseurs

À mesure que l’architecture E/E passait du distribué au domaine, puis au zonal plus calcul central, cinq éléments ont rendu le plan de contrôle du véhicule possible sur le plan technique (en correspondance avec le cadre Bosch en six étapes du chapitre 2 de D1) :

Des cinq, les quatre premiers décident si le plan de contrôle peut être unifié ; le cinquième décide si l’on peut s’y fier. Sans les quatre premiers, pas d’OS véhicule ; sans le cinquième, l’OS véhicule reste dans le monde du fail-soft — point que développe le chapitre 6.

3.3 La matrice des générations : quelle couche chaque génération E/E peut accueillir

Croisez S0–S5 avec les générations E/E (figure 3.1) et un schéma simple apparaît :

• Distribuée : S1 seulement (le RTOS propre à chaque calculateur).
• Domaine : S2 et S3 apparaissent — Android dans le cockpit, Linux / QNX pour la conduite, SOA intradomaine. Mais chaque domaine fait cavalier seul ; la plupart des revendications d’« OS véhicule » de cette génération relevaient du marketing.
• Fusion interdomaines : un S4 partiel apparaît — deux ou trois domaines commencent à partager des contrats ; l’intégration cockpit-conduite est tentée.
• Zonal + calcul central : S4 devient véritablement réalité technique.
• Central + natif IA : S5 commence à apparaître.

Figure 3.1 — Ce que chaque génération E/E peut accueillir. L’axe x est la génération E/E (distribuée → domaine → fusion interdomaines → zonal + central → central + natif IA) ; l’axe y est S1–S5. Chaque case est marquée « non faisable / partiel / en production / émergent ». Note de lecture : les cases « en production » de S4 n’apparaissent qu’à partir de la colonne zonal + central ; la plupart des produits appelés « OS véhicule » auparavant se situent en réalité en S3.

La matrice livre un corollaire réfutable : si quelqu’un construit un plan de contrôle couvrant les principaux domaines du véhicule sans changer de génération E/E, T2 devra être révisée. Nous l’inscrivons parmi les déclencheurs de révision (chapitre 10).

---

4. La causalité inversée : quand le logiciel commence à concevoir le matériel

4.1 De « l’E/E porte l’OS » à « l’OS conçoit l’E/E »

Le chapitre 3 décrivait un sens : d’abord l’E/E, ensuite l’OS. C’est l’histoire que l’industrie raconte le plus souvent — et la moitié la moins complète.

L’autre moitié : dès qu’un constructeur a véritablement bâti un plan de contrôle du véhicule, il commence en retour à décider de l’architecture E/E suivante.

GM fournit un rare exemple publié par le constructeur lui-même. Il affirme que sa plateforme de calcul central de 2028 apporte 10 fois la capacité OTA, 1 000 fois la bande passante et 35 fois la puissance de calcul IA [T1, déclaration de l’entreprise]. Aucun de ces trois chiffres n’est défini à partir d’un « meilleur matériel » ; tous sont des spécifications matérielles déduites à rebours de ce que le logiciel doit faire.

Le Tech Day de Leapmotor en septembre 2026 a fourni un second exemple, plus détaillé. Leapmotor présente l’évolution de son E/E comme une lignée générationnelle claire :

• LEAP 3.0 : l’architecture à intégration centrale « Four-Leaf Clover », lancée en 2023.
• LEAP 4.0 : intégration cockpit-conduite sur une seule puce sur la plateforme D [T3].
• LEAP 5.0 : le futur « Four-Leaf Clover 5.0 », avec trois changements [T2–T3] :
  • Contrôle : contrôle à intégration centrale.
  • Énergie : alimentation 48 V sur tout le véhicule, câblage total inférieur à 500 mètres, poids du faisceau réduit jusqu’à 50 % et — selon l’entreprise — pertes thermiques du câblage ramenées à 1/16.
  • Réseau : Ethernet sur tout le véhicule avec un schéma à débit asymétrique — 10G en descendant, 100M en montant.
• Production : premiers modèles en 2027 [T2].

Le dernier point réseau mérite qu’on s’y arrête. Un débit symétrique est la logique d’un réseau généraliste ; un débit asymétrique signifie que le réseau est conçu selon la façon dont les données circulent réellement — quel sens porte un trafic lourd et lequel ne porte que le contrôle et l’état. [inférence] C’est une topologie réseau définie par le logiciel et les flux de données : savoir d’abord comment le plan de contrôle doit déplacer les données, puis décider comment poser les câbles. L’alimentation 48 V et le faisceau plus court suivent la même logique — le contrôle central permet de réorganiser la distribution d’énergie et le câblage autour d’« un cerveau plus quelques zones » plutôt que d’« un boîtier par fonction ».

C’est la thèse centrale de l’article :

T3 | Dès que les fonctions deviennent logicielles, la causalité s’inverse : les charges de travail logicielles commencent à concevoir l’architecture E/E suivante.

Réunissez les deux sens et vous obtenez une boucle fermée (figure 4.1) :

Architecture E/E → plan de contrôle du véhicule → charges de travail / données / IA → architecture E/E de génération suivante

Nous l’appelons la boucle de coévolution architecture–OS.

Figure 4.1 — La boucle de coévolution architecture–OS. Note de lecture : la moitié supérieure de la boucle (E/E → OS) est la « limite du possible », formée des cinq catalyseurs du chapitre 3 ; la moitié inférieure (OS → E/E) est la « conception à rebours », formée des six classes d’exigences du tableau ci-dessus. Qu’un constructeur soit entré dans l’ère définie par le logiciel ne se juge pas à l’existence d’une marque d’OS, mais au fait que la moitié inférieure a commencé à tourner.

Soyons clairs : cette boucle n’est pas une échelle de maturité de plus. La série a déjà AR0–AR5 (seuils de capacité du système conçu) et AI²-ML (maturité de la chaîne d’outils). La boucle de coévolution décrit une structure causale, pas un grade.

4.2 Le spectre du « mutisme » : un désaccord sur la confiance

L’expression la plus visible de la moitié inférieure de la boucle est le degré auquel les contrôleurs zonaux sont « rendus muets » — la logique de contrôle critique reste-t-elle dans les zones ou passe-t-elle au centre ?

À une extrémité, GM. Ses « agrégateurs » zonaux « n’exécutent aucune logique de contrôle » ; toute l’intelligence — fusion de capteurs, arbitrage du contrôle, inférence d’apprentissage automatique — réside dans le calculateur central [T1]. C’est la voie du mutisme intégral.

À l’autre extrémité, BMW. La Neue Klasse place la dynamique de conduite sur un calculateur haute performance dédié appelé « Heart of Joy », dix fois plus rapide qu’un calculateur conventionnel [T2] ; infodivertissement, conduite automatisée et fonctions de base ont chacun leur superbrain. C’est la voie « le contrôle critique reste hors du centre ».

Plus loin encore se trouve l’architecture conventionnelle, avec une logique de contrôle répartie sur de nombreux calculateurs.

Figure 4.2 — Le spectre du mutisme des contrôleurs zonaux. De gauche à droite : calculateurs distribués → style BMW « contrôle critique sur calcul indépendant » → style GM « les agrégateurs ne font que relayer ; toute l’intelligence au centre ». Note de lecture : l’axe x ne mesure pas « à quel point c’est avancé », mais « quelle confiance est accordée au plan de contrôle central pour porter la chaîne d’exécution ASIL D ».

[inférence] Le désaccord ressemble à un débat sur la topologie matérielle ; sur le fond, c’est une question de confiance : le déterminisme du plan de contrôle central est-il déjà assez bon pour qu’on lui confie la chaîne d’exécution ASIL D ? La réponse de GM est « oui », celle de BMW « pas entièrement ». Il n’y a pas de réponse standard, mais le sens de la causalité est clair — c’est un jugement sur la capacité de l’OS qui décide de la topologie E/E.

4.3 Un indicateur observable : la granularité de l’OTA

La couverture d’un plan de contrôle est difficile à observer de l’extérieur — les constructeurs ne publient pas leurs catalogues d’API véhicule. Mais une chose est observable : les domaines que l’OTA peut mettre à jour.

Le nouveau Toyota RAV4 en est un exemple net : avec Arene, le cockpit et l’ADAS peuvent être mis à jour à distance, mais pas encore les fonctions de carrosserie et de dynamique [T2]. [inférence] Cela indique que le contrat d’Arene ne couvre pas encore le domaine du contrôle du véhicule. À l’inverse, un constructeur capable de mettre à jour à distance la calibration des freins ou du groupe motopropulseur a placé la chaîne d’exécution critique pour la sécurité sous gestion du cycle de vie.

Nous utilisons donc la granularité de l’OTA comme indicateur externe de la « couverture contractuelle du plan de contrôle », et l’employons dans la dimension V5 de la VOCM (chapitre 5). Elle n’est pas parfaite — être compatible OTA n’est pas la même chose qu’être bien architecturé —, mais c’est l’un des rares indicateurs vérifiables à partir d’informations publiques.

4.4 L’autre visage de la loi de Conway : E/E et OS livrés par une seule organisation

D3 a examiné la fusion par Tesla de ses équipes FSD et Optimus, où la structure organisationnelle façonne l’architecture technique. Sur la relation E/E–OS, il existe une preuve publique plus récente et plus directe.

Dans sa déclaration de procuration 2026, Rivian définit RV Tech, sa coentreprise avec le groupe Volkswagen, comme une « electrical architecture technology company with a focus on software, electronic control units and related network architecture » [T1]. Autrement dit, topologie E/E, calculateurs et logiciel forment un seul livrable dans cette entreprise.

Les chiffres de l’exercice 2025 de Rivian montrent le poids économique de ce livrable : la marge brute logiciels et services est passée de 7 millions USD en 2024 à 576 millions USD, principalement grâce aux « vehicle electrical architecture and software development services » liés à la coentreprise [T1].

[inférence] La portée de ces chiffres ne tient pas au montant mais à l’unité de prix : « E/E + OS » peut désormais être évalué et échangé comme un tout. Dès qu’une architecture peut être vendue seule, elle n’est plus un accessoire de la voiture mais un actif. La boucle de coévolution trouve ici une contrepartie au bilan.

Le groupe Volkswagen va plus loin encore : il exploite simultanément deux architectures E/E livrées par des organisations différentes — RV Tech dans l’hémisphère occidental et CEA en Chine. La section 5.5 y revient.

4.5 La rétrocompatibilité : le prix de la boucle et l’épreuve du contrat

La boucle de coévolution a un effet secondaire souvent négligé : pendant que l’E/E suivante est redessinée par les besoins du logiciel, la génération précédente de voitures est toujours sur la route. Ces voitures peuvent-elles continuer à recevoir de nouveaux logiciels ? Cela mène à une question plus stricte que « sait-il faire de l’OTA ? » :

Un OS véhicule peut-il être rétrocompatible — permettre aux voitures de la génération matérielle précédente, voire de l’avant-dernière, de continuer à acquérir à distance les capacités logicielles de la nouvelle génération ?

Notre réponse : la rétrocompatibilité est le test externe le plus strict du caractère réel du découplage matériel–logiciel ; mais elle doit se juger à la stabilité du contrat, non à l’égalité des fonctions. Il y a quatre raisons.

Premièrement, c’est la seule forme de découplage vérifiable de l’extérieur. Tout constructeur dit avoir découplé matériel et logiciel. Mais si le nouveau logiciel ne tourne que sur du matériel neuf, le « découplage » revient en réalité à « réintégrer à chaque génération ». Le découplage n’est prouvé que lorsque le logiciel de nouvelle génération peut être déployé sur du matériel ancien via le même contrat.

Deuxièmement, le parc en circulation est le dénominateur de l’économie logicielle. Abonnements logiciels, fonctions payantes et boucle de données croissent avec le nombre de véhicules capables de recevoir des mises à jour. Coupez les anciennes voitures à chaque génération et le dénominateur des revenus logiciels retombe périodiquement à zéro.

Troisièmement, la réglementation a déjà inscrit la compatibilité dans le processus de mise à jour. Le paragraphe 7.1.1 du règlement ONU R156 exige que le système de gestion des mises à jour logicielles d’un constructeur comprenne une série de processus, dont : identifier les véhicules cibles d’une mise à jour (7.1.1.6), confirmer avant diffusion la compatibilité d’une mise à jour avec la configuration des véhicules cibles (7.1.1.7), identifier les interdépendances du système mis à jour avec d’autres systèmes (7.1.1.5) et tenir à jour l’identification logicielle RXSWIN avant et après une mise à jour (7.1.1.3) [T1]. La rétrocompatibilité n’est pas seulement une question d’expérience utilisateur ; c’est un point auquel le système de gestion des mises à jour doit répondre.

Quatrièmement, elle met au jour la tension de la boucle. Si l’E/E suivante doit conserver le même contrat pour les voitures plus anciennes, le contrat verrouille la trajectoire d’évolution de l’E/E — précisément là où la valeur et le coût d’un plan de contrôle apparaissent ensemble. Abandonner le contrat, c’est renoncer au parc en circulation ; le conserver, c’est faire porter d’anciennes interfaces à la nouvelle architecture.

Mais la rétrocompatibilité ne peut pas signifier la parité fonctionnelle. Puissance de calcul, jeux de capteurs et redondance sont des faits physiques que l’OTA ne peut pas changer. D3 a déjà analysé la rupture générationnelle entre le HW3 de Tesla et les versions récentes de FSD : lorsque l’écart matériel est trop grand, même l’acteur logiciel le plus agressif ne peut faire exécuter toutes les nouvelles capacités à du matériel ancien.

Une meilleure façon de juger emprunte à l’industrie du smartphone — la stabilité du contrat avec des capacités échelonnées :

Le Tech Day de Leapmotor a offert un exemple public de niveau 3 : son aide à la conduite LWM fondée sur un modèle du monde réduirait de 90 % le volume de code, peut être déployée sur des paliers de calcul de 200, 640 et 1 280 TOPS, et s’accompagne d’un engagement de mises à niveau gratuites et d’usage gratuit à vie pour tous les véhicules équipés de LiDAR — environ 350 000 voitures en circulation selon la presse [T3, déclaration de l’entreprise]. [inférence] « Un modèle, plusieurs paliers de calcul » est en soi une conception pour la rétrocompatibilité — elle transforme les différences de capacité de « avoir ou ne pas avoir » en « plus ou moins ».

Nous intégrons donc la rétrocompatibilité dans la grille de notation de la dimension V2 de la VOCM (découplage matériel–logiciel ; annexe B) : V2 ne peut atteindre 4 ou plus que lorsqu’il est démontré que les capacités logicielles peuvent être livrées d’une génération matérielle à l’autre. Ce n’est pas une septième dimension, car il s’agit au fond d’un test du découplage et non d’une capacité indépendante.

4.6 Synthèse : pour savoir si un constructeur a un OS véhicule, regardez la moitié inférieure

La conclusion de ce chapitre vaut test pratique :

Ne demandez pas si un constructeur « a un OS véhicule ». Demandez si sa moitié inférieure a commencé à tourner — sa prochaine spécification E/E est-elle définie par les besoins du logiciel de la génération actuelle ?

Si oui, il est entré dans l’ère définie par le logiciel. Sinon, quel que soit le nom de sa marque d’OS, il en est encore au stade « défini par le matériel, rempli de logiciel ».

Il y a une seconde question : la génération précédente de voitures est-elle toujours sous le même contrat ? Plus la moitié inférieure tourne vite, plus cette question devient aiguë.

---

5. La table en 2026 : qui fait quoi, et jusqu’où

5.1 Ne pas demander « est-ce mûr ? », mais « quelle couche est mûre ? »

« L’OS véhicule est-il mûr ? » n’a pas de réponse, car les couches sont à une époque d’écart.

Le jugement d’ensemble :

2026 est l’année où l’OS véhicule est passé de l’« ambition architecturale » à la « réalité de série précoce ». Ce n’est plus une diapositive, mais on est loin d’un paradigme industriel stable comme Android / iOS.

Selon leur statut de production, les principaux acteurs se répartissent en quatre paliers. Il s’agit d’un classement descriptif, pas d’une nouvelle échelle de maturité :

• M1 Infrastructure à grande échelle (centaines de millions / millions de véhicules) : QNX, Classic AUTOSAR, le cockpit HarmonyOS, Android Automotive.
• M2 Plan de contrôle pleine domaine de l’OEM en production : MB.OS (CLA), SkyOS (plateforme NT3), HaloOS, BMW Neue Klasse, Tesla.
• M3 Premier lancement ou production sur une partie des domaines : Toyota Arene (RAV4 ; carrosserie et dynamique pas encore actualisables par OTA) [T2] ; Hyundai Pleos Connect (lancement au T2 2026, infodivertissement seulement) [T2–T3] ; la plateforme de deuxième génération de Rivian.
• M4 Sur la feuille de route ou en restructuration : la plateforme de calcul central de GM (2028, débutant sur le Cadillac Escalade IQ) [T1] ; Stellantis STLA Brain (initialement prévu pour une intégration fin 2024, désormais intégré pour la première fois avec la plateforme STLA One en 2027) [T1–T2] ; l’architecture RV Tech du groupe Volkswagen × Rivian (essais hivernaux achevés au T1 2026, débutant avec l’ID.EVERY1 en 2027) [T1] ; Hyundai Pleos Vehicle OS et son architecture zonale centralisée (objectif 2030) [T3].

L’architecture chinoise du groupe Volkswagen, CEA, a déjà dépassé ce palier : entrée en production dans l’Anhui fin 2025, lancée avec l’ID. UNYX 07 en janvier 2026, avec prise en charge de l’OTA du véhicule entier selon l’entreprise [T1] — un cas M3.

Un schéma récurrent mérite d’être relevé : presque tous les constructeurs du palier M4 sont en retard sur leur propre calendrier initial. La filiale logicielle du groupe Volkswagen, CARIAD, en est l’exemple le plus observé : la plateforme logicielle unifiée qu’elle devait livrer a glissé à plusieurs reprises, l’entreprise a connu une restructuration majeure et des suppressions de postes à partir de 2025 [T3], et l’architecture occidentale de nouvelle génération est désormais livrée par RV Tech. [inférence] La cause du retard est rarement le noyau ou la puce ; c’est le plus souvent l’organisation — transformer des dizaines de silos fonctionnels en une organisation de plateforme est bien plus difficile que d’écrire un hyperviseur. Le chapitre 9 y revient.

5.2 Par rôle, non par marque : neuf types d’acteurs

À la table de l’OS véhicule siègent des acteurs aux rôles entièrement différents. Un classement par marque les mélange ; une classification par rôle architectural montre qui est réellement en concurrence avec qui.

5.3 VOCM : noter le plan de contrôle du véhicule sur six dimensions

Pour mesurer les acteurs des rôles ① à ④ avec une même règle, nous proposons la matrice de capacités de l’OS véhicule (Vehicle OS Capability Matrix, VOCM). Elle déplie le « contrat + orchestration + cycle de vie » de la section 2.3 en six dimensions, chacune notée de 0 à 5, pour un maximum de 30. La grille figure à l’annexe B.

Comment la VOCM s’articule avec les cadres existants de la série — il faut le dire clairement pour éviter les doubles comptages :

• AR0–AR5 mesure les seuils de capacité architecturale du système conçu (le véhicule), principalement la topologie matérielle et l’intégration système ; la VOCM ne mesure que le plan de contrôle logiciel. Les deux sont orthogonales : un constructeur peut être haut en AR et bas en VOCM, ou l’inverse — et c’est précisément dans cet écart que réside la valeur analytique.
• AI²-ML mesure la maturité des chaînes d’outils d’architecture — un objet tout à fait différent. Les V2 et V5 de la VOCM ressemblent de nom aux D2 (découplage HW/SW) et D3 (OTA) d’AI²-ML, mais les premières regardent le logiciel dans la voiture, les secondes les outils qui servent à concevoir la voiture.
• La VOCM n’est pas une échelle de maturité et ne définit pas de « niveaux VOCM ». C’est un profil de capacités à six dimensions.

5.4 Première évaluation

Le tableau ci-dessous donne la première évaluation VOCM, mise en regard des scores AR instantanés de D2 (Snapshot 2026.1.31, total des cinq dimensions sur 25, cités ici et non renotés).

Les scores reposent uniquement sur des sources publiques. La confiance H / M / L reflète la solidité des preuves : H = la plupart des dimensions directement étayées par des preuves de niveau 1–2 ; M = certaines dimensions reposent sur des déclarations d’entreprise ; L = la plupart des dimensions reposent sur des sources secondaires ou des inférences. Comme dans D2, pour les constructeurs dont l’architecture phare est en production mais dont le parc n’a pas encore largement basculé, le tableau note la dernière architecture de série et le signale.

Non notés (preuves insuffisantes à ce stade) : Ford, Lucid, Geely, GWM, SAIC, Stellantis, Renault, Kia.

Leapmotor ne fait pas partie des 22 OEM de D2 ; il a donc un score VOCM mais pas de score AR, et n’apparaît pas dans le nuage de points de la figure 5.1. Base de la notation :

• V1, V3 : architecture à intégration centrale depuis LEAP 3.0 ; intégration cockpit-conduite sur une seule puce dans LEAP 4.0 [T3].
• V2 : son modèle du monde peut être déployé sur trois paliers de calcul, avec livraison gratuite promise aux véhicules équipés de LiDAR déjà en circulation [T3, déclaration de l’entreprise].
• V6 : AgentOS véhicule–cloud [T3].
• Les autres dimensions reposent sur des informations secondaires ; la confiance est faible.

La note sera mise à jour quand LEAP 5.0 entrera en production en 2027.

Remarques :

• Mercedes est noté sur MB.OS tel que lancé initialement dans la CLA.
• Le groupe Volkswagen est noté sur son architecture chinoise CEA (ID. UNYX 07). Base publique : contrôle zonal avec calcul quasi central, environ 30 % de calculateurs en moins, prise en charge de l’OTA du véhicule entier, couverture de toutes les motorisations — électrique, hybride et thermique [T1] ; une nouvelle génération de CEA tous les deux ans (2.0 en 2027, couvrant les segments A à D), avec un calcul de conduite prévu à la fois sur la puce Turing de XPeng et sur une solution CARIZON (la coentreprise de Volkswagen avec Horizon Robotics) [T3]. CEA a été codéveloppée avec XPeng et en hérite la lignée architecturale ; là où les informations publiques sur V1, V3, V4 et V5 sont minces, les notes se réfèrent donc à celles de XPeng [inférence] — l’exception de même lignée à la règle « au plus 2 sans preuves » de l’annexe B. V6 se situe un point en dessous de XPeng : le calcul de conduite provient de deux fournisseurs, et les sources publiques ne montrent pas sur CEA l’ordonnancement conjoint bout-en-bout / VLA avec l’OS propre à XPeng.
• L’architecture RV Tech n’est pas encore en production (2027) et n’est pas notée à ce stade ; elle sera mise à jour après son lancement. L’entreprise affirme que « powerful modular central computers control all vehicle functions » [T1]. Si cela se confirme en série, son V1 atteindrait directement 4–5.

Figure 5.1 — Architecture E/E × capacité de l’OS véhicule. Axe x : total AR instantané de D2 (/25) ; axe y : total VOCM (/30). Un point par constructeur ; les points creux indiquent une faible confiance. La ligne en tirets est la diagonale de parité (même part du maximum de chaque échelle) ; la bande ombrée est la droite de tendance de l’échantillon ±2,5 points (ajustée sans VW CEA). Note de lecture : les constructeurs situés dans la bande de tendance font évoluer plan de contrôle et E/E au même rythme ; les points nettement éloignés de la bande sont ceux qu’il faut interroger.

5.5 Lire le graphique : quatre constats

Constat 1 : AR et VOCM évoluent de concert, mais le plan de contrôle a un demi-pas de retard. Hors VW CEA, les 13 points de la figure 5.1 forment presque une droite : la pente ajustée est d’environ 1,2 — exactement le rapport des maximums des deux échelles (30/25) — et chaque point se situe à moins de 3 points de la tendance. C’est en soi une preuve de T2 — là où en est l’E/E, en est à peu près le plan de contrôle. Mais la droite de tendance se situe dans son ensemble environ 3 points sous la diagonale de parité : ramenés au maximum de chaque échelle, les plans de contrôle du secteur accusent en général un retard d’environ un dixième sur son E/E. [inférence] Cela concorde avec la boucle de coévolution : sa moitié supérieure (l’E/E fixant la frontière du possible) tourne depuis des années, tandis que sa moitié inférieure (le logiciel qui reconçoit l’E/E en retour) vient tout juste de s’enclencher. Parmi les constructeurs dont le score AR est inférieur à 15, seul VW CEA a une VOCM supérieure à 15 ; le constat 4 explique pourquoi.

Sous la bande de tendance se trouvent les constructeurs dont « l’E/E devance le plan de contrôle » : Toyota le plus nettement, Rivian se situant au bord inférieur de la bande. [inférence] Pour Toyota, cela signifie que l’architecture matérielle a pris les devants tandis que les contrats d’Arene n’ont pas encore rattrapé — ce qui concorde avec l’observation sur la granularité de l’OTA en 4.3. Rivian est un cas différent : son E/E figure parmi les plus audacieuses de l’échantillon, mais la divulgation publique de sa pile logicielle est la plus mince ; son score plus bas traduit davantage un manque de preuves (faible confiance) qu’un manque de capacité.

Constat 2 : les nouveaux entrants chinois obtiennent de bons scores en V4 et V2. L’ouverture de HaloOS par Li Auto, l’écosystème multimarque de Huawei et l’écosystème « humain–voiture–maison » de Xiaomi font tous de l’ouverture une stratégie. [inférence] Cela correspond à l’environnement chinois, où les normes précèdent et où la chaîne d’approvisionnement se construit collectivement — quand les interfaces sont normalisées, le coût de leur ouverture baisse et son bénéfice augmente.

Constat 3 : au sein d’un même palier AR, Mercedes a le meilleur score de plan de contrôle. Mercedes et BYD sont tous deux AR2.5 (17 points) dans D2, mais la première VOCM de MB.OS (20) dépasse de 3 points celle de BYD (17), sur le bord supérieur de la bande de tendance. Il faut le lire avec prudence : l’AR instantané de D2 note le groupe dans son ensemble, tandis que MB.OS a d’abord atterri sur un seul modèle, la CLA. [inférence] L’explication la plus probable est que Mercedes construit d’abord le plan de contrôle sur un modèle phare et laisse l’E/E rattraper sur les modèles suivants — c’est exactement ce à quoi ressemble le début de rotation de la moitié inférieure de la boucle de coévolution. Si c’est juste, ses modèles de prochaine génération afficheront un AR nettement plus élevé ; sinon, la couverture contractuelle de MB.OS a été surestimée (les actionneurs critiques pour la sécurité réellement placés sous MB.OS n’ont pas été publiquement divulgués).

Constat 4 : le groupe Volkswagen a répondu à la question de l’OS véhicule par « un constructeur, deux architectures, deux partenaires extérieurs ». C’est le point le plus singulier de l’échantillon, qui mérite une discussion à part.

• CEA en Chine : codéveloppée par Volkswagen Group China Technology Company, CARIAD China et XPeng, en seulement 18 mois du concept à la production — le calendrier le plus rapide jamais atteint par le groupe Volkswagen pour une architecture électronique entièrement nouvelle, selon l’entreprise ; les coûts de développement de nouveaux modèles baissent jusqu’à 50 % sur certains projets clés [T1, déclaration de l’entreprise].
• RV Tech à l’Ouest : une coentreprise avec Rivian, forte de plus de 1 500 salariés aux États-Unis, au Canada, en Suède, en Serbie et à Berlin [T1].

Les deux voies ont un point commun : aucun des nouveaux plans de contrôle du groupe Volkswagen n’a été livré par sa seule filiale logicielle ; tous deux ont été coconstruits avec un nouvel entrant déjà en avance sur le plan de contrôle.

[inférence] La portée dépasse Volkswagen. Elle montre qu’un plan de contrôle de véhicule peut désormais être « importé » d’une entreprise à l’autre — non pas en achetant un noyau ou un middleware, mais en faisant entrer une topologie E/E, une pile logicielle et une méthode de développement complètes. Les 18 mois de CEA mesurent la vitesse à laquelle la moitié inférieure de la boucle peut être « empruntée » et mise en rotation. Le coût est tout aussi clair : un groupe doit entretenir deux architectures, deux partenaires et deux corpus logiciels face à des régimes d’interfaces différents (normes nationales chinoises et écosystème de normes occidental). Ramenée au maximum de chaque échelle, la première VOCM de CEA (20/30) est nettement supérieure à l’AR instantané du groupe (13/25), ce qui en fait le seul point de la figure 5.1 situé loin au-dessus de la bande de tendance. C’est en partie une question de périmètre — comme pour Mercedes, l’AR note le groupe dans son ensemble tandis que la VOCM note l’architecture la plus récente ; [inférence] mais la raison principale est que le plan de contrôle a été importé d’un bloc avec une architecture de même lignée, arrivant ainsi avant l’E/E du groupe dans son ensemble. CEA n’est qu’une nouvelle architecture pour la Chine, et l’écart entre elle et les plateformes installées du groupe en Europe est ce qu’il importe le plus de suivre. Une fois RV Tech en production, le groupe Volkswagen sera le seul constructeur historique de l’échantillon à disposer d’un plan de contrôle zonal + calcul central distinct sur chacun de deux marchés. Forme transitoire ou future norme des constructeurs multinationaux ? C’est la question de la section 7.6.

---

6. Le test de résistance : le cockpit teste si un OS sait faire tourner des applications ; l’autonomie teste s’il sait faire rouler la voiture

6.1 La conduite autonome n’est pas un OS

Cela semble redondant, et pourtant l’industrie confond souvent les deux — appelant « OS » la pile logicielle de conduite d’une entreprise.

T4 | La conduite autonome n’est pas l’OS véhicule. C’est la charge de travail la plus exigeante qui tourne sur le plan de contrôle — et le meilleur test de résistance pour savoir si un « OS véhicule » mérite son nom.

En une phrase :

Le cockpit teste si un OS sait faire tourner des applications ; la conduite autonome teste si un OS véhicule sait faire rouler le véhicule.

6.2 L’échelle des conséquences d’une défaillance

Pourquoi la conduite autonome est-elle le test de résistance ? Parce qu’elle élève le coût d’une défaillance par paliers, jusqu’à ce qu’aucun humain ne reste pour la rattraper.

Figure 6.1 — L’autonomie comme test de résistance d’un OS véhicule. Note de lecture : de gauche à droite, le coût d’une défaillance passe de « désagrément » à « repli au niveau du véhicule », et l’exigence envers le plan de contrôle passe de « savoir redémarrer » à « prouver qu’il fonctionne encore en sécurité en cas de défaillance partielle ». La marche entre L3 et L4 est la plus haute — c’est là que l’humain quitte la chaîne de repli.

C’est la ligne de partage des eaux qu’analysait DD-08, Le conducteur s’efface : dès que le conducteur s’efface, matériel redondant, argumentaire de sécurité, surveillance à l’exécution et validation des OTA ne sont plus des options, mais la capacité même du système. Cet article ajoute une perspective à DD-08 : toutes ces exigences retombent finalement sur le plan de contrôle. Des unités de calcul redondantes ont besoin d’une couche d’orchestration capable de basculer de l’une à l’autre ; l’OTA a besoin d’un système de cycle de vie capable de prouver que « cette mise à jour ne casse pas l’argumentaire de sécurité » ; la surveillance à l’exécution a besoin d’une base déterministe capable d’isoler la charge d’IA, de l’observer et, si nécessaire, d’en reprendre le contrôle.

[inférence] Donc un « OS véhicule » qui n’a jamais porté de responsabilité de niveau L3 ou supérieur n’a pas encore vu son caractère « véhicule » éprouvé. Il peut exceller sur le cockpit, la carrosserie et l’énergie, mais ce n’est que lorsque la chaîne d’exécution critique pour la sécurité est intégrée au même plan de contrôle et soumise au test du fail-operational que le mot « véhicule » s’applique vraiment.

6.3 La nouvelle tâche de l’OS : de « gérer les ressources » à « prouver l’isolation »

La tâche centrale d’un système d’exploitation traditionnel est de gérer les ressources : allouer le CPU, la mémoire et les E/S. Sur une plateforme de calcul automobile à criticité mixte, cette tâche change de nature — l’OS doit prouver que des charges de criticités différentes n’interfèrent pas entre elles.

En 2026, c’est déjà une réalité de série :

• Qualcomm qualifie Snapdragon Ride Flex de « the industry’s first commercialized mixed-criticality platform », faisant tourner des charges QM, ASIL B et ASIL D sur un seul SoC, en production dans huit programmes mondiaux [T2, déclaration de l’entreprise].
• NVIDIA Halos OS utilise un hyperviseur pour isoler les fonctions critiques pour la sécurité des charges d’IA et fournit CUDA et TensorRT certifiés pour la sécurité [T2].

Sur le plan technique, « prouver l’isolation » signifie un partitionnement spatial, temporel et de la bande passante mémoire dans l’hyperviseur, ainsi que des argumentaires formels ou de niveau certification pour ces partitions. L’usage par NIO du micronoyau seL4, formellement vérifié, pour son noyau de contrôle du véhicule [T3] est une tentative de pousser la « preuve » jusqu’aux mathématiques.

6.4 Ce que les modèles de bout en bout exigent de l’OS

La diffusion des modèles de conduite de bout en bout et des modèles VLA (vision–langage–action) soumet le plan de contrôle à trois nouvelles pressions :

1. Contention de bande passante mémoire : l’inférence de grands modèles consomme beaucoup de bande passante DDR et peut étouffer les tâches temps réel sur la même puce.
2. Gigue de latence : l’incertitude du temps d’inférence GPU entre par nature en conflit avec le déterminisme des boucles de contrôle.
3. Préemption des accélérateurs : quand le modèle de conduite et le grand modèle du cockpit partagent les accélérateurs, qui a la priorité ?

Le Halos SDK de NVIDIA met explicitement en avant « deterministic scheduling, zero-copy inter-process communication » [T2] — signe que ces problèmes sont passés du statut de sujets de recherche à celui d’exigences produit.

6.5 Intégration cockpit-conduite : l’isolation passe d’option à précondition

Lorsque les fonctions cockpit et conduite sont placées sur la même puce ou le même calculateur central, elles entrent dans le même domaine de défaillance matérielle. Dans une architecture distribuée, un plantage du cockpit ne peut pas affecter le freinage, car les deux sont physiquement séparés ; dans une architecture intégrée, cette « isolation naturelle » disparaît et doit être reconstruite en logiciel par le plan de contrôle.

[inférence] L’intégration cockpit-conduite fait passer l’isolation d’une « optimisation facultative » à une « précondition de sécurité ». C’est pourquoi la consolidation à criticité mixte (V3) constitue une dimension à part entière de la VOCM.

6.6 Robotaxis : la structure à deux canaux

Dans les flottes L4 sans conducteur, [inférence : la divulgation publique par Waymo, Baidu Apollo, Pony.ai, WeRide et d’autres de la mise en œuvre de leurs piles logicielles est limitée] une structure courante est « pile IA principale + surveillance de sécurité et calcul redondant indépendants » — la pile principale conduit, tandis qu’un second canal la supervise en continu et, en cas d’anomalie, amène le véhicule à un état à risque minimal. Cette structure à deux canaux est le contrat fail-operational exprimé en logiciel, et la forme la plus extrême de la mission d’orchestration du plan de contrôle.

---

7. Les plateformes horizontales à la porte : Google, les fondeurs et la lutte pour les interfaces

7.1 Un nouveau champ de bataille

À l’ère du smartphone, Apple et Google ont avalé le système d’exploitation et les fabricants de combinés se sont repliés sur le matériel et la marque. Depuis dix ans, le consensus de l’industrie automobile est : les constructeurs ne laisseront jamais cela se reproduire dans la voiture.

En 2026, ce consensus fait face à son premier défi sérieux.

T6 | Ce que l’industrie standardise réellement n’est pas « un OS automobile » mais l’API véhicule, le modèle de données et le contrat d’exécution. Les noyaux se banalisent, et le point de contrôle C3 (OS) est pris en tenaille entre C2 (le silicium) et C4 (le middleware).

7.2 Google : Android sort du cockpit

Le 24 mars 2026, Google a publié sur l’Android Developers Blog l’extension SDV d’Android Automotive OS (AAOS SDV) sous un titre sans détour : Beyond Infotainment [T2]. Les faits vérifiés :

• Forme : une « lightweight, fast-booting headless Android foundation (SDV Core, similar to Microdroid) », s’exécutant comme machine virtuelle sur un hyperviseur compatible VirtIO ; les interfaces de service sont définies dans le VSIDL de Google plus protobuf et se connectent aux calculateurs externes via SOME/IP, sockets VirtIO, Ethernet, etc. ; une SDV Gateway se trouve côté cockpit [T1 : source.android.com, documentation mise à jour le 24/09/2026, pour Android 17 et supérieur].
• Domaines couverts : Google cite « Core Compute, Body Controls, and Cluster domains », avec des exemples de fonctions tels qu’actionneurs de sièges, combiné d’instruments, climatisation, éclairage, caméras, rétroviseurs et télémétrie [T2]. Les documents officiels ne mentionnent ni le châssis ni l’ADAS.
• Frontière de sécurité : ni la documentation ni le blog ne formulent la moindre revendication ASIL. Le seul contenu lié à la sécurité est Display Safety (affichages du combiné tels que vitesse et témoins), plus une chaîne d’outils de conception de sécurité et un Safety Monitor de référence [T1–T2].
• Adoptants : Qualcomm a annoncé au CES 2026 une pile AAOS SDV préintégrée sur Snapdragon Digital Chassis ; le premier programme de série est un véhicule utilitaire léger de Renault, dont la production doit démarrer fin 2026 [T2]. Google indique qu’AAOS SDV entrera dans AOSP en 2026.

[inférence] Ces faits tracent une ligne de partage nette : la plateforme horizontale a franchi le cockpit pour entrer dans les domaines du confort carrosserie et du combiné, mais elle reste dans le territoire QM à ASIL faible et n’a pas encore touché aux chaînes d’exécution critiques pour la sécurité du châssis, du freinage, de la direction et de la conduite automatisée. Que cette ligne continue de descendre est l’un des signaux industriels les plus importants à suivre dans les cinq prochaines années (chapitre 10, déclencheur de révision 4).

7.3 Les fondeurs : C2 absorbe C3

Si Google presse du haut vers le bas, les fondeurs enveloppent du bas vers le haut.

• NVIDIA : DriveOS (certifié ASIL D) + Halos OS (hyperviseur isolant les charges d’IA des fonctions de sécurité) + Halos SDK (ordonnancement déterministe, IPC sans copie) [T2]. La plateforme de calcul central de GM pour 2028 repose sur NVIDIA Thor [T1].
• Qualcomm : la plateforme à criticité mixte Ride Flex + une pile AAOS SDV préintégrée [T2].

[inférence] Ce que livrent les fondeurs n’est plus une puce mais un ensemble « puce + hyperviseur + environnement d’exécution certifié pour la sécurité + partie du middleware ». Pour un constructeur, choisir une puce revient de plus en plus à choisir en même temps S1 et S2 — voire une partie de S3. Parmi les sept points de contrôle de D1, c’est C2 (SoC) qui absorbe C3 (OS).

7.4 Middleware et « fournisseurs de Vehicle OS » : C4 s’étend

Une autre force vient du middleware et des fournisseurs tiers de Vehicle OS.

• Applied Intuition fournit un Vehicle OS aux constructeurs. En mai 2026, Stellantis a annoncé une collaboration élargie avec elle sur STLA Brain [T1] ; l’entreprise affirme que 18 des 20 premiers constructeurs mondiaux utilisent ses solutions [T2, déclaration de l’entreprise].
• Eclipse S-CORE : en juin 2025, 11 entreprises ont signé le protocole d’accord de la VDA sur la collaboration open source dans le SDV (BMW, Continental, ETAS, HELLA, Mercedes-Benz, Qorix, Bosch, Valeo, Vector, Porsche, ZF) [T1] ; selon un communiqué de la VDA du 7 janvier 2026, les signataires sont passés à 32 [T1–T2]. S-CORE 0.5 est sorti en novembre 2025, la plateforme de référence ayant d’abord été démontrée sur du matériel QNX et Qualcomm [T2].

[inférence] Lorsqu’un constructeur européen utilise S-CORE en open source pour S2, QNX pour S1, l’hyperviseur du fondeur pour l’isolation, et achète un Vehicle OS tiers pour une partie de S4, que possède-t-il encore réellement ? La réponse : la sémantique du véhicule, la responsabilité de sécurité, et la capacité à intégrer, valider et faire tourner la boucle de données.

7.5 La lutte porte sur les interfaces, pas sur les noyaux

Réunissez les trois forces et un fait sous-estimé apparaît : ce pour quoi toutes les parties se battent vraiment — et ce qu’elles standardisent vraiment —, c’est la couche d’interface.

[inférence] Ensemble, ces efforts pointent vers une conclusion : ce qui se dirige vers la standardisation n’est pas « un OS automobile » mais « API véhicule + modèle de données + contrat d’exécution ». Cela correspond exactement à la première des trois parties du plan de contrôle de la section 2.3 — le contrat.

On en tire un corollaire sur la localisation de la valeur :

La couche contractuelle converge ; l’orchestration et le cycle de vie sont l’espace restant pour la différenciation des constructeurs.

7.6 Plateforme horizontale contre plan de contrôle de l’OEM : quelle fin de partie ?

L’industrie va-t-elle donc converger vers un OS véhicule horizontal, ou les constructeurs garderont-ils le plan de contrôle du véhicule ?

[inférence] Notre jugement : ce n’est pas l’un ou l’autre. L’infrastructure du bas (S1, S2 et normes de la couche contractuelle) continuera de converger ; la sémantique du véhicule, la responsabilité de la sécurité et la différenciation de marque (orchestration, cycle de vie, boucle de données) continueront de diverger. C’est la deuxième réapparition, au niveau logiciel, du modèle à deux couches convergence–divergence de D1.

Quatre types de constructeurs atteindront quatre fins de partie différentes :

1. Les intégrateurs verticaux (Tesla, Huawei, NIO) : possèdent C2, C3 et C4 ensemble ; le plan de contrôle leur appartient entièrement. Ils sont le contre-exemple le plus fort à T6 — pour eux, l’OS n’est pas quelque chose qui se banalise, mais une partie de leurs douves.
2. Les plans de contrôle fédérés : plusieurs plans de contrôle construits par région, voire par partenaire, partageant marque, chaîne d’approvisionnement et une partie de la base, sans viser une pile logicielle mondiale unique. Le groupe Volkswagen en est aujourd’hui l’exemple le plus net : CEA coconstruite avec XPeng en Chine, RV Tech coconstruite avec Rivian à l’Ouest (voir le constat 4 en 5.5). Les avantages sont la vitesse et l’adaptation locale — 18 mois jusqu’à la production, alignement direct sur les normes nationales chinoises et l’écosystème de conduite local. Le risque est l’éclatement des économies d’échelle : deux architectures signifient deux régimes de validation, deux exploitations OTA, deux viviers de talents et des coûts d’intégration à long terme. [inférence] La fin de partie de l’OS véhicule n’est pas forcément « one kernel to rule them all » ; un plan de contrôle fédéré peut être le choix rationnel des multinationales face à des normes divergentes en Chine et en Occident — mais la capacité de la fédération à converger en un seul à la génération suivante décidera si cette voie finit en « transition » ou en « passif ».
3. Les consommateurs de plateforme : achètent des solutions tierces jusqu’en S4 (Applied Intuition, Google, offres groupées des fondeurs) et concentrent la différenciation sur la marque, le design et la distribution.
4. Les exportateurs de plan de contrôle : exportent leur propre plan de contrôle — avec la topologie E/E et la méthode de développement — comme produit à d’autres constructeurs. C’est la forme la plus récente, apparue en 2025–2026, et ses protagonistes sont presque tous chinois :
   • XPeng a coconstruit CEA avec Volkswagen (5.5) ;
   • lors de son Tech Day 2026, Leapmotor a indiqué que ses systèmes électroniques travaillent désormais avec cinq partenaires et qu’il fournit une technologie au niveau véhicule à FAW, Stellantis et d’autres [T3] ;
   • le cockpit HarmonyOS et Qiankun de Huawei couvrent 25 marques [T2].

[inférence] La quatrième forme modifie le tableau que dresse T6. Le point de contrôle C3 n’est pas seulement pris en tenaille, par le haut et par le bas, entre les fondeurs (C2) et le middleware / les plateformes horizontales (C4) ; il est aussi disputé latéralement par un autre type de constructeur. Pour l’importateur, faire entrer un plan de contrôle est bien plus rapide que d’en bâtir un : CEA est passée du concept à la production en 18 mois. Pour l’exportateur, le plan de contrôle devient une seconde courbe de revenus et un amplificateur d’échelle — le taux de communalité de plateforme de 90 % revendiqué par Leapmotor est précisément ce qui rend un plan de contrôle reproductible à l’export [T3, déclaration de l’entreprise]. Que Stellantis travaille à la fois avec Applied Intuition (Vehicle OS tiers) et Leapmotor (technologie au niveau véhicule) montre qu’un même constructeur peut être à la fois « consommateur de plateforme » et « importateur de plan de contrôle », selon les marchés et les modèles.

Aucune des quatre formes n’est supérieure ; chacune est un pari différent sur l’endroit où doit se trouver le point de contrôle.

---

8. Quand l’IA entre dans le système d’exploitation : le sablier et la gouvernance déterministe

8.1 Mettre un grand modèle dans la voiture, ce n’est pas faire entrer l’IA dans l’OS

La discussion la plus courante — et la plus superficielle — sur « l’IA et l’OS véhicule » porte sur le grand modèle qui siège dans la voiture : Gemini, GPT, DeepSeek, Pangu ou Grok. C’est l’IA en tant qu’application. Le vrai changement se produit plus en profondeur, et se déroule en trois stades.

Le stade B porte un corollaire facile à négliger mais lourd de conséquences : le modèle devient un artefact logiciel de première classe. Aujourd’hui, une mise à jour OTA livre « le paquet logiciel v3.7 » ; demain, elle livrera un ensemble « logiciel + modèle + politique + graphe d’agents + enveloppe de sécurité ». L’objet de la gestion du cycle de vie s’étend du code à des produits probabilistes.

L’industrie se dirige déjà vers le stade B :

• Le MBUX Virtual Assistant de Mercedes intègre l’IA de Microsoft et de Google et bâtit un agent IA automobile sur Gemini [T2].
• L’agent IA Gleo AI de Hyundai arrive avec Pleos Connect ; Hyundai présente ce virage comme un passage du SDV à l’« AIDV » (AI-defined vehicle, véhicule défini par l’IA) [T2].
• NIO qualifie SkyOS de « système d’exploitation véhicule pleine domaine pour l’IA » [T2].
• Lors de son Tech Day 2026, Leapmotor a lancé un « AgentOS véhicule–cloud » : les agents centraux dans le véhicule gèrent les tâches à faible latence et sensibles pour la vie privée ; les agents cloud gèrent le raisonnement complexe et la mémoire à long terme [T3]. [inférence] C’est une conception qui « répartit l’intelligence selon la confiance et la latence » — et elle se superpose nettement à l’anneau extérieur du plan de contrôle (cloud, OTA, boucle de données) : l’agent lui-même est divisé en une « partie déterministe dans la voiture » et une « partie étendue dans le cloud ».
• En octobre 2025, le comité chinois de l’écosystème du logiciel de base automobile (AUTOSEMO) a publié son Rapport 6.0 sur le développement du logiciel de base automobile en Chine, centré sur l’AIOS et proposant une architecture « abstraction du calcul — fusion des données — servitisation des fonctions » [T2].

8.2 L’OS va-t-il s’amincir ou s’épaissir ?

L’IA va-t-elle absorber le système d’exploitation ? Les deux points de vue ont du mérite.

Le camp de l’amincissement : interaction, orchestration applicative et logique fonctionnelle sont absorbées par les grands modèles et les agents. Les flux d’IHM, hiérarchies de menus et moteurs de règles qu’il fallait autrefois coder en dur sont remplacés par un modèle qui comprend l’intention. Les modèles de conduite de bout en bout ont aussi absorbé un middleware jadis découpé en modules distincts de perception, de prédiction et de planification. Vue ainsi, la moitié supérieure de l’OS s’amincit.

Le camp de l’épaississement : plus le modèle est incertain, plus il a besoin d’un squelette déterministe. Isolation des ressources, déterminisme temporel, surveillance de sécurité, chemins de repli démontrables et chaîne de preuves du cycle de vie de l’IA exigée par l’ISO/PAS 8800 doivent tous descendre dans la couche OS. NVIDIA fait d’« un hyperviseur qui isole les fonctions critiques pour la sécurité des charges d’IA » l’argument central de Halos OS [T2]. Vue ainsi, la moitié inférieure de l’OS s’épaissit.

Notre réponse : les deux se produisent en même temps.

T5 | L’IA n’éliminera pas l’OS véhicule ; elle le polarisera : la moitié supérieure (interaction, orchestration) s’amincit, la moitié inférieure (déterminisme, isolation, preuve) s’épaissit, et le contrat de service entre les deux devient l’étranglement du sablier. L’intelligence probabiliste doit s’exécuter au sein d’une gouvernance déterministe.

Figure 8.1 — Le sablier : comment l’IA remodèle l’OS véhicule. Le haut évasé : interaction, orchestration et logique fonctionnelle absorbées par les modèles. L’étranglement : le contrat de service du plan de contrôle. La base évasée : la couche déterministe qui s’épaissit (isolation, ordonnancement, surveillance de sécurité, repli, chaîne de preuves). Le côté droit montre l’évolution de l’artefact logiciel : « code » → « code + modèle + politique + graphe d’agents + enveloppe de sécurité ».

Cela concorde pleinement avec le jugement de D3 selon lequel « l’IA est une faculté de langage, pas un cerveau » : la faculté de langage monte dans le modèle ; le « tronc cérébral » de la sécurité — le squelette déterministe — reste dans l’OS. Les deux ne se contredisent pas ; ce sont deux faces d’une même chose.

8.3 Une prédiction réfutable

La « polarisation » prête facilement le flanc à la critique, comme une échappatoire selon laquelle « les deux camps ont raison ». Pour l’éviter, nous formulons une prédiction claire que les faits pourraient renverser :

[inférence] Avant 2030, il n’y aura aucune voiture particulière de série dans laquelle un grand modèle de langage ou un agent généraliste obtienne directement le contrôle d’actionneurs ASIL D. Les agents pourront suggérer, demander et appeler des services véhicule autorisés, mais le contrôle final des actionneurs critiques pour la sécurité, tels que le freinage et la direction, restera arbitré par le plan de contrôle déterministe.

Si cette prédiction est infirmée, T5 devra être révisée (chapitre 10, déclencheur de révision 3).

8.4 Normes et réglementation : les contraintes sur l’IA dans l’OS ont pris forme

Que l’IA entre dans l’OS véhicule ne dépend pas de la seule technologie. Le système de règles qui l’encadre a déjà pris forme :

• ISO 26262 (sécurité fonctionnelle) et ISO 21448 (SOTIF, sécurité de la fonction attendue) [T1].
• ISO/PAS 8800:2024 (Véhicules routiers — Sécurité et intelligence artificielle), publiée en décembre 2024, qui adapte des clauses pertinentes des parties 4, 6 et 8 de l’ISO 26262 [T1]. En août 2025, SGS-TÜV Saar a décerné à Geely la première certification de processus ISO/PAS 8800 au monde [T2].
• UN R155 / R156 (système de gestion de la cybersécurité / système de gestion des mises à jour logicielles), et les normes obligatoires chinoises correspondantes GB 44495 / 44496 / 44497, en vigueur depuis le 1er janvier 2026 [T1].

[inférence] L’effet combiné de ces normes : plus il y a d’IA, plus la gestion du cycle de vie s’alourdit. Chaque mise à jour de modèle peut exiger un argumentaire de sécurité actualisé ; chaque agent doté de droits d’action sur le véhicule a besoin d’un modèle de permissions auditable. Ces charges ne peuvent pas être portées par le modèle lui-même ; seul le plan de contrôle peut les porter.

Une question reste sans réponse : comment du code d’OS généré par l’IA entre-t-il dans un argumentaire de sécurité ISO 26262 ? D4 a déjà montré que, dans les chaînes d’outils d’architecture, la capacité de « génération par l’IA » s’est découplée de l’« autonomie de raisonnement ». Au niveau de l’OS véhicule, à la date d’arrêt des données de cet article, nous n’avons trouvé aucun cas public de série où du code généré par l’IA soit entré dans un argumentaire ASIL. C’est une lacune à surveiller.

---

9. Feuille de route 2026–2035 : du défini par le logiciel au défini par l’IA

9.1 Cinq stades

Le tableau distingue les états observés des hypothèses de recherche. Les trois premiers stades sont observés ; les deux derniers sont des hypothèses.

Remarque : le stade V partage son nom avec le niveau L8 « AI-Defined Vehicle » de la taxonomie à huit niveaux de l’évolution des EEA de cette série, mais les deux décrivent des objets différents : la taxonomie à huit niveaux décrit la forme de l’EEA du véhicule ; ce tableau décrit la forme du plan de contrôle logiciel. Les deux dimensions sont orthogonales et ne doivent pas être mélangées.

9.2 Ce qui sépare réellement les stades III, IV et V

Les trois derniers stades sont les plus faciles à confondre. En une phrase : le stade III transforme les fonctions en logiciel, le stade IV transforme le logiciel en ressources ordonnançables, et le stade V laisse les modèles participer à la décision de ce qui est ordonnancé.

L’évolution des centres de données offre une analogie toute prête :

• Le stade III ressemble à l’ère des machines virtuelles : les serveurs sont virtualisés, mais ce que chaque VM exécute et l’endroit où elle se trouve sont configurés à l’avance par les équipes d’exploitation.
• Le stade IV ressemble à l’ère Kubernetes : les charges de travail sont empaquetées en unités standard et placées dans un pool de ressources par un ordonnanceur selon des règles ; elles peuvent migrer, monter en charge et être remplacées.
• Le stade V ressemble à l’ère native IA : au-dessus de l’ordonnanceur se trouve une couche de modèles qui comprennent l’intention, si bien que le système peut composer à la volée des flux que personne n’a écrits à l’avance.

Chacune des six caractéristiques du stade IV a une forme concrète :

1. Placement dynamique des fonctions. Lorsque l’unité de calcul principale tombe en panne, l’orchestrateur migre les fonctions non critiques pour la sécurité vers une unité de secours ; ou bien la même fonction est déployée sur des nœuds différents selon la configuration du véhicule.
   • Une limite doit être soulignée : les fonctions ASIL D ne seront pas ordonnancées « dynamiquement » dans un avenir prévisible. Leurs chemins de migration sont des basculements de redondance conçus et certifiés à l’avance. Ce qui est véritablement dynamique concerne surtout les charges QM et d’ASIL faible.
2. Calcul partagé. Quand la voiture est stationnée, l’essentiel de la puissance de calcul de la puce de conduite reste inutilisé. Une plateforme de stade IV peut la prêter au grand modèle du cockpit, à l’analyse visuelle en mode sentinelle ou au prétraitement des données embarqué, puis la reprendre par ordre de priorité dès que la voiture roule. Le stade III ne le permet pas, car cockpit et conduite appartiennent à deux domaines dotés de deux piles logicielles.
3. Services interdomaines. Au stade III, un « mode camping » est une fonction développée sur mesure qui exige de modifier le code de la climatisation, de l’affichage, de la gestion de batterie et des serrures. Au stade IV, ce n’est qu’une composition de services existants. Les fonctions d’« orchestration de scènes » des constructeurs chinois vont déjà dans ce sens, même si la plupart restent au niveau du cockpit et n’ont pas pénétré profondément le contrôle du véhicule [inférence].
4. Parité de développement cloud–véhicule. Le même conteneur logiciel achève sa régression sur un véhicule virtuel dans le cloud avant d’être déployé sur un véhicule réel. La documentation AAOS SDV de Google indique explicitement que l’exécution dans une machine virtuelle « facilitates testing and integration in the cloud » [T1].
5. Consolidation à criticité mixte comme norme. Aujourd’hui, Ride Flex permet à des charges ASIL D et QM de partager une puce dans huit programmes de série [T2] — encore une « première vague » ; au stade IV, cela devient la configuration par défaut des nouvelles plateformes plutôt qu’un argument de vente.
6. Cycle de vie des modèles standardisé. Le versionnage, la validation et le retour arrière des modèles de conduite passent des outils propres à chaque entreprise au même pipeline que le logiciel, sous la contrainte de l’ISO/PAS 8800 et du R156. Le « un modèle déployé sur trois paliers de calcul » de Leapmotor [T3] est un exemple précoce de décisions de déploiement prises par palier matériel.

La frontière entre les stades IV et V tient à qui écrit les règles. Si habile que soit l’orchestrateur du stade IV, il exécute des règles écrites par des ingénieurs. Au stade V, modèles et agents commencent à prendre part à la décision. Comparez :

• Stade IV : l’utilisateur dit « active le mode camping », et le système exécute une composition de services préconstruite.
• Stade V : l’utilisateur dit « je passe la nuit en montagne et je dois rentrer en ville demain matin ». L’agent compare la charge restante à la distance du retour, calcule l’énergie que la climatisation peut consommer, fixe un plancher de réserve de batterie, baisse la luminosité des écrans et trouve des bornes de recharge sur l’itinéraire du lendemain. Aucun ingénieur n’a jamais écrit cette composition ; elle est générée à la volée dans les limites du modèle de permissions et de l’enveloppe de sécurité.

L’AgentOS de Leapmotor, le Gleo AI de Hyundai et l’agent de Mercedes basé sur Gemini en sont tous encore au stade « l’IA devient un service de l’OS » décrit au chapitre 8 : ils comprennent l’intention, mais l’éventail des services véhicule qu’ils peuvent appeler, et leurs permissions, restent limités.

Comment saurons-nous que l’industrie est entrée dans le stade IV ? Surveillez quatre signaux observables :

1. des voitures de série dont les fonctions migrent entre unités de calcul sans nouvelle version logicielle ;
2. le même conteneur logiciel, validé dans le cloud, déployé sur plusieurs paliers matériels ;
3. de nouvelles plateformes qui partagent par défaut un SoC entre charges ASIL D et QM ;
4. des mises à jour de modèles entrant dans un pipeline unifié et réglementé, avec retour arrière.

Les signaux du stade V sont des voitures de série dont les agents appellent des services véhicule via un modèle de permissions, et des compositions de fonctions qui n’ont pas été précodées mais générées à partir de l’intention de l’utilisateur.

[inférence] Les frontières entre les trois stades sont floues ; un même constructeur chevauche souvent deux stades. Le tableau décrit un déplacement du centre de gravité, pas une coupure nette.

9.3 La migration des points de contrôle

[inférence] D’ici 2030, les trois des sept points de contrôle de D1 qui nous concernent ici évolueront ainsi :

• C2 (SoC) : continue d’absorber vers le haut, en livrant la pile complète « puce + hyperviseur + environnement d’exécution certifié + partie du middleware ».
• C3 (OS) : noyaux et environnements d’exécution de base se banalisent ; la valeur indépendante se déplace vers l’orchestration et le cycle de vie du plan de contrôle.
• C4 (middleware) : l’open source (S-CORE, HaloOS) et les normes (VSS, normes nationales chinoises) accélèrent la convergence ; la couche contractuelle devient peu à peu un bien commun.

Figure 9.1 — C3 pris en tenaille : où migre la valeur de l’OS véhicule. Note de lecture : C3 est comprimé par des forces venues d’en haut et d’en bas ; ce qui reste propre au constructeur, ce sont l’orchestration, le cycle de vie et la boucle de données (C5).

9.4 La voie chinoise : développement maison, open source et normes nationales en parallèle

L’évolution de l’OS véhicule en Chine a une structure distinctive : développement maison, open source et normes nationales progressent en parallèle et se renforcent mutuellement.

• Développement maison : NIO SkyOS, le cockpit HarmonyOS et Qiankun de Huawei, XPeng, Xiaomi et d’autres construisent leurs propres piles logicielles [T2].
• Open source : Li Auto a publié HaloOS en open source sous Apache 2.0 (2025), transformant un travail maison en bien commun industriel [T2].
• Normes nationales : GB/T 47351 / 47341-2026 sont entrées en vigueur le 1er juillet 2026 ; les trois normes obligatoires GB 44495 / 44496 / 44497 sont entrées en vigueur le 1er janvier 2026, harmonisées avec UN R155 / R156 [T1].

[inférence] Une conséquence importante des normes nationales : elles deviennent une interface sur laquelle tout constructeur vendant en Chine — constructeurs étrangers compris — doit s’aligner. La présence de Mercedes-Benz Chine et de Volkswagen Chine parmi les organismes rédacteurs montre que les constructeurs étrangers l’ont compris. C’est peut-être aussi l’une des raisons structurelles pour lesquelles des « plans de contrôle fédérés » apparaissent dans le monde : un même constructeur peut devoir entretenir des piles logicielles faisant face à des régimes d’interfaces différents en Chine et ailleurs.

9.5 Économie et organisation : le véritable goulet d’étranglement

Sur le plan économique, un OS véhicule se rentabilise de quatre façons : baisse du coût de nomenclature des calculateurs et du câblage, réutilisation logicielle d’un modèle à l’autre, amortissement du coût de plateforme et revenus logiciels après la vente de la voiture. Le bond de la marge brute logiciels et services de Rivian, de 7 millions USD à 576 millions USD sur l’exercice 2025 [T1], montre que la valeur de « E/E + OS » en tant qu’actif peut déjà apparaître dans les états financiers.

Sur le plan organisationnel, son coût est souvent sous-estimé. La section 5.1 notait que presque tous les constructeurs du palier « feuille de route » (M4) ont pris du retard. [inférence] La cause est rarement technologique et le plus souvent organisationnelle :

• transformer des dizaines de départements organisés par fonction en une seule organisation de plateforme ;
• faire passer les contrats avec les fournisseurs de rang 1 d’unités « calculateur boîte noire » à des unités « module logiciel + responsabilité d’intégration » ;
• construire la plateforme de nouvelle génération tout en continuant de livrer les modèles actuels.

C’est la loi de Conway appliquée à l’OS véhicule : votre plan de contrôle ressemblera à votre organisation. Un constructeur encore divisé en départements « carrosserie, châssis, groupe motopropulseur et cockpit » aura du mal à bâtir un plan de contrôle qui enjambe les quatre domaines.

Pour résumer ce chapitre en une phrase :

La centralisation supprime la complexité locale en créant de la complexité systémique. Elle élimine la fragmentation entre 100 calculateurs, mais apporte un rayon d’impact plus large, une surface d’attaque plus concentrée, une validation plus complexe — et une organisation qui doit se réorganiser elle-même avant de pouvoir réorganiser la voiture.

---

10. Le couteau sous notre propre gorge : contre-arguments et déclencheurs de révision

10.1 Sept contre-arguments

Contre-argument 1 : l’OS véhicule n’est qu’un concept marketing. Retirez la couche de marque et il ne reste que QNX + Linux + AUTOSAR + un hyperviseur. Réponse : c’est exactement le point de départ de T1. Nous ne prétendons pas que l’OS véhicule soit un nouveau noyau ; nous affirmons qu’il est le plan de contrôle qui gouverne plusieurs noyaux. La marque est effectivement surestimée, mais ses trois parties — contrat, orchestration et cycle de vie — sont réelles, observables et évaluables.

Contre-argument 2 : le calcul central pourrait ne pas être rentable. Le surcoût de la virtualisation, de la redondance et du refroidissement liquide pourrait annuler les économies réalisées grâce à la réduction du nombre de calculateurs. Réponse : nous ne tirons pas de conclusion ici. L’économie dépend des volumes de véhicules et des revenus logiciels, et les données publiques ne suffisent pas pour juger. Nous notons seulement que « la centralisation échange de la complexité locale contre de la complexité systémique » — que l’échange soit rentable dépend du constructeur.

Contre-argument 3 : un OS véhicule accroît en réalité le risque systémique. Réponse : d’accord. C’est précisément l’argument du chapitre 6 : la centralisation fait de l’isolation, propriété naturelle, une propriété qu’il faut prouver. La maîtrise du risque dépend de la qualité de V3 (criticité mixte).

Contre-argument 4 : des API standardisées effaceront la différenciation des constructeurs. Réponse : la différenciation au niveau de la couche contractuelle va effectivement se réduire (T6), mais l’orchestration, le cycle de vie et la boucle de données restent des espaces de différenciation. La différenciation ne disparaîtra pas ; elle migrera.

Contre-argument 5 : les agents IA ne devraient jamais entrer dans le chemin de contrôle critique pour la sécurité. Réponse : notre position est plus précise : les agents peuvent entrer dans le plan de contrôle, mais uniquement sous gouvernance déterministe ; le contrôle final des actionneurs ASIL D ne leur sera pas confié dans un avenir prévisible (la prédiction de 8.3).

Contre-argument 6 : la régionalisation des piles logicielles empêchera l’émergence d’un OS véhicule mondial. Réponse : d’accord — et ce n’est peut-être pas un problème, mais la fin de partie. Le « plan de contrôle fédéré » discuté en 7.6 développe précisément ce jugement.

Contre-argument 7 : la L4 aura finalement besoin de son propre OS, et non d’une partie de l’OS véhicule. Réponse : c’est une question ouverte. La structure à deux canaux (6.6) peut signifier que le canal de surveillance de sécurité L4 est logiquement indépendant du plan de contrôle du véhicule. Si les flottes L4 adoptent largement des piles logicielles entièrement séparées de l’OS véhicule des voitures particulières, T4 devra être reformulée en « la conduite autonome teste le contrat entre l’OS véhicule et le canal de sécurité ».

10.2 Cinq déclencheurs de révision

Si l’un des événements suivants se produit, la thèse correspondante doit être révisée :

---

11. Conclusion : trois jugements et un avertissement

Retour au titre. « Un système de systèmes d’exploitation » n’est pas une figure de style — c’est la description la plus exacte de cette couche présente dans chaque voiture définie par le logiciel. On l’a affublée de tant de noms d’« OS » que personne ne s’est arrêté pour demander ce qu’elle est réellement.

Notre réponse : c’est un plan de contrôle fait de contrat, d’orchestration et de cycle de vie, qui gouverne un ensemble de systèmes d’exploitation — et non l’un de ces systèmes d’exploitation lui-même.

Jugement 1 : l’OS véhicule est un système de systèmes d’exploitation, et sa frontière est tracée par l’architecture E/E. Ce qui s’appelle OS n’est pas forcément un OS véhicule, et ce qui ne s’appelle pas ainsi peut en être un. Le critère n’est pas le nom de marque, mais les domaines que couvre le contrat, la capacité de l’orchestration à prouver l’isolation et les couches que le cycle de vie peut mettre à jour. Jusqu’où ces trois éléments peuvent aller dépend d’abord de la génération atteinte par l’architecture E/E.

Jugement 2 : la véritable ligne de partage des eaux est l’inversion de la causalité. Ce qui marque l’entrée d’un constructeur dans l’ère définie par le logiciel n’est pas la possession d’une marque d’OS, mais le fait que la moitié inférieure de la boucle de coévolution ait commencé à tourner — que sa prochaine spécification E/E soit définie par les besoins du logiciel de la génération actuelle. Les « 10× / 1 000× / 35× » de GM, le désaccord entre BMW et GM sur le degré de mutisme des contrôleurs zonaux et la vente par Rivian de « E/E + OS » comme un tout sont autant de signes que la boucle a commencé à tourner.

Jugement 3 : l’IA rend le système d’exploitation plus important, pas moins. L’IA absorbera la moitié supérieure de l’OS mais épaissira sa moitié inférieure. Plus il y a de probabilité, plus le déterminisme devient précieux. La conduite autonome en est le test de résistance : le cockpit teste seulement si un OS sait faire tourner des applications, tandis qu’une voiture sans conducteur teste si un OS véhicule sait faire rouler le véhicule.

Un avertissement : ne pas considérer la « possession d’un OS » comme la ligne d’arrivée. Les noyaux se banalisent, les contrats se standardisent, et fondeurs et plateformes horizontales compriment par les deux bouts. Pour la plupart des constructeurs, la vraie question n’est pas « devons-nous construire notre propre OS ? » mais « dans quelle partie du plan de contrôle devons-nous avoir le dernier mot ? » L’orchestration, le cycle de vie, la boucle de données et la propriété ultime de la responsabilité de sécurité — voilà ce qui appartient encore au constructeur après la vague de standardisation.

La compétition autour de l’OS véhicule ne se terminera pas par la victoire d’un système. Elle se terminera par une question plus simple : quand chaque couche d’une voiture peut être achetée, quelle est la couche que vous ne pouvez pas acheter ? Cet article a posé le système de coordonnées sur la table ; où placer la mise a toujours été la décision du lecteur.

---

Annexe A | Niveaux de preuve et principales sources

A.1 Niveaux de preuve

Remarque : toutes les dates futures (GM 2028, STLA One 2027, Hyundai 2030, etc.) sont des plans ou des objectifs d’entreprise, non des faits, et il existe des précédents de retard.

A.2 Principales sources (par thème, sélection)

• Parc installé de QNX : BlackBerry, 10-K de l’exercice 2026 — https://www.sec.gov/Archives/edgar/data/1070235/000107023526000039/bbry-20260228.htm
• Démarrage de la production de MB.OS : Mercedes-Benz Group, démarrage de la production de la CLA à Rastatt — https://group.mercedes-benz.com/company/production/production-network/start-of-production-cla-rastatt.html
• NIO SkyOS : site officiel de NIO (technologie full-stack : OS véhicule pleine domaine) — https://www.nio.cn/smart-technology/20251215002 ; IT Home — https://www.ithome.com/0/720/560.htm
• Passage en open source de HaloOS (Li Auto) : TechNode — https://cn.technode.com/post/2025-03-29/lixiang-xinghuan-os/
• Normes nationales chinoises : Plateforme nationale de service public d’information sur les normes — https://std.samr.gov.cn/gb/search/gbDetailed?id=0BBF0FBBBE1AE46FE06397BE0A0AD1FD ; https://std.samr.gov.cn/gb/search/gbDetailed?id=D33BADAFBDDF2CD0E05397BE0A0A113C
• Traduction commerciale de GB/T 47341-2026 (T3) — https://www.chinaautoregs.com/archives/7587
• Plateforme de calcul central de GM : communiqué de presse de GM, 2025-10-22 — https://news.gm.com/home.detail.html/Pages/news/us/en/2025/oct/1022-SDV-GM-centralized-vehicle-computer-platform-electric-gas-vehicles.html
• Superbrains de la BMW Neue Klasse : https://www.bmwgroup.com/en/news/general/2025/superbrains.html
• Toyota Arene / RAV4 : https://pressroom.toyota.com/three-two-one-toyota-debuts-amazing-all-new-rav4/ ; https://insideevs.com/news/775729/2026-toyota-rav4-phev-arene-software-ev/
• Toyota Arene (formulation de 2023) : communiqué de presse de Toyota, 2023-04-11 — https://global.toyota/en/newsroom/corporate/39070846.html
• Hyundai Pleos : https://www.hyundainews.com/releases/4774 ; S&P Global Mobility — https://www.mobilityglobal.com/en-us/automotive-insights/blog/hyundai-pleos-software-launch-shifts-mobility-game
• Rivian / RV Tech : 8-K de Rivian pour l’exercice 2025 — https://www.sec.gov/Archives/edgar/data/1874178/000187417826000007/ex-991pressrelease4q25earn.htm ; DEF 14A — https://www.sec.gov/Archives/edgar/data/0001874178/000187417826000023/rivn-20260427.htm
• Avancement de RV Tech : communiqué de presse du groupe Volkswagen, 2025-11-12 — https://www.volkswagen-group.com/en/press-releases/one-year-after-its-founding-joint-venture-between-volkswagen-group-and-rivian-shows-strong-progress-19980 ; essais hivernaux — https://www.electrive.com/2026/03/27/vw-and-rivian-conclude-winter-testing-programme/
• CEA du groupe Volkswagen : communiqué de presse du groupe Volkswagen, 2026-01-28 — https://www.volkswagen-group.com/en/press-releases/volkswagen-group-china-starts-production-of-its-first-locally-developed-zonal-electronic-architecture-20144 ; CarNewsChina — https://carnewschina.com/2026/01/29/volkswagen-starts-production-of-xpeng-co-developed-cea-architecture-five-new-models-due-in-2026/ ; CarNewsChina, 2025-12-10 — https://carnewschina.com/2025/12/10/volkswagen-and-xpengs-first-joint-vehicle-id-unyx-07-nears-production-after-just-18-month-chinese-led-development/ ; IT Home — https://www.ithome.com/0/903/897.htm
• Restructuration de CARIAD (T3) : https://allthingstalent.org/volkswagen-to-cut-1600-jobs-at-cariad-software-division-in-major-restructuring-move/2025/03/13/
• Leapmotor LEAP 5.0 : Stellantis Media (Leapmotor Tech Day 2026, 2026-09-30) — https://www.media.stellantis.com/uk-en/leapmotor/press/leapmotor-unveils-next-generation-vehicle-architecture-battery-technology-at-tech-day-2026 ; Gasgoo — https://autonews.gasgoo.com/articles/ev/leapmotor-counters-tech-peak-theory-with-one-architecture-and-three-systems-2101156419729817601 ; Sina Auto, 2026-09-16 — https://auto.sina.cn/news/2026-09-16/detail-inirzwqt4627345.d.html
• Qualcomm Ride Flex : TechInsights — https://www.techinsights.com/blog/qualcomm-integrates-cockpit-adas
• NVIDIA Halos : https://www.nvidia.com/en-us/ai-trust-center/halos/autonomous-vehicles/
• Google AAOS SDV : Android Developers Blog, 2026-03-24 — https://android-developers.googleblog.com/2026/03/Beyond-Infotainment-Extending-Android-Automotive-OS-for-Software-defined-Vehicles.html ; architecture système d’AAOS SDV — https://source.android.com/docs/automotive/sdv/sdv-system-architecture
• Stellantis × Applied Intuition : https://www.stellantis.com/en/news/press-releases/2026/may/stellantis-and-applied-intuition-expand-collaboration-with-stla-brain-to-advance-vehicle-software-and-enhance-customer-experience
• VDA / Eclipse S-CORE : https://blogs.eclipse.org/post/sara-gallian/eclipse-sdv-2025-all-roads-lead-open-source ; https://www.adt.media/software-defined-vehicles/vda-and-eclipse-foundation-expand-sdv-software-ecosystem/2587652
• SOAFEE : https://www.globenewswire.com/news-release/2026/04/22/3279060/0/en/here-joins-soafee-to-bring-expertise-in-ai-powered-mapmaking-into-open-software-defined-vehicle-platforms.html ; Open AD Kit — https://autoware.org/open-ad-kit-the-first-soafee-blueprint-powering-open-collaboration-in-autonomous-driving/
• Eclipse Open Vehicle API : https://projects.eclipse.org/projects/automotive.openvehicle-api/reviews/eclipse-open-vehicle-api-2026.08-progress-review
• AUTOSAR Adaptive et POSIX : UL Solutions — https://www.ul.com/sis/blog/autosar-part-2-adaptive-platform
• UN R156 (texte du paragraphe 7.1.1) : EUR-Lex — https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:42021X0388
• ISO/PAS 8800 : UL — https://www.ul.com/sis/blog/safety-related-systems-road-vehicles-artificial-intelligence-are-addressed-isopas-88002024 ; certification de Geely (SGS) — https://www.sgs.com/en-hk/news/2025/08/geely-auto-awarded-first-global-ai-safety-certification-for-road-vehicles
• Parc installé du cockpit HarmonyOS / de Qiankun (Huawei) : https://news.qq.com/rain/a/20260908A0664N00
• Rapport AUTOSEMO 6.0 : communiqué de presse de Reach Auto (Neusoft), octobre 2025, publiant le rapport au nom d’AUTOSEMO — https://www.reachauto.com/en/2025/10/

---

Annexe B | Grille de notation VOCM

Chaque dimension est notée de 0 à 5. Les notes reposent uniquement sur des sources publiques ; une dimension aux preuves insuffisantes ne peut dépasser 2, ou est marquée n.d.

Confiance : H = des preuves de niveau 1–2 étayent directement la plupart des dimensions ; M = certaines dimensions reposent sur des déclarations d’entreprise ; L = la plupart des dimensions reposent sur des sources secondaires ou des inférences.

Exception de même lignée : une plateforme codéveloppée avec un constructeur déjà noté et héritant de la même lignée architecturale (comme VW CEA avec XPeng) peut se référer aux notes de ce constructeur sur les dimensions où ses propres informations publiques sont minces. Chacune de ces dimensions doit être nommée dans les remarques, et la confiance est plafonnée à L.

---

Annexe C | Abréviations