Fiabiliser le TRS sans saisie manuelle grâce aux données machines

Fiabiliser le TRS sans saisie manuelle : passer de l’estimation à la donnée machine

Un TRS fiable ne peut pas reposer uniquement sur des déclarations manuelles. Pour piloter la performance, il faut capter les bons états machine, mesurer les arrêts courts et relier les données aux causes terrain.

Vincent Goossens
Rédigé par
Vincent Goossens

Performance industrielle

3 juin 2026

Dans beaucoup d’ateliers, le TRS existe déjà.

Il est affiché dans un tableau Excel. Il apparaît dans un rapport de production. Il est commenté en réunion du matin. Il sert parfois à comparer des lignes, des machines ou des équipes.

Mais une question revient souvent :

est-ce que ce TRS reflète vraiment ce qui s’est passé sur la machine ?

C’est là que les discussions commencent.

La production sait que la cadence n’a pas été bonne.
L’opérateur explique qu’il a relancé plusieurs fois la machine.
La maintenance ne voit pas de panne longue.
Les méthodes soupçonnent des pertes entre deux cycles.
Et le tableau indique un TRS “pas si mauvais”.

Le problème n’est pas forcément la formule du TRS. Le problème vient souvent de la donnée qui l’alimente.

Un TRS calculé avec des arrêts mal déclarés, des cadences théoriques irréalistes ou des causes trop vagues donne une impression de pilotage. Mais il ne permet pas toujours d’agir.

Pour une PME industrielle, fiabiliser le TRS ne veut pas dire installer une usine à gaz digitale. Cela veut dire rendre la machine plus lisible : quand elle produit, quand elle attend, quand elle s’arrête, pourquoi elle perd de la cadence.

Et pour cela, la saisie manuelle ne suffit pas toujours.

Pourquoi la saisie manuelle atteint vite ses limites

La saisie manuelle n’est pas inutile. Au contraire, elle apporte un contexte que la machine ne connaît pas toujours.

Un opérateur peut expliquer qu’une série était particulière, qu’une pièce était difficile à positionner, qu’un réglage a été repris, qu’un contrôle qualité a pris plus de temps ou qu’un approvisionnement a manqué.

Cette information terrain est précieuse.

Mais demander à l’opérateur de saisir tous les événements de production est rarement réaliste.

Dans un atelier, l’opérateur ne passe pas sa journée devant un formulaire. Il charge, décharge, contrôle, surveille, règle, nettoie, appelle la maintenance, gère les imprévus et fait repartir la machine.

Quand un arrêt dure 20 secondes, il n’est souvent pas saisi.

Quand un défaut revient cinq fois dans l’heure, il peut être regroupé dans une cause générale.

Quand la machine tourne moins vite que prévu, mais sans arrêt franc, il n’y a parfois rien à déclarer.

À la fin du poste, le rapport donne une image approximative. Pas parce que les équipes travaillent mal, mais parce que le système leur demande de déclarer manuellement ce qu’une machine pourrait mesurer automatiquement.

Le vrai problème : un TRS contesté ne sert plus à grand-chose

Un indicateur de performance doit créer de la clarté.

Si le TRS devient un sujet de débat permanent, il perd une partie de sa valeur.

On entend alors des phrases comme :

“Le TRS est faux.”
“Les arrêts ne sont pas tous saisis.”
“Les micro-arrêts n’apparaissent pas.”
“Le temps de cycle standard n’est plus à jour.”
“On ne sait pas si la machine était vraiment en production.”
“Les causes d’arrêt sont trop générales.”

Ce n’est pas seulement un problème de reporting. C’est un problème d’amélioration continue.

Si le TRS n’est pas fiable, les priorités deviennent floues. La maintenance ne sait pas quels défauts traiter en premier. Les méthodes ne savent pas où agir. La production manque d’éléments pour arbitrer. La direction voit un chiffre, mais pas toujours la réalité atelier.

Un bon TRS doit aider à répondre à des questions simples :

où perdons-nous du temps ?

combien cela représente-t-il ?

est-ce un problème d’arrêt, de cadence ou de qualité ?

quelle cause revient le plus souvent ?

quelle action doit passer en priorité ?

Tant que ces réponses reposent principalement sur de l’estimation, le pilotage reste fragile.

Pourquoi les données machines changent la logique

Les données machines ne remplacent pas le terrain. Elles l’éclairent.

Elles permettent de passer d’un ressenti à un fait mesurable.

Au lieu de dire :

