Dans un atelier CNC, la capacité réelle n’est jamais égale à la capacité “sur le papier”. Entre les arrêts non planifiés, les micro-arrêts, les changements de série, les réglages, les pièces rebutées et les vitesses réellement tenues, une machine peut sembler “occupée” tout en produisant moins que prévu. C’est exactement pour ça que le TRS (Taux de Rendement Synthétique) est devenu un KPI central : il relie disponibilité, performance et qualité dans un indicateur unique, actionnable, qui parle immédiatement aux responsables production, méthodes et direction d’usine.
Le TRS est particulièrement utile en sous-traitance et en PME industrielles, parce qu’il permet de passer d’une gestion “au ressenti” à un pilotage factuel via un tableau de production, un suivi en temps réel et un tracking machine fiable. Bien utilisé, le TRS ne sert pas à “surveiller” : il sert à identifier les pertes, prioriser les actions (maintenance, méthodes, organisation), et augmenter la productivité sans recruter ni acheter une nouvelle machine.
Ce guide vous explique :
comment faire le calcul du TRS pas à pas,
comment capter les données sans saisie manuelle (et fiabiliser le suivi des temps de travail machine/opérateur),
comment choisir un logiciel et construire un pilote en 90 jours,
comment fiabiliser le temps de cycle (la clé du composant “performance”),
quelles actions donnent les gains les plus rapides sur les arrêts et la cadence.
Niveau de départ fréquent : beaucoup d’ateliers CNC démarrent avec un TRS entre 30 et 60% ; atteindre 60%+ est déjà solide, et 85% correspond à un niveau “référence” très exigeant. Les premiers chantiers bien ciblés font souvent gagner 10 à 25 points.
Automatiser la donnée : capter automatiquement état machine, comptage pièces, rebut et alarmes (via MTConnect / OPC-UA / modules d’E/S) réduit fortement les erreurs de saisie et donne enfin des causes d’arrêt exploitables.
Pilote 90 jours : démarrez sur une cellule. Activez la capture automatique du temps de cycle, mettez en place un codage des arrêts simple, suivez MTTR/MTBF, et obtenez un retour sur investissement typiquement en 3 à 12 mois si vous agissez sur les 2–3 pertes majeures.
Le TRS mesure l’efficacité d’un équipement à transformer du temps disponible en pièces bonnes, au rythme attendu. Il est “composite” : au lieu de regarder seulement le temps de marche, il mesure ce qui compte réellement pour la production.
Dans un atelier CNC, le TRS sert à :
objectiver la capacité : combien de pièces réellement produites par heure/poste,
mieux tenir les délais : moins de surprises de fin de semaine,
réduire la dépendance à l’héroïsme (heures sup, rattrapage),
aligner méthodes, maintenance et production sur les mêmes faits.
Le TRS est aussi un excellent langage commun : la direction comprend l’impact d’un gain de TRS (capacité), les méthodes voient où agir (performance), la maintenance voit les pertes (disponibilité), et la qualité voit l’effet des rebuts/retouches (qualité).
Le TRS se calcule ainsi :
TRS = Disponibilité × Performance × Qualité
Chaque composante répond à une question simple.
Elle compare le temps de marche au temps planifié.
Pertes typiques : pannes, arrêts longs, manque de matière, attente outillage, réglages prolongés, maintenance non planifiée.
En CNC : les micro-arrêts (quelques minutes) peuvent peser énormément s’ils se répètent.
Elle compare la cadence réelle à une cadence de référence (souvent basée sur le temps de cycle idéal).
Pertes typiques : vitesse réduite, reprises, usure outil, paramètres prudents, air-cuts, bridage instable, programme non optimisé.
En CNC : la performance est souvent le levier leI (le plus gros gisement) si le temps de cycle de référence est fiable.
Elle mesure le ratio pièces bonnes / pièces totales.
Pertes typiques : rebuts, retouches, reprises, non-conformités détectées tard.
En sous-traitance : quelques défauts sur une caractéristique critique peuvent exploser les retouches et “manger” la capacité.
Pour un calcul clair, il faut des définitions stables (sinon le TRS devient incomparable d’une équipe à l’autre).
Disponibilité = Temps de marche / Temps de production planifié
Performance = (Temps de cycle de référence × Quantité totale) / Temps de marche
Qualité = Quantité bonne / Quantité totale
TRS = Disponibilité × Performance × Qualité
Note : Le “temps planifié” exclut les arrêts planifiés (pause, maintenance planifiée) si vous choisissez de les exclure. L’essentiel est d’être cohérent.
Poste : 10 h = 600 min
Arrêt planifié : 30 min (maintenance)
→ Temps planifié = 570 min
Arrêts non planifiés (panne + attente outil + micro-arrêts cumulés) : 60 min
→ Temps de marche = 510 min
→ Disponibilité = 510 / 570 = 89,5%
Temps de cycle de référence (validé) : 2,5 min/pièce
Pièces produites (bonnes + rebut) : 180
→ Performance = (2,5 × 180) / 510 = 450 / 510 = 88,2%
Pièces bonnes : 175
→ Qualité = 175 / 180 = 97,2%
→ TRS = 0,895 × 0,882 × 0,972 = 0,769 → 76,9%
Ce calcul montre un point clé : une petite dérive de temps d’arrêt, de cadence ou de rebuts se voit immédiatement sur le TRS. Et surtout, il vous dit où agir (ici, disponibilité et performance sont les plus “améliorables”).
En atelier CNC, le TRS se joue souvent sur la performance, donc sur la qualité du temps de cycle de référence.
temps CAM “théorique” (accélérations idéales),
oublis de changements d’outil / palettisation,
air-cuts, approches et retraits non comptés de la même façon,
pauses opérateur (chargement, contrôle) mélangées ou non,
variantes programme (conditions, sous-programmes).
Si votre temps de cycle est trop optimiste, votre performance paraît faible (on “n’atteint jamais” la référence). S’il est trop pessimiste, vous masquez un gisement (tout semble correct alors que la cadence pourrait monter).
Définir ce que vous appelez “cycle” (début/fin : start programme, start broche, etc.).
Capturer le cycle réel automatiquement (éviter l’estimation manuelle).
Valider sur 10–20 cycles en conditions normales (pas un seul “cycle parfait”).
Geler une référence par opération / programme / matière / outil, puis la réviser quand le process change.
Le “bon” TRS n’est pas juste machine : il s’appuie sur un suivi des temps de travail structuré (machine + opérateur), sans tomber dans la surveillance individuelle. L’objectif est de distinguer :
temps machine (marche/arrêt),
temps opérateur (chargement, contrôle, réglage),
temps d’attente (matière, outil, maintenance).
C’est là qu’un logiciel de gestion des temps (côté production, pas RH) peut aider : horodatage, événements simples, consolidation dans un tableau de production.
Un TRS “fin de semaine” calculé à la main donne rarement des actions. Pour piloter, vous devez voir les pertes pendant qu’elles arrivent.
état machine : marche / arrêt / défaut / attente,
début/fin cycle (ou compteur de pièces + horodatage),
quantité bonne / rebut (au plus près de la production),
alarmes (codes, timestamps),
raison d’arrêt (codage simple, sélection rapide).
Les micro-arrêts sont importants : 30 micro-arrêts de 2 minutes, c’est 1 heure perdue… et souvent invisible si on ne suit pas finement.
Intégration contrôleur : MTConnect, OPC-UA, API constructeur…
Avantages : données riches (programme, états, alarmes).
Capteurs / modules E/S : utile si l’accès contrôleur est limité (machines anciennes).
Avantages : rapide à déployer, robuste pour états simples (marche/arrêt) et comptage.
L’objectif n’est pas de tout mesurer. C’est de mesurer ce qui déclenche une décision : où ça s’arrête, combien de temps, pourquoi, et quel impact sur le temps de cycle.
Un tableau de bord efficace se lit en 10 secondes et déclenche une action.
état machine actuel + timer depuis arrêt,
compteur pièces vs objectif,
1 bouton “raison d’arrêt” (liste courte),
alerte simple (ex : arrêt > 5 min, dérive cycle > 10%).
TRS par machine/cellule, sur le poste et sur 24 h,
top 3 raisons d’arrêt (Pareto),
dérive du temps de cycle (réel vs référence),
rebut / retouche en tendance.
tendance hebdomadaire du TRS,
capacité récupérée (heures machine gagnées),
impact sur délais / retards,
projets en cours (SMED, maintenance, qualité).
Quand l’affichage est bon, le TRS devient un outil de management visuel, pas un KPI “pour le reporting”.
Un logiciel TRS doit faire deux choses : connecter la donnée terrain et la transformer en décisions.
connectivité machine (OPC-UA / MTConnect / E/S),
calcul TRS paramétrable (définitions claires),
capture automatique cycles / compteurs / états,
codage des arrêts simple + export,
alertes + tableaux de production,
API / connecteurs ERP/MES (pour contexte OF, article, opération).
ergonomie atelier (saisie en 2 clics),
gestion multi-équipes / multi-postes,
historisation “audit trail” (utile en qualité),
capacité à gérer plusieurs temps de cycle (par programme, par opération, par matière).
Sans contexte, un arrêt est “un arrêt”. Avec l’ERP/MES, il devient :
arrêt sur OF X / opération Y,
impact sur la promesse client,
impact sur la charge et la planification.
C’est là que le TRS devient un levier de planification, pas seulement un indicateur.
Les ateliers qui gagnent vite font la même chose : ils ciblent 2–3 pertes majeures, pas 15 chantiers.
standard de réaction : qui fait quoi dans les 5 premières minutes,
réduction MTTR : pièces de rechange critiques, procédures courtes, accès outillage,
maintenance préventive sur les causes top 3,
élimination des “attentes” (matière, outils, programmes) via préparation amont.
nettoyage programme : réduire air-cuts, optimiser approches,
optimisation stratégie CAM (ébauche adaptative, engagement constant),
réduction changements d’outil, regroupement opérations,
bridage/fixturing plus rigide (autorise des avances plus élevées),
revue des conditions de coupe à partir de données (pas au ressenti).
contrôle plus tôt sur caractéristiques critiques,
stabilisation outil/offset, gestion de l’usure,
boucle qualité : si dérive détectée, correction immédiate (au lieu d’attendre la fin de lot),
standard de validation première pièce.
Voici un plan réaliste, orienté résultats.
choisir une cellule / 1–3 machines représentatives,
définir les règles de calcul du TRS,
capter un baseline : TRS actuel, arrêts principaux, rebuts.
activer tracking machine (états + cycles + compteurs),
mettre un codage arrêts court (10 raisons max),
valider temps de cycle de référence (10–20 cycles réels).
Pareto arrêts + 5 pourquoi sur top 1–2 causes,
une action MTTR (procédure/kit),
une action performance (programme/outil/fixturing),
une action qualité (contrôle/offset/usure).
vérifier gain TRS (points),
mesurer MTTR/MTBF, temps de cycle, rebut,
standardiser ce qui marche, préparer l’extension.
Ce pilote crée rapidement de la crédibilité : un TRS stable, des causes d’arrêts fiables, et des gains visibles.
Le TRS est utile uniquement s’il vous aide à décider plus vite : où sont les pertes, lesquelles coûtent le plus, et quelle action ramène de la capacité immédiatement. Avec un suivi en temps réel, un temps de cycle fiabilisé, et un codage d’arrêts simple, vous obtenez un tableau de production qui “parle” à tous.
L’action la plus rentable à court terme : démarrer un pilote 90 jours sur une cellule, automatiser la collecte (tracking machine), valider les temps de cycle, puis attaquer les 2 pertes majeures (souvent micro-arrêts + performance). C’est généralement la façon la plus directe d’augmenter la productivité sans ajouter d’effectifs.
Le bon temps de cycle est celui qui sert de référence stable pour mesurer la performance, et il doit être validé. Un temps de cycle purement “CAM” peut être utile au départ, mais il est souvent trop théorique (accélérations idéales, oublis d’événements réels). La meilleure approche est hybride : vous partez d’une estimation (CAM/programme), puis vous la confrontez à des cycles réels captés automatiquement (contrôleur, capteurs, compteur pièces) sur 10–20 répétitions. Ensuite, vous “geler” une référence par opération/programme/matière, et vous la revoyez quand vous changez d’outil, de stratégie, ou de bridage. Sans cette discipline, votre performance devient un chiffre qui monte ou descend sans cause réelle. Un TRS crédible repose presque toujours sur un temps de cycle de référence crédible.
Le TRS doit rester un indicateur système, pas un indicateur “personne”. Pour ça, il faut (1) afficher clairement qu’il sert à identifier des pertes de processus (attentes, pannes, méthodes, qualité), (2) éviter les classements individuels, (3) associer le TRS à des actions d’amélioration concrètes (SMED, outillage, maintenance, préparation), et (4) donner aux opérateurs un moyen simple de qualifier la réalité via des raisons d’arrêt pertinentes. Dans les ateliers où le TRS fonctionne, les opérateurs ne “subissent” pas le tableau : ils l’utilisent pour demander des solutions (outil manquant, programme à corriger, maintenance à planifier). Le bon signal est simple : si le TRS déclenche de l’amélioration, il est sain ; s’il déclenche de la peur et de la sous-déclaration, il devient contre-productif.
Pour un suivi en temps réel utile (et pas un projet interminable), captez d’abord : état machine (marche/arrêt/défaut), horodatage des cycles (ou compteur pièces), quantité rebut/retouche, et quelques alarmes ou événements clés. Ensuite, ajoutez un codage des arrêts simple (pas 50 raisons) afin d’obtenir un Pareto exploitable. La granularité compte : les micro-arrêts doivent être visibles, sinon vous ratez souvent le principal gisement de disponibilité. Enfin, reliez la donnée à un minimum de contexte (machine, poste, produit/OF si possible) pour que le tableau de production soit actionnable. Si vous n’avez pas le contexte ERP/MES au début, commencez sans, mais gardez une convention de nommage stricte pour intégrer ensuite.
Le TRS mesure l’efficacité machine/production, mais il devient beaucoup plus puissant quand il s’inscrit dans un suivi des temps de travail structuré. En pratique, vous voulez distinguer : temps machine (cycle, arrêt), temps opérateur (chargement, contrôle, réglage), temps d’attente (matière, outil, validation). Un logiciel de gestion des temps orienté production (et non RH) permet d’horodater les événements, de réduire les saisies manuelles, et d’alimenter un tableau de production cohérent. L’objectif n’est pas de “suivre les personnes”, mais de mesurer le système : où se perd le temps, quelles tâches consomment la capacité, et quel est l’impact sur la cadence. Quand ces temps sont visibles, vous pouvez faire des arbitrages factuels : ajouter un outillage qui réduit 15 secondes de chargement vaut parfois plus qu’une nouvelle machine.
Un bon objectif TRS est progressif et basé sur vos pertes dominantes. Au lieu de dire “on veut 85%”, commencez par viser un gain concret : réduire de 30% les micro-arrêts, diviser par 2 une panne récurrente, réduire le rebut sur une famille critique, ou stabiliser un temps de cycle. Ensuite, observez l’effet sur disponibilité/performance/qualité. Dans beaucoup d’ateliers, gagner 10–20 points de TRS est déjà énorme si cela vient d’actions durables (maintenance, méthodes, standard). Fixez aussi des objectifs sur des KPIs de soutien : MTTR, MTBF, taux de codage d’arrêt (qualité de la donnée), écart temps de cycle réel vs référence. Le TRS doit être le résultat d’un système qui s’améliore, pas une consigne isolée.