RTO : qu'est-ce que le Recovery Time Objective (et pourquoi ce n'est pas le délai de votre activité)

Ce qu'il faut retenir

Le RTO (Recovery Time Objective) est le délai dans lequel une application doit être remise en marche après une panne. Quand on construit un Plan de Continuité d'Activité (PCA) pour la première fois, on confond souvent ce délai avec celui que l'activité métier peut supporter sans dégât. Ce sont en réalité deux choses différentes. Cet article reprend les notions dans le bon ordre, avec des exemples concrets, pour qu'à la fin vous sachiez de quoi vous parlez quand on vous demande de remplir une colonne RTO dans un tableau.

Pourquoi le RTO est-il un sujet sensible dans un PCA ?

Imaginez la scène. Vous venez de récupérer le dossier "continuité d'activité" dans votre entreprise. On vous tend un grand tableau Excel avec plein de colonnes, dont une intitulée RTO. On vous demande de la remplir pour chaque application de l'entreprise. Personne ne vous a vraiment expliqué ce qu'il faut mettre dedans.

Le problème, c'est que ce chiffre n'est pas anodin. Le RTO dit aux équipes techniques en combien de temps elles doivent être capables de remettre une application en marche après une panne. À partir de ce chiffre, l'entreprise dimensionne ses sauvegardes, achète des serveurs de secours, signe des contrats avec des prestataires, met en place des procédures de redémarrage. Si vous mettez "4 heures" alors qu'il fallait mettre "1 heure", tout ce qui se construit derrière est sous-dimensionné. Si vous mettez "1 heure" alors qu'on pouvait se contenter de "8 heures", l'entreprise paie pour des moyens dont elle n'avait pas besoin.

L'objectif de cet article est simple : poser les bases pour quelqu'un qui débute sur le sujet. On va voir ce qu'est le RTO, à quoi il sert, comment on le calcule, et comment éviter les pièges qui font qu'un RTO écrit dans un PCA n'a aucun rapport avec la réalité.

Qu'est-ce que le RTO ?

Le RTO, pour Recovery Time Objective, est la capacité de la direction des systèmes d'information (DSI) à remettre une application en marche dans un délai donné après une panne. Autrement dit, c'est le temps que la DSI s'engage à tenir, compte tenu de ses moyens techniques, pour relancer cette application précise.

Prenons un exemple. Pour le logiciel de facturation, la DSI annonce un RTO de 4 heures. Cela veut dire que techniquement, en cas de panne, son infrastructure et ses procédures lui permettent de relancer le logiciel en 4 heures maximum. Si une panne survient à 9 heures du matin et que le logiciel est de nouveau opérationnel à 11 heures, le RTO est tenu. S'il faut attendre 14 heures, le RTO n'est pas tenu, et c'est le signe d'un dispositif technique sous-dimensionné ou d'un RTO mal évalué au départ.

Pour la suite, deux choses sont importantes à retenir.

Le RTO concerne une application, pas une activité

C'est la première source de confusion, et la plus fréquente. Beaucoup parlent du "RTO d'une activité". Ce n'est pas la bonne formulation.

Une activité, c'est quelque chose que fait l'entreprise pour ses clients ou pour elle-même. "Facturer les clients" est une activité. "Produire des pièces sur la chaîne" est une activité. "Verser les salaires" est une activité.

Une application, c'est l'outil informatique qui sert à faire tourner l'activité. Pour facturer les clients, vous utilisez un logiciel de facturation. Pour produire des pièces, vous utilisez un système qui pilote les machines. Pour verser les salaires, vous utilisez un logiciel de paie.

Le RTO se mesure sur l'application, pas sur l'activité. Pourquoi ? Parce qu'une activité dépend souvent de plusieurs applications, et qu'un même incident technique peut toucher une application sans toucher les autres. Pour piloter correctement la continuité, on a besoin de raisonner application par application.

Le RTO est une capacité technique

Tout le monde aimerait que ses applications redémarrent en cinq minutes. La question n'est pas là. La question est : avec les moyens techniques en place aujourd'hui, en combien de temps l'équipe informatique est-elle réellement capable de relancer l'application ?

