Télématique embarquée pour les équipementiers : Le nouveau paysage des données de flotte connectées

Vous souvenez-vous de l'époque où l'installation de traceurs GPS sur chaque véhicule était le seul moyen de gérer votre flotte ? Cette époque est en train de disparaître rapidement du rétroviseur. Les véhicules d'aujourd'hui sortent des chaînes de montage déjà équipés de systèmes télématiques OEM sophistiqués, ce qui crée à la fois des opportunités intéressantes et des maux de tête inattendus pour les gestionnaires de flotte du monde entier.

En tant qu'opérateur de flotte ou fournisseur de services télématiques, vous vous posez certainement des questions : Que puis-je faire exactement avec cette technologie intégrée ? Quelle est la fiabilité des données ? Et, ce qui est peut-être le plus important, cela signifie-t-il que je peux enfin dire adieu aux installations de matériel d'après-vente ? Ce ne sont pas des questions simples, surtout lorsque vous jonglez avec des véhicules de plusieurs constructeurs, chacun parlant son propre langage numérique.

Dans cette étude approfondie, nous décoderons le fonctionnement de la télématique des équipementiers, nous explorerons les données que vous pouvez vous attendre à recevoir (des véhicules à essence aux véhicules électriques) et nous nous attaquerons aux défis très réels que représente la transformation de ces informations fournies par les constructeurs en informations exploitables pour votre entreprise. Nous mettrons également en lumière la manière dont Navixy comble les lacunes avec des solutions adaptées à cette nouvelle réalité connectée.

D'OnStar à tout le monde : La télématique des équipementiers se mondialise

Il y a quelques décennies, la technologie des voitures connectées, comme OnStar de GM, était un accessoire de luxe ; aujourd'hui, la télématique embarquée équipe les flottes du monde entier. En fait, trois voitures sur quatre vendues en 2023 seront équipées d'un système télématique installé par l'équipementier. Ce matériel intégré (généralement une unité de contrôle télématique dotée d'un modem cellulaire et d'un GPS) permet aux véhicules de transmettre des données directement au nuage du fabricant. Ce qui était autrefois une nouveauté est aujourd'hui un courant dominant : pratiquement tous les grands constructeurs automobiles disposent d'une plateforme de véhicule connecté, et l'adoption est fulgurante sur les marchés clés.

L'essor ne se limite pas aux voitures. Les flottes commerciales et les équipements tout-terrain sont de plus en plus "connectés de naissance". Tous les grands constructeurs de camions en Europe, par exemple, proposent désormais des solutions télématiques pour les équipementiers dans le cadre de leur portefeuille de produits. En Chine, des équipementiers nationaux comme BYD, NIO, Geely et SAIC intègrent à leurs véhicules des systèmes télématiques avancés et même des écosystèmes d'applications embarquées, sous l'impulsion d'une clientèle férue de technologie et d'initiatives gouvernementales en faveur du partage des données. Il en résulte un boom des véhicules connectés: les flottes d'aujourd'hui peuvent comprendre des berlines qui communiquent leur niveau de carburant au nuage, des semi-remorques qui téléchargent des statistiques sur l'état du moteur en temps réel et des excavatrices qui transmettent leurs heures de fonctionnement à un portail de gestion de l'équipement.

Pourquoi cette croissance explosive ? Les constructeurs automobiles reconnaissent que les données sont de l'or - pour eux et pour leurs clients. Les flottes peuvent prendre des décisions rentables, fondées sur des données, et rationaliser leurs opérations lorsqu'elles ont un aperçu direct des performances des véhicules. Les équipementiers y voient une chance de différencier leur produit (une voiture "prête pour les flottes") et de générer de nouveaux revenus en offrant des services télématiques. En bref, la voiture connectée est passée d'un facteur de différenciation à une caractéristique indispensable, avec des forces commerciales et réglementaires qui la poussent en avant. Une analyse du secteur a résumé la tendance des données télématiques des équipementiers en ces termes : "plus ! "plus !" - plus de véhicules connectés, plus de données collectées, plus d'applications activées.

Qu'est-ce que la télématique embarquée ? (et en quoi elle diffère de l'après-vente)

Clarifions les définitions. La télématique embarquée OEM fait référence au matériel et au logiciel télématiques intégrés dans un véhicule en usine. Pensez à une "boîte noire" ou à un modem caché dans votre voiture qui enregistre automatiquement les données et se connecte à l'internet. Ces dispositifs se distinguent des dispositifs télématiques d'après-vente, c'est-à-dire les traceurs GPS ou les clés électroniques OBD-II que les flottes peuvent installer dans n'importe quel véhicule. Ces deux types de dispositifs ont un objectif similaire (recueillir des données sur le véhicule et les envoyer à un serveur), mais leur origine et leur intégration diffèrent grandement.

Lessystèmes embarqués des équipementiers font partie intégrante de la conception du véhicule. Le constructeur automobile installe le module et l'intègre au bus CAN et aux capteurs du véhicule. Cette intégration étroite permet d'accéder à des données plus approfondies, spécifiques au véhicule, que des dispositifs tiers pourraient ne pas avoir. Elle signifie également qu'aucune installation n'est nécessaire après l'achat - un nouveau véhicule de flotte peut être activé à distance en quelques heures au lieu de passer des jours à câbler des unités du marché secondaire dans des douzaines de camions. Par conséquent, la télématique des équipementiers élimine les temps d'arrêt liés à l'installation du matériel et est prête à l'emploi pour une visibilité instantanée de la flotte.

Cependant, la télématique du marché secondaire a ses propres atouts. Les dispositifs des fournisseurs indépendants sont indépendants de la marque - une seule plateforme peut connecter des flottes mixtes de Ford, Toyota, Freightliners, etc. En revanche, les solutions des équipementiers ont toujours été cloisonnées par marque (les données de Ford sur le portail de Ford, celles de GM sur le portail de GM, etc. ), ce qui n'est pas pratique pour les flottes mixtes de plusieurs marques. Une entreprise de camionnage possédant cinq marques de camions différentes aurait besoin de cinq tableaux de bord télématiques OEM différents, ce qui n'est pas une bonne chose pour l'efficacité des opérations. Les systèmes du marché secondaire permettent d'unifier tous les véhicules sous un même toit. Ils sont également exempts de tout conflit d'intérêts - un fournisseur de services télématiques indépendant vous dira volontiers de réduire votre flotte pour la rendre plus efficace, alors qu'un équipementier ne se précipitera peut-être pas pour vous informer que vous pourriez réduire votre flotte (il préfère vendre plus de camions !).

Aujourd'hui, ces lignes s'estompent. De nombreux équipementiers se rendent compte qu'ils doivent jouer le jeu dans les flottes mixtes, et certains s'associent à des plates-formes indépendantes ou offrent un soutien intermarques. Par exemple, le programme télématique de Ford permet même d'installer son dispositif dans des véhicules d'autres marques afin d'unifier les données de la flotte sur la plateforme Ford. De même, les plateformes télématiques telles que Navixy construisent des connecteurs et adoptent des normes (comme le protocole générique Navixy, NGP) afin d'ingérer les données des équipementiers en même temps que les dispositifs du marché secondaire de manière transparente. L'objectif final est un écosystème unifié où peu importe que les données proviennent d'un module intégré ou d'un dispositif enfichable, elles parleront toutes le même "langage" sur la plateforme. Le NGP de Navixy, par exemple, agit comme un traducteur universel, normalisant des centaines de protocoles propriétaires en un seul format. De cette manière, le fournisseur de solutions télématiques simplifie l'intégration et s'assure que le paquet de données, qu'il provienne d'un modem BMW intégré ou d'un tracker tiers, est traité de manière uniforme.

Protocoles télématiques : tous ces véhicules parlent-ils la même langue ?

L'un des obstacles techniques de la télématique est la multiplicité des protocoles. Historiquement, chaque équipementier a développé sa propre façon d'encoder et de transmettre les données - en fait, chacun parle un dialecte différent. Les protocoles télématiques englobent à la fois la communication des données à l'intérieur du véhicule (comment les signaux du moteur, des freins, de la batterie, etc. sont regroupés) et la communication avec le serveur (comment l'appareil envoie des données sur les réseaux cellulaires vers le nuage).

À l'intérieur du véhicule, les données sont souvent collectées via le bus CAN (Controller Area Network) - le réseau interne du véhicule qui transmet les signaux de dizaines d'unités de contrôle électronique (ECU). L'unité télématique de l'équipementier écoute les paramètres pertinents (vitesse, niveau de carburant, codes d'erreur, etc.) sur le bus CAN. Le choix des paramètres à envoyer et leur fréquence dépendent de la logique de chaque équipementier. Pour la transmission, de nombreux dispositifs embarqués utilisent des liaisons de données cellulaires standard et des protocoles courants tels que HTTPS ou MQTT pour envoyer des données vers le nuage. Cependant, le schéma de données - la structure et la dénomination des données - varie considérablement. Par exemple, l'API d'un équipementier peut désigner un compteur kilométrique par "Odo" en kilomètres, celle d'un autre par "Mileage" en miles ; l'un envoie un simple booléen pour l'état de la serrure de la porte, l'autre un code enum. Le manque de normalisation est un casse-tête pour les FST : l'intégration de cinq API d'équipementiers peut donner l'impression de construire cinq systèmes distincts.

Des efforts de normalisation sont en cours. Dans le passé, des consortiums ont tenté de créer des cadres télématiques communs (par exemple, le NGTP - Next-Generation Telematics Protocol - lancé par les équipementiers européens). Plus récemment, des groupes industriels comme COVESA (Connected Vehicle Systems Alliance) ont proposé des modèles de données standard (par exemple, Vehicle Signal Specification). Mais l'adoption est lente - les équipementiers ont tendance à donner la priorité à leurs propres écosystèmes. Par conséquent, les agrégateurs et les plateformes comblent le fossé en traduisant ces différents "langages". L'approche de Navixy avec NGP est l'une de ces solutions : au lieu d'alimenter des protocoles bruts et disparates en amont, les appareils (ou les passerelles IoT) convertissent tout en schéma NGP, que la plateforme traite ensuite de manière uniforme. Cela réduit considérablement la charge d'intégration et garantit des définitions de données cohérentes (ainsi, "engine_speed" signifie la même chose qu'il provienne d'une Toyota ou d'une Tesla).

Pour un gestionnaire de flotte ou un fournisseur de services télématiques, la conclusion est que même si les véhicules ne parlent pas nécessairement la même langue, les plateformes télématiques modernes servent de traducteurs en temps réel. L'époque où il fallait jongler avec plusieurs analyseurs de protocole et des mappages de données personnalisés est révolue. Avec des outils comme IoT Logic et Data Stream Analyzer de Navixy, vous pouvez définir des transformations de données et vérifier facilement les flux de données, en vous assurant qu'un événement "Allumage du véhicule activé" provenant de n'importe quelle source déclenche la même alerte en aval. Il est difficile de gérer des milliers de véhicules si chaque sous-ensemble parle un dialecte différent. Une couche de protocole normalisée transforme une cacophonie de données en une symphonie cohérente.

De la jauge de carburant à l'état de la batterie : les attributs des données pour tous les types de véhicules

