Introduction

Capteurs de vibration sur les organes tournants, supervision sur les lignes, remontées d'arrêts dans un outil de production : la donnée arrive. Elle ne répond pourtant pas à la question posée devant une machine arrêtée.

Vos capteurs et votre supervision mesurent l'état de la machine, pas la cause de la panne. Ils signalent qu'un seuil est franchi, rarement pourquoi. Le diagnostic demande une couche supplémentaire : le lien entre les composants, l'historique réel des interventions, et le raisonnement qui relie les deux.

Des plateformes comme Mimorian modélisent les équipements industriels et structurent le diagnostic de pannes, en s'appuyant sur ce que le site possède déjà plutôt qu'en réclamant un nouveau parc de capteurs. Voici ce que vos remontées machines savent faire, ce qu'elles ne font pas, et par quoi commencer.

Que mesurent réellement vos capteurs et votre supervision ?

Un capteur mesure une grandeur physique : température, vibration, pression, courant. La surveillance conditionnelle qui en découle est encadrée par la norme ISO 17359, qui décrit la chaîne allant de la mesure à l'alerte. Cette chaîne est solide, et elle répond à une question précise : l'état de cet organe dérive-t-il par rapport à sa référence.

La supervision, elle, affiche l'état de la ligne et remonte les messages que l'automate est programmé pour émettre. Là encore, la question traitée est celle de l'état courant.

Aucune de ces deux couches ne traite la question du technicien devant l'équipement arrêté : quelle est la cause, et dans quel ordre la vérifier. C'est une question de relations entre composants, pas de valeurs instantanées.

Le décalage est net sur le terrain. Un directeur industriel d'un site de production de pales résume la situation en une phrase que beaucoup reconnaîtront : trop de données tue la donnée. Les écrans se multiplient, la décision ne progresse pas.

Pourquoi votre historique de supervision n'est pas un historique de pannes

C'est le piège le plus coûteux, et il se repère rarement avant d'avoir perdu du temps.

Sur un site de pasteurisation alimentaire équipé d'automates et d'une supervision classique, le fichier fourni comme historique de défauts s'est révélé être la liste des messages que la supervision est capable d'afficher. Un catalogue, pas un vécu. Personne n'avait menti : la confusion entre les deux est naturelle quand les deux sortent du même outil.

La différence compte parce qu'un diagnostic s'appuie sur ce qui s'est réellement produit, avec quelle fréquence, sur quel équipement et avec quelle issue.

Un second décalage apparaît sur la qualité de saisie. Dans un site de parfumerie où la production et la maintenance vivent dans deux outils qui ne se parlent pas, les durées d'intervention sont saisies au rond supérieur. L'écart paraît négligeable sur une ligne, il fausse les analyses de fiabilité accumulées sur plusieurs années. Ce que l'on croit être une mesure est une estimation recopiée.

Chaque ligne du tableau est utile. Aucune ne suffit seule, et surtout, rien ne les relie entre elles.

Ce qui manque entre la mesure et le diagnostic

Trois éléments transforment des remontées en aide au diagnostic.

Le modèle de l'équipement

Quel composant dépend de quel autre. C'est lui qui permet de remonter d'un symptôme à des causes candidates, au lieu de lire des valeurs côte à côte. Cette modélisation est détaillée dans cet article sur la façon dont l'IA modélise vos équipements depuis les schémas.

L'historique réel des interventions

Avec ce qui a été trouvé et pas seulement ce qui a été remplacé. La plupart des sites le possèdent sans l'exploiter, comme le décrit cet article sur l'historique GMAO qui dort.

Le savoir qui n'a jamais été écrit

Sur le site de pasteurisation cité plus haut, une panne bien connue de l'équipe venait du débordement d'un compteur interne de l'automate, un comportement classique des entiers codés sur seize bits. Aucune remontée machine ne portait cette explication. Elle vivait dans la tête de deux personnes.

Faut-il connecter les machines pour commencer ?

Non, et c'est la réponse la moins attendue de la part d'un éditeur.

