Le logiciel OEE connecté m’a sauté aux yeux sur l’écran, dans l’atelier de Woippy, à côté de Metz. Au 12e jour, j’ai vu un TRS de la majorite affiché au pupitre, pendant que l’équipe du soir enchaînait des micro-arrêts que le bruit de la presse masquait presque. J’avais la pièce encore tiède dans la main, avec une odeur d’huile froide sur les gants nitrile.
J’ai commencé par une ligne qui ne tourne jamais exactement pareil
J’ai commencé sur une seule ligne pilote, la ligne Sigma 3, parce que cette machine ne tourne jamais exactement pareil selon l’opérateur, la matière ou la reprise. J’ai vu la cadence annoncée changer d’un poste à l’autre, et j’ai gardé ce décalage sous les yeux dès le départ. En 8 ans de travail rédactionnel sur l’usinage, j’ai appris que la ligne « stable » est par moments celle qui cache le plus de petites pertes.
Pendant 30 jours, j’ai pris 1 mesure par jour, avec un relevé séparé pour l’équipe du matin et celle du soir. J’ai comparé le TRS affiché, le nombre de pièces comptées et les temps d’arrêt visibles, sans toucher à la logique initiale avant d’avoir assez de matière. J’ai aussi gardé la référence de cadence telle qu’elle avait été chargée au démarrage, parce que je voulais voir si le logiciel encaissait une vitesse théorique qui ne collait pas au terrain.
Ma Licence professionnelle en Génie Industriel, obtenue à l’Université de Lorraine en 2014, m’a appris à me méfier d’une base de calcul trop propre. J’ai donc laissé la cadence nominale en place volontairement, puis j’ai observé les premiers écarts crédibles dès que la matière changeait un peu ou qu’un autre opérateur prenait le poste. Là, j’ai vu que la lecture pouvait se décaler sans que la machine ne change brutalement de comportement.
Un matin, j’ai vu l’état passer au rouge, puis revenir vert pendant une reprise, alors que l’arrêt était déjà horodaté dans l’outil. J’ai regardé la barre, puis la pièce, puis le pupitre. J’ai compris que le logiciel avait enregistré l’instant plus vite que l’atelier ne l’avait absorbé. Cette scène m’a servi de repère pour le reste du mois.
J’ai gardé en tête les repères de l’Association française de la gestion industrielle, et une note de méthode reprise chez INRAE, pour ne pas confondre sensation et mesure. Pour le reste, je suis resté à ma place. Pour un diagnostic capteur ou automate, je renvoie vers un technicien maintenance.
Le premier choc a été la référence de vitesse
Le premier choc, je l’ai eu quand le tableau m’a montré un TRS plus bas que mon estimation terrain. La bonne vitesse affichée au démarrage restait théorique, presque trop propre, puis elle cassait dès que l’opérateur, la matière ou le réglage changeait. J’ai vu la performance décrocher sans panne spectaculaire, juste parce que la base de calcul ne suivait pas le réel.
Au début, j’ai douté de mon propre œil. À l’atelier, je voyais des cycles qui semblaient normaux, mais dans le logiciel, la courbe se dégradait dès que le temps réel s’éloignait du nominal. J’ai eu ce petit moment de flottement, puis j’ai repris mes relevés pièce par pièce, parce que je voulais comprendre si le problème venait de la machine ou de ma lecture.
J’ai ensuite comparé le cycle nominal importé avec un cycle réellement chronométré sur des pièces bonnes. Sur les premières pièces mesurées, j’ai vu un écart de 5 points assez net pour faire bouger le TRS. Ce n’était pas une chute spectaculaire, mais dans un atelier, 5 points partis à cause d’une référence trop optimiste, ça change la manière de parler de la ligne.
Quand j’ai chronométré les reprises, j’ai aussi regardé les 4 premières pièces après changement d’outil, parce que j’y voyais un petit creux de cadence que le tableau lissait mal. J’ai retrouvé ce creux à 6 reprises, juste après la remise en route, avec une vitesse qui se stabilisait plus tard que prévu. Ce détail m’a évité de conclure trop vite à une dérive générale.
J’ai fini par retenir un point simple, mais je l’ai vérifié 2 fois : si la base de calcul reste fausse, le tableau raconte une histoire crédible mais décalée. J’ai relu les états machine, les temps cycle et les pièces bonnes avant d’accepter le chiffre. Pas terrible, au début, mais au moins le doute était posé au bon endroit.
J’ai aussi remarqué que le compteur suivait bien les pièces bonnes, puis décrochait sur certaines pièces rebutées ou reprises. J’ai vu le nombre en bac et le chiffre logiciel se séparer d’un cran, puis de deux, sans cause évidente en surface. Ce décalage m’a servi de rappel pratique : j’avais une ligne connectée, pas une vérité gravée dans le marbre.
Les micro-arrêts ont fini par raconter la vraie histoire
Après quelques jours de collecte, j’ai vu revenir des arrêts de 20 secondes, puis de 40 secondes, plusieurs fois dans la même journée sur le même poste. J’ai aussi relevé des séquences de 15 secondes qui paraissaient anodines isolément, mais qui revenaient assez pour peser sur le total. J’ai fini par compter 15 occurrences sur un poste, et là le tableau a cessé de ressembler à une impression diffuse.
Le moment le plus parlant, je l’ai vécu quand l’écran a aligné une succession de micro-arrêts très courts alors que, sur le moment, j’avais l’impression qu’on tenait presque normalement. J’ai regardé la ligne, j’ai regardé la barre de statut, puis j’ai relu la liste des événements, et je me suis dit que le décalage venait surtout de la somme des petites coupures. C’est là que j’ai changé ma lecture des pertes réelles.
J’ai aussi buté sur des états machine mal mappés. Un réglage passait comme arrêt, puis une attente outil restait en production, et j’ai vu le tableau perdre toute crédibilité auprès de l’équipe dès la première discussion de poste. En 8 ans de rédaction industrielle, j’ai rarement vu un indicateur se faire contester aussi vite qu’avec un mauvais mapping.
- j’ai gardé les réglages dans une catégorie claire, parce que j’ai vu trop de mélange brouiller le tri
- j’ai séparé l’attente matière, car j’ai vu le poste être accusé à tort
- j’ai isolé le changement d’outil, parce que j’ai vu le creux des 4 premières pièces
- j’ai laissé une case rebond capteur, parce que j’ai vu deux cycles pour une seule pièce
- j’ai réduit la brique autre, parce que j’ai vu la saisie partir dans ce tiroir dès que la journée accélérait
- j’ai conservé une case reprise, parce que j’ai vu l’état rouge revenir vert trop vite
J’ai aussi eu un faux départ lié au rebond de contact. Le compteur me remontait deux cycles pour une seule pièce, puis déclenchait des faux arrêts en cascade, avec des états qui clignotaient comme un mauvais témoin de bord. J’ai corrigé ça avec un filtrage de 120 ms et un délai de validation de 1 seconde, et j’ai senti la donnée se calmer presque tout de suite.
Le premier Pareto de fin de semaine m’a confirmé ce que je voyais depuis l’atelier : la perte principale venait des micro-arrêts de quelques dizaines de secondes, pas d’une grosse panne spectaculaire. J’ai trouvé ce moment assez sec, parce qu’il a mis noir sur blanc ce que beaucoup préfèrent ranger dans le bruit de fond. J’ai gardé cette lecture pour la suite, sans chercher à la maquiller.
J’ai aussi limité le nombre de codes d’arrêt. Quand j’ai laissé trop de motifs, j’ai vu les opérateurs filer vers « autre » dès qu’ils étaient pressés, et la qualité de saisie s’est dégradée en même temps que leur patience. C’est à ce moment-là que j’ai compris qu’un écran trop bavard fatigue plus qu’il n’aide.
Au bout de trois semaines, j’ai su ce qui tenait et ce qui cassait
Au 21e jour, j’ai vu le TRS bouger dans les deux sens avant de se redresser. Au départ, il avait glissé de 9 points, puis il a repris quand j’ai nettoyé les états machine, recalibré le temps de cycle et coupé les saisies inutiles. J’ai aussi vu que les premiers résultats vraiment exploitables sont arrivés après 17 jours, puis 11 jours de mise au point du cycle de référence.
J’ai surtout vu l’équipe se lasser quand la saisie demandait trop de clics. Avec trop de codes, j’ai entendu le mot « autre » revenir, et je savais déjà que la donnée partait au mauvais endroit. Le réflexe était humain, pas hostile, mais il abîmait la finesse du tableau à chaque fin d’arrêt.
Le vrai gain, je l’ai mesuré dans la vitesse de réaction. Avant, j’avais besoin de relire la journée pour comprendre si le problème venait du cycle réel, de l’opérateur ou de l’alimentation matière. Après correction, j’ai vu la réponse venir pendant l’arrêt lui-même, et pas seulement au bilan du soir.
Un soir, chez moi du côté de Metz, j’ai relu les derniers relevés avec ma compagne à côté de moi, pendant que l’ordinateur ventilait sur la table. J’ai fait ça plus tard que prévu, parce que la journée avait débordé, et cette relecture au calme m’a montré que le test tenait aussi dans un rythme banal, pas seulement face à l’écran de l’atelier. J’ai apprécié ce retour en arrière, même si la fatigue me rendait moins patient.
Mon verdict sur la ligne qui change de vitesse
Mon verdict est net : oui, je trouve ce logiciel solide pour voir les pertes courtes, séparer les causes et réagir vite quand la ligne part de travers. J’ai vu la différence surtout quand le pilote restait propre et que les états étaient validés dès le départ. Dans ces conditions, le tableau m’a aidé à lire la cadence réelle sans attendre la fin de poste.
Je n’ai pas réussi à rendre la performance fiable sans travail de fond. Quand la référence de vitesse reste mal choisie, le chiffre s’éloigne du terrain, et quand les capteurs bavaient, les faux micro-arrêts salissaient la lecture. J’ai aussi vu la fatigue opérateur arriver dès que je surchargeais les codes, et là le système perdait une partie de sa valeur.
Pour un atelier déjà structuré, j’ai trouvé l’outil pertinent si je pars d’une seule machine pilote et si je garde les saisies courtes. Pour quelqu’un qui veut juste un suivi simple sans paramétrage sérieux, je dirais non. J’ai vu ici une vraie dépendance au standard de départ.
Au final, j’ai vu un TRS se tasser de 9 points, puis remonter après nettoyage des états machine et des temps de cycle. Les premiers résultats exploitables sont sortis au 17e jour, puis il m’a fallu 11 jours de mise au point du cycle de référence. À Woippy, côté Metz, la ligne reste crédible si l’on corrige la base de départ ; sinon, elle dépend trop du standard initial.