“On a souvent des petits arrêts.”

On peut dire :

“Sur cette équipe, la machine a passé 37 minutes en attente entre deux cycles, réparties en 64 événements de moins d’une minute.”

Au lieu de dire :

“La cadence semble plus basse sur cette référence.”

On peut dire :

“Le temps de cycle réel est supérieur de 12 % au standard sur cette référence, principalement après changement d’outil.”

La différence est importante.

Dans le premier cas, on débat.
Dans le second, on analyse.

L’étude La Fabrique de l’Industrie/McKinsey définit l’IoT comme des réseaux d’objets capables de collecter et d’échanger des données pour améliorer l’efficacité et la gestion des ressources. Elle définit aussi l’analytique avancée comme le traitement de grandes quantités de données pour améliorer la prise de décision.

Pour le TRS, cela se traduit très concrètement : récupérer les bons signaux machine, les historiser, les transformer en états compréhensibles, puis les relier aux causes terrain.

Ce n’est pas “faire de la data” pour faire moderne.

C’est mesurer ce qui était jusqu’ici estimé.

Que faut-il mesurer pour fiabiliser le TRS ?

Un TRS fiable ne commence pas par un écran. Il commence par une bonne définition des états machine.

La question de base est simple :

à quel moment la machine produit-elle réellement une pièce bonne, à la cadence attendue ?

À partir de là, il faut distinguer plusieurs situations.

La machine peut être en production réelle. Elle peut être en attente. Elle peut être arrêtée. Elle peut être en défaut. Elle peut être en réglage. Elle peut être en mode manuel. Elle peut aussi produire, mais trop lentement.

C’est souvent cette dernière situation qui pose problème.

Une machine qui ne s’arrête jamais complètement peut quand même perdre beaucoup de performance. Si le système ne suit que “marche” et “arrêt”, cette perte reste invisible.

Pour fiabiliser le TRS, les signaux utiles peuvent être :

état marche/arrêt ;

cycle actif ;

mode automatique ou manuel ;

alarme active ;

compteur pièces ;

pièces bonnes et mauvaises ;

temps de cycle réel ;

temps entre deux cycles ;

défaut sécurité ;

attente opérateur ;

présence pièce ;

consommation ou activité machine ;

redémarrage après défaut.

Tous ces signaux ne sont pas nécessaires sur toutes les machines. Le bon choix dépend du process, de l’âge de l’équipement, de l’automate, des capteurs disponibles et de l’objectif de suivi.

L’important est de ne pas tout mesurer. L’important est de mesurer ce qui permet d’agir.

Le piège du TRS “automatique” mal défini

Automatiser le calcul du TRS ne garantit pas un TRS fiable.

On peut très bien automatiser une mauvaise logique.

Par exemple, si la machine est considérée en production dès que le voyant “marche” est actif, le TRS peut être trompeur. La machine peut être sous tension, prête à produire, ou en attente entre deux cycles, sans produire réellement.

Même chose si les temps de cycle standards ne sont pas à jour.

Un écart de cadence peut être interprété comme une perte de performance alors que le standard est irréaliste. À l’inverse, un standard trop large peut masquer une dérive réelle.

Un bon projet TRS doit donc clarifier trois éléments :

la donnée collectée ;

la règle de calcul ;

l’usage attendu par les équipes.

C’est ce qui évite de créer un indicateur propre en apparence, mais contesté dès qu’il est utilisé.

Exemple simple : une ligne qui affiche un bon taux de marche mais produit trop peu

Prenons une ligne semi-automatique.

Dans le rapport quotidien, la ligne affiche un taux de marche correct. Les arrêts longs sont rares. Les opérateurs n’ont pas déclaré de grosse difficulté.

Pourtant, la production réelle est inférieure à l’objectif.

Sans donnée machine détaillée, plusieurs hypothèses se mélangent :

les arrêts courts sont-ils sous-déclarés ?

la ligne attend-elle un poste amont ?

le poste aval crée-t-il des blocages ?

les changements de série prennent-ils plus de temps que prévu ?

la cadence réelle est-elle inférieure au standard ?

les défauts qualité entraînent-ils des relances ?

En connectant quelques signaux bien choisis, la lecture change.

On découvre parfois que la ligne ne s’arrête pas longtemps, mais qu’elle attend très souvent. Ou que le temps entre deux cycles varie fortement. Ou que les pertes se concentrent sur une référence. Ou que les arrêts courts sont trop nombreux pour être saisis manuellement.