L'une des grandes promesses de la télématique des équipementiers est la richesse des données spécifiques aux véhicules. Que peuvent donc nous apporter exactement ces systèmes embarqués ? En fait, beaucoup de choses, mais cela dépend du type de véhicule (essence, hybride, électrique) et de l'offre du constructeur. Voyons cela en détail :

• Données de base communes (tous les véhicules). Presque toutes les unités télématiques des équipementiers fournissent un ensemble de données de base comprenant la position GPS du véhicule (latitude/longitude), la vitesse et le cap, l'état de l'allumage (marche/arrêt) et, souvent, le kilométrage. Vous obtiendrez également le niveau de carburant pour les véhicules à combustion ou l'état de charge (% de la batterie) pour les véhicules électriques. L'altitude, l'horodatage et le numéro d'identification du véhicule (VIN) sont également inclus. Ces données de base sont extrêmement utiles : les flottes peuvent savoir où se trouvent les véhicules, quelle distance ils ont parcourue et quelles sont leurs réserves de carburant et d'énergie, le tout sans matériel supplémentaire.
• Données sur les véhicules à essence/diesel. Outre la localisation et le carburant, les véhicules à moteur à combustion interne (ICE) peuvent communiquer des données moteur telles que le régime, la température du liquide de refroidissement, la durée de vie restante de l'huile et les codes de diagnostic de panne (DTC) à partir de l'unité de contrôle du moteur. Les API des équipementiers exposent souvent certains de ces diagnostics afin que vous sachiez si le témoin de contrôle du moteur est allumé et pourquoi. Le taux de consommation de carburant ou le MPG moyen, la position de l'accélérateur et même les relevés du compteur kilométrique provenant directement du véhicule (qui sont plus fiables pour la programmation de l'entretien) peuvent être accessibles. Certains équipementiers fournissent des alertes d'entretien - par exemple, le système OnStar de GM peut signaler la durée de vie de l'huile et la pression des pneus ; certains modèles européens peuvent même indiquer si les plaquettes de frein ou le liquide de frein ont besoin d'être entretenus. Ces données permettent aux gestionnaires de flotte de programmer l'entretien de manière proactive.
• Données sur les véhicules hybrides. Les véhicules hybrides offrent les deux mondes - données sur le carburant et sur la batterie. La télématique peut indiquer non seulement le niveau du réservoir de carburant, mais aussi la charge de la batterie, si le véhicule est en mode EV et les avertissements du système hybride. Par exemple, une Toyota hybride peut vous indiquer l'état de charge de la batterie et si le moteur est en marche ou s'il s'est arrêté automatiquement. Cela peut aider à mesurer la consommation de carburant par rapport à la consommation d'électricité dans les véhicules hybrides et à comprendre leurs performances. La plupart des données sous-jacentes (comme les codes défaut ou les informations d'entretien) sont similaires à celles des véhicules à combustion, avec quelques champs supplémentaires pour les composants de la transmission électrique.
• Données relatives aux véhicules électriques (VE). Les VE ont tendance à diffuser une multitude d'informations par le biais de la télématique, ce qui est essentiel car les flottes doivent gérer l'autonomie et la recharge. Les attributs clés spécifiques aux VE comprennent l'état de charge (SoC) de la batterie (%), l'état de charge (en charge, non en charge, branché ou non), le taux de charge et l'autonomie estimée (miles ou km restants). De nombreux VE indiquent également les paramètres de santé de la batterie (comme le nombre total de kWh disponibles, ou si certaines cellules de la batterie sont faibles) et l'historique de la charge. Certaines API d'équipementiers pour VE incluent même des détails sur les sessions de charge (heures de début et de fin, énergie ajoutée), ce qui est très utile pour suivre les coûts du carburant électrique. La température de la batterie et l'activation de la gestion thermique peuvent être disponibles sur certains modèles. En bref, la télématique des VE va au-delà de la localisation pour fournir une jauge de carburant presque en temps réel et un journal de ravitaillement (charge) pour les flottes électriques. Un gestionnaire de flotte peut vérifier à distance si une camionnette électrique a suffisamment de charge pour la prochaine équipe ou si elle est actuellement branchée et dans combien de temps elle sera pleine.
• Données avancées et de niche. Au-delà des données de base, les équipementiers ajoutent continuellement de nouveaux points de données à leurs API, mais pas toujours de manière cohérente. Certaines voitures européennes haut de gamme offrent des données télémétriques sur le comportement de conduite (par exemple, si le contrôle de stabilité a été activé, les freinages brusques, etc.), des données environnementales (température extérieure, état des essuie-glaces, ce qui peut signifier qu'il pleut, etc. Les données relatives à l'entretien peuvent inclure des rappels d'entretien détaillés (usure des plaquettes de frein, dates de vidange d'huile, etc.) Les camions électriques ou les véhicules spécialisés peuvent fournir des données sur les systèmes auxiliaires (par exemple, la télématique d'un camion frigorifique pourrait indiquer l'état de l'unité frigorifique par l'intermédiaire de l'équipementier si elle est intégrée). La télématique des machines industrielles (provenant des systèmes OEM sur les bulldozers ou les tracteurs) comprend souvent les heures de fonctionnement du moteur, la pression hydraulique, le poids de la charge utile, et plus encore - adaptés aux cas d'utilisation de l'équipement.

Il convient de noter que la disponibilité des données varie considérablement d'un fabricant à l'autre et d'un modèle à l'autre. Une marque peut divulguer les données relatives à la pression des pneus, une autre non ; une marque peut permettre la récupération de l'état des ceintures de sécurité (pour le suivi de la sécurité), d'autres gardent ces données confidentielles. Par conséquent, les flottes doivent identifier les points de données dont elles ont réellement besoin et vérifier l'assistance des équipementiers avant d'acheter des véhicules. Si un équipementier ne fournit pas un point de données essentiel (par exemple, si vous souhaitez vraiment connaître la pression des pneus en temps réel pour des raisons de sécurité), vous devrez peut-être installer un capteur ou un dispositif télématique en deuxième monte pour l'obtenir.

Enfin, il existe une catégorie de données qui n'est pas (généralement) disponible via les systèmes télématiques des constructeurs : les commandes à distance et les données des capteurs à haute fréquence. Pour des raisons de sécurité, la plupart des constructeurs automobiles sont prudents lorsqu'il s'agit d'autoriser des commandes à distance telles que le déverrouillage des portes ou le démarrage du moteur par l'intermédiaire de leurs API publiques. Seuls quelques-uns (Tesla, certaines marques de Stellantis) ont commencé à autoriser de telles actions pour une utilisation en flotte. De même, les données lorsque le véhicule est éteint ou hors couverture cellulaire constituent un angle mort - de nombreuses unités OEM ne mettent pas en mémoire tampon et ne téléchargent pas ultérieurement, de sorte que si une voiture est arrêtée, vous risquez de perdre le suivi de la localisation jusqu'à ce qu'elle soit remise en marche. Les unités télématiques dédiées du marché secondaire disposent souvent d'une mémoire interne permettant de stocker les données pendant les pannes et de les transférer une fois la connexion rétablie, ce dont les systèmes OEM sont actuellement dépourvus. Nous reviendrons sur ces lacunes dans la section consacrée aux défis, mais il s'agit d'une mise en garde importante lorsque l'on considère l'exhaustivité des données des équipementiers.

Quand et à quelle fréquence les véhicules "téléphonent-ils à la maison" ?

Disposer d'un grand nombre de données est une bonne chose, mais à quelle fréquence les systèmes des équipementiers nous les transmettent-ils ? La fréquence des rapports (ou latence des données) est un facteur critique, en particulier pour les cas d'utilisation tels que le suivi en temps réel ou la surveillance du comportement du conducteur. Ici, la télématique embarquée montre parfois ses racines conservatrices, orientées vers le consommateur : Les équipementiers accordent souvent la priorité à la réduction de l'utilisation des données et de l'épuisement de la batterie, de sorte qu'ils peuvent envoyer des données moins fréquemment que ne le feraient des dispositifs télématiques de flotte classiques.

Un système télématique OEM typique peut mettre à jour l'état du véhicule une fois toutes les minutes ou toutes les deux minutes lorsque le contact est mis. Dans certains cas, les mises à jour peuvent être encore moins fréquentes (par exemple, une toutes les 5 minutes) ou basées sur des événements (envoi lorsque le contact est mis ou coupé, envoi lorsque le niveau de carburant change de X, etc.) En revanche, de nombreux systèmes de suivi de flotte du marché secondaire peuvent être configurés pour des intervalles de 10 à 30 secondes ou même pour une fréquence plus élevée avec un flux continu, par exemple pour la reconstitution d'un accident.

Pourquoi cet écart ? Les systèmes OEM ont été historiquement conçus pour des cas d'utilisation tels que les interventions d'urgence (qui ne nécessitent pas une fréquence élevée), les diagnostics à distance ou le suivi de véhicules volés - des scénarios où la minute par minute est généralement suffisante. En outre, les données cellulaires coûtent cher ; un constructeur automobile offrant des services connectés gratuits pendant cinq ans par voiture, par exemple, essaiera d'éviter une configuration gourmande en données. C'est pourquoi il réduit souvent la fréquence afin de trouver un équilibre entre le coût et l'utilité.

Cela dit, la situation s'améliore. Certains équipementiers proposent désormais des options de données à "haute fréquence", avec des mises à jour aussi rapides que toutes les 30 secondes, en particulier dans le cadre des offres API premium pour les flottes. Par exemple, l'API télématique pour flotte de BMW peut fournir des mises à jour de localisation toutes les 30 secondes lorsque la voiture est en mouvement, ce qui est suffisant pour de nombreux besoins de suivi. Tesla, connue pour être une marque à la pointe de la technologie, diffuse effectivement des données presque en continu lorsque ses véhicules sont en mouvement (c'est ainsi que les applications tierces pour Tesla peuvent indiquer la localisation presque en temps réel).

Il est également courant que l'état de l'allumage dicte la fréquence des rapports : lorsque le véhicule est éteint, de nombreux systèmes OEM se contentent d'un programme très restreint (ou n'émettent aucun rapport). Certains peuvent envoyer une requête toutes les quelques heures pour connaître l'état du véhicule, ou seulement en cas de changement (par exemple, si une porte s'ouvre alors que le véhicule est garé, une alerte peut être envoyée). Lorsque le véhicule est en marche, ils passent au rythme actif (par exemple, toutes les minutes). Si un système OEM détecte un incident (déploiement d'un airbag, accident), il enverra généralement une notification d'urgence immédiate, quel que soit l'intervalle.

Pour les VE, la fréquence peut dépendre du fait qu'ils soient branchés ou non. Pendant les sessions de charge, certains envoient des mises à jour fréquentes (pour actualiser le pourcentage de charge) ; d'autres se contentent de signaler le début et la fin de la charge.

En résumé : La télématique des équipementiers n'est généralement pas aussi granulaire que les systèmes de suivi de flotte spécialisés. Mais si votre cas d'utilisation peut tolérer, par exemple, de connaître la position d'un camion dans la dernière minute plutôt que dans les 10 dernières secondes, les données des équipementiers peuvent fonctionner. Si vous avez besoin d'une résolution plus élevée (peut-être pour évaluer le comportement du conducteur, par exemple en cas de freinage brusque, ou pour les calculs d'assurance basés sur l'utilisation), vous devrez peut-être compléter avec des capteurs supplémentaires ou espérer que l'équipementier fournisse des données déclenchées par des événements. Certaines API d'équipementiers proposent des indicateurs d'événements - par exemple, une alerte "freinage brusque" avec horodatage - même si elles ne fournissent pas d'enregistrements de vitesse seconde par seconde. Ces alertes peuvent être extrêmement utiles : au lieu de passer au crible des données à haute fréquence, vous obtenez une alerte distillée.

La plateforme de Navixy aide à combler les lacunes en permettant des configurations hybrides : vous pouvez utiliser les données de l'équipementier pour 90 % de vos besoins, mais aussi attacher un capteur bon marché du marché secondaire pour des mesures spécifiques à haute fréquence, le tout étant canalisé dans le même système. De plus, des fonctions comme IoT Logic de Navixy peuvent simuler des informations à plus haute fréquence - par exemple, si vous obtenez une localisation par minute, la plateforme peut interpoler ou se caler sur les routes pour une visualisation plus fluide. L'outil Data Stream Analyzer peut surveiller si les données ne sont pas reçues aussi souvent qu'elles le devraient (disons un "battement de cœur" attendu toutes les 60 secondes - il vous signalera si, soudainement, rien n'est arrivé pendant 5 minutes, ce qui indiquerait une panne ou un problème). En fait, comme les véhicules téléphonent sporadiquement, la plate-forme télématique agit comme une bonne réceptionniste : si l'appel n'arrive pas à temps, elle s'en aperçoit et peut prendre des mesures (alerte ou mise en mémoire tampon de données provenant d'autres canaux).

