Le Software-Defined Vehicle rebat les cartes dans l’industrie automobile
S’il n’est pas encore une réalité généralisée, le concept de Software-Defined Vehicle réclame aux constructeurs, équipementiers et fournisseurs technologiques de revoir en profondeur leurs méthodes de développement et de collaboration.
Le concept du Software-Defined Vehicle prend corps. Lors du CES 2024, les constructeurs automobiles, les équipementiers et leurs partenaires de la Silicon Valley avaient déjà fait la lumière sur les technologies amenées à équiper les voitures au cours des cinq prochaines années. Le CES 2025 était l’occasion d’en suivre les évolutions.
Comme dans le réseau ou le stockage, le software-defined vehicle est un concept visant à contrôler les principales fonctionnalités et/ou à les améliorer à l’aide de logiciels. En l’adoptant, les constructeurs espèrent découpler les logiciels embarqués du matériel, s’appuyer sur des plateformes centralisées faisant appel à de l’électronique de puissance (des HPC dédiés à l’automobile) et favoriser la connexion permanente entre le véhicule et le cloud.
In fine, il s’agit de vendre des services et des éléments de personnalisation tout au long de la durée de vie d’une voiture. Bref, les constructeurs s’inspirent du modèle Tesla, lui-même dérivé de celui du smartphone. Cette tendance dépasse l’électrification. Si son développement récent est concomitant à l’émergence de la « watture », le logiciel embarqué devient incontournable dans tous types de véhicules, électriques, thermiques et hybrides.
L’importance grandissante des fabricants de semiconducteurs et des cloudistes
Cette priorisation du logiciel n’est pas sans effet sur l’écosystème.
« Ce qui est clair, c’est que tous les acteurs ont compris qu’aujourd’hui, la croissance, elle, n’est pas dans le matériel, mais vraiment dans le logiciel », observe Thomas Cardon, directeur des ventes EMEA, secteur automobile chez BlackBerry QNX, auprès du MagIT. « C’est particulièrement visible chez les acteurs du rang 1 ».
« Ce qui est clair, c’est que tous les acteurs ont compris qu’aujourd’hui, la croissance, elle n’est pas dans le matériel, mais vraiment dans le logiciel ».
Thomas CardonDirecteur des ventes EMEA, secteur automobile, BlackBerry QNX
Les fournisseurs du rang ou du tier 1 sont des industriels qui développent habituellement des systèmes et des modules électroniques. Ce sont des entités comme Bosch, Valeo, ZF ou encore Continental.
« Ils [les acteurs du rang 1] actent le fait qu’ils sont des fournisseurs de logiciels et pas uniquement de calculateurs », poursuit Thomas Cardon.
Les constructeurs et ces membres du rang 1 ont pour fournisseurs des fabricants de semiconducteurs, traditionnellement catégorisés dans le rang 2. Certains se contentent de produire les puces, mais de plus en plus les géants comme Qualcomm, Intel ou Nvidia développent des systèmes – des appliances personnalisables – pouvant être embarqués dans les véhicules. Court-circuiter les équipementiers du rang 1 ne serait plus un doux rêve pour ces « silicon vendors », mais déjà une réalité, selon Thomas Cardon.
« Aujourd’hui, nous avons des exemples assez concrets dans des programmes où quelque part, il y a des calculateurs qui sont gérés presque intégralement par des fabricants de semiconducteurs, par des gens comme Qualcomm ou par Nvidia, là où historiquement, c’était le marché des équipementiers », observe-t-il.
Aussi, pratiquement tous les acteurs de l’automobile se rapprochent des fournisseurs cloud. À ce jeu, AWS décroche la timbale. Lors du CES 2025, Valeo, Mitsubishi, Hyundai, Stellantis, Qualcomm, Intel, BlackBerry QNX ont annoncé ou rappelé l’existence de partenariats avec le géant du cloud appartenant à Jeff Bezos. Le groupe Mercedes Benz, lui, a annoncé un partenariat avec Google Cloud afin d’intégrer la « recherche conversationnelle » dans son assistant virtuel de bord, MBUX. Ce système sera propulsé par un agent IA basé sur un grand modèle de langage Gemini développé à partir de Vertex AI. Il était évident que l’IA générative prendrait davantage de place dans la sphère automobile.
« Il est évident que le cloud devient omniprésent, que ce soit pour les aspects de développement, mais également pour la mise en production de cette logique de Software-Defined Vehicle », poursuit Thomas Cardon. « Elle ne se cantonne pas simplement au périmètre du véhicule. Il y a toute une architecture cloud qui doit être mise en place pour pouvoir intégrer le véhicule dans un écosystème beaucoup plus global ».
« Les entreprises technologiques cherchent naturellement à collaborer directement avec les constructeurs automobiles (OEM) afin de s’assurer que les architectures SDV développées par ces fabricants intègrent leurs produits », confirme Paul Miller, vice-président et analyste principal chez Forrester Research auprès du MagIT. « Des fabricants de puces comme Infineon, NVIDIA, NXP et d’autres mènent ces discussions, tout comme des éditeurs de logiciels tels qu’AWS, Cerence, Google, Microsoft, QNX et bien d’autres », poursuit-il.
« Par exemple, NVIDIA a annoncé ce mois-ci que les futurs véhicules Toyota utiliseront ses puces. Ford, Renault, Volvo et d’autres intègrent depuis plusieurs années les logiciels de Google de manière approfondie dans l’interface utilisateur de leurs véhicules ».
Le Software-Defined Vehicle, loin d’être une réalité
Toutefois, cela ne rebat pas encore totalement les cartes : les fournisseurs de rang 1 et 2 conservent leur place dans la chaîne de valeur.
« Les OEM automobiles accordent aujourd’hui plus d’importance au choix du matériel et des logiciels utilisés par leurs fournisseurs de rang 1 et 2 qu’auparavant, dans le but de réduire les doublons et le gaspillage », nuance l’analyste. « Les fabricants d’automobiles peuvent exiger que leurs fournisseurs collaborent avec des entreprises de matériel ou de logiciels spécifiques. Cependant, les fournisseurs traditionnels de rang 1 et 2 restent des acteurs clés et s’adaptent pour préserver leur pertinence ».
« Les constructeurs automobiles (Renault, Ford, Volkswagen, etc.) évoquent le concept de véhicule défini par logiciel ».
Paul MillerVice-président et analyste principal, Forrester Research
D’autant que, bien que très présent dans les discours de l’écosystème automobile, le SDV n’est pas une réalité, selon Paul Miller.
« Les constructeurs automobiles (Renault, Ford, Volkswagen, etc.) évoquent le concept de véhicule défini par logiciel, mais sa mise en œuvre nécessitera une réinvention complète des méthodes de conception et de fabrication des nouveaux véhicules par les constructeurs et leurs fournisseurs », estime l’analyste.
« Mais sa mise en œuvre nécessitera une réinvention complète des méthodes de conception et de fabrication des nouveaux véhicules par les constructeurs et leurs fournisseurs ».
Paul MillerVice-président et analyste principal, Forrester Research
Malgré l’engouement autour du SDV, la plupart des constructeurs « ne font que commencer à repenser et sécuriser leurs systèmes, leurs processus de travail, leurs partenariats et leurs véhicules ».
Tesla et quelques acteurs chinois seraient des exceptions. « Nos clients européens sont dans une phase très transitoire », confirme Stefan Buerkle, président de l’informatique interdisciplinaire pour la région Amérique du Nord chez Bosch, lors d’une discussion consacrée à l’avenir du Software-Defined Vehicle au CES 2025.
« L’enjeu est différent de celui de Tesla ou des acteurs chinois. Ces constructeurs historiques doivent gérer des systèmes existants, ainsi que des portfolios de produits bien plus importants, sur tous les segments, de l’entrée au très haut de gamme », ajoute-t-il.
À cela s’ajoute la nécessité d’adapter les architectures software-defined à tous les types de véhicules, et non pas seulement aux plateformes électriques. De fait, en 2024, la vente de véhicules électriques n’a pas été aussi élevée que les autorités et les constructeurs l’espéraient.
Surtout, il semble difficile d’anticiper les besoins technologiques. « Nous sommes habitués à changer de smartphone tous les trois à quatre ans. Une voiture a une durée de vie minimum de 10, 15 ans », rappelle Stefan Buerkle. « Vous devez donc prévoir des besoins en puissance de calcul, en mémoire, en stockage pour activer des fonctionnalités dont vous ne connaissez même pas la nature ! Vous ne connaissez pas la fonctionnalité que vous allez lancer dans cinq ans ou sept ans, mais vous devez vous préparer maintenant ».
Si la face émergée n’est autre que le tableau de bord – les écrans présents dans les véhicules –, mettre à jour des systèmes critiques n’est pas anodin. Et pourtant, le concept de SDV pousse les constructeurs à adopter des pratiques DevOps et Agile, alors qu’ils étaient habitués aux cycles en V.
Il y a un intérêt économique : ne plus recommencer les développements à chaque génération de véhicules.
« Par le passé, les systèmes cockpits et ADAS étaient développés en fonction du cahier des charges de la prochaine gamme de véhicules, puis déployés dans ces différentes voitures à l’aide d’un acteur Tier 1. Et vous recommenciez depuis le début à la prochaine génération », explique Stefan Buerkle.
L’internalisation des développements, une solution provisoire, selon Bosch
Outre les problèmes techniques et organisationnels que le passage du développement en continu pose, les constructeurs se méfient de l’enfermement propriétaire que pourraient provoquer ces évolutions continues. Ils préfèrent donc faire (« make »), et non « faire-faire » (« buy »).
« La solution de beaucoup de constructeurs à ce problème d’enfermement propriétaire est d’internaliser les développements ».
Stefan BuerklePrésident de l’informatique interdisciplinaire pour la région Amérique du Nord, Bosch.
« La solution de beaucoup de constructeurs à ce problème d’enfermement propriétaire est d’internaliser les développements », assure le président de l’informatique interdisciplinaire pour la région Amérique du Nord chez Bosch. « Si je le fais en interne, je dois m’assurer que l’effort [de développement continu] ne soit pas trop important si mes équipements évoluent régulièrement ».
De fait, les middlewares des SoC, des systèmes de stockage, de sûreté doivent être régulièrement mis à jour. « Ils [les constructeurs] se disent donc : “d’accord, j’effectue ces évolutions moi-même, je fais tout moi-même” ».
Dans ce cas de figure, les équipementiers du rang 1 ne jouent plus le même rôle. « Problème, cette internalisation représente primo, de gros efforts à fournir, et, secundo, des investissements massifs », nuance Stefan Buerkle.
« Tout cet argent sert donc à rendre possible l’existence du Software-defined Vehicle, mais cela ne vous rapporte rien pour l’instant », dit-il en s’adressant aux constructeurs. Selon lui, 80 % des investissements en temps, capacité et argent de l’industrie automobile dans le SDV, serviraient à le mettre en place. Et seulement 20 % de ces moyens seraient consacrés aux usages et bénéfices à tirer d’un tel concept.
Sans compter des défis techniques. « De nombreux systèmes critiques à bord restent encore inaccessibles aux mises à jour OTA », illustre l’analyste de Forrester.
L’open source, une porte de sortie pour l’industrie ?
De fait, les fabricants automobiles n’ont pas la main sur le code de l’ensemble des ECU déployés dans leurs produits.
« Et c’est là que nous avons besoin de créer des standards, des usages communs d’outils pour rendre possible le SDV et les OEM pourront ensuite en faire quelque chose de spécial », avance Stefan Buerkle.
Les constructeurs chercheraient déjà à imposer des pratiques rigoureuses de développement logiciel à leurs fournisseurs, d’après Paul Miller de Forrester. Ils sont épaulés en cela par les sociétés d’externalisation et les intégrateurs de systèmes. « Presque tous les intégrateurs de systèmes mondiaux disposent d’une équipe importante dans le secteur automobile », avance-t-il.
Suivant ce cahier des charges, différentes fonctions embarquées doivent partager des ressources au sein d’un nombre restreint d’ordinateurs de bord plus standardisés, au lieu d’ajouter systématiquement une nouvelle unité de contrôle électronique (ECU), « tout en réduisant le poids et la complexité liés au câblage de ces systèmes ».
Hormis l’évolution des relations entre les fabricants et leurs fournisseurs, cette quête du SDV aurait un impact sur les clients finaux, d’après Stefan Buerkle. Du fait qu’il faut faire gonfler la puissance de calcul et de stockage de bord « à l’aveugle » – sans compter les pénuries pouvant affecter l’accès aux composants –, les prix pratiqués par les marques augmentent en conséquence. Et ils deviennent des freins à l’achat.
En vue de faire baisser les prix de conception, ces équipementiers, dont Bosch et ETAS poussent la collaboration et l’adoption de technologies open source.
« Je ne dis pas qu’il faut tout faire en open source, mais il y a des plateformes standards et des composants spécifiques que nous pouvons rendre open source », déclare Thomas Irawan, CEO d’ETAS, un éditeur de solutions logiciels pour l’industrie automobile. « Cela représenterait un espace sûr pour collaborer où chaque acteur pourrait apporter ce qu’il fait le mieux pour que l’ensemble du secteur en bénéficie ».
Cela nécessiterait la mise en place d’un « dialogue ouvert ». Et aux constructeurs de déposer – même temporairement – la hache de guerre face à leurs compétiteurs.
Le groupe de travail SDV au sein de la fondation open source Eclipse s’est justement donné cette mission, rappelle le dirigeant d’ETAS. Il rassemble déjà BMW, Mercedes-Benz, GM, Cummins, Microsoft, ETAS, Bosch, ZF, Denso, Continental, Canonical, Elektrobit, Red Hat, Valeo, STMicroelectronics ou encore ARM.
