Le contexte
Un équipementier industriel français fabrique des équipements installés chez des clients finaux répartis sur tout le territoire. Jusqu’ici, une défaillance se traduisait par un appel, un déplacement, un diagnostic sur place, et parfois une seconde visite parce que la bonne pièce n’était pas dans le camion.
L’équipementier voulait deux choses : savoir à distance comment ses équipements se comportent réellement en exploitation, et pouvoir restituer ces données à ses clients, qui commencent à les réclamer et à qui la réglementation européenne sur les données en donne le droit.
Ce que nous avons fait
Nous avons ajouté une remontée de données cellulaire depuis les équipements vers AWS IoT Core, puis construit la plateforme qui exploite ces données.
- Ingestion et stockage des mesures, avec un modèle de données conçu pour que l’ajout d’un nouveau type d’équipement ne demande pas de reprendre la chaîne.
- Maintenance prédictive par apprentissage sur l’historique d’exploitation, pour déclencher une intervention avant la défaillance plutôt qu’après l’appel du client.
- APIs documentées de restitution des données aux clients finaux, conçues pour répondre aux obligations de portabilité introduites par le Data Act.
- Trois canaux de restitution sur une même source : ces APIs REST pour les clients finaux, un serveur MCP pour les agents, et les interfaces web utilisées en interne. Trois vues d’un même jeu de données, et non trois chaînes de traitement à maintenir en parallèle.
- Des interfaces d’administration pour la gestion du parc et le suivi du SAV.
Le résultat
Les interventions se planifient au lieu de se subir, et le SAV répond avec l’historique complet de l’équipement sous les yeux.
La restitution de données, abordée au départ comme une contrainte réglementaire, s’est révélée être un argument commercial : l’équipementier vend désormais la visibilité sur les équipements comme un service, à des clients qui en avaient besoin sans savoir la demander.
Le point le plus délicat n’était pas le modèle prédictif mais le seuil d’alerte. Il arbitre entre fausses alertes et pannes manquées, et ce compromis appartient à l’équipe de maintenance, pas au modèle : un réglage métier, exposé comme tel, plutôt qu’un paramètre enfoui dans un notebook.