Aller directement au contenu
Commercial

L'équation de la disponibilité : pourquoi les plateformes automobiles ne peuvent pas se contenter du cloud

12 novembre 2026

Voici la troisième partie de « L'équation de la disponibilité ». Partie 1 traitait du contexte du véhicule, et la deuxième partie traitait du compromis entre matériel et logiciel. Cette partie aborde la question de savoir où le travail doit s'exécuter.

Un poids lourd traverse un tronçon d’autoroute où le signal mobile est interrompu. À un endroit de ce tronçon, un défaut électrique intermittent apparaît pendant 90 secondes, puis disparaît. Si la détection repose sur le cloud, deux scénarios sont possibles : soit l’événement n’est pas détecté, soit un instantané arrive avec du retard, une fois que les signaux pertinents ont déjà été écrasés. La prochaine fois que le problème se produira, il se peut que ce soit dans un atelier ne disposant d’aucun enregistrement des conditions qui l’ont provoqué auparavant.

Il s'agit de la version « sur le terrain » du problème de « re-drive » décrit dans « The Agentic Loop ». Ce phénomène se produit plus fréquemment sur les véhicules utilitaires, en raison de leur lieu et de leurs modalités d'exploitation.

La connectivité n'est pas une évidence

Les cartes de couverture sont optimistes. Dans une enquête menée en 2019 par le personnel de la FCC, les agents de terrain ont effectué 24 649 essais de couverture sur près de 10 000 miles dans 12 États. Seuls 62,3 % des essais ont atteint les débits de téléchargement prévus par les cartes des opérateurs. Les réseaux se sont améliorés depuis 2019, mais la leçon reste valable : une carte indiquant la couverture ne garantit pas qu’un camion disposera d’un signal au moment où une panne survient. Les engins hors route utilisés sur les sites miniers, les exploitations agricoles, les chantiers de construction et dans les ports opèrent dans des zones que les responsables de la couverture réseau priorisent rarement. Les flottes s’organisent déjà en conséquence. Les conducteurs attendent d’arriver dans une aire de stationnement pour envoyer leurs rapports, les techniciens extraient les données manuellement à l’arrivée d’un camion, et un camion qui cesse de communiquer sur la route est considéré comme un phénomène normal plutôt que comme un signal d’alerte. Chaque solution de contournement réduit le temps de disponibilité, et aucune d’entre elles ne permet de détecter une panne de 90 secondes sur un tronçon d’autoroute désert.

Cette incertitude fait du fonctionnement hors ligne une exigence de conception, et non plus seulement une solution de secours. Dans l'enquête de McKinsey sur l’ AI en périphérie dans le secteur automobile, 39 % des personnes interrogées ont cité la disponibilité hors ligne comme une exigence clé pour tous les cas d’utilisation de l’ AI , devant la faible latence (35 %) et la confidentialité et la sécurité des données (20 %). Seuls 6 % ont mentionné le coût des données réseau. L’intérêt de l’edge réside moins dans la facture de téléphonie mobile que dans ce que le cloud ne peut pas voir.

Volume : le problème, c'est le rapport signal/bruit, pas la facture de données

Les réseaux de véhicules utilitaires génèrent des données en continu. Un seul bus SAE J1939/14 peut fonctionner à un débit allant jusqu’à 500 kbit/s ; de nombreux poids lourds en intègrent plusieurs, et les plateformes les plus récentes intègrent l’Ethernet automobile, dont une grande partie achemine les flux vidéo des caméras destinés aux systèmes ADAS et aux dispositifs de sécurité. Sur une journée complète de conduite, cela représente bien plus de données qu’il n’est utile d’envoyer, et la plupart d’entre elles ne font que confirmer qu’aucun incident ne s’est produit.

Comme l' boucle agentique , la collecte de données en continu est « coûteuse à transmettre sur les réseaux mobiles, coûteuse à stocker et coûteuse à analyser ». L’alternative consiste à déterminer — directement dans le véhicule — quelles données sont pertinentes :

  • Capture déclenchée par un événement. Enregistrez les signaux avant et après un événement, plutôt que tout en permanence. Grâce aux Fastlane™ Edge Smart Triggers, par exemple, un modèle léger de détection d’anomalies installé sur le véhicule ne déclenche une politique d’ Fastlane™ Collector que lorsqu’il détecte un comportement anormal, tel qu’un moteur fonctionnant en dehors de sa plage normale ; ainsi, le véhicule capture les signaux liés à l’événement anormal plutôt qu’un flux continu.
  • Compression embarquée. Fastlane™ Collector Indique une réduction pouvant atteindre 28 fois la taille de la charge utile de données grâce à la compression de séries chronologiques.
  • Historique embarqué. Une base de données chronologique relative au véhicule conserve l'historique des signaux des dernières semaines ou des derniers mois. Si un dysfonctionnement survient dans une zone sans couverture, le contexte est toujours disponible lorsque le camion se reconnecte, et les ingénieurs peuvent extraire la période exacte dont ils ont besoin au lieu d'attendre que le dysfonctionnement se reproduise.
  • Filtrage avant le téléchargement. Envoyez des résultats synthétisés et pertinents plutôt que des flux bruts. Dans une étude de cas d’un partenaire portant sur la détection des intrusions à bord des véhicules, le traitement local et le téléchargement des seules alertes pertinentes ont permis de réduire les coûts liés au cloud de 60 %.

