Calcul du MTBF et du MTTR : formules, exemples et suivi automatique avec MQTT

Le calcul du MTBF et du MTTR est la base de toute discussion sur la fiabilité dans une usine : à quelle fréquence cette machine tombe-t-elle en panne, et combien de temps nous faut-il pour la remettre en marche ? Ce guide explique les deux formules, déroule un exemple complet, met en évidence les pièges de définition qui rendent les chiffres incomparables et montre comment calculer automatiquement ces indicateurs à partir d'événements de panne et de réparation captés en MQTT.

Ce que mesurent le MTBF et le MTTR

Le MTBF (Mean Time Between Failures, temps moyen entre pannes) est la durée moyenne de fonctionnement entre une panne et la suivante pour un équipement réparable. Plus il est élevé, mieux c'est. Il décrit la fiabilité : combien de temps la machine tourne généralement avant que quelque chose ne casse.

Le MTTR (Mean Time To Repair, temps moyen de réparation) est la durée moyenne entre le moment où une panne arrête la machine et sa remise en service. Plus il est faible, mieux c'est. Il décrit la maintenabilité et l'efficacité de votre réaction : détection, déplacement, diagnostic, attente des pièces, réparation et essais.

Ensemble, ils déterminent la part du temps pendant laquelle une machine est disponible, et ils désignent des leviers d'amélioration différents. Un MTBF faible appelle une meilleure stratégie de maintenance, des modifications de conception ou une surveillance d'état. Un MTTR élevé appelle une détection plus rapide, une meilleure gestion des pièces de rechange, des procédures plus claires et de la formation.

Les formules

Le temps de fonctionnement désigne le temps pendant lequel l'équipement devait tourner et a effectivement tourné. Il exclut les arrêts planifiés comme les week-ends, la maintenance planifiée et les changements de série, ainsi que le temps d'arrêt dû aux pannes elles-mêmes. C'est sur ce dénominateur que la plupart des calculs se trompent.

Exemple chiffré de calcul MTBF MTTR

Prenons une machine d'emballage sur une période de quatre semaines. Elle est planifiée en deux postes de 8 heures, cinq jours par semaine, soit 20 jours x 16 heures = 320 heures planifiées. Pendant cette période, elle enregistre quatre pannes :

Étape par étape :

1. Temps d'arrêt total dû aux pannes = 0,5 + 3,0 + 1,0 + 1,5 = 6,0 heures.
2. Temps de fonctionnement = 320 heures planifiées - 6,0 heures d'arrêt pour panne = 314 heures.
3. MTBF = 314 / 4 = 78,5 heures.
4. MTTR = 6,0 / 4 = 1,5 heure.
5. Disponibilité intrinsèque = 78,5 / (78,5 + 1,5) = 98,1 pour cent.
6. Taux de défaillance = 4 / 314 = environ 0,0127 panne par heure de fonctionnement.

Les mêmes données indiquent aussi où regarder. Deux des quatre pannes étaient des bourrages à l'alimentation : une seule correction à cet endroit pourrait diviser par deux le nombre de pannes, tandis que la panne de courroie domine le MTTR et invite à vérifier si des courroies de rechange sont stockées près de la ligne.

Pièges de définition à éviter

Les indicateurs ne sont utiles que si tout le monde les calcule de la même façon. Mettez-vous d'accord sur ces règles avant de publier le moindre chiffre :