La qualité des données est importante : précision, exhaustivité et actualité

Tout ce qui brille n'est pas de l'or, et toutes les données télématiques des équipementiers ne sont pas parfaites. Les problèmes de qualité des données - qui vont de l'exactitude des valeurs à l'exhaustivité de l'ensemble des données - sont des défis courants que rencontrent les gestionnaires de flotte. Passons en revue quelques problèmes clés et la manière dont ils se manifestent :

• Précision. Il peut s'agir de la précision des capteurs ou de l'exactitude des données rapportées. Par exemple, les relevés de niveau de carburant sont notoirement délicats - le capteur à flotteur dans le réservoir peut n'avoir qu'une estimation à 5 % près et peut être affecté par l'inclinaison du véhicule. Certains systèmes télématiques des équipementiers indiquent le niveau de carburant sous la forme d'un nombre entier (0-100 %) qui peut sauter par morceaux, ce qui donne une image grossière. La précision du GPS est un autre facteur : si un appareil OEM n'utilise que le GPS et pas les nouveaux GNSS ou l'augmentation, vous pouvez constater une dérive de la position de plusieurs mètres. La vitesse indiquée par le GPS et celle indiquée par les capteurs de roues du véhicule peuvent différer légèrement. Il y a également des erreurs de conversion d'unités occasionnelles - une API OEM peut vous donner un odomètre en miles, une autre en km, et si vous ne vous en rendez pas compte, vous penserez qu'une voiture a parcouru 60 "unités" alors qu'il s'agit en fait de 60 miles contre 60 km (une erreur d'environ 1,6x). Il est donc essentiel de veiller à la cohérence (et à la conversion des unités). Le NGP de Navixy y contribue en normalisant les unités et les formats entre les appareils, de sorte que vous obtenez toujours, par exemple, des kilomètres et des litres, sauf indication contraire. En outre, la précision des données de diagnostic (comme la température du moteur ou la pression des pneus) dépend de l'étalonnage des capteurs ; en général, les capteurs OEM sont assez bons, mais si les données semblent erronées (par exemple, un régime moteur irréaliste), il peut s'agir d'un problème d'analyse ou d'un défaut du capteur. En tant que FST, vous devez souvent mettre en place une logique pour vérifier les données entrantes et signaler les anomalies.
• Complétude. Nous l'avons évoqué précédemment : les lacunes dans les données sont une réalité dans de nombreuses configurations OEM. Imaginez qu'un véhicule de flotte entre dans un parking souterrain (sans signal cellulaire), puis parcourt 80 km avant de sortir de la zone de couverture. Si le système télématique de l'équipementier ne stocke pas les données hors ligne, l'intégralité de ce trajet risque de ne pas figurer dans vos dossiers. Vous verrez simplement le véhicule passer du point A au point B sans aucune information entre les deux. Pour les flottes où le suivi des itinéraires ou l'enregistrement des trajets sont importants, c'est un véritable casse-tête. De même, si un véhicule est mis hors tension, de nombreux systèmes OEM ne signalent rien ; ils se mettent essentiellement en veille. Par conséquent, si quelqu'un remorque le véhicule ou s'il est volé alors qu'il est éteint, vous risquez d'en perdre la trace. Les dispositifs de seconde monte disposent souvent de batteries de secours internes et se réveillent en cas de mouvement pour signaler les événements même si le véhicule est éteint - les dispositifs d'origine ne le font souvent pas, pour éviter de décharger la batterie du véhicule. La rapidité d'exécution est également importante : même si des données sont collectées, à quelle vitesse les obtenez-vous ? Si une solution OEM n'envoie les données qu'après les avoir accumulées pendant quelques minutes, il y a un retard. La plupart des solutions sont relativement en temps réel, mais certaines peuvent regrouper les données pour réduire les frais généraux. Par exemple, un dispositif OEM peut collecter des données toutes les 15 secondes, mais ne les transmettre au nuage que toutes les 60 secondes, sous la forme d'un paquet de quatre points. En général, cela ne pose pas de problème, mais cela signifie que vous ne recevrez pas immédiatement une alerte d'accident au bout de 0 seconde - elle pourrait arriver une minute plus tard, ce qui, en termes de sécurité, peut s'avérer critique.
• Latence et gigue. Il s'agit du délai entre le moment où quelque chose se produit et le moment où vous en êtes informé, ainsi que de la cohérence de ce délai. Si un conducteur met le contact, votre plateforme le répercute-t-elle en quelques secondes ou seulement lors de la mise à jour de la minute suivante ? L'intervalle de mise à jour est-il cohérent ou est-il parfois de 30 secondes, parfois de 2 minutes (gigue) en raison de la variabilité du réseau ? En règle générale, les données des équipementiers peuvent avoir un peu plus de latence qu'un dispositif direct alimentant une plate-forme parce qu'elles vont du véhicule au serveur de l'équipementier, puis à l'agrégateur et enfin à votre plate-forme. Chaque saut ajoute un délai. De nombreuses API des équipementiers sont basées sur l'interrogation: votre système peut avoir à demander de nouvelles données au serveur de l'équipementier, disons, toutes les 60 secondes. Si les données ont manqué la fenêtre d'interrogation, vous devez attendre une minute de plus. Certaines intégrations plus récentes sont pilotées par les événements ou basées sur la poussée, ce qui améliore la latence. Les FST doivent être conçus de manière à pouvoir tolérer un certain décalage. Par exemple, la plateforme de Navixy peut ingérer à la fois des flux instantanés de dispositifs et des flux API plus lents ; en utilisant son analyseur de flux de données, on peut mesurer la fraîcheur des données de chaque source et générer des alertes si quelque chose est périmé (par exemple, "le véhicule n'a pas été mis à jour depuis 5 minutes").
• Cohérence et fiabilité. Les services télématiques des équipementiers peuvent occasionnellement connaître des pannes ou des bizarreries. Il se peut que le nuage du constructeur automobile soit en maintenance, ou que les données d'un nouveau modèle de véhicule soient livrées dans un format légèrement différent de celui qui a été documenté. Cela peut entraîner des pertes de données ou des erreurs d'analyse. Un autre facteur est l'exhaustivité des champs - un jour, vous pouvez obtenir un point de données (par exemple, la tension de la batterie), et le lendemain, ce champ est nul pour une raison quelconque dans l'API. Cela peut être dû à une mise à jour du micrologiciel du véhicule ou à un changement de version de l'API. Une solution robuste doit gérer les champs manquants avec élégance et éventuellement essayer de les récupérer plus tard. Le stockage des données brutes est une excellente pratique dans ce cas : L'entrepôt de données brutes de Navixy, par exemple, conserve tous les messages entrants bruts dans tous leurs détails. Si quelque chose semble louche dans les données traitées, les ingénieurs peuvent fouiller dans les journaux bruts pour voir si, par exemple, le véhicule a cessé d'envoyer un paramètre particulier ou s'il n'y en a jamais eu. Ces archives historiques brutes sont d'une aide précieuse pour résoudre les problèmes de précision des données - c'est un peu comme si vous disposiez d'une boîte noire pour enregistrer les données de votre flotte.

En résumé, si la télématique des équipementiers fournit des données précieuses, il ne s'agit pas toujours d'un flux parfaitement propre. Une gestion intelligente de la flotte implique de filtrer et de compenser : utiliser la logique de la plateforme pour combler les lacunes (interpoler ou supposer la dernière valeur connue), procéder à des vérifications croisées (comparer le compteur kilométrique à la distance GPS pour détecter les réinitialisations ou les erreurs du compteur kilométrique) et alerter sur les anomalies (une chute du niveau de carburant de 50 % à 0 % en une minute peut signifier une défaillance du capteur... ou un vol de carburant). Relever ces défis en matière de qualité des données fait partie du voyage - et avec des outils appropriés, il est possible de transformer les données brutes des équipementiers en informations fiables et exploitables.

L'Europe et la Chine à l'avant-garde : Tendances télématiques des équipementiers par région

La télématique embarquée est peut-être un phénomène mondial, mais les tendances régionales et les stratégies des constructeurs diffèrent, en particulier en Europe et en Chine. Ces deux plaques tournantes ont mené la charge en matière de connectivité, mais pour des raisons différentes.

EUROPE : Les constructeurs automobiles européens ont été les premiers à adopter la technologie connectée pour la sécurité et la différenciation des services. Le règlement eCall de l'UE, qui est entré en vigueur en 2018, exigeait que toutes les nouvelles voitures aient la capacité d'appeler automatiquement les services d'urgence en cas d'accident. Cela signifie essentiellement que chaque nouvelle voiture doit être équipée d'une unité télématique connectée à un réseau cellulaire (même s'il s'agit d'une unité très basique). Le taux d'équipement télématique des voitures neuves en Europe atteindra ainsi environ 90 % d'ici à 2023, contre 91 % en Amérique du Nord. Les équipementiers européens tels que BMW, Mercedes-Benz, Audi/VW et Volvo proposent des services de voiture connectée (déverrouillage des portes à distance, applications sur l'état du véhicule, conciergerie, etc. Ils ont également lancé des programmes spécifiques aux flottes : par exemple, Mercedes a Daimler Fleetboard (pour les camions) et Mercedes PRO pour les fourgonnettes, BMW a lancé une plateforme CarData et des API de flotte pour les entreprises clientes, et Volkswagen a introduit We Connect Fleet. Un concept européen notable est le modèle du "véhicule étendu", dans lequel l'équipementier joue le rôle de gardien des données du véhicule, en les fournissant à des tiers par l'intermédiaire d'API dans le nuage (au lieu d'autoriser l'accès direct à l'OBD-II). Cette approche, défendue par des organisations telles que l'ACEA, était censée résoudre le problème de la cybersécurité en faisant passer tous les accès par le backend de l'équipementier. Il en résulte que les fournisseurs de services indépendants doivent s'interfacer avec le nuage de chaque équipementier pour obtenir des données, ce qui peut s'avérer fastidieux, mais c'est précisément la raison pour laquelle des agrégateurs ont vu le jour en Europe afin de simplifier cette démarche.

Les flottes européennes sont également soumises à des lois strictes en matière de protection des données (GDPR), ce qui signifie que le consentement du conducteur et la protection de la vie privée sont primordiaux. Dans de nombreux pays européens, même si une entreprise est propriétaire du véhicule, le conducteur doit consentir au partage des données qu'il contient. Les équipementiers ont donc intégré la gestion du consentement dans leurs flux de travail. Par exemple, une flotte peut avoir à télécharger un formulaire de consentement signé par le conducteur vers l'équipementier avant que les données ne circulent - une étape supplémentaire qui n'est pas aussi courante aux États-Unis.

Sur le plan technologique, l'Europe connaît une forte normalisation du backend. De nombreux équipementiers européens se sont associés à des plateformes telles que High Mobility, Targa Telematics ou la plateforme Car Data de Munich Re, afin d'offrir des API à guichet unique pour plusieurs marques. C'est le signe d'une tendance : plutôt que de réinventer la roue, chaque équipementier pourrait utiliser des interfaces communes pour les tiers. Par ailleurs, l'accent mis par l'Europe sur le développement durable et l'efficacité signifie que les données télématiques sont exploitées pour réduire les émissions et améliorer la logistique (par exemple, en utilisant les données pour optimiser les itinéraires et réduire les temps morts). Nous constatons également que le système d'exploitation Android Automotive OS progresse dans les voitures européennes (Volvo et Renault adoptent la plateforme de Google), ce qui pourrait à terme brouiller les frontières entre l'infodivertissement et les données télématiques - bien que cela ait principalement un impact sur les fonctions orientées vers l'utilisateur pour l'instant.

CHINE : Si l'Europe a été poussée par la réglementation et les services haut de gamme, l'essor des véhicules connectés en Chine est dû à un mélange d'enthousiasme technologique des consommateurs et d'orientation gouvernementale. Les équipementiers chinois ont été très agressifs dans l'ajout de la connectivité aux voitures - d'ici 2023, 78 % des nouvelles voitures en Chine seront équipées de systèmes télématiques intégrés, et ce chiffre augmente rapidement (contre environ 65 % l'année précédente). L'un des facteurs est que les consommateurs chinois sont extrêmement centrés sur les applications mobiles ; ils s'attendent à ce que leur voiture s'intègre à leur vie numérique (navigation, musique, commande à distance via des applications téléphoniques, etc.) Des marques comme NIO, Xpeng, BYD, Li Auto se distinguent non seulement par le matériel de la voiture, mais aussi par l'expérience logicielle - les mises à jour "over-the-air", les applications de contrôle pour smartphone et même les "app stores" dans les voitures sont des arguments de vente. En effet, les constructeurs automobiles chinois ont été parmi les premiers à intégrer des fonctions telles que le commerce électronique embarqué et la diffusion vidéo en continu. En 2023, les marques chinoises équipaient leurs véhicules d'écosystèmes d'applications sur les unités d'infodivertissement, ce que les marques étrangères commencent maintenant à imiter.

Du côté du gouvernement, la Chine dispose d'une réglementation unique pour les NEV (véhicules à énergie nouvelle - c'est-à-dire les VE et les hybrides rechargeables) : les fabricants sont tenus d'envoyer les données relatives à la batterie et à la localisation des VE à une plateforme de surveillance nationale à des fins de sécurité et de recherche. Cela signifie que chaque véhicule électrique en Chine dispose d'une connectivité par mandat, en fait. Bien que ces données soient destinées à un usage gouvernemental, elles ont permis de s'assurer de l'existence du matériel et ont probablement eu des répercussions sur les fonctionnalités destinées aux consommateurs. Les régulateurs chinois façonnent aussi activement la sécurité des données via les normes IoV (Internet of Vehicles) - des directives récentes (en 2021-2022) imposent un traitement sécurisé des données des véhicules et limitent l'exportation de données de véhicules hors de Chine. Ainsi, les FST internationaux qui travaillent avec les données des équipementiers chinois doivent souvent utiliser des serveurs locaux et respecter les règles de localisation des données.

En termes de services, les services télématiques des équipementiers chinois offrent souvent plus de fonctions "style de vie" : Assistants vocaux IA dans la voiture, démarrage à distance de la climatisation (pour pré-refroidir la voiture en été, par exemple) et intégration poussée des téléphones (certaines voitures s'intègrent à WeChat pour les messages). Pour les flottes, cela peut ne pas sembler directement pertinent, mais cela montre à quel point la télématique intégrée n'est pas négociable en Chine - c'est le conduit pour toutes ces fonctionnalités. Pour les flottes commerciales, des entreprises locales comme Alibaba, Tencent et Baidu se sont associées à des équipementiers pour fournir des solutions télématiques et d'intelligence artificielle (comme le système d'exploitation automobile AliOS, la plateforme Apollo de Baidu pour la télématique et les données autonomes). Le marché chinois s'oriente également vers des plateformes tout-en-un - une application de gestion de flotte peut incorporer des données OEM, des vidéos de dashcam, et même une évaluation du comportement du conducteur basée sur l'IA, le tout lié à des écosystèmes de super-applications omniprésentes.

AMÉRIQUE DU NORD : Bien que la question mette l'accent sur l'Europe et la Chine, une petite remarque s'impose : les États-Unis et le Canada ont également atteint un niveau de connectivité élevé (91 % des nouvelles voitures). Là, c'est davantage le marché qui a joué un rôle moteur : OnStar de GM (depuis les années 2000), suivi par Ford, Chrysler, etc., ont tous ajouté la télématique pour apporter une valeur ajoutée (démarrage à distance, assistance routière) et, plus tard, pour permettre des services par abonnement (hotspot Wi-Fi dans la voiture, etc.). Au milieu des années 2010, tous les grands constructeurs automobiles en Amérique du Nord proposaient des services télématiques. Le mandat ELD (Electronic Logging Device) pour les camions aux États-Unis a indirectement stimulé la télématique dans le secteur du camionnage commercial, bien que beaucoup aient opté pour des dispositifs ELD du marché secondaire, certains équipementiers de camions ont intégré des fonctions ELD dans leurs plateformes télématiques destinées à la vente. En définitive, qu'il s'agisse d'une berline de luxe à Los Angeles ou d'un semi-remorque transportant des marchandises d'un bout à l'autre du pays, il y a de fortes chances qu'il soit connecté - ou qu'il le soit la prochaine fois qu'il sera remplacé.

D**'AUTRES RÉGIONS** (Amérique latine, Afrique, Asie du Sud-Est) rattrapent leur retard, même si le coût et l'infrastructure sont des facteurs à prendre en compte. En 2023, en dehors des grands marchés, moins de 40 % des nouveaux véhicules étaient équipés de la télématique, mais ce chiffre augmentera à mesure que la connectivité abordable et les réglementations (comme l'obligation de suivi des véhicules volés au Brésil ou la norme AIS-140 en Inde pour le GPS dans les transports publics) se multiplieront.

Pour résumer le paysage régional : L'Europe et la Chine sont des précurseurs - l'Europe du point de vue de la réglementation et des équipementiers haut de gamme, la Chine du point de vue des consommateurs, de la technologie et de la politique. Les deux ont une connectivité quasi saturée pour les nouvelles voitures et explorent les prochaines frontières (comme les plateformes de monétisation des données des véhicules et l'infrastructure V2X). Pour les FST, cela signifie qu'en Europe, vous devrez obtenir un consentement strict et passer par de multiples portails d'équipementiers (à moins de faire appel à un intégrateur), et qu'en Chine, vous travaillerez dans un cadre de forte connectivité mais aussi de forte gouvernance des données (et peut-être d'interface avec des plates-formes chinoises). Dans les deux cas, une plateforme comme Navixy, capable de gérer des données multi-pays et multi-équipementiers en tenant compte de la conformité, est inestimable. Par exemple, les outils de conformité de Navixy peuvent aider à garantir que les exigences du GDPR (comme la possibilité de supprimer les données personnelles ou d'enregistrer le consentement) sont respectées lors de l'utilisation des données des véhicules de l'UE, et son déploiement flexible (dans le nuage ou sur site) peut répondre aux besoins de localisation des données pour des marchés comme la Chine.

Au-delà des voitures particulières : la télémétrie dans les camions et les équipements lourds

Les berlines et les SUV ne sont pas les seuls à bénéficier de la télématique. Les véhicules commerciaux et les machines industrielles ont leurs propres écosystèmes télématiques, qu'il est essentiel de comprendre pour les gestionnaires de flotte professionnels. Ces secteurs ont souvent été les pionniers de la télématique avant qu'elle ne soit à la mode - les camions long-courriers et les engins de chantier tirent parti de la surveillance à distance pour l'entretien et la logistique depuis de nombreuses années. Faisons un tour d'horizon :

• Camionnage et flottes commerciales. Tous les grands constructeurs de camions (Freightliner et Navistar aux États-Unis, Daimler Trucks, Volvo Trucks, Scania, MAN en Europe, FAW et Dongfeng en Chine, etc.) proposent la télématique en usine pour leurs véhicules. Par exemple, Fleetboard de Daimler, Dynafleet de Volvo, Scania Fleet Management, TruckTech+ de Paccar, etc. Ces systèmes fournissent des données similaires à celles des voitures (GPS, carburant, vitesse), mais avec des ajouts spécifiques aux camions : heures de fonctionnement du moteur, niveau de liquide d'échappement diesel (DEF), usure des freins, poids des essieux (si les capteurs sont présents) et diagnostics avancés du moteur. Ils sont également souvent liés à des services de gestion de flotte pour le transport routier, comme le téléchargement à distance des données du tachygraphe (en Europe) ou l'intégration du journal de bord du conducteur.
  

L'adoption de la télématique dans les poids lourds est assez élevée pour les grands opérateurs - selon Penske, plus de 50 % des grandes flottes utilisent la télématique sur leurs camions, alors que les petites flottes sont à la traîne (seulement un tiers des petites flottes l'utilisent). Cela indique un clivage : les grandes entreprises de logistique instrumentent tout (parfois en utilisant la solution de l'équipementier, d'autres fois en la supprimant et en faisant appel à un tiers), tandis qu'une entreprise locale de cinq camions peut encore en être aux premiers stades de l'adoption en raison du coût. En Amérique du Nord, le mandat ELD a essentiellement forcé même les petites flottes à adopter au moins un dispositif télématique minimal (pour l'enregistrement des heures de service), ce qui a stimulé la pénétration.

L'un des problèmes de la télématique pour les camions des équipementiers est que les flottes mixtes sont très courantes - une entreprise peut avoir des Freightliners et des Volvo, etc. L'utilisation séparée du portail de chaque équipementier est inefficace, c'est pourquoi de nombreuses entreprises se tournent vers des plates-formes de flotte du marché secondaire qui peuvent regrouper les données. Il est intéressant de noter que les équipementiers eux-mêmes s'associent parfois à ces plateformes : par exemple, la marque Mack de Volvo permet le transfert de données vers des systèmes tiers, et les principaux fournisseurs de solutions télématiques pour les flottes ont des programmes d'intégration de données avec des équipementiers comme Ford, GM, Volvo Trucks et d'autres, jouant ainsi le rôle d'agrégateur. De même, Navixy peut ingérer des données OEM pour les camions si l'API est disponible, ou vous pouvez toujours vous rabattre sur un dispositif matériel que Navixy prend en charge (avec sa bibliothèque de pratiquement toutes les intégrations de dispositifs modernes ).

Autre remarque sur les camions : les remorques et les biens remorqués par les camions disposent également de la télématique (suivi des remorques, des conteneurs, etc.), mais il s'agit généralement de modules complémentaires du marché secondaire, car une remorque n'est pas liée à un seul constructeur de camions. Cependant, les solutions télématiques modernes pour le transport routier combinent les données du camion (tracteur) et celles de la remorque pour obtenir une image complète. Les données OEM du tracteur peuvent vous indiquer si une remorque est connectée ou si l'ABS de la remorque a émis une erreur (certains camions peuvent lire les diagnostics de la remorque via la connexion ISO 11992). Il s'agit donc d'un domaine riche où les données OEM et non-OEM se mélangent.

• Véhicules utilitaires légers (fourgonnettes et camionnettes). Ils relèvent souvent des divisions voitures particulières des équipementiers (par exemple, les fourgonnettes Ford Transit utilisent la technologie télématique de Ford, tout comme les voitures Ford). La disponibilité est donc élevée, en particulier en Europe où les fourgonnettes sont courantes dans les flottes de livraison. De nombreuses camionnettes sont désormais équipées de modules de connectivité en option (Ford, Peugeot, Mercedes Sprinter, etc. ont toutes des solutions). Les flottes qui utilisent des camionnettes de livraison (comme les entreprises de logistique et de services) peuvent utiliser ces solutions OEM ou ajouter leurs propres dispositifs s'ils ont besoin de fonctions telles que l'identification du conducteur, etc. En Amérique du Nord, les camionnettes (Ford F-series, Chevy Silverado) ont des taux de connectivité élevés parce qu'elles sont aussi des véhicules grand public et que les équipementiers intègrent ces fonctions dans leur gamme. Les données d'une flotte de camionnettes peuvent donc être extraites via les API des équipementiers de la même manière. Les cas d'utilisation : routage, vérification des livraisons, consommation de carburant, etc., ne diffèrent pas beaucoup de ceux des voitures, mais un aspect intéressant est l'équipement de ces véhicules en fonction du travail à effectuer. Par exemple, la camionnette d'une entreprise de services publics peut être équipée d'une nacelle élévatrice ; la télématique des équipementiers ne couvrira probablement pas l'état de cet accessoire. C'est là que les capteurs du marché secondaire jouent encore un rôle (et que la logique IoT de Navixy peut fusionner les données de ces capteurs avec les données du véhicule d'origine pour obtenir une vue d'ensemble).
• Bus et transports publics. Les autobus et autocars urbains sont souvent équipés de systèmes télématiques pour les opérations et les informations sur les passagers (comme le suivi des heures d'arrivée). Certains constructeurs d'autobus proposent ce service (Volvo et Mercedes, par exemple, fabriquent des autobus équipés de la télématique). Par ailleurs, dans certains pays, la réglementation impose le suivi par GPS dans les transports publics pour des raisons de sécurité. Bien que ce ne soit pas l'objet de cet article, il convient de reconnaître que la télématique des équipementiers ne concerne pas seulement les véhicules personnels ou de transport de marchandises - elle s'étend également aux transports publics.
• Équipements industriels, de construction et spécialisés. Il s'agit d'un domaine fascinant. Les équipementiers de machines lourdes ont été extrêmement avancés dans le domaine de la télématique, en grande partie pour soutenir les contrats de maintenance et maximiser le temps de fonctionnement pour les clients. Caterpillar, par exemple, équipe ses excavateurs, bulldozers, générateurs, etc. de son système télématique Cat Product Link, qui est utilisé par plus de 1,4 million d'équipements connectés dans le monde entier ! Des entreprises comme John Deere (JDLink), Komatsu (Komtrax) et d'autres ont chacune des centaines de milliers de machines connectées. Ces systèmes transmettent des données telles que le nombre d'heures de fonctionnement du moteur, la consommation de carburant, le temps d'inactivité par rapport au temps de travail, les codes d'erreur et la localisation. Ils aident à planifier la maintenance préventive (les concessionnaires surveillent souvent les machines et contactent les propriétaires lorsque l'entretien doit être effectué) et contribuent à l'analyse de l'utilisation des machines sur les chantiers. Pour les gestionnaires de parcs d'équipements de construction ou agricoles, l'exploitation des données des équipementiers peut s'avérer très utile, par exemple en enregistrant automatiquement les heures de fonctionnement de chaque machine afin de répartir les coûts par projet, ou en établissant un géoréférencement des machines afin d'empêcher toute utilisation non autorisée.
  

La télématique industrielle est souvent confrontée à des environnements difficiles et parfois à l'absence de couverture cellulaire (sites miniers dans des zones reculées). Les solutions OEM peuvent utiliser des liaisons montantes par satellite ou exiger l'enregistrement local des données. Certains fournisseurs tiers proposent du matériel télématique bimode qui fonctionne dans ces conditions. L'intégration peut donc être complexe. La plateforme Navixy, avec sa souplesse d'intégration des dispositifs, peut combiner les données provenant des flux OEM et de tous les trackers robustes du marché secondaire (y compris les dispositifs satellite et LPWAN ) pour s'assurer que même les actifs hors réseau sont pris en compte.

Tableau : Adoption de la télématique par les équipementiers dans les différentes catégories de véhicules

Pour un aperçu rapide, voici comment la disponibilité et l'utilisation de la télématique embarquée varient selon les segments :

| Segment de véhicule | Disponibilité de la télématique pour les équipementiers | Notes sur l'adoption et l'utilisation | | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | Très forte adoption en Amérique du Nord et dans l'Union européenne (plus de 90 % des nouvelles voitures). D'ici 2028, ~94% des nouvelles voitures dans le monde seront connectées, utilisées aussi bien pour les services aux consommateurs que pour la gestion des flottes. | Les véhicules utilitaires légers (fourgonnettes et camionnettes) sont de plus en plus souvent équipés en usine (souvent en option). Ford, Mercedes, Stellantis, etc., proposent des services télématiques sur les camionnettes ; les camionnettes partagent les plateformes avec les voitures (connectivité élevée). | Utilisation croissante dans les flottes de livraison/service. Souvent mélangée avec le marché secondaire pour des besoins de niche. Les données de l'équipementier sont utiles pour les itinéraires, le carburant, l'entretien ; les modules complémentaires sont utilisés pour l'identification du conducteur, etc. | Les poids lourds (fret) sont proposés par tous les grands constructeurs (Daimler Fleetboard, Volvo/Mack Connect, PACCAR SmartLinq). Les nouveaux camions sont souvent livrés avec des abonnements télématiques pluriannuels. | L'adoption est forte dans les grandes flottes ; les petites flottes sont à la traîne. En 2022, environ 54 % des grandes flottes et 37 % des petites flottes utilisaient la télématique sur les camions. De nombreuses flottes équipent les anciens camions avec des dispositifs du marché secondaire pour s'assurer que toutes les unités sont suivies, en utilisant les flux OEM lorsqu'ils sont disponibles sur les nouvelles unités. | Autobus et autocars | Courant dans les nouveaux modèles des principaux constructeurs d'autobus (Volvo, BYD, etc.), souvent avec une technologie similaire à celle des camions. Certaines municipalités l'exigent pour les transports en commun. | Adoption modérée ; généralement utilisé par les agences de transport en commun pour les opérations et le respect des horaires. Le marché de l'après-vente est encore utilisé dans les flottes plus anciennes. | Les modules télématiques sont standard ou en option sur la plupart des équipements modernes (Cat, Komatsu, John Deere, etc.). Souvent offerts gratuitement pour une période d'essai lors de l'achat d'un équipement. | En augmentation rapide. Caterpillar compte à lui seul plus de 1,4 million de machines connectées, utilisées pour les alertes de maintenance, le suivi de l'utilisation et la sécurité des actifs. Combinaison de communications cellulaires et par satellite pour les sites éloignés. |

Comme nous le voyons, la télématique des équipementiers s'étend désormais à presque toutes les catégories de véhicules, mais les modes d'utilisation diffèrent. Les gestionnaires de flotte se retrouvent souvent avec un amalgame de sources de données - quelques véhicules nativement connectés, d'autres plus anciens équipés de dispositifs de seconde monte, peut-être un ou deux portails d'équipementiers - ce qui nous amène à la question de savoir comment agréger et utiliser efficacement toutes ces données.

Obtenir les données : API des équipementiers, agrégateurs et plateformes tierces

Vos véhicules diffusent donc toutes ces données vers le nuage du fabricant. Comment, en tant que gestionnaire de flotte ou FST, pouvez-vous les exploiter ? Il y a généralement deux possibilités : directement auprès de l'équipementier ou par l'intermédiaire d'un agrégateur ou d'une plateforme tierce. Chacune présente des avantages et des inconvénients, et une combinaison est souvent utilisée.

API directes des équipementiers

De nombreux constructeurs automobiles proposent des plateformes API ou des services de données permettant aux clients (en particulier les flottes) de récupérer les données télématiques de leurs véhicules. Il s'agit essentiellement de services web où, une fois authentifié et autorisé, vous pouvez interroger les données du véhicule (ou vous abonner aux mises à jour). Parmi les exemples, citons l'API OnStar Business Solutions de GM, les Ford Data Services (accessibles via la plateforme Ford Pro), le MSPF de Toyota, l'API Fleet de Mercedes-Benz, les API Car-Net/We Connect de Volkswagen, etc.

Pour les utiliser, il faut généralement suivre quatre étapes :

1. S'abonner au service et à l'API de l'équipementier. Souvent, vous devez acheter un plan de service télématique pour chaque véhicule (parfois inclus pour une période lors de l'achat du véhicule). Pour les flottes, les équipementiers disposent généralement d'un programme API B2B distinct de l'application grand public. Ces API B2B sont souvent payantes ou assorties de contrats de service, mais elles permettent un accès massif aux données (les API grand public peuvent se limiter à un véhicule par compte). Par exemple, BMW dispose d'une "BMW CarData / BMW Fleet API" pour les entreprises, et GM a un plan télématique pour les flottes indépendant du compte OnStar du consommateur.
2. S'authentifier et se connecter. Vous enregistrez votre application (ou utilisez une plateforme partenaire) et obtenez des clés API ou des identifiants OAuth. Ensuite, vous établirez des connexions avec les points d'extrémité de l'équipementier. Il s'agit d'un effort de développement non trivial, car chaque API d'équipementier est différente. L'une peut utiliser des appels REST JSON, une autre utilise SOAP XML, chacune avec son propre schéma de données. Il y a aussi la maintenance - si l'équipementier change quelque chose, vous devez vous adapter. Peu d'équipementiers unifient leurs marques (à l'exception de Stellantis, qui englobe désormais les marques FCA et PSA ; ils travaillent sur une plateforme unique pour tous). Par conséquent, si vous avez cinq marques dans votre flotte, il se peut que vous deviez coder sur cinq API. C'est là que beaucoup lèvent les bras au ciel et envisagent de faire appel à des agrégateurs, qui ont déjà fait ce travail,
3. Fournir des justificatifs pour les véhicules. Les équipementiers doivent s'assurer que seules les parties autorisées accèdent aux données d'un véhicule. Les flottes doivent donc généralement prouver qu'elles sont propriétaires du véhicule ou qu'elles en ont l'autorisation. Il peut s'agir de télécharger des documents tels que des informations d'enregistrement ou d'achat pour chaque numéro d'identification du véhicule, ou parfois d'une lettre en vrac. Mercedes, par exemple, a exigé que 15 % des numéros d'identification soient prouvés par des documents, à titre de contrôle ponctuel. D'autres peuvent demander une déclaration signée attestant que vous êtes bien propriétaire de ces véhicules, ou une vérification du kilométrage actuel par l'utilisateur, à titre de mécanisme de consentement. Cela peut être bureaucratique, mais il s'agit d'une étape d'intégration unique par véhicule ou par flotte.
4. Consentement du conducteur/propriétaire. Particulièrement en Europe (et de plus en plus ailleurs), vous devrez peut-être obtenir le consentement explicite du conducteur ou du propriétaire principal du véhicule pour accéder aux données. Si votre entreprise est propriétaire du véhicule et emploie le conducteur, il peut s'agir d'un formulaire que le conducteur signe pour reconnaître le suivi. Ces formulaires de consentement peuvent être conservés en cas d'audit. Certains équipementiers intègrent un consentement numérique - par exemple, le conducteur peut recevoir un courriel dans lequel il doit cliquer pour approuver, ou dans l'infotainment du véhicule, il accepte un message-guide. Cela varie. Mais c'est une étape à laquelle il faut être attentif (et qu'il ne faut pas sauter, pour des raisons de conformité légale).

Une fois la configuration établie, le flux de données commence ! Vous recevrez probablement des messages JSON ou XML contenant les données du véhicule à intervalles réguliers ou sur demande. Certaines API sont de type "push" (elles vous envoient les données à une URL de rappel ou à un sujet MQTT ), d'autres sont de type "pull" (votre système doit interroger chaque véhicule pour connaître son dernier statut). S'il s'agit d'une API "pull", vous devez programmer des appels périodiques pour obtenir des mises à jour.

Agrégateurs et places de marché de données

Si faire tout ce qui précède pour chaque équipementier vous semble décourageant, vous n'êtes pas le seul. Ce besoin a donné naissance aux agrégateurs de données sur les véhicules - des entreprises qui se chargent de l'intégration avec des dizaines d'API d'équipementiers et proposent une API unique et unifiée aux clients. Parmi les exemples, citons Otonomo, Wejo, High Mobility, Smartcar, MotoLauncher (anciennement Abright) et d'autres. Leur discours : "Un contrat, une API, un accès à de nombreuses marques".

Par exemple, la plateforme de High Mobility vous permet de connecter des véhicules de BMW, Mercedes, Audi, Ford, etc. et fournit un modèle de données normalisé afin que vous n'ayez pas à les analyser différemment. La plateforme Navixy peut s'intégrer à ces services ou les clients peuvent les utiliser pour alimenter Navixy en données via des webhooks.

Les structures tarifaires de ces services impliquent généralement des frais d'abonnement par véhicule ou des frais d'appel de données. High Mobility annonce des prix à partir de 0,99 € par véhicule et par mois pour les forfaits de données de base, avec des plans échelonnés au-delà. Il s'agit de données simples, comme le compteur kilométrique ou le niveau de carburant, qui ne sont pas consultées fréquemment. Des données plus complètes ou plus fréquentes peuvent coûter quelques euros par véhicule et par mois. Otonomo a toujours pratiqué des prix de l'ordre de quelques dollars par voiture et par mois pour les données de base sur les flottes, avec parfois des remises sur les volumes. Ils peuvent également facturer des frais de configuration ou d'utilisation de l'API (par exemple, certains facturent par appel à l'API si vous dépassez un certain quota).

Pour les flottes, ce coût peut encore être inférieur à celui de l'installation de matériel (qui peut s'élever à plus de 100 $ pour l'appareil, plus 5 à 10 $ par mois pour le service). Mais à grande échelle, payer, par exemple, 3 dollars par véhicule à l'agrégateur, plus l'abonnement de l'équipementier, le cas échéant, peut faire grimper la facture. Certains équipementiers ne facturent pas directement et se contentent d'autoriser les agrégateurs qui vous facturent ensuite ; d'autres exigent que vous ayez un plan OEM actif et que vous payiez l'agrégateur.

Un autre type d'agrégateur est la plateforme verticale. Navixy se veut un guichet unique où la plateforme s'occupe de tout, que vous utilisiez des trackers matériels ou des flux OEM. En fait, la plateforme télématique elle-même peut vous servir d'agrégateur si elle a établi ces connexions.

La disponibilité des données via les agrégateurs est généralement bonne pour les grandes marques, mais peut être aléatoire pour les équipementiers plus petits ou spécifiques à une région. Les marques européennes, américaines et certaines marques asiatiques sont généralement intégrées. Les API des équipementiers chinois peuvent ne pas être aussi facilement accessibles aux agrégateurs étrangers pour des raisons réglementaires. Par conséquent, si vous exploitez une flotte de voitures de marques nationales chinoises en dehors de la Chine, vous risquez d'être moins bien soutenu. Dans ce cas, il peut être nécessaire de traiter directement avec l'entité locale de l'équipementier.

Il faut également tenir compte du fait que toutes les données ne sont pas égales - certains équipementiers ont des niveaux de données (paquet de base ou paquet premium). Les agrégateurs prennent généralement en charge plusieurs ensembles de données, et vous choisissez ce dont vous avez besoin (et payez en conséquence). Par exemple, l'offre de base peut inclure la localisation et le kilométrage ; l'offre avancée peut ajouter le carburant, la pression des pneus et les codes DTC.

Processus typique avec un agrégateur: Vous vous inscrivez auprès de l'agrégateur X, vous fournissez la preuve que vous êtes propriétaire du véhicule ou que vous avez donné votre accord de la même manière (ils gèrent souvent cela de manière simplifiée, vous leur donnez le numéro d'identification du véhicule et les documents, ils se chargent des démarches auprès des équipementiers ou obtiennent des approbations préalables). Ils vous fournissent ensuite une interface pour activer le flux de données de chaque véhicule. Une fois l'interface activée, vous commencez à recevoir les données dans un format unifié. C'est plus pratique, mais vous avez introduit un intermédiaire (coût et autre point de dépendance).

Plateformes télématiques tierces et intégration

La troisième solution consiste à tirer parti d'une plateforme de fournisseur de services télématiques comme Navixy, qui prend en charge les données des équipementiers. L'avantage ici est que vous obtenez également la couche applicative - c'est-à-dire une interface de gestion de flotte prête à l'emploi, des analyses, des alertes, etc., au-dessus des données, alors que l'API d'un agrégateur brut ne fait que fournir des données et que vous devez toujours créer une application ou vous intégrer à une application.

Avec Navixy, par exemple, vous pouvez connecter les données des équipementiers de deux manières :

• Utiliser des simulateurs/connecteurs d'appareils si Navixy a intégré un OEM particulier (la bibliothèque d'appareils de Navixy pourrait inclure des "appareils" virtuels représentant les flux de données de l'API de l'OEM).
• Utilisez l'API/SDK de Navixy pour pousser les données d'un agrégateur ou d'un OEM API dans Navixy (la fonction Data Bridge peut aider à canaliser les données API externes dans la plateforme, en les traduisant si nécessaire via NGP).

Le gros du travail d'harmonisation des données est pris en charge par le système Navixy, de sorte qu'il apparaît comme n'importe quel autre dispositif de suivi dans l'interface. Cela signifie qu'un gestionnaire de flotte peut voir ses véhicules connectés à l'OEM sur la même carte et les mêmes rapports que ceux équipés de traceurs du marché secondaire. Il peut définir des alertes (géofence, survitesse, etc.) et effectuer des analyses (rapports de consommation de carburant, comportement du conducteur) sur l'ensemble de la flotte de manière uniforme.

Une remarque sur les prix : Certains équipementiers ont commencé à proposer eux-mêmes des plateformes directes pour les flottes - par exemple, GM propose OnStar Vehicle Insights (un portail web pour les flottes qui permet d'accéder aux données des véhicules GM, sur la base d'un abonnement). Ces plates-formes peuvent être intéressantes pour les flottes d'une seule marque, mais ne permettent pas de résoudre le problème des flottes de plusieurs marques. Leur prix peut varier de 10 à 20 dollars par véhicule et par mois en général (puisqu'ils regroupent le logiciel et les données). En revanche, les agrégateurs peuvent être moins chers mais nécessitent une plateforme existante pour utiliser les données. Les plateformes TSP comme Navixy sont indépendantes du matériel - que vous payiez l'équipementier ou un agrégateur pour les données, vous payez Navixy pour le service logiciel comme d'habitude (qui est souvent par véhicule ou par appareil également, mais vous n'avez peut-être pas besoin d'un appareil physique).

En résumé, l'accès aux données télématiques des équipementiers est devenu beaucoup plus facile grâce à ces nouveaux canaux. Vous n'avez plus besoin de négocier séparément avec chaque constructeur automobile si vous utilisez un intermédiaire qui l'a déjà fait. Cependant, chaque couche ajoute un coût et une latence potentielle. Les grandes flottes s'adressent parfois directement à l'équipementier pour éviter les frais (surtout si elles disposent d'équipes de développement pour intégrer les API). Les flottes de taille moyenne peuvent utiliser un agrégateur pour économiser du temps de développement. Les petites flottes peuvent contourner complètement les données des équipementiers et se contenter d'installer un traceur GPS du marché secondaire par souci de simplicité (même si la voiture est connectée, parce que la configuration des équipementiers a toujours été complexe - bien que cela soit en train de changer).

