RTO, RPO, MTPD : déjà mesurés ?

Un client m’a montré son plan de continuité. En page 4, un tableau indiquait « RTO : 4 heures » pour son ERP.

Au premier test, le serveur est revenu en 9 heures. Les commandes ont recommencé à sortir de l’entrepôt le lendemain midi, 28 heures après le début de l’exercice. Le « 4 h » écrit au tableau blanc le matin est resté là toute la journée. Personne n’a osé l’effacer.

Personne n’avait menti. Le chiffre venait de la fiche technique du logiciel de sauvegarde, pas d’une mesure. Un RTO jamais chronométré est une promesse, pas un chiffre. Et le RTO n’est qu’un des chiffres qui comptent quand on parle de continuité des affaires.

Pour rappel, j’ai déjà présenté le RTO et le RPO dans mon article sur la norme ISO 27031:2025. Ici, je vais plus loin : d’où viennent ces chiffres, comment les mesurer et quoi suivre une fois qu’ils existent.

Quinze jours sans services : le cas de la CCQ

Le 24 août 2026, la Commission de la construction du Québec (CCQ) a fermé ses systèmes à la suite d’une cyberattaque. Ses services ont été rétablis le 8 septembre, environ quinze jours plus tard. Pendant ce temps, la CCQ a prolongé jusqu’au 30 septembre la validité de certains certificats de compétence qui venaient à échéance. Elle a aussi reporté sans pénalité la date de remise du rapport mensuel.

Je ne connais pas les cibles de reprise internes de la CCQ et je ne vais pas en inventer. Par contre, ce cas illustre très bien une notion que peu de PME connaissent.

Un organisme qui fixe ses propres règles peut repousser ses propres échéances pour acheter du temps. Votre PME, elle, ne peut pas prolonger le délai de livraison de son plus gros client. Le moment où vous ne pouvez plus acheter de temps porte un nom : le MTPD.

Les acronymes, dans l’ordre où il faut les définir

La plupart des plans que je lis commencent par le RTO. C’est à l’envers. Voici l’ordre logique.

BIA : d’où viennent tous les autres chiffres

Le BIA (Business Impact Analysis, ou bilan d’impact sur les activités) est l’exercice qui produit tous les autres chiffres. La norme ISO 22301, la norme de référence en continuité des affaires, l’exige à la clause 8.2.2. Sans BIA, vos RTO sont des devinettes.

MTPD : la limite que la gestion fixe

Le MTPD (Maximum Tolerable Period of Disruption, ou durée maximale d’interruption tolérable) est la durée après laquelle les conséquences deviennent inacceptables. Un client perdu, une pénalité contractuelle, une obligation légale manquée, une paie qui ne part pas. Vous verrez aussi l’acronyme MAO (Maximum Acceptable Outage) pour la même notion.

Ce chiffre appartient à la gestion. Pas au fournisseur MSP, pas au technicien.

RTO : le délai pour remettre en marche

Le RTO (Recovery Time Objective, ou objectif de temps de reprise) est le délai visé pour que l’activité reprenne après le début de l’interruption. Il doit toujours être plus court que le MTPD, avec une marge.

WRT : le temps que tout le monde oublie

Le WRT (Work Recovery Time, ou temps de remise au travail) couvre la période entre le retour du système et le retour au travail normal. Vérifier que les données sont intactes, ressaisir les transactions perdues, rattraper les commandes en retard.

Chez mon client, le serveur avait pris 9 heures. Les 19 heures suivantes, c’était du WRT. La règle est simple : RTO + WRT doit rester sous le MTPD.

RPO : le travail que vous acceptez de refaire

Le RPO (Recovery Point Objective, ou objectif de point de reprise) indique jusqu’où dans le passé vous acceptez de revenir. Un RPO de 24 heures veut dire que vous acceptez de ressaisir une journée complète de travail.

Attention au rançongiciel. Si l’attaquant était dans votre réseau depuis dix jours, votre dernière copie fiable peut être beaucoup plus vieille que celle d’hier soir. Votre RPO réel devient celui de la dernière copie propre, pas de la dernière copie.

MBCO : le mode dégradé acceptable

Le MBCO (Minimum Business Continuity Objective, ou niveau minimal de continuité) décrit ce que l’entreprise doit minimalement être capable de faire pendant la panne. Prendre les commandes au téléphone, expédier ce qui est déjà emballé, verser la paie. Pendant les premiers jours, c’est souvent le MBCO qui sauve une PME, bien avant le retour des systèmes.

En résumé

Acronyme	Nom complet	La question	Qui répond
BIA	Business Impact Analysis (bilan d’impact sur les activités)	Quelles activités sont critiques et que coûte leur arrêt?	La gestion, avec une personne par fonction
MTPD (ou MAO)	Maximum Tolerable Period of Disruption, ou Maximum Acceptable Outage (durée maximale d’interruption tolérable)	Après combien de temps l’arrêt devient-il inacceptable?	La gestion
MBCO	Minimum Business Continuity Objective (niveau minimal de continuité)	Que doit-on minimalement continuer à faire pendant la panne?	La gestion et les opérations
WRT	Work Recovery Time (temps de remise au travail)	Combien de temps pour reprendre le travail une fois le système revenu?	Les opérations
RTO	Recovery Time Objective (objectif de temps de reprise)	En combien de temps le système doit-il revenir?	Calculé à partir du MTPD et du WRT, puis approuvé par la gestion
RPO	Recovery Point Objective (objectif de point de reprise)	Combien de travail accepte-t-on de refaire?	Les opérations, puis la gestion
RTA	Recovery Time Actual (temps de reprise réel)	Combien de temps la reprise a-t-elle pris lors du test?	Mesuré pendant un test

