Voici la deuxième partie de « L'équation de la disponibilité ». La première partie expliquait pourquoi il est nécessaire de collecter les données contextuelles directement sur le véhicule. Cette partie examine le coût d'une telle opération.
Une équipe chargée de la plateforme dispose d’un modèle capable de prédire les défaillances du système de post-traitement (contrôle des émissions) d’un camion plusieurs semaines avant qu’elles ne se produisent. La question technique est réglée. Ce n’est pas le cas de celle relative à la plateforme : où ce modèle va-t-il s’exécuter ? S’il peut s’intégrer à la passerelle ou au contrôleur télématique déjà présent dans le camion, il peut être déployé sur les programmes actuels. S’il nécessite un contrôleur plus performant, il devra attendre la prochaine architecture électrique/électronique (E/E) et ne sera jamais disponible sur les camions déjà en circulation.
C'est une question qui se pose à chaque nouveau cas d'utilisation des données et, dans le domaine des véhicules utilitaires, les aspects économiques qui sous-tendent la réponse diffèrent de ceux des voitures particulières à trois égards.
Pourquoi les calculs sont différents pour les camions ?
Volume. Les ventes au détail de camions de classe 8 aux États-Unis s'élevaient à 208 386 en 2025. Les ventes de véhicules légers neufs aux États-Unis s'élevaient à 16,2 millions, soit environ 78 fois plus. L’ajout des camions de poids moyen et des camions spécialisés réduit l’écart, mais ne le comble pas. Chaque dollar investi dans du matériel informatique supplémentaire, et chaque dollar dépensé pour l’intégration et la validation d’un nouveau contrôleur, est réparti sur une fraction des unités.
Durée de vie. Aux États-Unis, la durée de vie moyenne des poids lourds est de 12,1 ans en service. Les flottes conservent également leurs camions plus longtemps : selon les données d’ACT Research rapportées par FleetOwner indiquent que la durée moyenne de service d’un camion de classe 8 au sein d’une flotte est de 6,3 ans, soit la plus longue depuis 2013. Les nouveaux équipements informatiques, tels qu’une passerelle plus performante, un boîtier télématique ou un calculateur électronique (ECU), ne profitent qu’aux véhicules neufs. Le parc existant conserve le matériel d’origine pendant une décennie ou plus, et une grande partie de la valeur liée au temps de fonctionnement décrite dans la première partie réside dans ce parc existant.
Cycles d'évolution de l'architecture. Les architectures E/E des véhicules utilitaires sont renouvelées selon des cycles pluriannuels, et de nombreux contrôleurs proviennent de fournisseurs sur lesquels l'équipementier n'exerce pas un contrôle total. Un cas d'utilisation lié à un nouveau matériel informatique s'inscrit dans ce calendrier.
Pris dans leur ensemble, ces trois facteurs soulèvent une question cruciale : dans quelle mesure les capacités intelligentes dont un camion a besoin doivent-elles provenir de nouveau matériel, et dans quelle mesure peuvent-elles résulter d’une meilleure utilisation du matériel déjà en place ? Il existe deux façons de financer l’ AI embarquée. La première consiste à acheter des capacités. La seconde consiste à gagner en efficacité.
Première option : acquérir des capacités
Les arguments en faveur du matériel sont solides. Les architectures centralisées et zonales regroupent les charges de travail sur un nombre réduit de contrôleurs plus puissants et permettent de réduire le câblage. McKinsey souligne que, comme ces contrôleurs nécessitent davantage de puissance de calcul, ils peuvent entraîner des coûts supplémentaires. Les équipementiers de véhicules utilitaires s’orientent eux aussi dans cette direction. Coretura, la coentreprise entre Daimler Truck et le groupe Volvo lancée en 2025, développe une plateforme commune de véhicules définis par logiciel. Elle se chargera également de définir les spécifications et d’acquérir des contrôleurs centralisés haute performance pour les véhicules utilitaires, les premiers produits devant équiper des véhicules d’ici la fin de la décennie.
Un matériel de calcul plus performant, tel qu’un contrôleur central ou de zone haute performance ou un accélérateur dédié à l’ AI , constitue la solution idéale lorsque la charge de travail l’exige réellement : perception par caméra, systèmes d’aide à la conduite avancés (ADAS), conduite autonome, ou tout autre cas où la valeur ajoutée par véhicule sur toute sa durée de vie l’emporte clairement sur le surcoût lié à votre volume de production. Cela s’avère également judicieux lorsqu’une nouvelle plateforme est de toute façon en cours de conception.
Mais cette approche a ses limites. Elle ne concerne que les nouveaux véhicules, selon le calendrier de la plateforme. Et un contrôleur plus puissant ne rend pas superflu le recours à un logiciel efficace, car chaque tâche exécutée sur un ordinateur partagé entre en concurrence pour les mêmes ressources. Dans l’étude de McKinsey sur AI en périphérie dans le secteur automobile, 46 % des personnes interrogées ont cité les ressources limitées des systèmes sur puce comme un obstacle.
Deuxième piste : améliorer l'efficacité
La voie logicielle permet de tirer davantage parti du matériel déjà en place. Plusieurs techniques ont désormais atteint leur maturité :
- Compression de modèles. La quantification en nombres entiers rend les modèles environ 4 fois plus petits et 3 fois plus rapides avec une perte de précision minime. La combinaison de l'élagage et de la quantification réduit l'espace de stockage des modèles de 35 à 49 fois sans affecter la précision. McKinsey souligne que les microcontrôleurs sont de plus en plus capables d’exécuter des modèles d’ AI s légers en périphérie.
- Exécution à la demande. Un modèle peut être installé sur le véhicule sans fonctionner en permanence. Comme décrit dans « Les modèles d’ AI s toujours actifs sollicitent excessivement les ressources des véhicules utilitaires », un environnement d'exécution embarqué partagé peut maintenir en fonctionnement les modèles continus ou critiques pour la sécurité et n'activer les autres, tels que le contrôle de l'état de la batterie lors d'une session au dépôt, que lorsque les conditions du véhicule l'exigent.
- Collecte déclenchée par un événement et compression à bord du véhicule. Le véhicule stocke et envoie uniquement les données pertinentes liées à un événement, au lieu de diffuser l'intégralité des données en continu.
- Capteurs virtuels. Un logiciel peut estimer une valeur à partir des signaux déjà présents sur le réseau du véhicule, sans avoir à ajouter de capteur physique. Dans une étude de cas d’un partenaire, un capteur de réglage de la hauteur des phares, entièrement logiciel et basé sur les signaux CAN, a permis de réduire les coûts matériels de 20 dollars par véhicule. Dans ce cas précis, la solution logicielle ne se contente pas d’éviter d’ajouter des coûts liés à la nomenclature, elle les supprime purement et simplement.
Le principal avantage de cette approche logicielle dans le domaine des poids lourds réside dans sa portée. Elle peut être déployée à distance sur des véhicules déjà en service, dans les limites de leur capacité de calcul, et sur les programmes actuels, sans avoir à attendre la prochaine architecture. C'est le principe sur lequel repose Fastlane™ Edge, qui exécute des modèles d’ AI , des capteurs virtuels et des diagnostics prédictifs sur les ressources de calcul dont dispose déjà le véhicule, telles qu’une passerelle haute performance, une unité télématique ou un ordinateur central, sans nécessiter d’accélérateur d’ AI dédié. Lorsque les camions ne disposent pas encore de cette capacité de calcul, Fastlane™ Copilot ajoute une passerelle haute performance aux véhicules existants sans modifier leur architecture de série, que ce soit sur des prototypes ou dans des flottes d’essai.
Mais cela a aussi ses limites. Un logiciel ne peut pas transformer une passerelle en un ordinateur doté de capacités de perception. Il est limité par la puissance de calcul disponible, la mémoire et les efforts de validation, et il engendre ses propres coûts en matière de sécurité, de cybersécurité et de gestion du cycle de vie.
Considérez cela comme une seule et même décision
L'erreur consiste à traiter le matériel et les logiciels comme des budgets distincts. C'est l'efficacité du logiciel qui détermine la quantité de matériel dont vous avez besoin. Voici une démarche concrète pour les équipes chargées des plateformes :
- Commencez par optimiser, puis dimensionnez le matériel. Déterminez les besoins de la charge de travail après la compression et la conception déclenchée par les événements, et non avant.
- Demandez-vous où réside la valeur. Si celle-ci réside principalement dans le parc installé, la voie matérielle ne permet pas d'y accéder.
- Comparez la valeur au coût en fonction de votre volume de production. Évaluez la valeur par véhicule sur toute sa durée de vie par rapport aux coûts supplémentaires liés au matériel et à l'intégration, répartis sur vos chiffres de production réels.
- Prévoyez une marge de manœuvre en prévision de l'arrivée prochaine d'une nouvelle architecture. Prévoyez-la en partant du principe que des logiciels performants viendront l'occuper.
Les logiciels ont un coût qui leur est propre. Chaque modèle ajouté à un camion nécessite des ressources de calcul, de la mémoire, un travail d’intégration et une validation, et doit faire l’objet d’une maintenance pendant toute la durée de vie du véhicule. Le fait de n’exécuter les modèles qu’en cas de besoin et de partager un même environnement d’exécution entre eux permet d’éviter que ce coût n’augmente à chaque nouveau cas d’utilisation.
Une fois qu’une charge de travail est adaptée au véhicule, la question suivante est de savoir quelles tâches doivent y être exécutées et lesquelles doivent être traitées dans le cloud. Nous y reviendrons dans la troisième partie.
En résumé : La collecte d’informations contextuelles détaillées sur le véhicule et l’exécution d’ AI s à bord du véhicule ont un coût, et les équipementiers de véhicules utilitaires supportent ce coût sur une base de production bien plus réduite que celle des constructeurs de voitures particulières. Ils peuvent financer cela de deux manières : soit en ajoutant du matériel plus performant et en justifiant cet investissement par la valeur des données, soit en rendant le logiciel suffisamment efficace pour fonctionner sur la puissance de calcul dont dispose déjà le véhicule. La plupart adopteront ces deux approches. Mais les faibles volumes, les durées de vie de 12 ans et les longs cycles d’évolution des architectures impliquent que les équipementiers devraient privilégier le logiciel par défaut : exécuter les nouvelles charges de travail sur la puissance de calcul dont disposent déjà les camions, et n’ajouter du matériel de calcul que lorsque cela est nécessaire pour une charge de travail telle que la perception par caméra, ou lorsqu’une nouvelle architecture E/E est déjà en cours de conception.