Lorsqu’un service numérique est interrompu, les conséquences ne sont pas les mêmes pour tous les processus, et chacun ne peut pas attendre aussi longtemps avant de reprendre. De même, perdre quelques minutes de données n’équivaut pas à perdre une journée d’activité. Définir des objectifs de reprise suppose donc de relier les besoins de l’entreprise aux capacités techniques, plutôt que d’attribuer un chiffre uniforme à toutes les applications.
Deux mesures permettent d’exprimer ces besoins : le RTO, qui détermine combien de temps un processus peut rester interrompu avant que l’impact devienne inacceptable, et le RPO, qui précise quelle perte de données, exprimée en durée, peut être tolérée. Il s’agit d’objectifs convenus, et non de garanties automatiques. Pour être utiles, ils doivent être compréhensibles, réalisables et vérifiables.
Le RTO et le RPO répondent à des questions différentes
Le RTO, ou objectif de délai de reprise, répond à la question : combien de temps pouvons-nous nous passer de ce processus ? Il se mesure entre le début de l’interruption et le retour du processus à un niveau opérationnel convenu. Il ne suffit pas qu’un serveur redémarre : le service doit pouvoir assurer les fonctions qui justifient sa reprise.
Le RPO, ou objectif de point de reprise, répond à la question : jusqu’à quel moment les données récupérées doivent-elles être disponibles ? Si le RPO convenu est d’une heure, l’entreprise accepte, au maximum, de récupérer des données dont l’état correspond à une heure avant l’incident. Il n’indique pas le temps nécessaire à leur restauration : cela relève du RTO.
Ces deux mesures sont complémentaires, mais ne se remplacent pas. Un système peut rapidement restaurer une copie contenant des données trop anciennes, ou préserver des données récentes tout en mettant trop de temps à reprendre son activité. La décision doit tenir compte de ces deux scénarios et préciser ce que signifie « rétabli » : quels utilisateurs, transactions ou services doivent être disponibles.
Définir des objectifs par processus, et non par application
Une application peut prendre en charge plusieurs processus dont les impacts diffèrent. À l’inverse, un processus dépend généralement de plusieurs applications, données, fournisseurs et tâches opérationnelles. Commencer par dresser la liste des systèmes et leur attribuer une priorité technique peut donc masquer les véritables besoins de protection de l’entreprise.
Il est préférable de commencer par identifier des processus précis, comme accepter des commandes, enregistrer des paiements ou traiter des demandes. Pour chacun d’eux, le responsable métier décrit les conséquences d’une interruption et d’une perte de données. L’équipe informatique peut ensuite cartographier les applications et les dépendances nécessaires à son fonctionnement. Si une même plateforme sert des processus ayant des objectifs différents, il faut vérifier s’il est possible de les reprendre séparément ou s’ils partagent une contrainte à expliciter.
Cette approche permet également de repérer les dépendances oubliées : gestion des identités et des accès, communications, intégrations, bases de données, informations de configuration, personnel disposant de connaissances spécifiques et prestataires externes. La reprise de l’application principale ne rétablit pas le processus si une dépendance critique reste indisponible.
Estimer l’impact dans le temps
L’impact n’apparaît pas toujours immédiatement. Une interruption de courte durée peut avoir des conséquences acceptables, puis, au-delà d’un certain seuil, entraîner une accumulation de travail, le non-respect d’engagements ou une perte de capacité opérationnelle. L’analyse doit décrire l’évolution des dommages au fil du temps, plutôt que de se limiter à qualifier un système de « critique ».
Pour mener cette analyse de manière concrète, l’équipe peut se poser les questions suivantes :
- Qu’est-ce qui s’arrête ? Les opérations, les canaux ou les décisions qui dépendent du processus.
- Qui est concerné ? Les clients, les employés, les partenaires ou d’autres équipes.
- Qu’est-ce qui s’accumule ? Les commandes en attente, les dossiers non traités ou les informations qui ne sont plus enregistrées.
- À partir de quand la situation devient-elle intolérable ? Le moment où l’impact dépasse le seuil accepté par l’entreprise.
- Quelles données risquent d’être perdues ? Leur importance, leur fréquence de mise à jour et la possibilité de les reconstituer.
Les estimations doivent intégrer les conditions pertinentes, comme les périodes de forte activité ou les clôtures opérationnelles. Si les données disponibles sont insuffisantes, mieux vaut consigner les incertitudes et convenir d’une hypothèse à réexaminer que de présenter un chiffre apparemment précis, mais sans fondement.
Convenir d’objectifs réalisables
Le responsable métier propose le niveau de perte et le délai tolérables ; l’équipe informatique évalue les moyens et les procédures nécessaires pour respecter ces limites. Les opérations précisent comment l’incident est détecté, qui décide de déclencher la reprise et quelles tâches doivent être exécutées. La décision finale suppose un échange entre ces fonctions : fixer un RTO ambitieux sans ressources ni capacité vérifiée ne réduit pas le risque.
Un accord utile définit au minimum le processus, le RTO, le RPO, le périmètre de la reprise, les dépendances, les responsables et les éléments qui démontreront que les objectifs sont atteints. Il précise également les hypothèses retenues : par exemple, les fonctions à rétablir en priorité ou les procédures manuelles permettant de maintenir temporairement l’activité. Une solution manuelle peut réduire l’impact, mais elle doit prévoir des responsables, des instructions et des limites claires ; il ne faut pas présumer qu’elle sera disponible par défaut.
La comparaison entre les besoins et les capacités actuelles peut révéler des lacunes. La solution ne consiste pas toujours à acquérir de nouvelles technologies. Elle peut impliquer de simplifier les dépendances, d’améliorer les procédures, de renforcer la collecte des données, de donner la priorité à une fonction essentielle ou d’accepter formellement un niveau de risque différent. Le choix dépend de l’impact et des options réellement disponibles pour les opérations.
Vérifier les dépendances, l’architecture et les opérations
L’objectif convenu doit être confronté à l’ensemble du parcours de reprise. Pour le RTO, il faut prendre en compte la détection, la prise de décision, l’accès aux personnes et aux systèmes, la restauration, la vérification et la reprise du processus. Si une étape ne figure pas dans le plan, le délai prévu risque d’être irréaliste.
Pour le RPO, il faut examiner la manière dont les données récupérables sont créées et conservées, la fréquence de leur mise à jour et les informations exclues de ce mécanisme. Une sauvegarde est un élément de la stratégie, pas la preuve qu’une reprise conforme aux objectifs est possible. Il faut vérifier que les données sont exploitables et que la procédure ne repose pas sur des hypothèses non validées.
Il importe également d’identifier les dépendances partagées. Si plusieurs processus ont besoin du même système d’identités, du même réseau ou du même fournisseur, leur reprise simultanée peut mobiliser les mêmes ressources ou exiger un ordre précis. Consigner ces relations permet de définir les priorités de restauration et de comprendre quels objectifs peuvent être atteints selon les circonstances.
Tester, réviser et corriger les objectifs
Les tests transforment les objectifs en éléments vérifiables. Un exercice peut parcourir la procédure de bout en bout, mesurer le temps nécessaire au rétablissement des fonctions convenues et vérifier l’état des données restaurées. Il ne suffit pas de confirmer qu’une sauvegarde existe ou qu’une instance démarre : le responsable du processus doit valider que le résultat permet de travailler.
Les exercices peuvent commencer par une revue des procédures, puis évoluer vers des scénarios techniques plus complets, selon le risque et les capacités de l’équipe. Pour chaque test, il est utile de consigner :
- Le processus, le scénario et les dépendances testés.
- Le début de l’interruption et le moment où les fonctions convenues ont été rétablies.
- Le point de restauration des données et la perte observée.
- Les étapes qui ont échoué, les hypothèses invalidées et les responsables de la correction de chaque lacune.
Si le résultat dépasse le RTO ou le RPO, il faut décider s’il convient d’améliorer les capacités, de modifier le processus ou de revoir l’objectif avec les équipes métier. Répéter un test sans traiter les constats ne renforce pas la confiance. Les objectifs doivent aussi être réexaminés lorsque le processus, l’architecture, le volume d’activité ou les dépendances évoluent.
Erreurs courantes et modèle de décision
Parmi les erreurs les plus fréquentes figurent l’attribution d’un objectif identique à tous les systèmes, la confusion entre RTO et RPO, l’idée qu’une sauvegarde équivaut à une reprise et la fixation d’objectifs sans participation des équipes métier. Il est également risqué de mesurer uniquement la disponibilité technique, d’ignorer les tâches de coordination ou de considérer un test comme réussi sans valider les données et les fonctions du processus.
Une fiche simple permet de garder une trace des décisions. Elle peut comporter les champs suivants :
- Processus et responsable métier : l’activité à protéger et la personne qui accepte l’impact.
- Impact selon la durée et la perte de données : les conséquences et les seuils de tolérance.
- RTO et RPO convenus : les objectifs et le périmètre de la reprise.
- Applications et dépendances : les composants, équipes et fournisseurs nécessaires.
- Procédure et solution manuelle : les étapes, les priorités, les responsables et les limites.
- Dernier test et éléments de preuve : le résultat observé, les lacunes et les actions en attente.
Définir le RTO et le RPO par processus ne consiste pas à choisir des chiffres idéaux, mais à convenir de limites qui reflètent l’impact, à vérifier si l’organisation peut les respecter et à traiter les lacunes. Un examen périodique maintient ces objectifs en phase avec le service réel et évite de confondre une attente documentée avec une capacité démontrée.