Comment mesurer ces chiffres

Le MTPD se mesure en questions, pas en technologie

Réunissez une personne par fonction : ventes, opérations, finances, ressources humaines. Pour chaque activité, posez la même question à quatre moments. Après 4 heures, 1 jour, 3 jours et 1 semaine d’arrêt, que se passe-t-il? Notez les conséquences en dollars, en clients et en obligations légales.

Le premier moment où quelqu’un dit « là, on perd le client » ou « là, on est en défaut », c’est votre MTPD pour cette activité. Dans ces rencontres, c’est souvent le contrôleur qui donne la réponse la plus précise. Il sait exactement quel jour la paie doit partir.

Le RTO se calcule à rebours

Prenons l’expédition d’un distributeur. Son MTPD est de 72 heures. Le WRT mesuré en exercice est de 16 heures. Il reste donc 56 heures. Avec une marge, le RTO visé devient 48 heures.

Ensuite, vous demandez à votre fournisseur MSP si l’infrastructure actuelle peut livrer 48 heures. Si la réponse est non, ce n’est plus une question technique. C’est une décision de budget qui revient à la gestion : payer pour une reprise plus rapide ou accepter le risque par écrit.

Le RTA : le seul chiffre qui compte

Le RTA (Recovery Time Actual, ou temps de reprise réel) est un terme moins officiel, mais très utilisé. C’est ce que vous mesurez pendant un test.

Le chronomètre part quand l’incident est déclaré. Il s’arrête quand un utilisateur confirme qu’il travaille normalement, pas quand le technicien voit le serveur redémarrer. C’est exactement là que l’écart de mon client s’est caché.

Même logique pour le RPO. Après la restauration, regardez la dernière transaction présente dans le système. L’écart avec l’heure de l’incident simulé, c’est votre RPO réel.

Quoi suivre une fois les chiffres en place

Des chiffres définis une fois et rangés dans un classeur vieillissent mal. Voici les indicateurs que je recommande de suivre :

L’écart entre le RTA et le RTO pour chaque système critique, à chaque test. Un écart positif = un plan à corriger ou un RTO à renégocier avec la gestion.
La date du dernier test de restauration complète pour chaque système critique. Minimalement une fois par année.
L’âge de la dernière copie restaurable, vérifié chaque mois. C’est votre RPO réel au quotidien.
La proportion des activités critiques qui ont un MTPD, un RTO et un RPO approuvés par la gestion.
Le délai de reprise garanti par vos fournisseurs (MSP, infonuagique, logiciel en ligne), comparé au vôtre.

Ce dernier point est souvent oublié. Le 20 octobre 2025, une panne d’Amazon Web Services dans sa région us-east-1 a paralysé pendant plusieurs heures des services comme Signal, Canva et Snapchat. Si votre ERP en ligne dépend d’un seul fournisseur, le délai garanti dans son contrat devient le plancher de votre propre RTO. Vous ne pouvez pas promettre mieux que lui.

Revoyez aussi votre BIA une fois par année et à chaque changement majeur. Un nouvel ERP, une migration infonuagique ou un nouveau client qui représente 30 % de vos ventes changent vos MTPD.

Pour une entreprise certifiée ISO 27001, c’est ce que l’auditeur va chercher pour le contrôle A.5.30 (préparation des TIC pour la continuité des activités). Des cibles approuvées, des tests datés et des écarts traités.

Quelques pièges

Je les vois revenir d’un mandat à l’autre :

Un seul RTO pour toute l’entreprise. La paie et l’intranet n’ont pas la même urgence.
Un RTO plus long que le MTPD. Ça arrive plus souvent qu’on pense, simplement parce que personne n’a mis les deux chiffres côte à côte.
Un RTO copié de la fiche technique d’un produit.
Un test de restauration fait sur un fichier plutôt que sur un système complet.
Des chiffres fixés par le fournisseur MSP seul, sans que la gestion les ait approuvés.

Concrètement, par où commencer

Listez vos 5 à 10 activités critiques. Des activités (expédier, facturer, payer), pas des serveurs.
Faites fixer le MTPD de chacune par la gestion.
Définissez le MBCO : ce que vous devez continuer à faire, même à la main.
Mesurez le WRT lors d’un exercice sur table avec les personnes qui font le travail.
Calculez le RTO et le RPO à rebours, puis faites-les approuver.
Testez une restauration complète et notez le RTA et le RPO réel.
Inscrivez les écarts à votre registre des risques et revoyez-les chaque année.

Bref, le RTO n’est pas un chiffre que votre fournisseur vous donne. C’est un chiffre que votre gestion fixe à partir du MTPD et que vos tests confirment ou contredisent.

Votre plan indique un RTO pour votre système le plus important. Ce chiffre a-t-il déjà été chronométré, du début de l’incident jusqu’au premier employé qui recommence à travailler?

Vous voulez savoir où vous en êtes là-dessus? Parlons-en.

RTO, RPO, MTPD : vos chiffres de continuité ont-ils déjà été mesurés?