1. Ce qui compte comme une panne. Une règle courante : tout arrêt non planifié plus long qu'un seuil, par exemple cinq minutes, et qui nécessite une intervention. Les micro-arrêts sous ce seuil relèvent des pertes de performance, pas du MTBF. Consignez le seuil par écrit.
2. Temps de fonctionnement contre temps calendaire. Utiliser les heures calendaires gonfle le MTBF des machines qui ne tournent qu'en un seul poste. Utilisez le temps de marche planifié moins le temps d'arrêt pour panne.
3. Où commence et où s'arrête le MTTR. Commencez au moment où la machine s'est arrêtée, pas à l'arrivée du technicien. Arrêtez-vous quand la machine est rendue à la production, pas quand l'ordre de travail est clôturé au bureau. Le temps de réaction fait partie du problème que vous cherchez à mesurer.
4. MTBF contre MTTF. Le MTTF (Mean Time To Failure, temps moyen jusqu'à la panne) s'applique aux éléments non réparables comme une ampoule ou un roulement étanche. Pour les machines que vous réparez, utilisez le MTBF.
5. Petits échantillons. Avec deux pannes par an, le MTBF varie énormément. Publiez-le avec le nombre de pannes et utilisez des fenêtres plus longues pour les équipements très fiables.
6. Le MTBF n'est pas une durée de vie. Un MTBF de 1 000 heures ne signifie pas que la machine tourne 1 000 heures puis tombe en panne. C'est un taux moyen ; des pannes peuvent survenir tôt, et c'est le cas.

Pourquoi le suivi manuel échoue

Dans de nombreuses usines, le MTBF et le MTTR sont calculés une fois par mois à partir des ordres de travail de la GMAO. Cela pose trois problèmes. Les ordres de travail sont créés tardivement, si bien que le début de panne enregistré est faux. Les pannes courtes réparées par les opérateurs ne donnent jamais lieu à un ordre de travail, si bien que le nombre de pannes est trop bas. Et quand le rapport mensuel arrive, le phénomène à l'origine des pannes date de plusieurs semaines.

Capturer les événements de panne et de réparation directement depuis la machine et auprès des personnes qui la réparent résout ces trois problèmes. La machine sait exactement quand elle s'est arrêtée et quand elle a redémarré. Un pupitre opérateur, un système andon numérique ou le téléphone d'un technicien peut ajouter la cause. MQTT est un transport naturel pour ces événements, car les mêmes événements alimentent aussi le suivi des arrêts machines et les tableaux de bord OEE.

Conception des événements pour un suivi automatique

Utilisez un topic par équipement pour les événements de maintenance, et un petit ensemble de types d'événements :

acme/plant1/packaging/line2/cartoner1/maintenance/event

{"event": "failure_start", "ts": "2026-10-16T08:12:40Z", "reason": "infeed_jam", "id": "f-0193"}
{"event": "repair_end", "ts": "2026-10-16T08:41:05Z", "id": "f-0193", "technician": "T07"}
{"event": "planned_stop_start", "ts": "2026-10-16T14:00:00Z"}
{"event": "planned_stop_end", "ts": "2026-10-16T14:30:00Z"}

Publiez ces événements en QoS 1 pour qu'ils soient livrés au moins une fois, et donnez un identifiant à chaque panne pour qu'une livraison en double ne soit pas comptée deux fois. Comme l'explique le guide des niveaux de QoS MQTT, QoS 1 est le bon compromis pour ce type de données événementielles.

Calculer le MTBF et le MTTR à partir d'événements MQTT

Le service Python ci-dessous s'abonne aux événements de maintenance de tous les équipements sous un préfixe, les stocke dans SQLite et recalcule chaque minute le MTBF et le MTTR sur une fenêtre glissante de 30 jours. Il publie les résultats en retained messages pour que tout tableau de bord voie les valeurs actuelles dès son abonnement. Il utilise paho-mqtt 2.x et le serveur MQTT public de test de ConnectMQ ; remplacez le préfixe par le vôtre.

import json
import sqlite3
import time
from datetime import datetime, timedelta, timezone
import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/d27e5b"
WINDOW_DAYS = 30
db = sqlite3.connect("maintenance.db", check_same_thread=False)
db.execute("""CREATE TABLE IF NOT EXISTS events (
    asset TEXT, event TEXT, ts TEXT, fid TEXT,
    UNIQUE(asset, event, ts))""")

def parse(ts):
    return datetime.fromisoformat(ts.replace("Z", "+00:00"))

def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{PREFIX}/+/maintenance/event", qos=1)

def on_message(client, userdata, msg):
    asset = msg.topic.split("/")[3]
    e = json.loads(msg.payload)
    db.execute("INSERT OR IGNORE INTO events VALUES (?,?,?,?)",
               (asset, e["event"], e["ts"], e.get("id")))
    db.commit()

def metrics(asset, now):
    start = now - timedelta(days=WINDOW_DAYS)
    rows = db.execute("SELECT event, ts FROM events WHERE asset=? ORDER BY ts", (asset,)).fetchall()
    failures, repair_s, planned_s = 0, 0.0, 0.0
    open_fail = open_plan = None
    for event, ts in rows:
        t = max(parse(ts), start)
        if event == "failure_start":
            open_fail = t
            if parse(ts) >= start:
                failures += 1
        elif event == "repair_end" and open_fail:
            repair_s += (t - open_fail).total_seconds()
            open_fail = None
        elif event == "planned_stop_start":
            open_plan = t
        elif event == "planned_stop_end" and open_plan:
            planned_s += (t - open_plan).total_seconds()
            open_plan = None
    if open_fail:
        repair_s += (now - open_fail).total_seconds()
    operating_h = (WINDOW_DAYS * 86400 - planned_s - repair_s) / 3600
    mtbf = operating_h / failures if failures else None
    mttr = repair_s / 3600 / failures if failures else None
    avail = mtbf / (mtbf + mttr) if failures else 1.0
    return {"window_days": WINDOW_DAYS, "failures": failures,
            "operating_h": round(operating_h, 1),
            "mtbf_h": round(mtbf, 1) if mtbf else None,
            "mttr_h": round(mttr, 2) if mttr else None,
            "inherent_availability": round(avail, 4)}

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="reliability-d27e5b")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()

