En Europe, une voiture prend souvent trois à cinq ans à développer. Pendant ce temps, le logiciel prend une place croissante dans chaque véhicule.
Reste à savoir si des cycles plus courts font naître de nouveaux risques. Cet article examine ces risques et distingue ce que les données permettent d’affirmer de ce qui reste à confirmer.
Deux ans de développement, ça fait quoi ?
En Europe, le développement d’une voiture prend souvent de trois à cinq ans, selon le segment. C’est le temps qui sépare les premières études du lancement en concession.
Renault vise un cycle de vingt-quatre mois, alors qu’il prévoit 36 nouveaux modèles d’ici 2030. Pour l’acheteur, un calendrier plus court ne dit pas encore si la voiture est mieux finie.
La Twingo E-Tech a été développée en 21 mois. C’est un cas précis, qui ne dit pas combien de temps prendra le prochain modèle.
Mercedes-Benz annonce jusqu’à 30 % de temps en moins avec PLM.AI, soit environ 17 mois. Son gain de 50 % d’efficacité dans certains processus ne réduit pas de moitié le développement de toute la voiture.
Pression concurrentielle et limites des chiffres
Pression concurrentielle
- 7 % des ventes de voitures neuves dans l’UE en 2025
- Ces voitures sont fabriquées en Chine
- Les constructeurs veulent lancer plus vite pour rester dans la course
Limites des chiffres
- La part de 7 % mesure le lieu de fabrication
- Elle ne dit pas la nationalité de la marque
- Un cycle annoncé par un constructeur ne donne pas la date de sortie de chaque modèle
Une voiture pensée comme un logiciel, pour aller plus vite
En 2006, une voiture comptait en moyenne 28 calculateurs électroniques. En 2016, ce nombre atteignait 38, tous segments confondus. Chaque calculateur commande une partie des fonctions de la voiture.
En 2018, les voitures haut de gamme pouvaient en avoir jusqu’à 110, contre environ 20 dans les petites voitures. Pour un acheteur, le modèle choisi compte donc autant que la taille du véhicule.
Quand plusieurs fonctions passent dans un même calculateur central, le logiciel se développe en un seul bloc au lieu de morceaux répartis. Sur la Volkswagen ID.3, des fonctions auparavant réparties entre plus de 70 calculateurs suivent cette logique.
Des outils d’IA complètent ce travail. Chez Mercedes-Benz, PLM.AI relie les données de développement, d’achats, de production, de vente et d’après-vente, et aide à repérer des erreurs dans le logiciel.
Volume de code, aujourd’hui et demain
Voiture non automatisée actuelle
Environ 100 millions de lignes de code, contre environ 10 millions en 2010. Ce code commande l’affichage, l’aide à la conduite et la gestion du moteur.
Voiture automatisée
Estimation entre 300 et 500 millions de lignes de code. Ce chiffre est une projection pour les véhicules automatisés, pas une mesure des voitures actuelles non automatisées.
Les pannes quittent la mécanique pour l’électronique
Dans l’étude américaine 2025 sur la qualité initiale, l’infodivertissement est la catégorie qui compte le plus de problèmes : 42,6 pour 100 véhicules. Avant l’achat, tester l’écran, la radio et l’appairage du téléphone permet de repérer ce type de défaut.
Dans l’étude sur les systèmes multimédias, le taux est de 42,3 pour 100 véhicules en 2025, contre 44,1 en 2024.
La baisse reste légère. Les deux études ne mesurent pas le même périmètre : leurs chiffres ne se comparent pas.
Une panne mécanique touche en général une seule voiture à la fois. Un défaut logiciel, lui, se reproduit sur tous les véhicules qui ont reçu la même version. Le problème est le même partout.
Un défaut logiciel se diagnostique mal à l’atelier. Une pièce usée se voit, mais un bug ne laisse pas toujours de trace. Il faut donc que le logiciel soit testé avec le même soin qu’une pièce mécanique.
L’étude porte sur 34 175 propriétaires américains de voitures de l’année-modèle 2022, interrogés après trois ans de possession. Le taux de 8,4 pour 100 véhicules pour Android Auto et Apple CarPlay ne mesure pas les problèmes du parc français : l’appliquer aux voitures vendues en France ferait croire à un défaut plus ou moins fréquent qu’il ne l’est.
La fiabilité logicielle est-elle pour autant maîtrisée ?
Au lancement de la Volkswagen ID.3, le logiciel n’était pas encore au point. Pendant les essais, des conducteurs d’essai signalaient jusqu’à 300 erreurs par jour. Ce chiffre n’est pas un comptage publié par Volkswagen.
Jusqu’à 20 000 ID.3 devaient recevoir une mise à jour après leur fabrication. Les premières livrées n’avaient pas encore App Connect ni l’affichage tête haute de la distance, prévus au début de 2021.
Un seul modèle ne suffit pas à prouver que des cycles plus courts font baisser la fiabilité. Les données sur l’ID.3 ne permettent pas de séparer le calendrier court des autres causes possibles.
Les études disponibles ne suffisent pas non plus. L’enquête américaine sur la qualité initiale ne donne pas la part des défauts électroniques dans les études européennes.
Sans ces chiffres, la tendance reste à confirmer.
Indicateurs à réunir avant de conclure
- Compter le nombre de rappels logiciels par an en France.
- Mesurer la part des rappels liés à l’électronique parmi l’ensemble des rappels en Europe.
- Calculer le délai moyen entre la détection d’un défaut logiciel et sa correction.
- Séparer les corrections faites à distance de celles faites en atelier.
- Rapporter chaque rappel au nombre de véhicules concernés.
Les mises à jour à distance face aux exigences du règlement R156
Dans une étude américaine de fiabilité 2025 portant sur 34 175 propriétaires de modèles 2022, 36 % ont reçu une mise à jour à distance pendant les trois premières années.
C’est donc fréquent : la voiture change souvent après l’achat, sans passer par l’atelier.
Parmi ceux qui en ont fait une, 30 % disent avoir remarqué une amélioration, et 56 % ne voient pas de changement notable. L’effet perçu reste limité : une mise à jour ne veut pas dire un gain visible pour le conducteur.
Le règlement ONU R156 s’applique aux véhicules qui reçoivent des mises à jour logicielles. Il oblige le constructeur à avoir un système qui suit la version installée sur chaque voiture et organise les mises à jour.
Si une mise à jour échoue ou s’interrompt, le véhicule doit pouvoir revenir à la version précédente, ou être placé dans un état sûr. Une installation interrompue ne doit pas laisser la voiture avec un logiciel incomplet.
Des cycles plus courts laissent moins de temps pour tester le logiciel. Les données disponibles ne prouvent pas encore qu’ils fassent baisser la fiabilité.
Pour savoir, il faut compter les rappels logiciels et les rapporter aux véhicules concernés.
{“@context”:”https://schema.org”,”@type”:”Article”,”headline”:”Accélération des cycles de conception automobile et complexification électronique : quels risques ?”,”description”:”Analyse des risques liés à la réduction des cycles de développement des véhicules (24 mois chez Renault) et à l’augmentation massive du code logiciel (100 millions de lignes).”,”inLanguage”:”fr”,”abstract”:”Un défaut logiciel touche toutes les voitures qui ont reçu la même version, alors qu’une panne mécanique reste en général isolée. L’article examine si les cycles de conception plus courts font baisser la fiabilité automobile.”,”image”:”https://gohmqpvtliqcvxerzehl.supabase.co/storage/v1/object/public/images/e7bb7cae-c46b-4be3-8630-9a2a6e28fa69/plan-s1-5aabbc34.jpg”,”hasPart”:[{“@type”:”WebPageElement”,”name”:”Pression concurrentielle et limites des chiffres”},{“@type”:”WebPageElement”,”name”:”Volume de code, aujourd’hui et demain”},{“@type”:”WebPageElement”,”name”:”R155 et R156 : rôles et limites”}]}
.wwc { –wwc-primary: #3b82f6; }