La donnée ne donne pas toute la réponse. Mais elle indique où regarder.

Et c’est déjà beaucoup.

La bonne place de l’opérateur dans un TRS fiabilisé

Fiabiliser le TRS sans saisie manuelle ne veut pas dire supprimer l’opérateur du suivi.

C’est même l’inverse.

L’automate, les capteurs ou le boîtier IoT peuvent mesurer les faits : marche, arrêt, cycle, alarme, cadence, comptage.

Mais le terrain reste indispensable pour comprendre le pourquoi.

La bonne logique consiste à automatiser ce qui peut l’être, puis à demander à l’opérateur uniquement ce qui a de la valeur.

Par exemple, il n’a pas besoin de saisir qu’un arrêt a commencé à 9h14 et s’est terminé à 9h15. La machine peut le mesurer.

En revanche, il peut être utile qu’il précise la cause : manque matière, attente contrôle, défaut outillage, réglage, nettoyage, problème qualité.

La saisie devient alors plus légère, plus ciblée et plus fiable.

On ne demande plus à l’opérateur de faire le travail de la machine. On lui demande d’apporter son expertise terrain.

Commencer simple : une machine critique, quelques signaux, un usage clair

Beaucoup de projets de suivi TRS échouent parce qu’ils démarrent trop large.

Trop de machines.
Trop d’indicateurs.
Trop de causes d’arrêt.
Trop d’écrans.
Trop peu d’usage terrain.

Une approche plus efficace consiste à commencer par une machine ou une ligne critique.

Celle qui bloque la production. Celle qui génère des discussions. Celle dont le TRS est contesté. Celle où les micro-arrêts sont suspectés. Celle où un gain de visibilité peut vraiment aider les équipes.

La présentation Francis Rossignol sur l’usine 4.0 pour les PME et ETI insiste justement sur le fait de passer d’une logique technologique à une logique d’usage métier, en partant des irritants opérationnels comme la qualité, la cadence ou l’ergonomie, puis en identifiant les cas d’usage à ROI rapide.

C’est exactement la bonne logique pour le TRS.

On ne démarre pas par “il nous faut un logiciel”.
On démarre par “quel problème de production voulons-nous objectiver ?”

Les étapes pour passer d’un TRS estimé à un TRS fiable

1. Vérifier la formule utilisée

Avant de connecter quoi que ce soit, il faut vérifier ce que l’entreprise appelle TRS.

Les trois composantes sont-elles bien distinguées : disponibilité, performance, qualité ?

Le temps d’ouverture est-il clair ?

Les arrêts planifiés sont-ils exclus ou intégrés ?

Le temps de cycle standard est-il à jour ?

Les rebuts sont-ils correctement affectés ?

Cette étape paraît basique, mais elle évite beaucoup de malentendus.

2. Cartographier les états machine

Ensuite, il faut décrire les états réels de la machine.

Production. Attente. Arrêt défaut. Réglage. Changement de série. Mode manuel. Nettoyage. Maintenance. Marche dégradée.

Cette cartographie doit être faite avec la production, la maintenance et les méthodes.

Un état machine défini uniquement depuis un bureau risque de ne pas correspondre à la réalité atelier.

3. Identifier les données disponibles

Certaines données existent déjà dans l’automate, l’IHM ou les variateurs. D’autres nécessitent des capteurs complémentaires.

Il faut regarder ce qui est disponible, accessible et fiable.

Sur une machine ancienne, un simple capteur de cycle ou un comptage pièces peut parfois suffire à démarrer.

Sur une machine plus récente, on peut récupérer davantage d’informations : alarmes, modes, états, compteurs, temps de cycle.

4. Définir les règles de calcul

La donnée brute doit être transformée en états exploitables.

Par exemple :

si cycle actif et pièce produite : production ;

si machine prête mais pas de cycle : attente ;

si alarme active : arrêt défaut ;

si cadence inférieure au standard : marche dégradée ;

si mode manuel : réglage ou intervention selon contexte.

Ces règles doivent être simples, compréhensibles et validées avec les équipes.

5. Tester sur une période courte

Avant de généraliser, il faut tester.

Une semaine ou deux sur une machine critique peuvent déjà révéler beaucoup de choses.

Le TRS calculé automatiquement correspond-il à ce que les équipes observent ?

Les arrêts sont-ils bien classés ?

Les micro-arrêts apparaissent-ils ?

Les causes sont-elles exploitables ?

Les données créent-elles de nouvelles questions utiles ?

