La voiture que vous achetez aujourd’hui est livrée avec une feuille de route, et celle-ci est entièrement logicielle. L’ensemble des fonctionnalités incluses à la livraison correspond à la version 1.0, mais le véritable produit est ce qu’elle deviendra au fil des cinq prochaines années de mises à jour. Cette évolution redéfinit le développement de logiciels automobiles comme une tâche d’ingénierie ponctuelle en une discipline produit continue, plus proche du SaaS que de la fabrication.
L’IA est également devenue une partie essentielle de la pile technologique : modèles exécutant l’inférence en périphérie, assistants gérant les interactions dans l’habitacle, ou systèmes prédisant la défaillance d’un composant avant que le conducteur ne remarque quoi que ce soit.
Si vous êtes en train de définir un projet d’IA automobile, ou d’évaluer si votre équipe actuelle peut le réaliser, cet article détaille ce qu’implique réellement le travail, de l’architecture aux normes, en passant par la pile technologique, et les points où la plupart des projets rencontrent des difficultés.
Du matériel au logiciel : les véhicules définis par logiciel
Le terme « véhicule défini par logiciel » (SDV) est souvent employé sans rigueur, mais sa signification technique est précise. Un véhicule traditionnel distribue ses fonctions sur des dizaines d’unités de contrôle électroniques (ECU) isolées, chacune exécutant un firmware propriétaire avec une communication minimale entre elles. Un véhicule défini par logiciel, quant à lui, consolide ces fonctions sur des plateformes de calcul centralisées. Là, le logiciel contrôle le comportement du véhicule, et de nouvelles fonctionnalités peuvent être déployées par voie hertzienne (OTA) sans intervention sur le matériel.
Ce changement architectural est d’une importance capitale pour les services de développement logiciel automobile, car il signifie que :
- Les fonctions du véhicule qui nécessitaient autrefois le remplacement physique d’une ECU peuvent désormais être mises à jour à distance.
- Les fonctionnalités peuvent être monétisées après la vente grâce à des modèles d’abonnement ou de fonctionnalité à la demande.
- Une seule équipe logicielle peut gérer le cycle de vie complet du véhicule, et pas seulement la phase de pré-production.
- La logique de retour arrière OTA devient aussi critique que la mise à jour elle-même.
Le marché des véhicules définis par logiciel témoigne de la rapidité de cette transition. Selon Fortune Business Insights, le marché mondial des logiciels automobiles était évalué à 36 milliards de dollars en 2025 et devrait atteindre 113 milliards de dollars d’ici 2034. Le secteur des SDV connaît une croissance annuelle de 25 à 30 %, ce qui représente environ 8 fois le rythme du marché automobile au sens large.
La prochaine étape de cette évolution porte un nom : le véhicule défini par IA, ou AIDV. Alors que le SDV fournit la base architecturale (calcul centralisé, livraison OTA, couches logicielles modulaires), l’AIDV introduit l’IA non pas comme une fonctionnalité applicative, mais comme une couche de plateforme fondamentale. Le véhicule interprète le contexte, apprend des schémas de conduite et adapte son comportement en temps réel. Cette distinction est importante pour les équipes qui développent aujourd’hui, car la conception d’une architecture AIDV dès le départ est un projet totalement différent que d’ajouter des fonctionnalités IA à un
Les 5 composants clés des logiciels automobiles basés sur l'IA
Le développement de logiciels automobiles pour véhicules dotés d’IA implique cinq couches fonctionnelles distinctes. Chacune d’entre elles a sa propre discipline d’ingénierie que nous détaillons ci-dessous.
Systèmes ADAS et de perception
Le développement de logiciels pour les systèmes avancés d’aide à la conduite (ADAS) est là où se concentre la majeure partie du travail gourmand en calcul. Les pipelines de perception ingèrent simultanément des données provenant de caméras, de radars, de LiDAR et de capteurs ultrasoniques, et les algorithmes de fusion de capteurs réconcilient ces entrées en un modèle cohérent en temps réel de l’environnement du véhicule.
Le défi d’ingénierie n’est pas seulement la précision, mais la précision dans des conditions que les données d’entraînement n’incluaient pas. La pluie la nuit, un panneau stop partiellement occulté, et un piéton qui sort entre des camions garés sont autant d’obstacles que les systèmes apprennent à partir de rencontres aléatoires et rares. Le développement de logiciels ADAS de qualité production nécessite une couverture scénarios contradictoires, pas seulement des performances de référence.
Lors du CES 2026, KPIT Technologies a présenté une suite d’IA agentique construite sur une IA générative spécifiquement conçue pour accélérer les cycles de développement ADAS et réduire les défauts dans les systèmes critiques pour la sécurité. La direction est claire : l’IA est maintenant utilisée pour construire une meilleure IA pour les véhicules.
IA embarquée et cockpit numérique
Le cockpit numérique est la couche du stack IA tournée vers l’utilisateur. C’est là que l’IA embarquée se manifeste sous forme d’assistants conversationnels, de paramètres personnalisés, de navigation prédictive et de système d’infodivertissement contextuel. C’est aussi l’un des domaines les plus dynamiques du stack, stimulé par l’intégration des LLM et l’évolution vers des architectures embarquées basées sur des LLM capables de traiter des commandes en langage naturel sur plusieurs fonctions du véhicule simultanément.
Bien faire l’IA embarquée nécessite plus que de brancher un grand modèle linguistique. Les exigences de latence pour l’interaction du conducteur se mesurent en millisecondes. Par conséquent, les modèles doivent s’exécuter de manière fiable sur du matériel périphérique contraint. De plus, le système doit se dégrader gracieusement en cas de perte de connectivité, car le conducteur est toujours dans la voiture, que le cloud soit accessible ou non.
Maintenance prédictive et diagnostic
Les logiciels automobiles de maintenance prédictive surveillent les données des capteurs des systèmes de motorisation, de batterie, de freinage et de suspension pour signaler les anomalies avant qu’elles n’entraînent des défaillances. Pour les opérateurs de flottes et les équipementiers qui gèrent des programmes de véhicules connectés, il s’agit de l’une des applications d’IA offrant le meilleur ROI disponible, car le coût d’une panne imprévue est presque toujours supérieur au coût d’une réparation proactive.
Bien bâtir cela signifie plus que d’entraîner un modèle de classification sur des codes d’erreur. Vous devez concevoir un pipeline de données qui transmet de manière fiable la télémétrie du véhicule à la couche d’inférence, gère les signaux manquants ou bruités, et affiche des alertes exploitables plutôt que des scores de probabilité qu’une équipe de maintenance ne peut pas utiliser.
Infrastructure de mise à jour OTA
La FOTA (firmware-over-the-air) est l’un des aspects moins glamour de l’architecture logicielle automobile, mais elle est d’une importance opérationnelle capitale. Un système OTA mal conçu peut rendre des véhicules inutilisables à grande échelle, créer des risques de non-conformité ou tomber en panne silencieusement, ce qui est pire à certains égards.
L’infrastructure OTA de production pour les logiciels automobiles doit gérer :
- La compression des mises à jour différentielles pour minimiser la bande passante cellulaire
- La signature et la vérification cryptographiques à chaque niveau
- Les déploiements progressifs avec retour arrière automatique en cas d’échec
- La conformité à la norme UNECE R156, la norme réglementaire internationale pour les mises à jour logicielles OTA dans les véhicules
58 % des conducteurs ayant reçu des mises à jour OTA en 2025 n’ont signalé aucune amélioration notable, selon le JD Power Vehicle Dependability Study. Ce chiffre vous indique quelque chose d’important sur l’écart entre la livraison d’une mise à jour et la livraison d’une bonne mise à jour.
Pipelines de données V2X et de véhicules connectés
Les logiciels de véhicules connectés gèrent la communication entre le véhicule et les systèmes externes, tels que l’infrastructure, d’autres véhicules, les plateformes de gestion de flotte et les backends cloud. Les protocoles V2X (vehicle-to-everything) permettent des cas d’utilisation allant de l’optimisation des feux de circulation à la coordination d’évitement de collision.
Le défi de l’ingénierie des données ici est considérable. Un seul véhicule génère entre 25 et 100 Go de données de capteurs et de télémétrie par heure. Décider ce qu’il faut traiter en périphérie, ce qu’il faut transmettre et ce qu’il faut stocker nécessite un travail d’architecture minutieux en amont, et non comme une optimisation des performances a posteriori.
Pourquoi c'est vraiment difficile : les véritables défis du développement logiciel automobile
Les défis du développement de véhicules définis par logiciel ne sont pas suffisamment abordés dans le contenu marketing entourant ce domaine. Ici, nous listons les problèmes réels que les équipes rencontrent, basés sur notre propre expérience de développement.
La sécurité fonctionnelle n'est pas de la documentation
ISO 26262 est la norme internationale pour la sécurité fonctionnelle des logiciels automobiles. MISRA C est l’ensemble des directives de codage qui régissent le développement en C et C++ dans les systèmes critiques pour la sécurité. AUTOSAR est le framework d’architecture logicielle auquel la plupart des chaînes d’approvisionnement des équipementiers exigent la conformité.
L’erreur que font la plupart des équipes de développement logiciel non automobile est de les considérer comme des cases à cocher de conformité, c’est-à-dire quelque chose que l’équipe QA gère à la fin. En réalité, les exigences de sécurité fonctionnelle façonnent la manière dont vous architecturez le système, la manière dont vous écrivez et passez en revue le code, la manière dont vous testez, et la manière dont vous documentez chaque décision de conception.
Ce n’est pas une couche que vous ajoutez par-dessus un logiciel fini, mais une contrainte qui s’applique à chaque décision d’ingénierie dès le premier jour. Le processus de développement logiciel automobile pour un composant critique pour la sécurité implique une analyse des dangers et une évaluation des risques (HARA) pendant la phase de conception, des tests logiciels en boucle (SIL) et matériels en boucle (HIL), et une traçabilité étendue des exigences aux cas de test. Ce n’est pas optionnel, et vous ne pouvez pas accélérer au-delà d’un certain point.
Les contraintes du calcul en périphérie sont réelles
Les grands modèles d’IA s’exécutent confortablement sur les GPU cloud. Ils ne s’exécutent pas confortablement sur le matériel informatique embarqué de la plupart des véhicules de production. Les logiciels embarqués automobiles pour les applications d’IA nécessitent une compression de modèle, une quantification et, dans de nombreux cas, des runtimes d’inférence spécialement conçus tels que ONNX ou TensorFlow Lite, optimisés pour le SoC spécifique du véhicule.
Le compromis entre la précision du modèle et la latence d’inférence sur du matériel contraint est l’un des défis d’ingénierie déterminants dans le développement d’IA automobile. Se tromper produit des systèmes trop lents pour être sûrs ou trop imprécis pour être utiles.
Étiquetage des données à l'échelle automobile
L’entraînement d’un modèle de perception pour l’ADAS n’est pas un projet de week-end. Les ensembles de données de production pour le développement de logiciels ADAS comprennent des millions d’images étiquetées dans diverses conditions d’éclairage, géographies, conditions météorologiques et cas limites. Le pipeline d’étiquetage lui-même est un défi d’ingénierie en termes de cohérence, de contrôle qualité et d’outils pour gérer l’annotation à grande échelle, tout cela nécessitant un investissement dédié.
De nombreuses entreprises lancent un projet d’IA automobile sans comprendre cela, découvrent le problème des données six mois plus tard, et soit compromettent la qualité du modèle, soit dépassent le calendrier.
Divergence réglementaire entre les marchés
La conformité pour le développement de logiciels dans l’industrie automobile varie selon les régions de manière significative pour l’architecture. Les réglementations UNECE de l’UE (R155 pour la cybersécurité, R156 pour les mises à jour OTA) définissent des exigences qui diffèrent des directives NHTSA américaines et des normes chinoises GB émergentes.
Si vous développez des logiciels pour un véhicule qui sera vendu sur plusieurs marchés, cela doit être intégré dès la conception du système, car l’adaptation de la conformité multi-marchés est coûteuse.
La pile technologique de l'IA automobile
Les choix de la pile technologique de l’IA automobile sont plus limités que dans le développement logiciel général. Voici à quoi ressemble le paysage réel en 2026.
Couche système d’exploitation :
- Automotive Grade Linux (AGL) pour l’infodivertissement et les domaines non critiques pour la sécurité
- BlackBerry QNX pour les systèmes temps réel critiques pour la sécurité (QNX et Vector Informatik ont signé un protocole d’accord en juin 2025 pour développer conjointement une plateforme SDV fondamentale)
- AUTOSAR Adaptive pour les middlewares orientés services sur des unités de calcul haute performance
- AUTOSAR Classic pour les domaines traditionnels basés sur les ECU, où il reste embarqué
IA et inférence :
- PyTorch et TensorFlow pour l’entraînement des modèles
- TensorFlow Lite et ONNX Runtime pour l’inférence en périphérie sur les SoC de véhicules
- CUDA pour l’inférence accélérée par GPU, lorsque les budgets de calcul le permettent
- LLM spécifiques au domaine, affinés sur des données d’interaction automobile pour les assistants embarqués
Communication :
- SOME/IP et DDS pour la communication inter-services du véhicule
- MQTT et AMQP pour les pipelines de télémétrie cloud
- Piles V2X dédiées (DSRC, C-V2X) pour la communication d’infrastructure
Cloud et backend :
- AWS et Azure proposent tous deux des SDK spécifiques à l’automobile et des services de véhicules connectés
- Plateformes de gestion OTA, y compris Uptane (le framework de sécurité utilisé par la plupart des systèmes OTA de production)
Langages :
- C et C++ pour les domaines embarqués et critiques pour la sécurité (avec des outils de conformité MISRA)
- Rust gagne du terrain pour le travail embarqué où la sécurité de la mémoire est importante et où la surcharge du C est acceptable
- Python pour les pipelines de ML et les outils (pas dans le runtime du véhicule)
À quoi ressemble réellement une équipe de développement logiciel automobile IA compétente
Embaucher des développeurs de logiciels automobiles est l’étape où les projets échouent le plus souvent, car les gens le font sans comprendre l’écart du domaine. C’est ainsi que vous vous retrouvez six mois plus tard avec une équipe qui écrit d’excellent Python mais qui n’a jamais travaillé sous ISO 26262 et n’a aucune idée de ce qu’est AUTOSAR.
Un partenaire de développement en IA automobile capable de fournir un travail de qualité production a besoin :
- D’ingénieurs logiciels embarqués ayant travaillé avec des systèmes d’exploitation temps réel
- D’ingénieurs IA et ML expérimentés dans le déploiement de modèles sur du matériel edge, pas seulement dans leur entraînement
- D’ingénieurs en sécurité fonctionnelle qui comprennent l’ISO 26262 au niveau de l’architecture
- D’une équipe de QA software testing qui connaît la différence entre les tests logiciels et la validation de logiciels automobiles
Comment commencer à construire des logiciels IA automobiles sans perdre six mois
Comment construire des logiciels automobiles basés sur l’IA est souvent présenté comme une grande question d’architecture. En pratique, le point de départ le plus efficace est plus restreint : choisissez un problème bien délimité, construisez-le avec une qualité de production, et utilisez-le pour développer les outils, les processus et la compréhension de l’équipe qu’un programme plus vaste nécessite.
Par exemple, les logiciels automobiles de maintenance prédictive constituent souvent un bon premier projet. Les données existent (la télémétrie des véhicules est déjà collectée sur la plupart des véhicules modernes), le ROI est mesurable (réduction des temps d’arrêt imprévus), et les implications de sécurité sont moindres que pour les systèmes de perception ou d’ADAS, ce qui signifie que vous pouvez avancer plus rapidement tout en développant la capacité organisationnelle pour les processus de sécurité fonctionnelle.
Quelques points à décider dans les deux premières semaines, pas le sixième mois :
- Inférence edge ou cloud ?
Ceci détermine les exigences matérielles, l’architecture de latence et les hypothèses de connectivité pour l’ensemble du projet. - Quelle classification de sécurité s’applique ?
L’ISO 26262 a des niveaux ASIL de A à D. Comprendre où se situe votre cas d’utilisation détermine la proportion du processus de sécurité dont vous avez besoin et quels outils sont non négociables. - Mises à jour OTA dès le premier jour ?
Adapter la capacité OTA à une pile logicielle de véhicule qui n’a pas été conçue pour cela est coûteux. Si la feuille de route produit inclut des mises à jour post-déploiement, elles doivent être incluses dans l’architecture initiale.
C’est là qu’une phase de découverte justifie son coût. Dans l’IA automobile, une mauvaise décision architecturale à la deuxième semaine entraîne une correction de six mois au huitième mois.
Vous définissez le périmètre de quelque chose dans l’IA automobile ? Nous sommes dans ce domaine depuis assez longtemps pour savoir quelles décisions sont importantes la première semaine et lesquelles semblent urgentes mais ne le sont pas. Contactez Redwerk dès aujourd’hui et discutons de la manière de construire votre produit.
FAQ
Qu'est-ce qu'un véhicule défini par logiciel ?
Un véhicule défini par logiciel (SDV) est un véhicule où les fonctions principales, telles que la dynamique de conduite, le système d’infodivertissement, les systèmes de sécurité et la gestion de l’alimentation, sont contrôlées, mises à jour et étendues par logiciel plutôt que par du matériel fixe. La caractéristique clé est que le véhicule peut recevoir des mises à jour de capacités significatives par voie aérienne tout au long de son cycle de vie.
En quoi le développement de logiciels IA automobiles diffère-t-il du développement logiciel classique ?
Trois éléments le distinguent :
- Les normes de sécurité fonctionnelle (l’ISO 26262 exige des processus de développement, une documentation et des méthodes de validation spécifiques)
- Les contraintes embarquées en temps réel (les modèles d’IA doivent s’exécuter dans des budgets de latence stricts sur du matériel spécialisé)
- La conformité réglementaire sur les marchés des véhicules
Un processus de développement web ou SaaS ne correspond à aucun de ces éléments.
Quelles normes s'appliquent aux logiciels IA automobiles ?
- ISO 26262 pour la sécurité fonctionnelle, MISRA C pour les normes de codage
- ISO 21434 pour la cybersécurité
- UNECE R155/R156 pour la gestion de la cybersécurité et les mises à jour OTA
- AUTOSAR fournit le cadre d’architecture logicielle que la plupart des chaînes d’approvisionnement des équipementiers automobiles exigent
Combien de temps faut-il pour développer des logiciels IA automobiles ?
Un module initial bien délimité, par exemple la maintenance prédictive ou un assistant IA embarqué, prend généralement 6 à 12 mois pour atteindre une qualité de production avec la bonne équipe. Les systèmes complets d’ADAS ou de conduite autonome sont des programmes pluriannuels. Le processus de sécurité fonctionnelle contribue de manière significative au calendrier et ne peut être compressé au-delà d’un certain point sans créer de risque de non-conformité.
Quelle pile technologique est utilisée pour le développement de logiciels IA automobiles ?
- Au niveau du véhicule : AUTOSAR (Classic et Adaptive), QNX ou Automotive Grade Linux, C et C++ avec des outils de conformité MISRA.
- Pour l’IA : PyTorch pour l’entraînement, TensorFlow Lite et ONNX Runtime pour l’inférence edge.
- Pour la connectivité : SOME/IP, DDS, MQTT et C-V2X pour la communication V2X.
- Les backends cloud s’exécutent sur les SDK automobiles AWS ou Azure avec une gestion OTA conforme à Uptane.
Découvrez comment nous avons aidé Mass Movement à lier ses actifs à J.B Hunt, entraînant une croissance de revenus de 2,74 milliards de dollars
