Dans beaucoup d’ateliers CNC, le planning “tient” parce que les équipes compensent : on ajoute des marges, on décale des ordres, on sur-sollicite les mêmes opérateurs, et on finit par “faire rentrer” les délais à coup d’heures supplémentaires. Le problème, c’est que ce pilotage repose souvent sur des temps “estimés” : temps de cycle pris dans un vieux fichier, standard non mis à jour après une amélioration, ou encore temps opérateur comptabilisé trop grossièrement.
Or, dès que vos temps de cycle sont faux de 5 à 10 %, l’effet domino est rapide : erreurs d’ordonnancement, charge machine mal évaluée, charge opérateur sous-estimée, goulots mal identifiés et au final des KPI de production (TRS, productivité, rendement, taux de service) qui deviennent discutables. À l’inverse, quand vous automatisez l’extraction et la validation des temps, vous transformez un “ressenti atelier” en suivi des KPI fiable, actionnable, et partagé.
Ce guide explique comment :
extraire un temps de cycle à partir d’un programme CNC (NC/G-code),
le valider avec des données machine (logs contrôleur / monitoring),
convertir le temps machine en temps standard (incluant les tâches opérateur),
injecter ces valeurs dans un MES/ERP et/ou un logiciel de gestion des temps,
améliorer le suivi des temps de travail, le suivi des performances et la capacité à augmenter la productivité sans embaucher.
Les temps de cycle issus des programmes CNC peuvent être très fiables, à condition d’être corrigés et validés avec des données réelles (contrôleur, monitoring). Visez une erreur moyenne (MAPE) < 5 % sur vos pièces répétitives.
Le temps standard = temps machine + tâches opérateur (chargement/déchargement, contrôle, nettoyage, etc.) + une allowance réaliste (souvent 3 à 8 % selon le contexte). Documentez la formule par opération.
La meilleure approche est hybride : parsing NC “offline” + logs d’exécution machine + micro-études terrain périodiques, puis intégration MES/ERP (OPC-UA/REST) ou via une plateforme edge (ex. JITbase) pour automatiser le suivi.
Le temps de cycle correspond au temps nécessaire pour usiner une pièce (ou réaliser une opération) tel que réellement exécuté. En pratique, on le mesure souvent :
du début programme à la fin programme, ou
du spindle start au spindle stop (selon ce que vous voulez inclure).
C’est un indicateur clé car il alimente directement :
vos calculs de capacité,
votre charge machine,
vos engagements de délais,
et le volet “performance” de vos indicateurs type TRS/OEE (dans la plupart des approches industrielles).
Le takt time est un rythme imposé par la demande :
temps disponible / quantité demandée.
Il sert surtout à dimensionner des lignes, équilibrer des charges et vérifier si la production peut suivre la cadence du client. En atelier CNC, il aide à “recadrer” l’objectif, mais il ne remplace pas un temps de cycle réel.
Le temps standard est le temps de référence utilisé pour planifier et chiffrer. Il inclut :
le temps de cycle machine,
les tâches opérateur (manutention, contrôle, saisies, nettoyage, etc.),
et une marge documentée (allowance) pour les aléas inévitables.
C’est le temps qui fait le lien entre planification et terrain. C’est aussi un pilier du suivi des temps de travail : si votre standard est faux, votre analyse “écart standard vs réalisé” devient du bruit.
5 % peut sembler “peu”, mais sur une journée d’atelier, c’est énorme. Prenons un exemple simple :
Temps réel : 120 s
Temps estimé (trop long) : 132 s (+10 %)
À la planification, vous “pensez” pouvoir produire moins que la réalité. Résultat :
vous alourdissez le planning,
vous augmentez des marges,
vous créez des trous artificiels,
et vos KPI peuvent donner l’impression d’une sous-utilisation.
Inversement, si vous sous-estimez :
vous surchargez la machine,
vous créez des retards,
vous déclenchez de l’urgence (expéditions, overtime),
et vos équipes compensent au prix d’une fatigue + variabilité.
Les écarts classiques viennent de :
accélérations/décélérations et “lookahead” contrôleur non modélisés par un parsing simple,
rapides (G0) mal estimés (vitesse nominale ≠ vitesse réelle selon axes, trajectoires),
sous-programmes, boucles, cycles fixes (G8x) mal “dépliés”,
événements auxiliaires : changement d’outil, palpage, attentes opérateur, ramp-up broche, nettoyage, évacuation copeaux.
D’où l’intérêt d’une méthode robuste : extraction + validation + standardisation.
L’objectif n’est pas de “comprendre toute la programmation”, mais d’identifier les blocs qui impactent le temps :
mouvements : G0 / G1 / G2 / G3
avance : F
changement d’outil : T… / M6
broche : M3/M4/M5 + S…
dwell : G4
appels : M98/M99, sous-programmes, répétitions
cycles fixes : G81–G89 (à développer si vous calculez)
Un bon parsing transforme le fichier en une liste structurée : type de mouvement, distance, avance, conditions, multiplicité.
Pour les avances (G1/G2/G3) :
temps = distance / avance
en respectant les unités (mm/min → mm/s).
Pour les rapides (G0) :
le contrôleur applique des vitesses réelles dépendantes des axes, et des rampes. Un modèle conservateur consiste à :
utiliser la vitesse rapide max de la machine (par axe si possible),
ajouter une correction “accel/decel” (souvent non négligeable sur petits déplacements).
C’est souvent là que le parsing “théorique” perd en qualité si on l’ignore.
Bon réflexe :
définir des standards d’atelier : ex. “changement outil auto = 6 s”, “palpage = 12 s”, etc.
les associer à des événements détectables (M6, cycles, macros),
et ajuster avec des données machine sur pièces répétitives.
Beaucoup d’ateliers appliquent une correction initiale (ex. +2 à +6 %) si le parsing est simple. Mais l’objectif n’est pas d’avoir une “marge” permanente : c’est d’arriver à une précision stable, validée, avec une méthode répétable.
En pratique, vous avez 3 familles :
Parsing NC offline (rapide à mettre en place)
Très utile pour :
démarrer vite,
comparer des révisions de programme,
alimenter une base temps pour un pilote.
Simulation CAM / CNC (plus précis si paramétrée)
Elle peut tenir compte de cinématiques et trajectoires, mais nécessite :
un modèle machine cohérent,
un post-processeur bien réglé,
et du temps de préparation.
Logs contrôleur / monitoring temps réel (référence terrain)
C’est la meilleure source pour les temps “exécutés” :
elle inclut les aléas,
reflète les pauses,
capture des états (run/idle/fault).
Si vous devez prioriser : utilisez les logs machine comme “vérité terrain”, et le parsing comme “outil d’ingénierie” + base de standardisation.
Quand les temps sont fiables, vous obtenez :
une capacité réelle (planning plus stable),
un meilleur suivi des performances (écarts standard/réalisé),
un suivi des KPI plus crédible (productivité, TRS/OEE, taux de service),
et un suivi des temps de travail mieux attribué aux opérations (moins de pointage approximatif).
Le temps machine ne suffit pas pour planifier la charge humaine. À intégrer (selon contexte) :
chargement / déchargement,
serrage / desserrage, changement de mors, bridage,
contrôle dimensionnel (atelier, CMM, gabarits),
ébavurage léger, nettoyage,
saisies nécessaires (traçabilité, non-conformité),
manutention (appro, palette, évacuation).
L’idée n’est pas d’empiler des estimations, mais de mesurer un “noyau dur” stable. Sur pièces répétitives, 5–10 cycles suffisent souvent à obtenir une moyenne exploitable.
Une allowance réaliste compense :
besoins personnels,
micro-attentes (matière, outils, contrôle),
variabilité normale du terrain.
Dans beaucoup d’ateliers, 3 à 8 % est un ordre de grandeur raisonnable (à ajuster selon poste, cadence, pénibilité, stabilité process). L’important : documenter la règle et la réviser périodiquement.
Pour une opération :
Temps programme validé : 180 s
Load/unload mesuré : 30 s
Contrôle : 15 s
Sous-total : 225 s
Allowance 5 % : 11,25 s
Temps standard = 236 s (arrondi)
Ce format est parfait pour un MES/ERP : il est traçable, révisable, et vous pouvez relier l’amélioration continue à des gains réels.
Sur une pièce répétitive :
sélectionner un programme stable,
lancer 10 à 20 cycles en conditions normales,
récupérer :
temps parsing (théorique),
temps contrôleur / monitoring (réel),
un point de contrôle manuel si besoin,
calculer l’écart et le MAPE,
documenter “pourquoi” en cas d’écarts (palpage, attente, outil, etc.).
Objectif concret :
MAPE < 5 % sur vos top références (celles qui font le volume/marge),
et des règles de recalage simples (correction parsing, événement manquant, standard auxiliaire).
MAPE par programme / famille
écart type (variabilité)
nombre d’outliers (> 2σ)
nombre de changements de standard / mois
part des opérations “sans standard validé”
Cela alimente directement votre suivi des KPI : un KPI n’est utile que si la donnée est stable.
Pour éviter les bases “immenses mais inutilisables”, gardez un noyau clair :
ID opération / gamme
référence pièce / OF
nom programme + révision
machine / cellule
temps de cycle validé
temps standard (avec formule)
hypothèses : load/unload, contrôle, allowance
date de validation + échantillon (n cycles)
source (parsing, contrôleur, monitoring)
Souvent, le meilleur compromis est :
collecte machine (OPC-UA / MTConnect / autres) vers une couche edge,
consolidation et calculs (par ex. plateforme type JITbase),
synchronisation vers MES/ERP (API REST / connecteurs / import).
Pourquoi ? Parce que ça réduit le travail manuel, et ça fiabilise le suivi des temps de travail : vos temps opérateur peuvent être attribués aux opérations au lieu d’être “au quart d’heure près” sur un pointage global.
identifiants incohérents (programme vs opération vs article)
standards mis à jour “à la main” sans traçabilité
temps machine validé mais tâches opérateur ignorées
systèmes en double saisie (ERP + Excel + papier)
Le gain de productivité vient souvent autant de la suppression de ces frictions que de l’usinage lui-même.
sélectionner 5–10 références répétitives (80/20),
lister les opérations critiques,
identifier la source “temps réel” disponible (contrôleur, monitoring, relevés).
parsing NC sur programmes,
collecte des temps réels sur 10–20 cycles,
standardisation des auxiliaires,
calcul MAPE + corrections.
injecter standards dans MES/ERP,
configurer dashboards : charge, capacité, écarts standard/réalisé,
suivre : productivité, heures/part, stabilité planning, TRS/OEE (si applicable).
À la fin du mois, vous devez être capable de dire :
“nos standards sont fiables sur X opérations”
“notre planning a gagné en stabilité”
“notre suivi des performances est exploitable”
“voici où nous allons augmenter la productivité (leviers concrets)”
Parce qu’un programme décrit une intention de mouvement, mais la machine exécute avec des contraintes réelles : accélérations, décélérations, limitations d’axes, anticipation (lookahead), conditions de coupe, et événements non modélisés (palpage, arrêt copeaux, pauses). Les rapides (G0) sont particulièrement piégeux : la vitesse nominale n’est pas tenue partout, surtout sur des trajectoires courtes. Enfin, des éléments “invisibles” dans un parsing simple (sous-programmes, macros, cycles fixes, boucles) peuvent changer fortement le temps. La bonne pratique consiste à utiliser le programme pour structurer et comparer, puis à valider par logs contrôleur/monitoring pour obtenir un temps “terrain” fiable.
Sur vos références répétitives, visez une erreur moyenne (MAPE) inférieure à 5 %. En dessous, votre charge machine devient suffisamment stable pour réduire les “retouches” de planning, et vos indicateurs (KPI de production, suivi des performances, TRS/OEE si calculé) deviennent cohérents dans le temps. Au-dessus de 8–10 %, vous allez continuer à surprotéger le planning avec des marges, ce qui masque vos vrais goulots. La clé n’est pas une précision parfaite partout, mais une précision maîtrisée sur l’axe 80/20 : les opérations qui font vos volumes, vos délais et votre marge.
Le temps standard doit refléter la réalité du poste : chargement/déchargement, contrôle, nettoyage, manutention, saisies, etc. La méthode la plus simple est de mesurer 5 à 10 cycles en conditions normales et de retenir une moyenne (ou une médiane si variabilité). Ensuite, ajoutez une allowance documentée (souvent 3 à 8 %) pour les micro-aléas inévitables. L’erreur fréquente est de “gonfler” l’allowance pour se protéger : cela fausse la lecture des écarts et ralentit l’amélioration continue. Mieux vaut un standard clair + une gestion d’exception (arrêts, non-conformités) qu’un standard trop large.
Un logiciel de gestion des temps (ou un module MES/ERP) devient réellement utile quand les temps sont attribués aux bonnes opérations. Concrètement, vous voulez relier : (1) l’opération (ID gamme), (2) la machine, (3) l’opérateur, (4) le temps réel, (5) le standard. Cela permet un suivi des temps de travail par OF, par poste, par équipe, et surtout une analyse “standard vs réalisé” exploitable pour le management (formation, méthodes, outillage, ergonomie). Si vous ne faites que pointer “par tranche” sans lien avec l’opération, vous obtenez au mieux de la paie, mais pas de pilotage production. Le bon compromis est souvent : collecte machine automatique + validations ciblées + attribution opérateur simple (badge, poste, déclarations minimales).
Commencez par un pilote ultra pragmatique : 5 programmes, 1 machine (ou 1 cellule), 10 à 20 cycles chacun, et un tableau unique qui stocke temps programme, temps réel mesuré, écarts, tâches opérateur, et standard final. Même sans intégration, vous allez déjà améliorer l’ordonnancement sur ces références et fiabiliser vos KPI de production. Ensuite, vous pourrez industrialiser : soit via des exports ERP (mise à jour des temps gamme), soit en ajoutant une collecte simple (logs machine, capteur, ou passerelle). L’objectif n’est pas d’acheter “une usine à gaz”, mais de rendre le temps fiable, traçable, et révisable. C’est ce socle qui vous permettra ensuite d’augmenter la productivité sans embaucher, en supprimant les attentes, les erreurs de planning et les reprises.