Cette phase de test est importante. Elle permet d’ajuster avant de déployer plus largement.

6. Construire un affichage utile

Une fois la donnée fiabilisée, l’affichage peut être simple.

Pas besoin de quinze graphiques.

Un bon écran TRS doit aider à décider :

TRS réel ;

disponibilité ;

performance ;

qualité ;

principales causes de perte ;

arrêts courts ;

cadence réelle ;

écart au standard ;

évolution par équipe, référence ou période.

Francis Rossignol évoque, dans l’organisation de projets data et connectivité machines, la collecte, le stockage et l’exploitation des données en atelier, ainsi que le développement d’applications spécifiques pour personnaliser les tableaux de bord et tirer parti de l’analytics.

C’est exactement l’enjeu : un tableau de bord n’a de valeur que s’il aide les équipes à agir.

Cybersécurité : ne pas connecter sans cadrer

Dès qu’une machine est connectée, il faut parler cybersécurité industrielle.

Ce n’est pas un sujet réservé aux grands groupes.

Une PME qui connecte une machine, récupère des données automate ou met en place une supervision doit se poser les bonnes questions : accès réseau, droits utilisateurs, accès distant, sauvegardes, segmentation, maintenance, mises à jour.

La Fabrique de l’Industrie/McKinsey rappelle que la cybersécurité fait partie des technologies 4.0 étudiées et la définit comme la protection des systèmes et des données contre les intrusions informatiques et cyberattaques.

Dans les faits, un projet TRS doit donc avancer avec deux exigences en parallèle :

mieux mesurer la performance ;

ne pas fragiliser l’architecture industrielle.

C’est particulièrement important sur des machines anciennes, parfois peu documentées, qui n’ont pas été pensées pour être connectées au départ.

Ce qu’un TRS fiable change dans l’atelier

Un TRS fiable ne sert pas seulement à produire un chiffre.

Il change la qualité des discussions.

La réunion de production ne commence plus par “je pense que”. Elle commence par “voici ce que la machine a réellement fait”.

La maintenance peut prioriser les défauts récurrents, même s’ils ne créent pas de longues pannes.

Les méthodes peuvent revoir un temps de cycle, un standard, un poste de chargement, un changement de série.

La production peut identifier les pertes par équipe, référence ou période.

La direction peut arbitrer un investissement sur une base plus solide.

Le TRS devient alors un outil d’amélioration continue, pas un simple indicateur de reporting.

Comment DSMS accompagne ce type de projet

Chez DSMS Industries, l’objectif n’est pas de vendre un tableau de bord standard.

L’objectif est de relier le besoin terrain, la machine et la donnée exploitable.

Un projet de fiabilisation TRS peut intégrer :

l’analyse du process et des irritants atelier ;

la vérification de la logique TRS existante ;

la cartographie des états machine ;

l’identification des signaux disponibles ;

la connexion à l’automate ;

l’ajout de capteurs si nécessaire ;

la mise en place d’un boîtier IoT industriel ;

l’historisation des événements ;

la supervision locale ou en ligne ;

la sécurisation des échanges IT/OT ;

l’accompagnement à l’exploitation des données.

Le résultat attendu n’est pas “plus de data”. Le résultat attendu, c’est une machine plus mesurable, un TRS plus crédible et des décisions plus concrètes.

Pour une PME industrielle à Roanne, dans la Loire ou en Auvergne-Rhône-Alpes, cette approche permet d’avancer progressivement : une machine critique, une mesure fiable, un usage clair, puis un déploiement si la valeur est confirmée.

Conclusion : un bon TRS commence par une bonne donnée

La saisie manuelle a sa place dans l’atelier. Elle apporte du contexte, de l’expérience et du sens.

Mais elle ne peut pas porter seule le calcul du TRS.

Elle ne voit pas tous les micro-arrêts. Elle ne mesure pas toujours les temps exacts. Elle ne suit pas finement les cadences. Elle dépend de la charge de l’opérateur, du moment, des habitudes et de la précision des causes disponibles.

Pour fiabiliser le TRS, il faut donc passer d’un indicateur estimé à un indicateur alimenté par les données machines.

Pas pour remplacer le terrain.
Mais pour lui donner une base plus solide.

Avant de chercher à améliorer le TRS, il faut pouvoir lui faire confiance.

Vous voulez fiabiliser le TRS d’une machine, d’une ligne ou d’un poste d’usinage ? DSMS Industries peut vous aider à connecter l’existant, capter les bons signaux et construire un suivi exploitable par vos équipes production, maintenance et méthodes.