while True:
    time.sleep(60)
    now = datetime.now(timezone.utc)
    for (asset,) in db.execute("SELECT DISTINCT asset FROM events").fetchall():
        result = metrics(asset, now)
        client.publish(f"{PREFIX}/{asset}/maintenance/kpi", json.dumps(result), qos=1, retain=True)
        print(asset, result)

Simulez une panne depuis la ligne de commande et regardez le KPI se mettre à jour en moins d'une minute :

mosquitto_pub -h broker.connectmq.com -p 1883 -i sim-d27e5b -q 1 \
  -t "connectmq/demo/d27e5b/cartoner1/maintenance/event" \
  -m '{"event":"failure_start","ts":"2026-10-16T08:12:40Z","id":"f-0001"}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i sim-d27e5b -q 1 \
  -t "connectmq/demo/d27e5b/cartoner1/maintenance/event" \
  -m '{"event":"repair_end","ts":"2026-10-16T08:41:05Z","id":"f-0001"}'

Cet exemple considère tout le temps hors arrêts planifiés et réparations comme du temps de fonctionnement, ce qui convient aux équipements qui tournent en continu. Pour les machines qui ne tournent que sur certains postes, publiez planned_stop_start et planned_stop_end pour les périodes hors production, ou alimentez le calendrier des postes depuis votre MES. Le broker ne fait que transporter les événements ; le fichier SQLite (ou votre historian) est le système de référence, car un broker n'est pas une base de données. En production, pointez le service vers votre broker ConnectMQ privé avec le nom d'utilisateur, le mot de passe et le client ID générés dans le portail, et utilisez TLS sur le port 8883.

Exploiter les chiffres

• Classez d'abord les équipements par nombre de pannes, puis par MTTR. L'équipement aux nombreuses pannes courtes a besoin d'une amélioration de fiabilité ; celui aux rares pannes longues, d'une amélioration de maintenabilité.
• Ventilez par code de cause. Le MTBF par cause de panne montre quelles corrections feraient le plus bouger l'indicateur.
• Suivez des tendances, pas des instantanés. Un MTBF glissant sur 30 ou 90 jours qui augmente après l'introduction de la surveillance d'état est la preuve la plus claire que les investissements en surveillance d'état et maintenance prédictive sont rentables.
• Surveillez les composantes du MTTR. Si la détection est lente, ajoutez des alertes ; si les pièces tardent, revoyez les rechanges ; si le diagnostic est lent, améliorez les procédures.

Pour une vue d'ensemble des indicateurs d'usine et du lien entre fiabilité et OEE, consultez le guide de la fabrication intelligente.

Suivez vos KPI de fiabilité avec ConnectMQ

ConnectMQ est un broker MQTT managé avec MQTT 5, QoS 1 et 2, retained messages, TLS et un explorateur de topics en direct : événements de panne, événements de réparation et KPI calculés transitent tous par un même backbone privé. Créez votre broker avec l'offre Serverless gratuite sur app.connectmq.com, sans carte bancaire, ou testez d'abord sur le serveur MQTT public gratuit, réservé aux tests et aux données non sensibles.

Questions fréquentes

Comment calcule-t-on le MTBF ?

Divisez le temps de fonctionnement total par le nombre de pannes sur la même période. Le temps de fonctionnement exclut les arrêts planifiés et les temps d'arrêt causés par les pannes elles-mêmes.

Comment calcule-t-on le MTTR ?

Divisez le temps total consacré à la remise en service des équipements en panne par le nombre de réparations. Mesurez à partir du moment où la machine s'est arrêtée jusqu'à sa remise à la production.

Quel est le lien entre MTBF, MTTR et disponibilité ?

La disponibilité intrinsèque est égale au MTBF divisé par la somme du MTBF et du MTTR. Augmenter le MTBF ou réduire le MTTR améliore la disponibilité.

Quelle est la différence entre MTBF et MTTF ?

Le MTBF s'applique aux équipements réparables qui reviennent en service après une panne. Le MTTF s'applique aux éléments non réparables, remplacés lorsqu'ils tombent en panne.