Le RTO est exprimé par la direction des systèmes d'information (DSI). Il dépend de l'infrastructure, des sauvegardes, des procédures, des personnes disponibles. Ce n'est pas un objectif politique qu'on inscrit dans un document pour faire bonne figure. C'est un chiffre que la technique doit pouvoir tenir.

Pourquoi parle-t-on aussi de DMIA et de BRTO ?

Si le RTO portait sur tout à la fois, on n'aurait besoin que de ce seul indicateur. Mais dans la vraie vie, trois questions différentes se posent, et chacune mérite son chiffre. Reprenons-les dans l'ordre.

Le DMIA : combien de temps l'activité peut-elle tenir à l'arrêt ?

La première question est la plus importante, et c'est celle qu'on oublie le plus souvent. Combien de temps une activité peut-elle s'arrêter avant que les conséquences ne deviennent vraiment graves pour l'entreprise ?

Cette durée porte un nom : le DMIA, Délai Maximal d'Interruption Admissible. Au-delà du DMIA, l'organisation subit des dégâts durables : perte de clients, sanction réglementaire, atteinte à la réputation, perte financière qu'on ne récupère pas.

Quelques exemples pour fixer les idées. L'activité "verser les salaires" peut probablement tolérer 24 ou 48 heures d'arrêt sans conséquence majeure. Son DMIA est donc long. L'activité "traiter les paiements par carte bancaire dans un magasin" ne peut pas tolérer plus de quelques minutes d'arrêt avant que les clients ne partent. Son DMIA est très court.

Important : le DMIA porte sur les activités, jamais sur les applications. C'est l'entreprise et ses clients qui décident de ce qui est tolérable, pas la technique.

Le BRTO : qu'est-ce que le métier demande à la DSI ?

Une fois qu'on connaît le DMIA d'une activité, on se tourne vers les applications qui la font tourner. Et on pose la question : à partir de quand le métier a-t-il besoin que cette application précise soit relancée ?

La réponse à cette question, c'est le BRTO (Business Recovery Time Objective). C'est le besoin de retour de l'application, exprimé par le métier, application par application. C'est une demande, pas une capacité technique.

Et voici un point qui surprend souvent les débutants : dans la grande majorité des cas, le BRTO d'une application est égal ou supérieur au DMIA de l'activité qu'elle supporte. Autrement dit, le métier accepte que l'application revienne en même temps que l'activité, ou même plus tard.

Pourquoi ? Parce qu'une application est là pour servir une activité, pas l'inverse. Si l'activité est à l'arrêt, relancer l'application en urgence n'apporte rien. Et il existe deux situations très courantes où le métier peut très bien faire tourner l'activité sans l'application.

Première situation : l'application gère quelque chose qui n'est pas critique pour cette activité-là. Une activité peut très bien reprendre sans toutes ses applications support. Si l'application gère, par exemple, le suivi statistique des opérations, son redémarrage peut attendre.

Seconde situation : le métier a prévu un mode dégradé. C'est une façon de continuer à travailler sans l'application, le temps qu'elle revienne. Un template Excel rempli à la main, un cahier où on note les commandes, un standard téléphonique en remplacement du logiciel de prise de rendez-vous. Tant que ce mode dégradé tient, l'application peut prendre son temps.

Les exceptions existent, et elles sont importantes à identifier. Certaines applications doivent revenir avant l'activité, par exemple parce qu'elles conditionnent le redémarrage d'autre chose, ou parce qu'une obligation réglementaire impose un fonctionnement continu. Dans ces cas-là, et dans ces cas-là seulement, le BRTO est plus court que le DMIA.

Le RTO : qu'est-ce que la DSI peut techniquement tenir ?

Le métier a exprimé son besoin avec le BRTO. La DSI regarde maintenant ce qu'elle peut faire, du point de vue purement technique.

Le RTO, c'est la capacité technique de l'application, exprimée par la DSI. C'est ce que la technique est capable de réaliser pour relancer cette application précise, compte tenu de l'infrastructure, des sauvegardes, des procédures et des équipes disponibles. C'est une capacité mesurable, idéalement vérifiée par un test, pas estimée à la louche.