Sommaire

Dans beaucoup d’ateliers, le TRS existe déjà.

Il est affiché dans un tableau Excel. Il apparaît dans un rapport de production. Il est commenté en réunion du matin. Il sert parfois à comparer des lignes, des machines ou des équipes.

Mais une question revient souvent :

est-ce que ce TRS reflète vraiment ce qui s’est passé sur la machine ?

C’est là que les discussions commencent.

La production sait que la cadence n’a pas été bonne.
L’opérateur explique qu’il a relancé plusieurs fois la machine.
La maintenance ne voit pas de panne longue.
Les méthodes soupçonnent des pertes entre deux cycles.
Et le tableau indique un TRS “pas si mauvais”.

Le problème n’est pas forcément la formule du TRS. Le problème vient souvent de la donnée qui l’alimente.

Un TRS calculé avec des arrêts mal déclarés, des cadences théoriques irréalistes ou des causes trop vagues donne une impression de pilotage. Mais il ne permet pas toujours d’agir.

Pour une PME industrielle, fiabiliser le TRS ne veut pas dire installer une usine à gaz digitale. Cela veut dire rendre la machine plus lisible : quand elle produit, quand elle attend, quand elle s’arrête, pourquoi elle perd de la cadence.

Et pour cela, la saisie manuelle ne suffit pas toujours.

Pourquoi la saisie manuelle atteint vite ses limites

La saisie manuelle n’est pas inutile. Au contraire, elle apporte un contexte que la machine ne connaît pas toujours.

Un opérateur peut expliquer qu’une série était particulière, qu’une pièce était difficile à positionner, qu’un réglage a été repris, qu’un contrôle qualité a pris plus de temps ou qu’un approvisionnement a manqué.

Cette information terrain est précieuse.

Mais demander à l’opérateur de saisir tous les événements de production est rarement réaliste.

Dans un atelier, l’opérateur ne passe pas sa journée devant un formulaire. Il charge, décharge, contrôle, surveille, règle, nettoie, appelle la maintenance, gère les imprévus et fait repartir la machine.

Quand un arrêt dure 20 secondes, il n’est souvent pas saisi.

Quand un défaut revient cinq fois dans l’heure, il peut être regroupé dans une cause générale.

Quand la machine tourne moins vite que prévu, mais sans arrêt franc, il n’y a parfois rien à déclarer.

À la fin du poste, le rapport donne une image approximative. Pas parce que les équipes travaillent mal, mais parce que le système leur demande de déclarer manuellement ce qu’une machine pourrait mesurer automatiquement.

Le vrai problème : un TRS contesté ne sert plus à grand-chose

Un indicateur de performance doit créer de la clarté.

Si le TRS devient un sujet de débat permanent, il perd une partie de sa valeur.

On entend alors des phrases comme :

“Le TRS est faux.”
“Les arrêts ne sont pas tous saisis.”
“Les micro-arrêts n’apparaissent pas.”
“Le temps de cycle standard n’est plus à jour.”
“On ne sait pas si la machine était vraiment en production.”
“Les causes d’arrêt sont trop générales.”

Ce n’est pas seulement un problème de reporting. C’est un problème d’amélioration continue.

Si le TRS n’est pas fiable, les priorités deviennent floues. La maintenance ne sait pas quels défauts traiter en premier. Les méthodes ne savent pas où agir. La production manque d’éléments pour arbitrer. La direction voit un chiffre, mais pas toujours la réalité atelier.

Un bon TRS doit aider à répondre à des questions simples :

où perdons-nous du temps ?

combien cela représente-t-il ?

est-ce un problème d’arrêt, de cadence ou de qualité ?

quelle cause revient le plus souvent ?

quelle action doit passer en priorité ?

Tant que ces réponses reposent principalement sur de l’estimation, le pilotage reste fragile.

Pourquoi les données machines changent la logique

Les données machines ne remplacent pas le terrain. Elles l’éclairent.

Elles permettent de passer d’un ressenti à un fait mesurable.

Au lieu de dire :

“On a souvent des petits arrêts.”

On peut dire :

“Sur cette équipe, la machine a passé 37 minutes en attente entre deux cycles, réparties en 64 événements de moins d’une minute.”

Au lieu de dire :

“La cadence semble plus basse sur cette référence.”

On peut dire :

“Le temps de cycle réel est supérieur de 12 % au standard sur cette référence, principalement après changement d’outil.”

La différence est importante.