Latence : certaines décisions ne peuvent pas attendre

Certaines actions — protéger un composant, ajuster le fonctionnement d’un système, alerter un conducteur ou signaler une éventuelle cyberintrusion — doivent être effectuées en quelques secondes. Le véhicule s’impose donc comme le lieu naturel pour les traiter, même si la latence ne détermine pas à elle seule où l’intelligence doit être exécutée. McKinsey souligne que la périphérie n’offre pas toujours un avantage décisif en matière de latence. Pour de nombreux cas d’utilisation liés au diagnostic, la disponibilité et le contexte importent davantage que les millisecondes.

Cela n'enlève rien à l'importance du cloud. Il accomplit ce qu'un seul véhicule ne peut pas faire :

  • Détection de tendances à l'échelle de la flotte. Un mode de défaillance peut se manifester sous forme de bruit sur un seul camion et constituer un problème évident sur des milliers d'autres.
  • Analyse des causes profondes. Elle combine les données du véhicule avec les documents techniques, l'historique d'entretien et les cas antérieurs. Fastlane™ Insight Cette analyse s'effectue dans le cloud, à l'aide d'AI , qui permet de mettre en corrélation ces sources et de proposer des causes profondes probables.
  • Entraînement et validation du modèle. Cette étape utilise les événements riches en contexte capturés en périphérie.
  • Distribution. Les modèles et les politiques de collecte mis à jour sont transmis aux véhicules par liaison sans fil.

La périphérie détecte et collecte les données, le cloud analyse et apprend, puis la périphérie agit en fonction de ce que le cloud a appris. Fastlane™ Edge Le système s’articule autour de cette boucle : il effectue une détection des anomalies sur le véhicule et reçoit des modèles mis à jour par liaison radio à mesure que le cloud apprend. L’exécution de l’intelligence en périphérie réduit la dépendance à la connectivité, tandis que l’apprentissage à l’échelle de la flotte permet d’améliorer en permanence les véhicules déjà en circulation.

Fixer des limites

Une règle utile : effectuez le travail là où se trouvent les données et où la date limite doit être respectée.

Sur le véhicule Dans le cloud
Surveillance continue et détection des anomalies Détection de tendances au sein de la flotte
Capture déclenchée par un événement et historique embarqué Analyse des causes profondes à l'aide des données de service et d'ingénierie
Actions urgentes Entraînement et validation du modèle
Filtrage et synthèse avant le téléchargement Modèle et répartition des politiques

Si une décision dépend des données d’un seul véhicule à un instant donné, elle doit être traitée à bord du véhicule. Si elle dépend des données de plusieurs véhicules sur une période donnée, elle doit être traitée dans le cloud. La collecte de données contextuelles à bord du véhicule est également utile pour les flottes mixtes. Lorsque ces données sont structurées à la source à l’aide de définitions de signaux partagées telles que COVESA VSS, ces données peuvent parvenir au prestataire télématique de la flotte sous un format identique, quelle que soit la marque. Et les prévisions du marché indiquent que les équipementiers investissent dans ce modèle. GM Insights estime que les véhicules utilitaires représenteront 3,59 milliards de dollars du marché de l’edge computing automobile en 2025, avec une croissance d’environ 22 % par an.

Une fois que les terminaux périphériques ont saisi le contexte approprié, ces données constituent la matière première d’ AI s capables de prédire les pannes plutôt que de se contenter de les signaler. La quatrième partie aborde ce sujet.

En résumé : Les véhicules utilitaires ont besoin d’intelligence aux deux extrémités de la connexion. Le véhicule se charge de la détection, de la saisie du contexte et des actions urgentes. Le cloud se charge de l’apprentissage à l’échelle de l’ensemble de la flotte. Recommandation : confiez par défaut ces tâches au véhicule et réservez le cloud à tout ce qui nécessite les données de plusieurs camions. Concevez dès le départ ces deux éléments comme un cycle unique, afin que les modèles entraînés dans le cloud soient réinjectés dans les camions qui ont capturé les données. Une défaillance que le camion ne détecte pas est une défaillance qui réapparaîtra, et chaque réapparition réduit le temps de disponibilité.

Retour en haut de la page