Pour un FST qui lance des services autour des données OEM, une approche judicieuse est souvent hybride : intégrer quelques API OEM directement pour les marques principales, et utiliser un agrégateur pour la longue traîne des marques moins courantes, le tout canalisé dans le modèle unifié de votre plateforme. L'API flexible et le NGP de Navixy facilitent l'intégration de données provenant de diverses sources : un partenaire peut être alimenté par l'OEM A, un autre par l'agrégateur B - une fois dans Navixy, les données sont normalisées et les clients peuvent exploiter des fonctionnalités telles que IoT Logic (pour déclencher des flux de travail automatisés sur certaines conditions de données), quelle que soit la source. Et si quelque chose n'est pas disponible via l'OEM (par exemple un véhicule plus ancien sans télématique), vous pouvez toujours vous rabattre sur l'installation d'un tracker de rechange pris en charge. En fin de compte, les FST doivent résoudre les problèmes sans tenir compte des sources de données - le client de la flotte veut simplement ses informations, c'est notre travail de les assembler dans les coulisses.

Obstacles pour les FST : authentification, lacunes dans la couverture, coût et temps de latence

Malgré tous ces progrès, la télémétrie des systèmes OEM n'est pas un jeu d'enfant. Les FST et les gestionnaires de flotte sont confrontés à des défis pratiques lorsqu'ils travaillent avec les données des équipementiers. Mettons en évidence les principaux points douloureux :