Dans le premier cas, on débat.
Dans le second, on analyse.

L’étude La Fabrique de l’Industrie/McKinsey définit l’IoT comme des réseaux d’objets capables de collecter et d’échanger des données pour améliorer l’efficacité et la gestion des ressources. Elle définit aussi l’analytique avancée comme le traitement de grandes quantités de données pour améliorer la prise de décision.

Pour le TRS, cela se traduit très concrètement : récupérer les bons signaux machine, les historiser, les transformer en états compréhensibles, puis les relier aux causes terrain.

Ce n’est pas “faire de la data” pour faire moderne.

C’est mesurer ce qui était jusqu’ici estimé.

Que faut-il mesurer pour fiabiliser le TRS ?

Un TRS fiable ne commence pas par un écran. Il commence par une bonne définition des états machine.

La question de base est simple :

à quel moment la machine produit-elle réellement une pièce bonne, à la cadence attendue ?

À partir de là, il faut distinguer plusieurs situations.

La machine peut être en production réelle. Elle peut être en attente. Elle peut être arrêtée. Elle peut être en défaut. Elle peut être en réglage. Elle peut être en mode manuel. Elle peut aussi produire, mais trop lentement.

C’est souvent cette dernière situation qui pose problème.

Une machine qui ne s’arrête jamais complètement peut quand même perdre beaucoup de performance. Si le système ne suit que “marche” et “arrêt”, cette perte reste invisible.

Pour fiabiliser le TRS, les signaux utiles peuvent être :

état marche/arrêt ;

cycle actif ;

mode automatique ou manuel ;

alarme active ;

compteur pièces ;

pièces bonnes et mauvaises ;

temps de cycle réel ;

temps entre deux cycles ;

défaut sécurité ;

attente opérateur ;

présence pièce ;

consommation ou activité machine ;

redémarrage après défaut.

Tous ces signaux ne sont pas nécessaires sur toutes les machines. Le bon choix dépend du process, de l’âge de l’équipement, de l’automate, des capteurs disponibles et de l’objectif de suivi.

L’important est de ne pas tout mesurer. L’important est de mesurer ce qui permet d’agir.

Le piège du TRS “automatique” mal défini

Automatiser le calcul du TRS ne garantit pas un TRS fiable.

On peut très bien automatiser une mauvaise logique.

Par exemple, si la machine est considérée en production dès que le voyant “marche” est actif, le TRS peut être trompeur. La machine peut être sous tension, prête à produire, ou en attente entre deux cycles, sans produire réellement.

Même chose si les temps de cycle standards ne sont pas à jour.

Un écart de cadence peut être interprété comme une perte de performance alors que le standard est irréaliste. À l’inverse, un standard trop large peut masquer une dérive réelle.

Un bon projet TRS doit donc clarifier trois éléments :

la donnée collectée ;

la règle de calcul ;

l’usage attendu par les équipes.

C’est ce qui évite de créer un indicateur propre en apparence, mais contesté dès qu’il est utilisé.

Exemple simple : une ligne qui affiche un bon taux de marche mais produit trop peu

Prenons une ligne semi-automatique.

Dans le rapport quotidien, la ligne affiche un taux de marche correct. Les arrêts longs sont rares. Les opérateurs n’ont pas déclaré de grosse difficulté.

Pourtant, la production réelle est inférieure à l’objectif.

Sans donnée machine détaillée, plusieurs hypothèses se mélangent :

les arrêts courts sont-ils sous-déclarés ?

la ligne attend-elle un poste amont ?

le poste aval crée-t-il des blocages ?

les changements de série prennent-ils plus de temps que prévu ?

la cadence réelle est-elle inférieure au standard ?

les défauts qualité entraînent-ils des relances ?

En connectant quelques signaux bien choisis, la lecture change.

On découvre parfois que la ligne ne s’arrête pas longtemps, mais qu’elle attend très souvent. Ou que le temps entre deux cycles varie fortement. Ou que les pertes se concentrent sur une référence. Ou que les arrêts courts sont trop nombreux pour être saisis manuellement.

La donnée ne donne pas toute la réponse. Mais elle indique où regarder.

Et c’est déjà beaucoup.

La bonne place de l’opérateur dans un TRS fiabilisé

Fiabiliser le TRS sans saisie manuelle ne veut pas dire supprimer l’opérateur du suivi.

C’est même l’inverse.

L’automate, les capteurs ou le boîtier IoT peuvent mesurer les faits : marche, arrêt, cycle, alarme, cadence, comptage.

