En bref : RTO RPO, ce sont deux chiffres d’affaires : le RTO fixe la durée maximale d’interruption tolérable, le RPO l’ancienneté maximale acceptable de la dernière copie de données utilisable. Ces cibles se décident par processus d’affaires, pas globalement pour « l’informatique », et sans chiffre fixé par la direction, les TI improvisent une limite que personne n’a validée ni testée.
Si un incident informatique frappait votre entreprise demain matin, vous demanderiez sans doute deux choses : combien de temps avant que tout revienne, et combien de travail va falloir refaire. Ces deux questions ont des noms techniques, RTO et RPO, mais les réponses ne sont pas techniques. Ce sont des choix d’affaires que beaucoup d’entreprises n’ont jamais faits, et que leurs TI ont dû deviner à leur place, sans jamais recevoir de cible à respecter ni de budget pour l’atteindre.
Dans cet article
C’est quoi le RTO, l’objectif de temps de reprise ?
Le RTO, ou Recovery Time Objective (objectif de temps de reprise), est la durée maximale pendant laquelle un système ou un processus d’affaires peut rester indisponible avant que l’interruption devienne inacceptable pour l’entreprise.
Le mot clé est « inacceptable », pas « souhaitable ». Tout le monde souhaite une reprise instantanée. La question que le RTO force à trancher est différente : à partir de combien d’heures, de minutes ou de jours l’arrêt commence-t-il à coûter plus cher que ce que l’entreprise est prête à absorber, en revenus perdus, en pénalités contractuelles, en réputation, en obligations légales.
Un RTO n’est pas une aspiration. C’est une limite fixée d’avance, que votre plan de reprise doit être capable de respecter, pas seulement viser un bon jour.
C’est quoi le RPO, l’objectif de point de reprise ?
Le RPO, ou Recovery Point Objective (objectif de point de reprise), est l’ancienneté maximale acceptable de la dernière copie de données que vous pouvez restaurer après un incident.
Concrètement, le RPO répond à une question précise : combien de temps de travail, mesuré depuis la dernière sauvegarde utilisable, l’entreprise accepte-t-elle de perdre ou de refaire. Un RPO de quatre heures veut dire que si un système tombe à 14 h, vous acceptez de perdre au maximum les quatre dernières heures de données saisies.
Le RTO et le RPO répondent à deux questions différentes. Le premier porte sur le temps d’indisponibilité. Le second porte sur la quantité de données perdues. Une entreprise peut tolérer un système hors service pendant six heures, un RTO généreux, tout en refusant de perdre plus de quinze minutes de transactions, un RPO serré, ou l’inverse. Les deux se fixent indépendamment, processus par processus.
Pourquoi la direction doit-elle fixer ces deux chiffres elle-même ?
Parce que ce sont des arbitrages financiers et opérationnels, pas des paramètres techniques. Un RTO de trente minutes coûte plus cher à soutenir qu’un RTO de vingt-quatre heures : il exige des systèmes redondants, une infrastructure de reprise prête à basculer, des tests réguliers. Un RPO de quelques minutes coûte plus cher qu’un RPO d’une nuit : il exige une réplication continue des données, pas seulement une copie quotidienne.
Vos TI peuvent chiffrer le coût de chaque option. Ils ne peuvent pas décider, à votre place, combien votre entreprise est prête à payer pour faire passer le temps d’arrêt tolérable sur la facturation de six heures à trente minutes. C’est un arbitrage entre un coût connu aujourd’hui et un risque qui ne se matérialisera peut-être jamais, exactement le genre de décision que la direction est censée trancher.
RTO RPO : la direction décide, les TI chiffrent.
La norme ISO 22301:2019 sur la continuité d’activité rattache ces deux objectifs à l’analyse d’impact sur les affaires, que la direction doit approuver : ce ne sont pas des paramètres que les TI fixent seuls. Le Centre canadien pour la cybersécurité recommande la même chose dans ses guides sur le plan de continuité des activités : le documenter, le tester et le réviser avant l’incident, pas pendant.
Le problème, dans la majorité des entreprises que nous rencontrons, n’est pas que la direction a fixé les mauvais chiffres. C’est qu’elle n’en a fixé aucun. Le sujet n’est jamais monté plus haut qu’une réunion technique, et personne au-dessus n’a validé, par écrit, ce que l’entreprise est prête à tolérer.
Comment traduire RTO RPO en décisions d’affaires ?
Le RTO et le RPO ne se fixent pas globalement pour « l’informatique ». Ils se fixent processus d’affaires par processus d’affaires, parce que la tolérance à l’interruption n’est pas la même partout dans une entreprise.
Le tableau suivant illustre la logique avec des exemples hypothétiques. Ce ne sont pas des références de marché ni des recommandations chiffrées : chaque entreprise doit fixer ses propres cibles selon sa réalité.
| Processus d’affaires | RTO illustratif | RPO illustratif | Logique |
|---|---|---|---|
| Facturation et encaissement | 4 heures | 1 heure | Un arrêt prolongé retarde les rentrées d’argent |
| Système de production ou d’exploitation | 1 heure | 15 minutes | Chaque minute d’arrêt bloque une opération en cours |
| Paie | 24 heures | 24 heures | Tolérance plus large hors des dates de versement |
| Courriel et communications internes | 8 heures | 4 heures | Contournement possible à court terme |
Ce tableau n’a de valeur que comme méthode, pas comme référence à copier. Pour un cabinet comptable, la facturation peut tolérer une journée complète. Pour un commerce en ligne, une heure d’arrêt sur la prise de commandes peut être jugée inacceptable. La question à poser à chaque propriétaire de processus reste la même : à partir de quand cet arrêt devient un problème que la direction ne peut plus ignorer, et combien d’heures de travail cette équipe accepte-t-elle de refaire.
Qu’est-ce que RTO et RPO ne sont pas ?
RTO RPO : trois confusions reviennent souvent chez les dirigeants à qui on présente ces deux sigles pour la première fois.
- Une promesse de vos TI : fixer un RTO de deux heures ne garantit pas que la reprise prendra deux heures. C’est la cible que le plan de reprise doit être capable d’atteindre, démontrée par des tests, pas une assurance contractuelle. Une entreprise qui affiche un RTO sans jamais l’avoir testé affiche un chiffre, pas une capacité.
- Des chiffres fixés une fois pour toutes : un processus d’affaires évolue. Un nouveau système de facturation, un nouveau canal de vente en ligne ou une nouvelle exigence contractuelle d’un client important peut changer ce que l’entreprise est prête à tolérer. Le RTO et le RPO se révisent, au même rythme que le reste de la planification.
- Des concepts réservés à la grande entreprise : une PME de vingt employés qui dépend d’un seul système de facturation a exactement la même conversation à avoir, à plus petite échelle.
Comment fixer RTO RPO, concrètement ?
Quatre étapes, dans l’ordre.
- Dressez la liste de vos processus d’affaires critiques, pas de vos systèmes. La facturation n’est pas un serveur, c’est un processus qui dépend de plusieurs systèmes. Commencez par les activités qui font entrer de l’argent ou qui touchent des renseignements personnels.
- Pour chaque processus, demandez au propriétaire d’affaires, pas aux TI, à partir de quand un arrêt devient inacceptable, et combien d’heures de données perdues il peut absorber. C’est cette conversation qui produit vos cibles de RTO et de RPO.
- Faites chiffrer par vos TI ce que coûte l’atteinte de chaque cible : infrastructure, licences, fréquence des copies, tests. Notre guide sur les sauvegardes, le plan de relance et les tests détaille les mécanismes concrets derrière ces coûts.
- Écrivez les cibles retenues, et testez-les. Un test de relance documenté est la seule façon de savoir si votre RTO et votre RPO sont réels ou théoriques. Une sauvegarde qui n’a jamais été restaurée en test n’est pas une garantie de RPO : une sauvegarde non testée n’est pas une sauvegarde.
Cette conversation ne se règle pas en une réunion. Elle se documente, se fait approuver par la direction et se révise au moins une fois par année, ou chaque fois qu’un processus d’affaires change de façon significative.
Que se passe-t-il quand personne n’a fixé de cible ?
RTO RPO : sans cible fixée par la direction, les TI improvisent, pas par négligence, mais par nécessité. Une équipe technique qui n’a jamais reçu de cible chiffrée en fixe une implicitement, à partir de ce que la technologie en place permet, pas à partir de ce que l’entreprise peut tolérer. Personne n’a validé ce chiffre implicite. Personne ne le teste non plus, puisqu’il n’a jamais été écrit nulle part.
Le jour d’un incident, l’écart se révèle en temps réel. La direction découvre que la reprise prend deux jours, pas deux heures, ou que les trois derniers jours de commandes sont irrécupérables. Personne n’a menti : personne n’avait simplement posé la question avant. Fixer un RTO après la panne, c’est lire le mode d’emploi du parachute en chute libre.
Il y a aussi une dimension légale à ne pas ignorer. Quand l’incident touche des renseignements personnels, la Loi 25 impose des obligations de notification si le risque de préjudice sérieux est présent. Un RPO élevé, découvert après coup, peut vouloir dire que davantage de renseignements personnels ont été perdus ou compromis que ce que l’entreprise croyait exposer au moment de l’incident. Ce n’est plus seulement un problème de continuité, c’est un problème de conformité.
Ce lien entre RTO, RPO et gouvernance TI explique en bonne partie pourquoi la direction voit les chiffres du budget, rarement les problèmes qu’ils cachent : un RTO jamais fixé ni budgété n’apparaît nulle part comme une ligne à justifier, jusqu’au jour où il coûte cher d’un coup, en une seule fois, pendant un incident.
Vos RTO et RPO sont-ils fixés, écrits et testés, ou seulement présumés ? Un audit informatique indépendant vérifie les faits tels qu’ils sont, sans rien vous vendre ensuite pour les corriger. Notre page Audit TI indépendant explique comment cette vérification se déroule.
Pour aller plus loin avec Factero :
Foire aux questions
RTO RPO : quelle est la différence entre les deux ?
Le RTO répond à une question de temps : combien d’heures un système ou un processus d’affaires peut rester arrêté avant que ce soit inacceptable. Le RPO répond à une question de données : jusqu’à quelle ancienneté la dernière copie utilisable peut remonter. Une entreprise peut tolérer un arrêt prolongé tout en étant intransigeante sur la perte de données, ou l’inverse. Les deux se fixent indépendamment, processus par processus.
Le RTO et le RPO s’appliquent-ils aussi aux petites entreprises ?
Oui. Ce ne sont pas des notions réservées aux grandes organisations. Une PME de vingt employés qui dépend d’un seul système de facturation doit prendre exactement la même décision, à plus petite échelle : à partir de quand un arrêt devient inacceptable, et combien d’heures de travail elle accepte de refaire après un incident. La taille de l’entreprise change l’ampleur du risque, pas la nécessité de fixer les deux chiffres.
Comment savoir si nos RTO et RPO actuels tiennent la route ?
En les testant. Un test de relance documenté, mené sur un processus réel, révèle l’écart entre le chiffre écrit et la capacité réelle de l’organisation à le respecter. Sans ce test, un RTO ou un RPO consigné dans un document n’est qu’une intention, jamais démontrée dans les faits.
Un RTO et un RPO à zéro, est-ce possible ?
Techniquement, oui, avec une réplication continue et une infrastructure redondante. Le coût suit directement l’ambition : chaque heure retranchée au RTO ou chaque minute retranchée au RPO a un prix, et ce prix est un choix d’affaires, pas un défaut technique à corriger gratuitement.
Un audit informatique vérifie-t-il le RTO et le RPO d’une entreprise ?
Oui, c’est un point de contrôle courant. L’audit vérifie si le RTO et le RPO existent par écrit, s’ils ont été approuvés par la direction et s’ils ont été testés récemment, pas seulement s’ils figurent dans un document de planification. C’est souvent un volet d’un audit informatique indépendant plus large, qui documente l’ensemble de la posture de continuité de l’entreprise.