Tout l'enjeu d'un dispositif sain tient en une règle simple : le RTO doit être inférieur ou égal au BRTO. Autrement dit, ce que la DSI est techniquement capable de faire doit être au moins aussi rapide que ce que le métier demande. Si la DSI annonce un RTO de 4 heures alors que le métier a un BRTO de 1 heure, il y a un écart à traiter. Soit en investissant dans des moyens techniques plus rapides, soit en convenant avec le métier que les 1 heure ne sont pas tenables et que le BRTO doit être revu.

À ce stade, vous avez les trois notions essentielles. Le même raisonnement existe pour la perte de données acceptable : c'est le RPO, que je traite dans un article séparé.

DMIA, BRTO, RTO en un coup d'œil

Avant d'aller plus loin, voici le récapitulatif des trois notions à garder en tête.

Indicateur	Porte sur	Nature	Question à laquelle il répond
DMIA	Une activité	Plafond de tolérance	Combien de temps l'activité peut-elle rester arrêtée avant que les conséquences soient inacceptables ?
BRTO	Une application support de l'activité	Besoin métier	En combien de temps le métier a-t-il besoin que l'application soit relancée ?
RTO	Une application support de l'activité	Capacité technique	En combien de temps la DSI est-elle capable de relancer l'application ?

Comment construit-on le RTO d'une application ?

Maintenant que les notions sont posées, voyons comment, concrètement, on remplit cette fameuse colonne RTO du tableau. La méthode suit toujours le même ordre : on part de l'activité, puis on descend vers l'application.

Tout part du BIA

Le point de départ est le BIA (Bilan d'Impact sur l'Activité, ou Business Impact Analysis). Le BIA est un exercice qui consiste à passer en revue toutes les activités de l'entreprise et à mesurer ce qui se passe quand elles s'arrêtent : perte financière, perte de clients, sanction réglementaire, atteinte à la réputation, risque sur les personnes.

De ce travail sort le DMIA de chaque activité. C'est le socle. Sans BIA sérieux, tous les chiffres qui suivent sont des suppositions. C'est exactement le travail que je mène dans ma mission BIA : des entretiens terrain avec les opérationnels, pas un questionnaire diffusé par mail.

Du DMIA de l'activité au BRTO de l'application

Une fois le DMIA connu, le métier détermine, pour chaque application qui supporte l'activité, son BRTO. Comme on l'a vu plus haut, ce n'est pas une recopie automatique. Le BRTO dépend du rôle réel de l'application dans l'activité, de l'existence ou non d'un mode dégradé, et d'éventuelles obligations réglementaires.

Du BRTO au RTO : la réponse de la DSI

Le BRTO en main, la DSI évalue sa capacité réelle et formule le RTO. Si le RTO atteignable est plus long que le BRTO, l'écart est documenté et un plan d'investissement ou d'organisation est défini pour le réduire. Le but reste constant : RTO inférieur ou égal au BRTO.

Les pièges les plus fréquents

Trois pièges reviennent presque systématiquement dans les PCA construits sans accompagnement. Les connaître évite de remplir le tableau Excel n'importe comment.

Recopier le DMIA dans la colonne RTO

C'est le piège mécanique. L'activité a un DMIA de 6 heures, on met 6 heures partout dans la colonne RTO des applications qui la supportent. Simple, et faux. Comme on l'a vu, le BRTO d'une application n'est pas un calque du DMIA. Et le RTO, c'est encore autre chose : c'est ce que la DSI peut tenir techniquement, pas ce que le métier demande.

Confondre besoin et capacité

Quand un PCA affiche une seule colonne RTO sans distinguer ce que le métier demande (BRTO) de ce que la DSI peut techniquement tenir (RTO), il masque presque toujours un écart. Le chiffre inscrit est souvent le besoin métier, repris tel quel, et personne n'a vérifié que la DSI savait le tenir. Tant que cet écart n'est pas nommé, il n'est pas traité. Et le jour de la crise, il se règle tout seul, dans le mauvais sens.

Écrire un RTO qui n'a jamais été testé

Une fois le RTO formulé par la DSI, il reste une hypothèse. Et une hypothèse non vérifiée, en continuité d'activité, est un risque déguisé en sécurité.