Mais le terrain reste indispensable pour comprendre le pourquoi.

La bonne logique consiste à automatiser ce qui peut l’être, puis à demander à l’opérateur uniquement ce qui a de la valeur.

Par exemple, il n’a pas besoin de saisir qu’un arrêt a commencé à 9h14 et s’est terminé à 9h15. La machine peut le mesurer.

En revanche, il peut être utile qu’il précise la cause : manque matière, attente contrôle, défaut outillage, réglage, nettoyage, problème qualité.

La saisie devient alors plus légère, plus ciblée et plus fiable.

On ne demande plus à l’opérateur de faire le travail de la machine. On lui demande d’apporter son expertise terrain.

Commencer simple : une machine critique, quelques signaux, un usage clair

Beaucoup de projets de suivi TRS échouent parce qu’ils démarrent trop large.

Trop de machines.
Trop d’indicateurs.
Trop de causes d’arrêt.
Trop d’écrans.
Trop peu d’usage terrain.

Une approche plus efficace consiste à commencer par une machine ou une ligne critique.

Celle qui bloque la production. Celle qui génère des discussions. Celle dont le TRS est contesté. Celle où les micro-arrêts sont suspectés. Celle où un gain de visibilité peut vraiment aider les équipes.

La présentation Francis Rossignol sur l’usine 4.0 pour les PME et ETI insiste justement sur le fait de passer d’une logique technologique à une logique d’usage métier, en partant des irritants opérationnels comme la qualité, la cadence ou l’ergonomie, puis en identifiant les cas d’usage à ROI rapide.

C’est exactement la bonne logique pour le TRS.

On ne démarre pas par “il nous faut un logiciel”.
On démarre par “quel problème de production voulons-nous objectiver ?”

Les étapes pour passer d’un TRS estimé à un TRS fiable

1. Vérifier la formule utilisée

Avant de connecter quoi que ce soit, il faut vérifier ce que l’entreprise appelle TRS.

Les trois composantes sont-elles bien distinguées : disponibilité, performance, qualité ?

Le temps d’ouverture est-il clair ?

Les arrêts planifiés sont-ils exclus ou intégrés ?

Le temps de cycle standard est-il à jour ?

Les rebuts sont-ils correctement affectés ?

Cette étape paraît basique, mais elle évite beaucoup de malentendus.

2. Cartographier les états machine

Ensuite, il faut décrire les états réels de la machine.

Production. Attente. Arrêt défaut. Réglage. Changement de série. Mode manuel. Nettoyage. Maintenance. Marche dégradée.

Cette cartographie doit être faite avec la production, la maintenance et les méthodes.

Un état machine défini uniquement depuis un bureau risque de ne pas correspondre à la réalité atelier.

3. Identifier les données disponibles

Certaines données existent déjà dans l’automate, l’IHM ou les variateurs. D’autres nécessitent des capteurs complémentaires.

Il faut regarder ce qui est disponible, accessible et fiable.

Sur une machine ancienne, un simple capteur de cycle ou un comptage pièces peut parfois suffire à démarrer.

Sur une machine plus récente, on peut récupérer davantage d’informations : alarmes, modes, états, compteurs, temps de cycle.

4. Définir les règles de calcul

La donnée brute doit être transformée en états exploitables.

Par exemple :

si cycle actif et pièce produite : production ;

si machine prête mais pas de cycle : attente ;

si alarme active : arrêt défaut ;

si cadence inférieure au standard : marche dégradée ;

si mode manuel : réglage ou intervention selon contexte.

Ces règles doivent être simples, compréhensibles et validées avec les équipes.

5. Tester sur une période courte

Avant de généraliser, il faut tester.

Une semaine ou deux sur une machine critique peuvent déjà révéler beaucoup de choses.

Le TRS calculé automatiquement correspond-il à ce que les équipes observent ?

Les arrêts sont-ils bien classés ?

Les micro-arrêts apparaissent-ils ?

Les causes sont-elles exploitables ?

Les données créent-elles de nouvelles questions utiles ?

Cette phase de test est importante. Elle permet d’ajuster avant de déployer plus largement.

6. Construire un affichage utile

Une fois la donnée fiabilisée, l’affichage peut être simple.

Pas besoin de quinze graphiques.

Un bon écran TRS doit aider à décider :

TRS réel ;

disponibilité ;

performance ;

qualité ;

principales causes de perte ;

arrêts courts ;

cadence réelle ;

écart au standard ;

