TRS Qui Déraille : Diagnostic et Correction de vos KPI Production

Un TRS qui ne colle jamais aux relevés terrain, des alertes que plus personne ne regarde, des débats sans fin sur "quel chiffre est le bon" en réunion de production : ce sont les signes d'un système de KPI qui déraille. Ce guide n'explique pas comment déployer un TRS SaaS de zéro — il explique comment diagnostiquer un système déjà en place qui ne fonctionne plus, identifier la cause exacte de la dérive, et la corriger sans créer de nouveaux effets pervers.

TL;DR :

• Un TRS qui diverge entre système et terrain vient presque toujours de trois causes : horodatage désynchronisé, mapping d'ordre incorrect, ou arrêts planifiés mal exclus.

• Ne corrigez jamais un KPI en ajustant les seuils pour masquer un problème : identifiez et corrigez la source, puis validez sur une machine pilote avant de généraliser.

• Un audit reproductible sur 24 heures (comparaison système vs relevé manuel) suffit pour localiser la majorité des dérives.

Les 5 signaux qu'un système de KPI est cassé

Avant de plonger dans le diagnostic technique, voici les symptômes qui doivent alerter :

• Divergence persistante
  Le TRS affiché par le logiciel ne correspond jamais aux relevés opérateurs, et l'écart n'est ni constant ni prévisible.
• Alertes ignorées
  Les notifications de seuil bas ne déclenchent plus aucune réaction — signe que l'équipe ne fait plus confiance à la donnée.
• Débats récurrents sur le chiffre
  Chaque revue hebdomadaire commence par une discussion sur la fiabilité du KPI plutôt que sur l'action à mener.
• KPI qui ne déclenche plus d'action
  Un TRS en baisse depuis plusieurs semaines n'a entraîné aucune décision de maintenance, de réaffectation ou de révision des standards.
• Incohérence inter-machines ou inter-shifts
  Deux machines identiques, sur le même type de pièce, affichent des TRS incompatibles sans explication opérationnelle.

Si vous reconnaissez 2 de ces signaux ou plus, le problème n'est probablement pas votre atelier — c'est votre système de mesure.

Diagnostic étape 1 : l'horodatage et le mapping

La cause la plus fréquente de divergence entre le TRS système et le TRS terrain est technique, pas organisationnelle : des horloges non synchronisées entre machines, automates et serveur SaaS, ou un mapping d'ordre incorrect (un ID d'ordre de fabrication associé à la mauvaise machine ou au mauvais poste).

Liste de vérification :

1. Confirmer que toutes les machines et passerelles utilisent la même référence de temps (NTP, format ISO 8601, idéalement en UTC).
2. Vérifier le mapping ID machine ↔ ID TRS pour chaque poste, y compris après un changement de configuration matérielle.
3. Contrôler que le numéro d'ordre remonté par la machine correspond bien à l'ordre réellement lancé (erreur fréquente lors des changements de série rapprochés).

Un décalage d'horloge de seulement quelques minutes peut suffire à faire basculer des événements d'un shift à l'autre et fausser des KPI calculés par créneau horaire. Si la source du problème remonte à la façon dont les données atelier sont transmises à l'ERP, notre guide sur l'intégration des données atelier à l'ERP détaille comment fiabiliser ce flux en amont.

Diagnostic étape 2 : double comptage et arrêts planifiés mal exclus

Deuxième cause fréquente : plusieurs sources remontent le même événement (par exemple un automate et un capteur additionnel comptent tous deux le même cycle), ce qui gonfle artificiellement le partcount ou le temps de production. À l'inverse, des arrêts planifiés (changement d'outil programmé, maintenance préventive) parfois mal identifiés viennent pénaliser le TRS alors qu'ils ne devraient pas être comptés dans le calcul de disponibilité.

Pour diagnostiquer :

