Étude de cas : maximiser l'utilisation de la flotte sur 3 régions

Un OEM d'équipements industriels exploitait des actifs sur trois régions sans pouvoir dire, avec certitude, à quel point chacun travaillait. La télémétrie était déjà déployée. Le problème tenait à ce qu'elle produisait : des chiffres auxquels personne ne se fiait. Chaque région définissait « en usage » et « inactif » un peu différemment, si bien qu'un taux d'utilisation venu d'un dépôt signifiait autre chose au suivant.

Sous l'ensemble se trouvait une plateforme fermée. Les données brutes restaient derrière l'API du fournisseur, chaque nouvelle alerte ou nouveau rapport devenait une demande de modification, et chaque demande avait un prix et une place dans la roadmap du fournisseur, pas dans celle de l'OEM. Un ajustement de seuil qui aurait dû prendre un après-midi prenait un trimestre. Les frais de licence et par fonctionnalité montaient pendant que la capacité réelle, elle, ne bougeait pas.

Sur le terrain, c'était encore plus confus. La connectivité variait d'un site à l'autre, d'une 4G solide sur un hub de service à une couverture intermittente sur les déploiements isolés. Différents sous-traitants exploitaient différentes régions selon différentes conventions. Le résultat : un reporting d'usage incapable de soutenir une vraie décision sur l'endroit où envoyer une machine ou le moment où la réviser.

Le cahier des charges était précis. Passer à une passerelle Linux embarquée ouverte que l'OEM possède entièrement : code source, images de build et les données que ces passerelles produisent, sans aucune couche laissée derrière une API fournisseur.

Une seule définition de l'utilisation devait valoir sur les trois régions. Si un KPI signifiait la même chose dans chaque dépôt, les disputes entre régions cessaient et les décisions d'allocation des actifs pouvaient s'y appuyer. Les signaux de maintenance et les seuils d'alerte devaient être modifiables par l'équipe même de l'OEM, en jours, et non déposés comme demande payante contre le calendrier de releases d'un tiers.

Et il fallait que cela monte en charge sans heurts : provisionnement reproductible, pipelines de données prévisibles et une séquence d'onboarding qu'un technicien peut mener au dépôt suivant sans ingénieur Melqart sur site.

Melqart Systems a livré une pile passerelle Linux embarquée ouverte dont l'OEM détient la base de code. L'équipe avait un accès complet au logiciel edge : le lire, le modifier, reconstruire l'image, la déployer en OTA. Rien dans la couche terrain n'exigeait un appel au fournisseur.

Les passerelles parlaient les protocoles réellement utilisés par la flotte. CAN bus (J1939) sur la transmission et les calculateurs moteur, I/O numériques et analogiques pour les contacts, les niveaux et les lignes de capteurs qui n'atteignaient jamais le bus, et des capteurs externes câblés là où un signal manquait. Une flotte mixte d'équipements mobiles, de véhicules d'accompagnement et de machines spécialisées est arrivée sur une seule couche d'acquisition. Chaque passerelle tamponnait localement et transmettait à la reconnexion, de sorte qu'une perte de couverture retardait les données au lieu de les perdre.

Un seul schéma de télémétrie couvrait toute la flotte. Noms de champs, unités et formules derrière chaque KPI étaient définis une fois et appartenaient à l'OEM. Ces définitions étaient versionnées : quand « heures moteur » ou « inactif » changeait, le changement était explicite et daté, au lieu de dériver en silence d'une région à l'autre. C'est précisément ce contrat unique qui rendait un chiffre d'un dépôt comparable à celui d'un autre.

Au-dessus, une seule vue opérationnelle pour le dispatch et la maintenance : état des actifs en direct, KPI d'utilisation, détection d'inactivité et alertes par exception ne se déclenchant que lorsqu'un humain était nécessaire. Les agrégats hebdomadaires et mensuels s'exportaient directement, sans chirurgie de tableur.

Le dispatch l'a ressenti en premier. Un seul écran affichait désormais chaque actif comme disponible, en usage ou inactif, tiré partout des mêmes définitions. La dispute permanente sur les chiffres de qui avaient raison a tout simplement cessé, et une décision qui demandait une série d'appels demandait désormais un coup d'œil.

Comme les chiffres tenaient entre régions, les machines allaient là où elles rapportaient. Un actif laissé inactif dans une région pendant qu'une autre payait pour louer le même type d'équipement était repéré tôt, et ce chevauchement disparaissait. La maintenance a gagné ce qu'elle n'avait jamais eu sous la plateforme fermée : ajuster elle-même un seuil d'alerte, directement dans la pile passerelle, le jour même où un schéma apparaissait sur le terrain. Pas de ticket, pas d'attente d'une release fournisseur. Les révisions se calaient sur l'usage réel des machines, les arrêts non planifiés baissaient et la disponibilité montait.

