Cas d’usage · Industrie
Des pannes anticipées, et une alerte avant l’arrêt
Les mesures de vos capteurs et l’historique de maintenance alimentent un modèle qui estime le risque de défaillance de chaque équipement. Le score est recalculé à chaque nouveau lot de mesures, servi à vos applications, et la liste des équipements à surveiller est prête avant l’arrêt.
Le défi
Des mesures abondantes, des pannes rares
- Des séries de capteurs volumineuses, à des fréquences différentes selon les équipements.
- Des pannes rares, décrites dans un historique de maintenance saisi à la main.
- Des sites de production parfois isolés du réseau de l’entreprise.
- Des données de production qui ne sortent pas de l’usine.
Comment graal le traite
Du capteur au score servi
Étape 01
Collecter
Les mesures exportées par vos automates ou votre historien arrivent sur S3, les ordres de maintenance sont lus dans votre base. Chaque nouveau dépôt déclenche la suite.
Étape 02
Préparer les signaux
Un pipeline calcule, par équipement, des fenêtres glissantes, des moyennes et des écarts. Des contrôles qualité écartent les capteurs muets ou aberrants.
Étape 03
Entraîner
Vos data scientists entraînent le modèle de risque sur Spark distribué ou sur GPU. Chaque essai est tracé dans les expériences.
Étape 04
Servir
Le modèle retenu passe au registre, puis il est servi en REST derrière votre SSO : vos outils de maintenance l’interrogent directement.
Étape 05
Surveiller
Un job planifié publie chaque jour les équipements à surveiller. La dérive des données est suivie, et une alerte prévient l’équipe quand le modèle se dégrade.
Le scénario type réunit trois sources que la plupart des sites possèdent déjà : les mesures des capteurs, l’historique des interventions et la liste des équipements. Le pilote commence par une famille d’équipements, celle dont les arrêts coûtent le plus, puis le modèle s’étend au reste du parc.
Le Data Act, applicable depuis le 12/09/2025, donne aux entreprises le droit d’accéder aux données produites par l’usage de leurs machines et objets connectés, et de les partager, par exemple pour la réparation et la maintenance.
Ce que vous obtenez
- Un score de risque par équipement, recalculé à chaque nouveau lot de mesures
- Un point d’accès REST que vos outils de maintenance interrogent
- Une dérive surveillée, pour savoir quand réentraîner
- Des interventions planifiées plutôt que subies
Ce qui reste chez vous
- Les mesures de vos capteurs et l’historique de maintenance
- Le modèle, ses versions et ses données d’entraînement
- Le point d’accès, servi dans votre infrastructure
Capacités mobilisées
- Connecteurs
S3, bases de données et API REST de votre historien.
- Pipelines low-code
Fenêtres glissantes, agrégats et contrôles qualité.
- Orchestration et calcul
Déclencheurs sur événement, Spark distribué et GPU.
- Machine learning
Expériences, registre, serving REST et suivi de dérive.
- Gouvernance
Un projet par site, des droits et un audit par projet.
Questions fréquentes
Faut-il un flux de données en temps réel ?
Non. Des lots réguliers de mesures, déposés sur S3 ou lus dans une base, suffisent : chaque dépôt déclenche le calcul.
Et si le site n’a pas accès à Internet ?
graal s’installe hors ligne, depuis votre propre registre d’images, sur le Kubernetes du site.
Peut-on reprendre nos modèles existants ?
Oui. Un modèle journalisé avec le client MLflow s’enregistre au registre et se sert comme les autres.
Commencez par une famille d’équipements
En 8 semaines, un premier modèle de risque sur vos mesures, servi dans votre infrastructure.