• Comparer, sur une même fenêtre horaire, le nombre d'événements remontés par chaque source connectée à une même machine.
• Vérifier la table de correspondance des codes d'arrêt : un arrêt planifié mal catégorisé comme "arrêt non planifié" fait chuter artificiellement la disponibilité.
• Auditer les cas de reset de compteur (redémarrage machine, changement de programme) qui peuvent générer un double comptage ponctuel.

Diagnostic étape 3 : le piège de la définition ambiguë

Un TRS calculé différemment selon le service — méthodes qui excluent certains arrêts, production qui inclut les pièces en cours de contrôle — rend les chiffres incomparables d'un atelier à l'autre, ou d'une revue à l'autre. C'est rarement un bug : c'est une définition qui n'a jamais été formalisée et documentée de façon unique.

Autre piège fréquent : trop de KPI suivis en simultané noient le signal utile. Une équipe qui reçoit 15 alertes par jour finit par toutes les ignorer, y compris les pertinentes.

Remède : normaliser chaque définition de KPI dans un référentiel unique, avec formule exacte, unité et fenêtre temporelle, et limiter les alertes actives aux 3 à 5 indicateurs qui déclenchent réellement une action.

Méthode de correction sans créer d'effets pervers

Une fois la cause identifiée, la tentation est de "réparer" le chiffre plutôt que la donnée. Trois règles à respecter :

• Ne jamais ajuster un seuil d'alerte pour faire disparaître un problème — cela masque la dérive au lieu de la résoudre.
• Documenter toute correction de données historiques, avec la raison et la date, pour garder une traçabilité en cas de nouvel écart.
• Valider chaque correctif par un test A/B sur une machine pilote avant de le généraliser — par exemple, changer une règle d'exclusion d'arrêt sur une seule machine pendant une semaine et comparer l'écart avant/après avec le relevé manuel.

Cette approche évite l'effet pervers le plus courant : un correctif appliqué à la va-vite qui répare le KPI pour une machine mais en casse un autre ailleurs dans l'atelier.

Liste de vérification d'audit reproductible

Voici la procédure à suivre dès qu'une divergence est signalée :

1. Lancer un audit parallèle sur 24 heures : TRS système vs relevé manuel, sur la même machine et le même shift.
2. Vérifier les horloges et le format d'horodatage (ISO 8601, fuseau, synchronisation NTP).
3. Auditer le mapping ID machine ↔ ID ordre ↔ ID TRS.
4. Contrôler le pipeline d'ingestion (logs d'erreur API, pertes de connexion passerelle).
5. Si l'écart persiste après ces contrôles, tester en mode pilote sur une machine isolée pendant une semaine avant de toucher au reste du parc.

Cette liste de vérification reproductible permet de traiter la majorité des divergences en une seule session d'audit, sans mobiliser toute l'équipe méthodes pendant des jours.

Quand le problème n'est pas la donnée mais l'organisation

Il arrive que la donnée soit parfaitement fiable et que le KPI reste pourtant inutile : personne ne le regarde en réunion, aucune routine ne s'appuie dessus pour décider. Dans ce cas, le diagnostic technique ne suffit pas — il faut revoir la routine de pilotage visuel qui entoure le KPI (fréquence de revue, propriétaire désigné, lien direct entre l'indicateur et une décision concrète). Notre guide sur le tableau de bord KPI production en temps réel détaille comment structurer cette routine autour d'un dashboard réellement actionnable.

Conclusion

Un système de KPI qui déraille se répare rarement en changeant de logiciel ou en ajoutant de nouveaux indicateurs. La majorité des dérives viennent de trois causes précises — horodatage, mapping, définitions ambiguës — identifiables avec un audit de 24 heures. La discipline la plus importante n'est pas technique : c'est de corriger la source plutôt que le chiffre, et de valider chaque correctif sur une machine pilote avant de le généraliser à tout l'atelier. Une fois vos données assainies, vous pouvez repartir sur des bases fiables pour améliorer durablement votre TRS.

Foire aux questions