La livraison s'est faite en trois phases, volontairement réduites au départ. Les semaines une à trois furent un pilote : un échantillon représentatif d'actifs sur les trois régions, instrumenté pour capter une baseline. Utilisation réelle, schémas d'arrêt réels, délais de dispatch réels, les chiffres qui diraient plus tard si quelque chose s'était amélioré.

Les semaines quatre à huit ont étendu le déploiement dépôt par dépôt et région par région, chaque installation suivant les mêmes étapes de provisionnement, de sorte que la dixième passerelle se posait comme la première. Les tableaux de bord par rôle sont arrivés dans cette fenêtre : une vue pour le dispatch, une pour les opérations, une pour la maintenance, chacune affichant les données sur lesquelles ce rôle agit, et guère plus.

Les semaines neuf à douze ont porté sur la qualité du signal. Les seuils ont été ajustés pour réduire le bruit d'alerte, les rapports KPI hebdomadaires figés dans un modèle, et les workflows passés en mode exception d'abord : le système restait silencieux jusqu'à ce que quelque chose mérite vraiment l'attention, puis escaladait. Moins à surveiller, rien d'important manqué.

Après le déploiement complet et la période d'optimisation, le client a rapporté une hausse d'environ 25 % de l'utilisation des actifs. Elle venait de moins de machines inactives, de décisions d'allocation plus rapides et de locations qui ne compensaient plus des actifs déjà inutilisés ailleurs. Une définition fiable et partagée de l'utilisation faisait le travail.

Le dispatch s'est resserré. Avec une vue commune de l'état des actifs, les allers-retours sont tombés et les actifs se déplaçaient plus vite entre dépôts, avec moins de flou sur ce qui était réellement disponible.

La dépendance fournisseur a fortement chuté. Les changements d'alerte et de KPI qui attendaient un trimestre passaient désormais en production en jours, parce que l'OEM les faisait lui-même. Les frais de modification par fonctionnalité et la ligne de licence récurrente ont disparu, et la pile télématique avançait sur la roadmap de l'OEM plutôt que sur celle d'un tiers. La leçon la plus claire : le gain venait de meilleurs signaux et d'une vérité opérationnelle partagée, pas d'un volume de données accru.

La propriété de l'IP passerelle a porté le projet. Avec le contrôle complet de la pile edge, l'OEM pouvait la modifier à son propre rythme, et c'est ce qui a transformé l'attente trimestrielle en correctif le jour même.

Le schéma de télémétrie unique a fait le travail discret et structurel. Un seul jeu de définitions sur toute la flotte signifiait qu'aucun tableau de bord ne se contredisait et qu'aucune région ne se disputait sur un KPI.

Les workflows par exception ont rendu le système vivable. Personne n'avait à veiller sur un tableau de bord ; le système réclamait l'attention seulement quand elle se justifiait, et c'est ce qui fait durer une telle solution au-delà du premier mois.

Le design résilient à la connectivité a maintenu la confiance. Le tampon local et le transport store-and-forward faisaient qu'une perte de couverture retardait les données au lieu de les perdre, et un système télématique qui laisse tomber des mesures en silence est un système auquel les opérateurs cessent de croire.

Mesurez avant de rien changer. Sans baseline captée pendant le pilote, les 25 % auraient été une affirmation, pas un résultat. Les premiers chiffres du pilote sont ce qui a permis à l'équipe de prouver le changement plutôt que de l'asséner.

Posséder l'edge, c'est acheter de la vitesse. Parce que l'OEM détenait la pile, les changements arrivaient en jours au lieu d'attendre une release fournisseur, un écart qu'aucune plateforme propriétaire n'offrait.

Les KPI ne comptent que s'ils collent à la façon dont les gens travaillent. Les métriques qui reflétaient le workflow dispatch servaient chaque jour ; celles qui ne le faisaient pas étaient ignorées en silence, quel que soit l'aspect de leur tableau de bord. Ajustez la télémétrie au processus, et l'investissement se rentabilise.

Pour tout OEM exploitant des actifs sur plusieurs sites, le schéma se répète. Partez d'une pile passerelle ouverte qui vous appartient : cela règle la question de l'IP et met fin au lock-in avant qu'il ne s'installe.

Définissez le schéma de télémétrie une fois, pour qu'un chiffre signifie la même chose dans chaque région et qu'il ne reste rien à contester. Construisez ensuite les tableaux de bord autour du workflow dispatch plutôt qu'autour des données, afin que la télémétrie pilote les décisions au lieu de rester inutilisée.

Gardez l'alerte par exception. L'attention va vers ce qui exige une action, pas vers un mur de tuiles vertes, et c'est ce qui garde un système télématique de flotte utile longtemps après le lancement, tant qu'il fait un vrai travail sur l'utilisation et la disponibilité.