• Authentification et complexité de l'intégration. Se connecter aux API des équipementiers implique de naviguer dans différents schémas d'authentification (jetons OAuth, clés API, certificats) pour chacun d'entre eux. Maintenir les jetons à jour et sécurisés n'est pas une mince affaire. Un FST peut avoir besoin de maintenir des dizaines d'intégrations d'API, chacune avec ses propres particularités. Si un équipementier modifie la version de son API ou exige une nouvelle authentification (peut-être que l'abonnement de la flotte a expiré et a été renouvelé), le FST doit gérer cela en douceur. C'est la raison pour laquelle les FST apprécient les solutions telles que le NGP et la boîte à outils d'intégration de Navixy - ils font abstraction d'une grande partie de ces différences. C'est un peu comme si vous deviez jongler avec plusieurs clés pour plusieurs portes au lieu d'avoir un passe-partout. Les FST doivent essentiellement devenir des experts du portail de développement de chaque équipementier (à condition qu'il en existe un et qu'il soit rédigé dans une langue qu'ils comprennent - certains documents d'équipementiers chinois peuvent ne pas être rédigés en anglais, par exemple). Il s'agit là d'un défi en termes de ressources: toutes les entreprises de télématique ne disposent pas de la bande passante de développeurs nécessaire pour mener à bien 10 projets d'API différents en parallèle, en plus de la maintenance continue. Cela justifie souvent le recours à des agrégateurs ou à des logiciels intermédiaires.
• Lacunes dans la couverture et flottes mixtes. Quelle que soit la nouveauté ou la haute technologie d'une flotte, il y a souvent des lacunes dans la couverture desdonnées des équipementiers. Il se peut que 80 % de la flotte soit constituée de nouveaux modèles connectés, mais que 20 % soit constituée de véhicules plus anciens ou d'autres marques qui ne sont pas équipés de systèmes OEM. Pendant une période de transition (comme aujourd'hui), les flottes seront hybrides - certains véhicules sont alimentés par l'OEM, d'autres par des dispositifs installés. Cela peut créer des silos de données s'ils ne sont pas unifiés. En outre, comme nous l'avons vu, même les véhicules connectés peuvent présenter des lacunes lorsqu'ils sont hors réseau ou hors tension. Pour les FST, cela signifie que vous devez gérer des ensembles de données incomplets. Vous devrez peut-être dire à vos clients : "Nous pouvons obtenir X données lorsque le véhicule est en marche, mais s'il est éteint, nous ne le pouvons pas, à moins que nous n'installions un dispositif de secours." Certaines configurations avancées incluent une batterie de secours sur l'unité OEM, mais c'est rare. Une solution créative adoptée par certaines entreprises de covoiturage a consisté à installer une unité télématique secondaire uniquement pour couvrir le déverrouillage à distance et l'enregistrement hors ligne, même si la voiture était équipée d'une unité télématique d'origine - parce que l'équipementier n'aurait pas assuré ces fonctions nécessaires. Pour un parc automobile classique, la redondance n'est pas forcément rentable, et il faut donc s'accommoder des lacunes. Les plates-formes TSP peuvent atténuer ce problème en indiquant au moins clairement l'heure de la dernière donnée connue (afin que vous ne supposiez pas que l'information est à jour si elle date de trois heures). La plateforme de Navixy, par exemple, affiche bien en évidence l'heure de la dernière mise à jour, et il est possible de configurer des alertes telles que "pas de contact pendant 30 minutes" pour savoir quand un véhicule a effectivement disparu.
• Cohérence et normalisation des données. Chaque équipementier fournit des données dans une structure différente, ce qui peut entraîner des incohérences si elles ne sont pas normalisées. Pour un FST, la mise en correspondance avec un modèle de données commun est une tâche permanente. Il ne s'agit pas seulement de la dénomination - même la signification peut différer (l'état "inactif" d'un équipementier peut signifier que le moteur est en marche mais que le véhicule n'a pas bougé pendant 5 minutes, tandis qu'un autre peut ne pas envoyer d'indicateur d'inactif du tout). Pour garantir une expérience cohérente (de sorte qu'un événement "arrêt" ou une "distance de voyage" soit calculé uniformément sur tous les véhicules), il peut être nécessaire de traduire ou même de dériver des données. Par exemple, si l'équipementier A ne fournit pas d'odomètre direct mais un GPS, vous pouvez accumuler la distance manuellement, tandis que l'équipementier B fournit une lecture de l'odomètre - pour fournir un rapport au gestionnaire de flotte, vous devez combiner ces données de manière transparente. C'est là que IoT Logic sur Navixy peut vous aider : vous pouvez écrire des règles ou des formules pour dériver les valeurs manquantes (comme calculer la distance à partir du GPS lorsque l'odomètre est manquant) afin que les rapports finaux n'affichent pas de blancs. Mais c'est un défi en coulisses.
• Coûts et considérations de retour sur investissement. Comme nous l'avons vu, l'obtention des données des équipementiers peut entraîner des coûts supplémentaires - soit en payant les frais d'abonnement des équipementiers, soit en payant les frais d'agrégation. Les FST qui intègrent les données des équipementiers doivent en tenir compte dans leur tarification. Cela peut être difficile à vendre aux clients : "Vos nouvelles voitures sont équipées de systèmes télématiques d'origine - nous pouvons nous y connecter, mais l'accès aux données coûtera X dollars par mois et par voiture. Certains clients supposent que si le matériel est intégré, son utilisation est "gratuite", ce qui n'est pas toujours le cas. Les FST peuvent choisir d'absorber une partie des coûts pour rester compétitifs, ou souligner que même avec des frais, c'est moins cher que d'installer un nouveau matériel. Il y a également un coût lié au temps nécessaire à l'intégration, qui est un coût d'ingénierie. Pour les petits FST, la recherche de données OEM ne vaut peut-être pas encore la peine si les flottes de leurs clients sont principalement constituées de véhicules plus anciens. Mais à mesure que l'équilibre se modifie (avec ~75% des nouveaux véhicules qui en disposent, une majorité de flottes finira par avoir une certaine capacité de données OEM), l'ignorer n'est pas viable à long terme.
• Latence et limitations en temps réel. Les pipelines des équipementiers peuvent introduire des temps de latence (comme nous l'avons vu plus haut). Pour un FST promettant une visibilité en temps réel, il est un peu gênant que les véhicules alimentés par les équipementiers affichent un léger retard ou une actualisation plus lente par rapport à ceux équipés de dispositifs du marché secondaire. Les FST doivent communiquer clairement leurs attentes ("mises à jour toutes les 60 secondes" ou "toutes les 10 secondes") à leurs clients. Il y a aussi la question de la latence des commandes - si vous envoyez une commande (comme le déverrouillage à distance des portes d'une voiture), à quelle vitesse s'exécute-t-elle via le système de l'équipementier ? Certains équipementiers peuvent mettre 5 à 10 secondes pour réveiller la voiture et l'exécuter, d'autres peuvent le faire presque instantanément. Et comme nous l'avons mentionné, peu d'équipementiers autorisent encore les commandes à distance via l'API, ce qui peut constituer une limitation pour des services tels que la location ou le partage de voitures. Cela signifie que les FST qui répondent à ces cas d'utilisation ont toujours besoin de matériel de seconde monte pour effectuer certaines actions (immobilisation, coups de klaxon, etc.).
• Dépendances en matière d'assistance et de services. Lorsqu'un FST utilise les données d'un équipementier, il devient partiellement dépendant de la fiabilité du service de l'équipementier ou de l'agrégateur. Si le nuage de l'équipementier tombe en panne ou si les données sont retardées, le FST est tenu pour responsable de la panne par la flotte. Toutefois, le FST peut avoir peu de contrôle dans ce scénario, si ce n'est d'envoyer un ticket d'assistance à l'équipementier. Cette perte de contrôle est désagréable pour de nombreux fournisseurs habitués à gérer leurs propres appareils de bout en bout. Elle souligne l'importance des accords de niveau de service (SLA). De nombreux équipementiers, lorsqu'ils vendent l'accès à l'API d'une flotte, fournissent une garantie de niveau de service ou de temps de fonctionnement, mais elle peut ne pas être aussi solide que celle que les FST fournissent à leurs clients. Certains équipementiers considèrent encore leurs API comme "bêta" ou "best-effort". Les agrégateurs peuvent offrir de meilleurs accords de niveau de service consolidés. Quoi qu'il en soit, les FST doivent surveiller les flux des équipementiers et disposer d'alertes en cas d'interruption des données, afin de pouvoir informer les clients de manière proactive ("Il semble que le flux de données du fabricant X soit temporairement indisponible, nous nous en occupons..."). Disposer d'un plan de secours - même s'il s'agit de déployer un dispositif temporaire - peut s'avérer salvateur dans les cas critiques.
• Confidentialité et cybersécurité. L'accès aux données des équipementiers implique la responsabilité de les traiter conformément aux lois sur la protection de la vie privée et de les sécuriser. Les flottes et les FST doivent s'assurer que toutes les données personnelles (comme les modèles de comportement des conducteurs ou les traces de localisation) sont stockées et utilisées conformément aux réglementations et au consentement donné. La cybersécurité est également essentielle ; les API des équipementiers, si elles sont compromises, peuvent donner lieu à un accès non autorisé. Les FST doivent mettre en œuvre une authentification forte et ne pas exposer ces clés API. Les outils de conformité de Navixy peuvent aider à gérer la conservation des données et les contrôles d'autorisation - par exemple, purger automatiquement les données de voyage personnelles après une période déterminée si nécessaire, ou restreindre qui dans une organisation peut voir certaines données dérivées de l'OEM (peut-être que seuls les gestionnaires voient les scores des conducteurs, et non les conducteurs eux-mêmes, selon la politique).

Compte tenu de ces défis, les FST font évoluer leur rôle. Ils ne sont plus seulement des fournisseurs de systèmes de localisation GPS, mais des intégrateurs et des analystes de données. Des plateformes comme Navixy se préparent en construisant l'échafaudage nécessaire : protocoles de données unifiés, traitement en périphérie (IoT Logic) pour détecter et corriger les anomalies à la volée, API robustes pour permettre de mélanger plusieurs sources de données, et analyses complètes qui fonctionnent que les données proviennent d'un tracker Teltonika ou d'une API Tesla. L'avantage concurrentiel des FST à l'ère des données OEM résidera dans leur capacité à fusionner tout cela de manière transparente en un service cohérent pour l'utilisateur de la flotte. Ceux qui y parviendront prospéreront ; ceux qui n'y parviendront pas risquent d'être dépassés par de nouveaux acteurs (y compris les équipementiers eux-mêmes, qui pourraient offrir des services plus directs).

Le point de vue de Navixy : naviguer dans la révolution des données des équipementiers

Tout au long de cet article, nous avons souligné comment les capacités de Navixy s'alignent sur ces demandes évolutives de l'industrie - mais connectons explicitement les points. Alors que la télématique des équipementiers devient dominante, Navixy s'est positionné pour permettre aux FST et aux flottes de s'imposer dans ce nouveau monde :

• Le lac de données brutes : Compte tenu des préoccupations concernant l'exactitude et l'exhaustivité des données, la base de données de données brutes de Navixy garantit que chaque donnée entrante (provenant des API des équipementiers ou des appareils) est stockée dans sa forme originale. Cette archive transparente signifie que rien n'est perdu, et si vous avez besoin d'un audit ou d'un dépannage (par exemple, "Avons-nous manqué une mise à jour de localisation ou le véhicule n'en a-t-il jamais envoyé ?"), vous avez la preuve.
• Protocole générique Navixy (NGP) : Le NGP est la réponse de Navixy - un langage standardisé que tous les appareils et sources de données peuvent utiliser sur la plateforme. En convertissant les formats de données OEM disparates en NGP, Navixy réduit considérablement l'effort d'intégration et les erreurs potentielles. Il intègre essentiellement la solution au problème des "définitions de données différentes" en faisant correspondre les champs OEM à une ontologie commune. Cela protège votre stratégie de données de flotte pour l'avenir - de nouveaux appareils ou flux OEM peuvent être ajoutés avec un minimum d'effort, car ils seront simplement traduits dans NGP.
• Logique IoT et analyseur de flux de données : Ces outils brillent dans un monde de flux de données complexes. IoT Logic permet aux FST et même aux utilisateurs finaux de créer des règles personnalisées et des pipelines de traitement sur les données entrantes en temps réel. Par exemple, vous pouvez créer une règle : "Si les données de l'équipementier indiquent que le carburant est < 10 % et que le véhicule n'est pas au dépôt, envoyer une alerte" ou "S'il n'y a pas de données GPS de l'équipementier pendant > 5 minutes, passer à la dernière tour de téléphonie cellulaire connue, si elle est disponible" - toute logique conditionnelle peut être élaborée. Ceci est crucial pour adapter les données OEM (qui peuvent être brutes) à des actions significatives. Parallèlement, Data Stream Analyzer est comme un diagnosticien pour vos flux de données. Il vous permet de contrôler la santé de ces flux entrants - les données d'un véhicule particulier arrivent-elles à temps ? Y a-t-il des erreurs d'analyse ? Il offre une visibilité sur les problèmes potentiels (comme un problème d'intégration API ou un appareil qui se comporte mal) afin que vous puissiez les résoudre avant qu'ils n'aient un impact sur les opérations. Lorsque vous devez jongler avec plusieurs OEM et sources d'appareils, ce type de surveillance est une bénédiction.
• Prise en charge des données OBD-II/CAN/EV : Navixy a des racines profondes dans la prise en charge des données provenant de traqueurs matériels qui lisent les informations des bus OBD-II et CAN. Cette expertise se traduit par le traitement des données OEM car, fondamentalement, il s'agit des mêmes points de données. La plateforme Navixy sait comment interpréter le niveau de carburant, le régime moteur, les codes DTC, les statistiques de la batterie du VE, etc., qu'ils proviennent d'un dongle OBD physique ou d'un flux cloud OEM. Pour les VE en particulier, Navixy prend déjà en charge des paramètres tels que l'état de charge, l'état de chargement, l'autonomie - s'alignant parfaitement sur ce que les API des équipementiers fournissent. Si les données d'un équipementier présentent des lacunes, il est possible de les compléter. Par exemple, si l'API d'un équipementier ne donne pas la pression des pneus mais que vous pouvez installer un capteur de pneus Bluetooth avec une passerelle, Navixy peut fusionner ces données. La flexibilité permet de ne pas avoir d'angle mort dans les données - tout ce que le véhicule peut raisonnablement fournir, Navixy peut l'enregistrer et l'utiliser, d'une manière ou d'une autre.
• Outils de conformité et de reporting. Au fur et à mesure que les flottes utilisent les données des équipementiers pour leurs opérations, elles auront également besoin de les utiliser pour la conformité (pensez aux heures de service, à la déclaration de la taxe sur le carburant, à la conformité en matière de sécurité). Navixy fournit des modules et des rapports pour divers besoins de conformité - et ils ne sont pas limités aux données de l'appareil. Par exemple, vous pouvez utiliser la plateforme Navixy pour enregistrer les heures de conduite ou le kilométrage pour les taxes, quelle qu'en soit la source. Si la loi exige de conserver certaines données pendant X années, la gestion des données de Navixy peut également vous aider. En outre, l'accent mis par Navixy sur la sécurité et la confidentialité des données (avec des contrôles d'accès robustes pour les utilisateurs et la possibilité d'anonymiser ou de supprimer les données personnelles sur demande) aide les FST à se conformer à des réglementations telles que le GDPR tout en tirant parti des données des équipementiers. Si un conducteur révoque son consentement, vous pouvez rapidement désactiver le flux de données de ce véhicule et démontrer l'effacement si nécessaire.
• Expérience utilisateur unifiée : La plus grande force de Navixy est peut-être d'offrir un guichet unique pour toutes les données de la flotte. Les gestionnaires de flotte ne devraient pas avoir à se soucier du fait que la localisation du camion 123 provient d'une API OEM alors que celle du camion 124 provient d'un tracker - ils voient simplement les deux sur la carte et dans les rapports. L'interface et les analyses de Navixy les traitent de manière uniforme. Cela s'étend également aux informations de haut niveau : vous pouvez lancer un rapport sur l'efficacité énergétique à l'échelle de la flotte qui couvre à la fois les voitures équipées par l'équipementier et celles équipées par le marché de l'après-vente. Vous pouvez également mettre en place un tableau de bord qui affiche des indicateurs clés de performance tels que l'utilisation ou les scores de comportement de conduite pour l'ensemble de la flotte mixte. Navixy veille à ce que la fragmentation croissante au niveau des sources de données ne se traduise pas par une fragmentation au niveau des utilisateurs.

En substance, Navixy donne à ses utilisateurs les moyens d'adopter l'ère télématique des équipementiers plutôt que d'être perturbés par elle. Il s'agit de transformer ce qui pourrait être un chaos d'applications et de portails en une centrale de données rationalisée. Ironie du sort : en essayant de valoriser les données, les équipementiers ont involontairement créé un nouveau problème (les silos de données multiples), que des plateformes comme Navixy résolvent intelligemment, ajoutant ainsi encore plus de valeur aux offres des équipementiers.

Adopter un avenir de flotte axé sur les données

Les systèmes télématiques intégrés des équipementiers deviennent rapidement le système circulatoire de la flotte moderne, pompant un flux constant de données qui, si elles sont correctement exploitées, peuvent donner lieu à des opérations plus saines, à des conduites plus sûres et à un résultat net plus élevé. À l'heure actuelle, presque tous les nouveaux véhicules sont des véhicules connectés, qu'il s'agisse d'une voiture électrique compacte à hayon ou d'un camion diesel de 40 tonnes. Le défi pour les fournisseurs de services télématiques et les gestionnaires de flotte est de surfer sur cette vague sans se noyer dans la complexité.

Le paysage actuel offre d'immenses possibilités : des données plus riches (des codes de défaut du moteur à l'état de la batterie du véhicule électrique), moins de matériel à installer et de nouveaux services à offrir aux conducteurs et aux clients. Mais il pose aussi de nouveaux problèmes d'intégration, de gestion des données et de contrôle des coûts. La télématique des équipementiers n'est pas une solution miracle ; c'est plutôt un nouvel ingrédient dans la recette - un ingrédient qui doit être habilement mélangé aux ingrédients existants (dispositifs du marché secondaire, systèmes d'entreprise, etc.

Parmi les principales tendances à surveiller, citons les tentatives de normalisation (nous pourrions assister à une collaboration accrue entre les équipementiers sur les formats de données à mesure que la pression monte de la part de l'industrie et des régulateurs), la montée en puissance des places de marché de données universelles (imaginez que les données des véhicules deviennent aussi accessibles que les API de données des smartphones - ce qui n'est pas impossible avec des acteurs comme Google ou AWS qui lorgnent sur cet espace), et la pénétration des équipementiers sur le territoire traditionnel des FST en proposant leurs propres plates-formes de flottes. Toutefois, les flottes sont rarement assez homogènes pour qu'une solution OEM unique l'emporte, de sorte que les plateformes tierces continueront à jouer le rôle vital d'agrégateur de données et d'innovateur.

Pour les gestionnaires de flotte, l'idée pratique est la suivante : faites l'inventaire de vos sources de données. Sachez lesquels de vos véhicules peuvent fournir des données OEM et de quel type, et établissez un plan pour les intégrer. N'ayez pas peur d'exiger l'accès aux données lors de l'achat de véhicules - de nombreux équipementiers ont des programmes de données de flotte prêts à l'emploi, mais vous devrez peut-être demander et signer la ligne pointillée pour les activer. Après tout, il s'agit d'un actif que vous avez payé lors de l'achat du véhicule. Et si vous avez des lacunes, choisissez des solutions fiables sur le marché secondaire pour les combler.

Les fournisseurs de services télématiques doivent mettre l'accent sur la flexibilité et les partenariats. Construisez des systèmes capables d'ingérer des données de n'importe où et forgez des alliances avec des équipementiers ou des agrégateurs lorsque c'est possible - cela peut débloquer de nouvelles offres comme la télématique d'assurance, les prévisions d'entretien ou les mesures de durabilité (par exemple, l'utilisation de données précises sur la consommation de carburant pour calculer les émissions de carbone avec plus de précision). Investissez également dans l'analyse et les facteurs humains : avec une telle quantité de données disponibles, les gagnants seront ceux qui les rendront compréhensibles et conviviales. Un gestionnaire de flotte n'a pas besoin de données brutes, il a besoin d'informations exploitables, comme "Quels sont les véhicules qui doivent faire l'objet d'une maintenance la semaine prochaine ? Lorsque les données des équipementiers sont combinées à des algorithmes intelligents, vous obtenez des réponses à des questions que vous n'aviez même pas pensé à poser.

D'une manière subtilement humoristique, on pourrait dire que nous sommes passés de l'ère "pas de données, faites confiance à votre instinct" à l'ère "big data, trop d'instinct". Le rôle de plateformes telles que Navixy est de s'assurer que l'on a davantage l'impression d'avoir "les bonnes données, prêtes à l'action". Au fur et à mesure que la télématique gagnera en maturité, l'écosystème s'équilibrera probablement - peut-être que dans une décennie, nous ne ferons plus du tout la distinction entre les données des équipementiers et celles du marché secondaire ; il s'agira simplement de données sur les véhicules, universellement accessibles (on peut rêver !). D'ici là, il est essentiel de rester informé et de s'adapter.

La télématique de flotte a toujours eu pour but de relier les points - relier les véhicules au bureau, les conducteurs aux répartiteurs, les alertes de maintenance aux mécaniciens. La télématique intégrée des équipementiers a ajouté des millions de points à relier, dispersés dans les nuages et les API des équipementiers. C'est une image complexe, mais avec la bonne stratégie et les bons outils, elle devient une mosaïque vivante et perspicace de vos opérations. Le paysage est en effet en train de changer, mais comme nous l'avons vu, il change d'une manière qui, en fin de compte, permet à ceux qui sont prêts à s'adapter de s'en sortir. Il s'agit donc d'embrasser l'avenir connecté - un paquet de données à la fois - et de transformer ces flux de données en décisions commerciales plus intelligentes pour l'avenir.