Votre tableau de bord affiche MTBF = 480 h sur la presse n°3. Vendredi 14h, votre chef de prod vous appelle pour le troisième arrêt de la semaine. Quelqu'un ment — et ce n'est pas votre équipe.
Les 3 KPI canoniques de la maintenance industrielle — MTBF, MTTR, disponibilité— sont mathématiquement justes. Tous les CMMS du marché savent les calculer en quelques secondes. Le problème n'est pas la formule.
Le problème, c'est que ces formules s'appliquent sur des données non nettoyées, et qu'elles produisent alors des nombres opérationnellement faux — qui finissent en revue mensuelle, en CAPEX déféré, en cibles budgétaires inatteignables. Bref : en décisions stratégiques bâties sur du sable.
Cet article diagnostique 3 failure modesclassiques des KPI maintenance, avec chiffres terrain à l'appui, et fournit pour chacun une correction concrète implémentable sans changer de logiciel.
MTBF gonflé : préventif et correctif mélangés
Le mensonge le plus répandu — et le plus invisible
MTBF(Mean Time Between Failures) = uptime cumulé / nombre de défaillances. Mesure de référence de la fiabilité d'un équipement réparable.
Le piège
La plupart des CMMS calculent le MTBF sur tous les WO terminés — préventifs, correctifs, inspections, tout ce qui ferme dans la même bucket. Résultat : plus vous faites de maintenance préventive (donc plus vous êtes mature), plus votre MTBF affiché grimpe — sans que vos équipements soient plus fiables.
Le bruit du préventif amortit le signal du correctif. Et le signal du correctif, c'est exactement ce qu'on cherche à mesurer.
Un asset qui panne tous les 2 mois est étiqueté “fiable”en revue mensuelle. Le CAPEX de remplacement reste reporté année après année. Le jour où l'asset lâche en plein cycle critique, la direction découvre le mensonge — trop tard.
Comment recalculer (3 actions)
- Séparer les types de WO au niveau data. Préventif, correctif, amélioration, inspection, urgence. La taxonomie standard ISO 14224 §B.2 est utilisable telle quelle (FreeMaint expose 7 types par défaut).
- Filtrer le calcul.
MTBF = uptime / count(WO WHERE maintenance_type IN ('CORRECTIVE', 'EMERGENCY')) - Distinguer défaillance fonctionnelle vs potentielle. Un préventif qui détecte une dégradation avant la panne n'est pas une panne — le compter comme défaillance tue l'intérêt même de l'inspection.
MTTR sous-estimé : le blast radius des arrêts en cascade
Quand le coût réel d'une panne est invisible dans le KPI
MTTR(Mean Time To Repair) = temps moyen entre l'ouverture du WO et sa complétion. Souvent confondu avec active repair time (le temps réellement passé à réparer).
Le piège
Le MTTR mesure la réparation de l'équipement défaillant. Mais une panne crée presque toujours un blast radius: la machine X tombe, la ligne Y arrêtée en aval, la matière Z dégradée en attendant, l'équipe immobilisée. Le MTTR sur le WO de X ne capture rien de tout ça.
Le coût horaire de panne calculé sur le MTTR (€/h × 2 h = 600 €) est ridiculement sous-évalué. Pas de business case pour investir dans la fiabilité parce que “ça coûte rien”. Le vrai coût (perte de production + matière + équipe = ~9 600 €) reste invisible — et le management refuse les budgets fiabilité parce que les KPI ne justifient pas la dépense.
Comment recalculer (3 actions)
- Modéliser le blast radius. Créer un objet “Shutdown” ou “Incident parent” qui regroupe les WO enfants déclenchés par la cascade. La plupart des CMMS modernes le permettent via un champ
parent_shutdown_idouincident_id. - Calculer le MTTR sur le parent.
downtime = closed_at(parent) − opened_at(parent), pas la somme des MTTR enfants. - Distinguer active repair time vs downtime. ISO 14224 §3.13 fait cette distinction depuis 30 ans. Vos rapports doivent les afficher côte à côte — pas le même nombre.
Disponibilité gonflée : les micro-arrêts non comptés
1 point d'OEE perdu dans le brouillard statistique
Availability = Uptime / (Uptime + Downtime). Au cœur du calcul OEE (Overall Equipment Effectiveness) = Availability × Performance × Quality.
Le piège
La disponibilité ne compte que les downtimes loggés via un WO. Mais sur une ligne de production typique, ~60% des arrêts sont des micro-arrêts de moins de 15 minutes : calage, réglage, purge, micro-bourrage, attente matière, changement de format mineur.
Ces arrêts ne génèrent pas de WO parce que l'opérateur les résout en 5 minutes sans rien dire à personne. Résultat : invisibles dans le CMMS, invisibles dans la dispo, invisibles dans l'OEE.
↑ Ce que le CMMS croit. Ce que la direction voit. Ce qui sert de baseline OEE budgétaire.
Sur une usine à 50 M€ de CA, 1 point d'OEE perdu = ~500 k€ de marge envolée dans le brouillard statistique. Et la cible OEE budgétée est inatteignable parce que la baseline est fausse.
Comment recalculer (3 actions)
- Instrumenter les micro-arrêts. Compteur
stop_countsur l'asset, incrémenté à chaque arrêt >5 secondes via SCADA, PLC, ou capteur de présence. C'est la première brique du downtime tracking sérieux. - Aggréger en time-buckets. Pas un WO par micro-arrêt (overhead administratif insoutenable), mais des buckets horaires/journaliers via meter readings dans le CMMS. Une ligne de meter par jour suffit.
- Distinguer 3 catégories. Breakdown (>1h, ouvre WO) — Short stop (15-60 min, loggé sans WO) — Minor stoppage(<15 min, compteur agrégé). Chacune reportée séparément dans le dashboard.
Tableau récap — à imprimer pour votre prochain comité
Les 3 failure modes, les 3 corrections, les 3 impacts directs.
| Indicateur | Faille classique | Calcul correct | Impact direction |
|---|---|---|---|
| MTBF | Mélange PM + correctif dans le compteur de défaillances | maintenance_type ∈ {CORRECTIVE, EMERGENCY} | Risque caché ×5 à ×10 |
| MTTR | WO start → complete only, ignore le blast radius | Modéliser un shutdown parent + downtime cascadé | Coût panne ×3 à ×15 |
| Disponibilité | Micro-arrêts <15 min jamais loggés | Instrumenter via SCADA + agréger en meter readings | OEE faux 1-3 points |
3 actions pour votre prochaine revue mensuelle
Ces 3 indicateurs ne sont pas mauvais. C'est leur configuration qui ment. La bonne nouvelle : aucun de ces fixes ne demande un nouveau logiciel ou un budget. Juste une taxonomie de WO propre, un objet shutdown parent dans votre CMMS existant, et un cron qui agrège les micro-arrêts depuis votre SCADA.
Recalculer le MTBF sur correctifs uniquement
Sur un asset critique, recalculez le MTBF en excluant les WO préventifs. Comparez avec le MTBF affiché. Le facteur d'erreur va parler de lui-même.
Logger le prochain incident avec un incident_id
Sur le prochain arrêt non-routine, loggez non seulement le WO de réparation mais aussi un identifiant d'incident qui groupe tous les WO impactés. Calculez le downtime réel sur ce parent.
Demander au SCADA vos micro-arrêts du mois
Demandez à votre équipe automatisme le nombre de micro-arrêts <15 min sur le mois passé. Comparez à zéro — ce que votre CMMS croit. Vous allez avoir une surprise.
Pour aller plus loin
- ISO 14224:2016 — Industries du pétrole, du gaz naturel et pétrochimique — Collecte et échange de données de fiabilité et de maintenance pour les équipements
- SEMI E10-0814 — Specification for Definition and Measurement of Equipment Reliability, Availability, and Maintainability (RAM)
- Nakajima (1988) — TPM : An Introduction — référence historique sur la décomposition OEE et les six big losses
Vos KPI maintenance disent la vérité ?
FreeMaint est un CMMS freemium (Core gratuit à vie, sans limite d'utilisateurs ni d'assets) qui sépare nativement préventif et correctif via la taxonomie ISO 14224 — et permet d'auditer chaque indicateur.
Article écrit par Melek Mehrez, fondateur de FreeMaint. Voir tous les articles.
Questions fréquentes
Pourquoi mon MTBF est-il trompeur ?
Le MTBF (Mean Time Between Failures) calculé sur tous les ordres de travail terminés mélange préventifs et correctifs. Plus vous avez de PM réalisés, plus le MTBF affiché monte — sans que votre équipement soit plus fiable. La correction : filtrer le calcul sur les seuls WO de type CORRECTIVE ou EMERGENCY, conformément à la taxonomie ISO 14224.
Qu'est-ce que le blast radius d'une panne ?
Le blast radius désigne l'ensemble des conséquences en cascade d'une panne : machine X tombe, ligne Y attend, matière Z se gâte, équipe en attente. Le MTTR calculé sur le seul WO de réparation de X ne capture rien de tout cela. Pour mesurer le coût réel, il faut modéliser un objet shutdown parent qui regroupe tous les WO impactés et calculer le MTTR sur ce parent.
Pourquoi ma disponibilité affichée est-elle fausse ?
La disponibilité ne compte que les downtimes loggés dans le CMMS via un ordre de travail. Mais ~60% des arrêts industriels sont des micro-arrêts de moins de 15 minutes (calage, réglage, purge, micro-bourrage) que l'opérateur résout en 5 minutes sans créer de WO. Ces minutes invisibles font gonfler artificiellement le taux de disponibilité affiché de 1 à 3 points sur l'OEE.
Comment corriger mes KPI sans changer de logiciel ?
Aucun des 3 fixes ne demande un nouveau logiciel : (1) ajouter un champ maintenance_type sur vos WO pour distinguer préventif / correctif / urgence, (2) introduire un champ incident_id pour grouper les WO d'un même blast radius, (3) instrumenter les micro-arrêts via votre SCADA et agréger via meter readings. Le tout dans votre CMMS existant.