MTBF / MTTR (Mean Time Between Failures / Mean Time To Repair)
#Définition MTBF / MTTR
MTBF (Mean Time Between Failures) : temps moyen entre défaillances d'un équipement industriel ou d'un service logiciel, indicateur de fiabilité. Formule : somme des heures de fonctionnement nominal / nombre total de défaillances sur la période. Pour approfondir, consultez la page service Agents IA Nehos (maintenance prédictive, agent d'investigation incidents SaaS).
Traduit en termes opérationnels, Plus la valeur est élevée, meilleure est la fiabilité. MTTR (Mean Time To Repair) : temps moyen de réparation, indicateur de réactivité maintenance. Formule : somme des temps de réparation / nombre d'interventions correctives. Plus la valeur est basse, meilleure est la performance.
Disponibilité = MTBF / (MTBF + MTTR). KPIs critiques en maintenance industrielle 4.0 et en disponibilité SaaS. Les valeurs cibles dépendent du secteur et de la criticité. SaaS : SLA 99,9 % = max 8,76 h indisponibilité/an. Normes applicables : ISO 14224 (fiabilité équipements pétrole/gaz/process), IEEE Std 762 (générique fiabilité).
On voit trop de projets échouer par méconnaissance de MTBF / MTTR. La théorie compte — mais la mise en pratique encore plus.
#MTBF / MTTR expliqué simplement
Le MTBF, c'est combien de temps en moyenne ta machine — ou ton service SaaS — tourne sans tomber en panne. Le MTTR, c'est combien de temps il te faut pour la réparer quand elle tombe. Les bonnes pratiques industrie 4.0 tiennent en deux verbes : maximiser le MTBF (maintenance prédictive pilotée par IA sur capteurs IoT, on intervient avant la casse) et minimiser le MTTR (pièces détachées prêtes, procédures écrites, équipe formée).
Pour un SaaS, le MTTR mesure combien de temps ton service est inaccessible avant restauration : c'est le chiffre qui te fait tenir ou exploser ton SLA contractuel.
Mettez-vous dans la peau d'un décideur qui doit arbitrer vite. C'est la réalité du terrain — loin des définitions académiques.
#Cas d'usage concrets
Exemple de situation — ETI industrielle, machines critiques et maintenance prédictive — Situation type : un site industriel équipe ses machines critiques de capteurs de vibration et de température, de gateways edge et d'un modèle ML de détection d'anomalies. On relève le MTBF et le MTTR avant le déploiement, puis après, sur une période de suivi définie au départ.
Le diagnostic anticipé et un stock de pièces détachées calibré sur les signaux faibles doivent allonger le MTBF et raccourcir le MTTR.
Exemple de situation — éditeur SaaS B2B, SLA 99,95 % et observabilité (Sentry, Grafana) — Situation type : une plateforme SaaS B2B s'engage contractuellement sur un SLA de 99,95 % (soit 4,38 h d'indisponibilité maximale par an). Pour tenir cet engagement, elle vise un MTTR court grâce à une observabilité fine (Sentry pour les erreurs d'exécution, Grafana pour les métriques d'infrastructure, PagerDuty pour l'astreinte), des runbooks par type d'incident et une base de connaissance de post-mortems.
Exemple de situation — énergéticien régional sous régulation CRE — Situation type : un gestionnaire de réseau de distribution électrique voit sa rémunération conditionnée par des objectifs fixés par la Commission de régulation de l'énergie (CRE). Il dispose d'un tableau de bord temps réel des défaillances sur ses points de mesure, d'une supervision IIoT et d'équipes d'intervention géolocalisées. Le respect des cibles de MTTR pèse directement sur ses revenus régulés.
#MTBF / MTTR chez Nehos Groupe
Notre service Agents IA Nehos (maintenance prédictive, agent d'investigation incidents SaaS) couvre ce périmètre de A à Z.
La méthode Nehos est documentée sur méthode Legacy Strangler IA-assisted (modernisation systèmes critiques). Chaque mission démarre par un cadrage structuré : objectifs chiffrés, périmètre technique, jalons à 30/60/90 jours. On livre, on mesure, on itère. Pas de slides sans livrable.
#Termes associés
Ce concept ne vit pas isolé.
- IoT industriel
- Maintenance prédictive
- SLA (Service Level Agreement)
- GMAO
- Industrie 4.0
- NIS2
- Observabilité
Tous ces termes sont interconnectés. Maîtriser l'un sans comprendre les autres, c'est voir le puzzle sans toutes les pièces.
Applications Concrètes
« Situation type : un site industriel équipe ses machines critiques de capteurs de vibration et de température, de gateways edge et d'un modèle ML de détection d'anomalies. On relève le MTBF et le MTTR avant le déploiement, puis après, sur une période de suivi définie au départ. Le diagnostic anticipé et un stock de pièces détachées calibré sur les signaux faibles doivent allonger le MTBF et raccourcir le MTTR. »
« Situation type : une plateforme SaaS B2B s'engage contractuellement sur un SLA de 99,95 % (soit 4,38 h d'indisponibilité maximale par an). Pour tenir cet engagement, elle vise un MTTR court grâce à une observabilité fine (Sentry pour les erreurs d'exécution, Grafana pour les métriques d'infrastructure, PagerDuty pour l'astreinte), des runbooks par type d'incident et une base de connaissance de post-mortems. »
« Situation type : un gestionnaire de réseau de distribution électrique voit sa rémunération conditionnée par des objectifs fixés par la Commission de régulation de l'énergie (CRE). Il dispose d'un tableau de bord temps réel des défaillances sur ses points de mesure, d'une supervision IIoT et d'équipes d'intervention géolocalisées. Le respect des cibles de MTTR pèse directement sur ses revenus régulés. »
Questions & réponses
Questions fréquentes sur MTBF et MTTR
Les deux indicateurs mesurent des dimensions opposées et complémentaires de la maintenance. Le MTBF (Mean Time Between Failures) mesure la fiabilité : il répond à la question 'combien de temps mon équipement tient-il entre deux pannes ?'. C'est une moyenne d'heures de fonctionnement sain. Plus il est élevé, mieux c'est. Le MTTR (Mean Time To Repair) mesure la réactivité maintenance : il répond à 'combien de temps me faut-il pour réparer quand ça casse ?'. C'est une moyenne d'heures d'intervention. Plus il est bas, mieux c'est. Les deux se combinent en disponibilité (availability) : MTBF / (MTBF + MTTR). Une machine avec MTBF 2 000 h et MTTR 4 h a une disponibilité théorique de 99,80 %. Optimiser uniquement le MTBF sans toucher au MTTR (ou l'inverse) est une erreur fréquente : ce sont deux leviers complémentaires.
Les ordres de grandeur varient fortement selon la criticité et le secteur. En manufacturing classique sur équipement critique, il n'existe pas de seuil universel : on compare un MTBF et un MTTR à ceux du même équipement dans le temps, ou à ceux d'équipements comparables. En énergie réseau, les exigences de la CRE imposent des MTTR très bas. Côté SaaS, on raisonne en SLA : 99,9 % = max 8,76 h cumul d'indisponibilité par an, 99,95 % = 4,38 h, 99,99 % = 52,6 min, 99,999 % = 5,26 min. Plus l'engagement SLA est élevé, plus le MTTR doit être court, ce qui impose observabilité temps réel, astreinte 24/7 et runbooks automatisés. Comparer des MTBF sans préciser le périmètre (équipement, criticité, conditions d'exploitation) n'a strictement aucun sens.
Quatre leviers structurels, à activer ensemble. Premier levier, la maintenance préventive systématique (changement pièces d'usure selon plan calendaire ou compteur d'heures) — c'est la base, sans elle aucun gain durable. Deuxième levier, la maintenance prédictive pilotée par IA : capteurs vibration, température, courant, acoustique, modèles ML détectant anomalies avant rupture (le gain de MTBF dépend de la qualité des données et se mesure sur plusieurs mois). Troisième levier, la fiabilisation des achats : qualifier sérieusement les pièces critiques, sourcer multi-fournisseurs, tester sur banc avant intégration. Quatrième levier, l'analyse causale post-panne (méthode 5 pourquoi, arbre de défaillance, Pareto Ishikawa) : sans boucle d'apprentissage formalisée, les pannes se répètent. La GMAO consolide ces quatre leviers et fournit la donnée historique nécessaire au calcul MTBF fiable.
L'IA agit sur trois maillons du temps de réparation. Détection : un modèle de détection d'anomalies sur logs, métriques et traces réduit le temps de détection (MTTD), comme le proposent des outils de type Sentry ou Datadog Watchdog. Diagnostic : un assistant IA (LLM augmenté de la base de connaissances incidents) propose les causes probables et le runbook applicable en quelques instants, là où un opérateur en astreinte doit d'abord se remettre en contexte. Résolution : automatisation des actions correctives standards (redémarrage service, rollback déploiement, bascule failover, isolation pod défaillant) via runbooks exécutables. L'effet sur le MTTR se mesure pendant un pilote, incident par incident, sans dégrader la qualité des post-mortems.
La nuance est technique mais réelle, et souvent confondue. Le MTBF (Mean Time Between Failures) s'applique aux systèmes réparables : on mesure le temps entre deux pannes successives sur un même équipement qu'on remet en service après réparation. Le MTTF (Mean Time To Failure) s'applique aux systèmes non réparables ou consommables : composants électroniques unitaires, ampoules, batteries, disques durs en mode jetable. Pour un disque dur, le constructeur annonce un MTTF (durée de vie moyenne avant défaillance non réparable), pas un MTBF. Pour une machine-outil ou un serveur applicatif, on parle de MTBF puisque la réparation remet le système en service. La confusion est courante dans les fiches techniques marketing, où MTBF est parfois employé à tort. La règle pratique : si on jette l'équipement après la première panne, c'est MTTF ; si on le répare et le remet en service, c'est MTBF.