La connexion aux machines apporte un gain réel, tardif et coûteux à obtenir. Elle soulève des questions d'interopérabilité et de cybersécurité qui mobilisent la direction des systèmes d'information avant même le premier test. Sur plusieurs sites, ce point a suffi à retarder un projet de plusieurs mois.

Or l'essentiel du gain de diagnostic vient d'abord des schémas, de la documentation et de l'historique d'interventions, que vous détenez déjà et qui ne demandent aucun raccordement. La surveillance conditionnelle se branche ensuite, sur les organes où elle est pertinente.

Sur un site agroalimentaire équipé de capteurs d'usure et d'analyse vibratoire sur broyeurs, l'exploitation du nuage de données obtenu a été jugée difficile par l'équipe elle-même.

Cette progression rejoint un constat de McKinsey sur les sites industriels les plus avancés : une solution d'IA s'y déploie avec ses modes opératoires, sa documentation utilisateur et ses guides de formation pour les opérateurs [Source : McKinsey, 2024].

Mise en pratique : par où commencer avec l'existant

Quatre étapes, dans cet ordre.

1. Vérifiez la nature de ce que vous appelez historique. Ouvrez le fichier et cherchez les issues d'intervention. Si vous n'y trouvez que des libellés de messages, vous tenez un catalogue.

2. Reliez les arrêts de production aux interventions de maintenance. Sur beaucoup de sites, l'outil de production sait quand la ligne s'est arrêtée et la GMAO sait qui est intervenu, sans qu'aucun lien n'existe entre les deux.

3. Mesurez la couverture réelle de vos indicateurs. Dans un groupe de services industriels multi-sites, le taux de panne n'était calculé que sur les machines dotées de personnel posté. Le chiffre était juste, son périmètre ne couvrait pas le parc.

4. Ajoutez le modèle de l'équipement, pour que ces données deviennent interrogeables depuis un symptôme.

Questions fréquentes

Q : Faut-il abandonner les capteurs déjà installés ? R : Non. Ils restent utiles là où ils ont été posés, sur les organes tournants notamment. Ils changent de rôle : ils deviennent une entrée du diagnostic parmi d'autres, plutôt que la promesse d'une prédiction autonome.

Q : Notre supervision remonte déjà des codes de défaut, est-ce suffisant ? R : Un code de défaut nomme une condition détectée, pas sa cause. Le même code peut venir d'un capteur, de son câblage ou de l'organe surveillé. Le tri demande le modèle de la machine.

Q : Notre direction des systèmes d'information bloque toute connexion machine. R : C'est une contrainte fréquente, et elle n'empêche pas de démarrer. Les schémas, la documentation et l'historique d'interventions ne demandent aucun raccordement aux automates.

Q : Nos saisies d'intervention sont approximatives, est-ce rédhibitoire ? R : Non, mais il faut le savoir avant d'en tirer des analyses de fiabilité. Un historique imprécis reste exploitable pour retrouver des cas semblables, il l'est beaucoup moins pour calculer des durées.

Conclusion

Trois points à retenir.

1. Vos capteurs et votre supervision répondent à la question de l'état, pas à celle de la cause. Ce sont deux problèmes différents.

2. Ce que vous appelez historique mérite d'être ouvert avant d'être exploité : un catalogue de messages et un vécu d'interventions ne se ressemblent que de loin.

3. La connexion aux machines est une étape tardive, pas un prérequis. Les schémas et l'historique d'interventions suffisent à démarrer.

Prochaine étape concrète : ouvrez votre export d'historique et comptez combien de lignes portent une issue d'intervention. Ce chiffre vous dira où vous en êtes.

Pour une vue d'ensemble du sujet, ce guide complet du diagnostic guidé par IA en maintenance reprend la méthode.

Sources : ISO 17359:2018 : Condition monitoring and diagnostics of machines · McKinsey, 2024 : How manufacturing's Lighthouses are capturing the full value of AI

Article publié initialement sur le blog Mimorian.