Seul un test révèle le RTO réel. Restaurer effectivement depuis une sauvegarde. Chronométrer. Vérifier que les bonnes personnes sont joignables, que les procédures sont à jour, que toutes les dépendances ont été identifiées. C'est souvent à ce moment qu'on découvre que la restauration prend le double du temps prévu, qu'une étape manuelle oubliée ajoute plusieurs heures, ou qu'une compétence clé n'est détenue que par une seule personne, en congé le jour J.

Point de vigilance. Un PCA qui affiche des RTO jamais testés affiche en réalité des intentions. L'écart entre le RTO écrit et le RTO constaté en exercice est presque toujours défavorable. Tant qu'il n'a pas été mesuré, il n'est pas traité, et il se règle tout seul le jour de l'incident, dans le mauvais sens.

Un exercice sur table permet déjà de confronter les RTO affichés à la réalité du déroulé, étape par étape, sans logistique lourde. Et tester ne suffit pas si les enseignements ne sont pas réinjectés dans le plan : c'est tout l'enjeu d'une vraie culture de continuité, que j'aborde dans mon article sur la culture de résilience.

Questions fréquentes sur le RTO

Le RTO concerne-t-il une activité ou une application ?

Une application, ou plus largement une ressource technique. Le RTO ne porte pas sur une activité métier. La tolérance d'interruption d'une activité se mesure avec le DMIA (Délai Maximal d'Interruption Admissible). Parler du RTO d'une activité est une confusion fréquente : une activité a un DMIA, les applications qui la supportent ont un RTO.

Quelle est la différence entre le BRTO et le RTO ?

Le BRTO est le besoin métier : le délai de retour de l'application demandé par le métier. Le RTO est la capacité technique : le délai de reprise que la DSI sait réellement tenir, compte tenu de son infrastructure. Le BRTO est une demande, le RTO est une capacité. L'objectif d'un dispositif sain est que le RTO soit inférieur ou égal au BRTO.

Le BRTO peut-il être plus court que le DMIA de l'activité ?

Oui, mais c'est l'exception, pas la règle. Dans la grande majorité des cas, le BRTO est égal ou supérieur au DMIA, parce que le métier peut souvent reprendre l'activité sans toutes ses applications, soit parce qu'elles ne sont pas critiques, soit parce qu'un mode dégradé prend le relais. Les exceptions concernent les applications qui conditionnent le redémarrage d'autres systèmes, ou celles soumises à une obligation réglementaire de fonctionnement continu.

Un RTO peut-il être de zéro ?

Oui, pour certaines applications critiques, en particulier quand une obligation réglementaire interdit toute interruption de surveillance. Un RTO proche de zéro suppose des dispositifs techniques adaptés, comme la redondance ou le basculement automatique. Cela a un coût, donc on le réserve aux applications dont le BRTO le justifie réellement, identifiées via le BIA.

À quelle fréquence faut-il revoir son RTO ?

Le RTO doit être revu dès qu'un changement significatif intervient : nouvelle application critique, évolution de l'infrastructure, nouvelle obligation réglementaire, changement d'organisation. À défaut, une revue annuelle accompagnée d'un test permet de vérifier que le RTO affiché reste tenable.

Passez à l'action

Le RTO n'est pas un chiffre à recopier. C'est le dernier maillon d'une chaîne : un DMIA d'activité issu du BIA, un BRTO qui exprime le besoin métier pour chaque application support, une capacité technique formulée par la DSI, et un test pour confirmer que cette capacité rejoint le besoin.

Si vous voulez vérifier que les RTO de votre plan de continuité reposent sur cette logique et tiennent vraiment la route, envoyez-moi un message via le formulaire de contact ou réservez directement un créneau de 30 minutes via Calendly. On fait le point ensemble, sans engagement.

Sources et références

ISO 22301:2019, Sécurité et résilience, Systèmes de management de la continuité d'activité (ISO)

Good Practice Guidelines (Business Continuity Institute)

What Is a Recovery Time Objective (RTO)? (Continuity2)

À lire également

Besoin d'accompagnement ?

Découvrez nos offres dédiées à la mise en place d'un PCA, à l'accompagnement ISO 22301 ou aux exercices de crise immersifs. Pour en savoir plus sur ma démarche, consultez la page À propos.