Xavier Desseaux, Responsable commercial ligne de produits ALM

28 octobre 2026

Si le Cybercab de Tesla attire l’attention par l’absence de volant, il illustre surtout l’émergence des Software-Defined Vehicles (SDV), capables d’être enrichis et mis à jour tout au long de leur cycle de vie. Dans ce nouveau paradigme, le véritable enjeu pour les constructeurs n’est plus seulement de développer le véhicule, mais de maîtriser durablement ses évolutions, leurs impacts et leur conformité.

Avec le lancement à Austin de ses premiers robots taxis « Cybercabs » sans volant ni pédales, Tesla a franchi une nouvelle étape vers la mobilité autonome. L’agence américaine de sécurité routière a depuis ouvert une enquête sur ces modèles. Elle attend des précisions techniques et juridiques, puisque Tesla a autocertifié sa conformité aux normes fédérales de sécurité automobile. Au-delà du débat réglementaire, le Cybercab est une belle illustration de l’évolution des méthodes de conception et de développement logiciel dans l’automobile. Il pose également une question centrale : comment faire évoluer en toute sécurité des véhicules définis par logiciel après leur sortie d’usine ?

Le développement après mise en production

Traditionnellement, le constructeur travaille à la réalisation d’une voiture dont les caractéristiques sont fixées par avance. Une fois les fonctions définies, développées et testées, la production démarre en suivant une configuration déterminée.

Le Software-Defined Vehicle (SDV) bouleverse cette logique en permettant d’activer, d’enrichir ou de modifier des fonctionnalités à distance après la livraison.

Chaque mise à jour devient alors un véritable projet d’ingénierie, qui doit pouvoir être documenté, testé, validé et tracé avec précision. Cette traçabilité est particulièrement critique lorsqu’elle touche aux fonctions de conduite autonome. Par exemple, une modification du système de détection d’objets peut sembler se limiter à certaines combinaisons de capteurs, de plateformes de calcul et de versions logicielles. En réalité, son impact peut avoir des répercussions beaucoup plus larges, notamment sur la sécurité fonctionnelle et l’homologation. Par conséquent, l’identification par série de fabrication et année-modèle ne suffit plus. Deux véhicules extérieurement identiques peuvent embarquer des versions logicielles et des configurations système différentes. La traçabilité doit donc désormais être assurée jusqu’au véhicule individuel.

Le logiciel, multiplicateur de variantes

Les stratégies de plateformes ont permis de rationaliser les architectures automobiles et de réduire le nombre de variantes physiques. Mais la complexité demeure. Elle se déplace vers les versions logicielles, les validations de fonctions, les spécificités nationales et les interdépendances entre systèmes.

Dans un véhicule autonome, aucune fonction n’existe isolément. Toute modification apportée aux capteurs ou aux logiciels associés peut ainsi affecter le comportement du système. Un test validé sur une configuration donnée ne vaut donc pas automatiquement pour toutes les combinaisons de matériel, de logiciel et d’exigences réglementaires. Les constructeurs n’ont d’autre choix que d’associer précisément la couverture des tests et la validation à un état de configuration défini. Avant toute modification, une analyse d’impact est nécessaire pour montrer quelles exigences, interfaces et variantes de véhicules doivent être soumises à de nouveaux contrôles. En cas d’anomalies ou de bugs, il faut pouvoir identifier les véhicules concernés et rétablir une version sécurisée.

Les systèmes cloisonnés comme limites du processus

Bien souvent, les informations requises pour mener à bien la modification souhaitée sont dispersées entre plusieurs systèmes. Chaque équipe dispose de solutions efficaces pour son propre périmètre, mais des disconnections apparaissent entre les différentes entités et leurs données.

De plus, les transferts manuels de données favorisent les erreurs, les incohérences, les écarts de version et des informations manquantes dans l’historique des modifications. Pour un constructeur développant des véhicules autonomes, ces manquements peuvent rapidement devenir problématiques, tant pour l’analyse des incidents que pour les audits de conformité.

La complexité des processus traditionnels au sein d’une entreprise devient encore plus aigüe lorsqu’elle s’applique aux véhicules autonomes. En cause : l’intervention de plusieurs métiers, d’équipementiers et de partenaires internes ou externes sur les parties logicielles d’une même fonction.

Or, l’anomalie détectée sur le terrain doit pouvoir être retracée rapidement jusqu’à la fonction concernée, tout en associant précisément chaque modification issue de l’ingénierie aux véhicules susceptibles de la recevoir. En somme, l’enjeu est donc de garantir des informations explicites, versionnées et exploitables de manière automatisée.

ALM, PLM, MBSE et PLE : la complémentarité

La gestion du cycle de vie des applications (ALM), la gestion du cycle de vie des produits (PLM), l’ingénierie système basée sur les modèles (MBSE), le Product Line Engineering (PLE) constituent des approches complémentaires pour surmonter le cloisonnement des données.

L’ALM relie les exigences au développement logiciel, aux tests et aux validations. Le PLM associe les modifications aux configurations produits et véhicules. Le MBSE décrit les fonctions, les architectures système, les interfaces et leurs dépendances. Quant au PLE, il permet de mieux gérer et d’automatiser la gestion des variants. C’est toutefois leur intégration qui garantit une vision globale, cohérente et traçable.

L’Intelligent Product Lifecycle fournit à cet effet un cadre de développement commun. Il relie les informations pertinentes, depuis l’exigence jusqu’à la configuration du véhicule en exploitation, en passant par l’architecture, la version logicielle et les tests. Cette approche aide les constructeurs à évaluer plus rapidement les modifications et à apporter les bonnes données de manière plus ciblée. Dans le même temps, le risque de déployer une modification techniquement correcte sur une configuration non validée se réduit considérablement.

Repenser la responsabilité sur l’ensemble du processus

Une chaîne d’outils intégrée suppose une répartition claire des responsabilités. Les différents services d’ingénierie ont chacun leurs méthodes, leurs objectifs et leurs responsabilités. L’avènement du SDV exige une maîtrise et une gouvernance de chaque fonction, de bout en bout.

Cette responsabilité, qui commence dès l’expression des besoins, ne s’arrête plus à la validation avant la mise en production. Elle s’étend à l’ensemble de son cycle de vie, y compris lorsque le véhicule est sur la route. Cela implique de savoir précisément les configurations concernées par une évolution, les données disponibles, qui autorise les mises à jour et comment gérer les options qui peuvent s’avérer erronées une fois le véhicule déployé.

Si Tesla a choisi de supprimer le volant de son Cybercab, le véritable défi pour l’industrie automobile est ailleurs. L’avenir des véhicules définis par logiciel dépendra autant de la capacité des constructeurs à maîtriser la traçabilité, les impacts des évolutions et les exigences de sécurité et de conformité réglementaire que des technologies qui rendent l’autonomie possible.