évolution par équipe, référence ou période.

Francis Rossignol évoque, dans l’organisation de projets data et connectivité machines, la collecte, le stockage et l’exploitation des données en atelier, ainsi que le développement d’applications spécifiques pour personnaliser les tableaux de bord et tirer parti de l’analytics.

C’est exactement l’enjeu : un tableau de bord n’a de valeur que s’il aide les équipes à agir.

Cybersécurité : ne pas connecter sans cadrer

Dès qu’une machine est connectée, il faut parler cybersécurité industrielle.

Ce n’est pas un sujet réservé aux grands groupes.

Une PME qui connecte une machine, récupère des données automate ou met en place une supervision doit se poser les bonnes questions : accès réseau, droits utilisateurs, accès distant, sauvegardes, segmentation, maintenance, mises à jour.

La Fabrique de l’Industrie/McKinsey rappelle que la cybersécurité fait partie des technologies 4.0 étudiées et la définit comme la protection des systèmes et des données contre les intrusions informatiques et cyberattaques.

Dans les faits, un projet TRS doit donc avancer avec deux exigences en parallèle :

mieux mesurer la performance ;

ne pas fragiliser l’architecture industrielle.

C’est particulièrement important sur des machines anciennes, parfois peu documentées, qui n’ont pas été pensées pour être connectées au départ.

Ce qu’un TRS fiable change dans l’atelier

Un TRS fiable ne sert pas seulement à produire un chiffre.

Il change la qualité des discussions.

La réunion de production ne commence plus par “je pense que”. Elle commence par “voici ce que la machine a réellement fait”.

La maintenance peut prioriser les défauts récurrents, même s’ils ne créent pas de longues pannes.

Les méthodes peuvent revoir un temps de cycle, un standard, un poste de chargement, un changement de série.

La production peut identifier les pertes par équipe, référence ou période.

La direction peut arbitrer un investissement sur une base plus solide.

Le TRS devient alors un outil d’amélioration continue, pas un simple indicateur de reporting.

Comment DSMS accompagne ce type de projet

Chez DSMS Industries, l’objectif n’est pas de vendre un tableau de bord standard.

L’objectif est de relier le besoin terrain, la machine et la donnée exploitable.

Un projet de fiabilisation TRS peut intégrer :

l’analyse du process et des irritants atelier ;

la vérification de la logique TRS existante ;

la cartographie des états machine ;

l’identification des signaux disponibles ;

la connexion à l’automate ;

l’ajout de capteurs si nécessaire ;

la mise en place d’un boîtier IoT industriel ;

l’historisation des événements ;

la supervision locale ou en ligne ;

la sécurisation des échanges IT/OT ;

l’accompagnement à l’exploitation des données.

Le résultat attendu n’est pas “plus de data”. Le résultat attendu, c’est une machine plus mesurable, un TRS plus crédible et des décisions plus concrètes.

Pour une PME industrielle à Roanne, dans la Loire ou en Auvergne-Rhône-Alpes, cette approche permet d’avancer progressivement : une machine critique, une mesure fiable, un usage clair, puis un déploiement si la valeur est confirmée.

Conclusion : un bon TRS commence par une bonne donnée

La saisie manuelle a sa place dans l’atelier. Elle apporte du contexte, de l’expérience et du sens.

Mais elle ne peut pas porter seule le calcul du TRS.

Elle ne voit pas tous les micro-arrêts. Elle ne mesure pas toujours les temps exacts. Elle ne suit pas finement les cadences. Elle dépend de la charge de l’opérateur, du moment, des habitudes et de la précision des causes disponibles.

Pour fiabiliser le TRS, il faut donc passer d’un indicateur estimé à un indicateur alimenté par les données machines.

Pas pour remplacer le terrain.
Mais pour lui donner une base plus solide.

Avant de chercher à améliorer le TRS, il faut pouvoir lui faire confiance.

Vous voulez fiabiliser le TRS d’une machine, d’une ligne ou d’un poste d’usinage ? DSMS Industries peut vous aider à connecter l’existant, capter les bons signaux et construire un suivi exploitable par vos équipes production, maintenance et méthodes.

Trouvez les réponses à vos questions

Pourquoi le TRS manuel est-il souvent imprécis ?

Quelles données machine faut-il collecter pour fiabiliser le TRS ?

Un TRS automatique est-il toujours fiable ?

Comment fiabiliser le TRS sur une machine ancienne ?

Quel est le lien entre TRS, micro-arrêts et supervision ?