RTO et RPO : ce que ça veut dire, ce que ça NE veut pas dire
Les deux sigles viennent de la norme ISO 22301 (continuité d'activité) et des travaux préparatoires de l'US-CERT sur la résilience des systèmes d'information. Ils ont une définition précise que beaucoup de dirigeants manipulent par à-peu-près, avec des conséquences budgétaires lourdes.
- RPO (Recovery Point Objective) : la quantité maximale de données que votre organisation accepte de perdre en cas de sinistre. Exprimé en temps : un RPO de 4 heures signifie que vous acceptez de perdre jusqu'à 4 heures de saisies, transactions, échanges de mails, écritures comptables. Techniquement, le RPO se lit dans l'intervalle entre votre dernier backup réussi et l'instant de l'incident.
- RTO (Recovery Time Objective) : la durée maximale pendant laquelle un service métier peut rester indisponible avant que l'impact ne devienne inacceptable. Exprimé en temps également : un RTO de 4 heures signifie qu'au bout de 4 heures, le service doit être redémarré et utilisable.
Le RPO se mesure vers le passé (avant l'incident). Le RTO se mesure vers le futur (après l'incident). C'est la confusion la plus fréquente en comité de pilotage.
Quatre confusions reviennent systématiquement en réunion de pilotage :
RTO n'est pas le SLA du support. Un SLA de prise en charge de 15 minutes n'a aucun rapport avec un RTO de 4 heures. Le premier engage l'infogérant à décrocher vite ; le second engage l'organisation à redémarrer l'activité. Un support peut décrocher en 10 minutes et mettre trois jours à restaurer.
RPO n'est pas la fréquence de sauvegarde. Une sauvegarde toutes les heures ne garantit pas un RPO d'une heure. Elle garantit un RPO d'une heure si la sauvegarde est réussie, vérifiée, et restaurable. Une sauvegarde qui tourne toutes les heures et qui échoue silencieusement depuis trois semaines donne un RPO de trois semaines.
RTO n'est pas la haute disponibilité. Un cluster actif/actif protège d'une panne matérielle, pas d'un ransomware qui chiffre les deux nœuds simultanément, ni d'une corruption logique qui se propage aux réplicas. La haute dispo et le PRA répondent à des menaces différentes. Les deux ensemble ont du sens ; l'un sans l'autre expose à la menace non couverte.
« Temps de restauration » n'est pas « temps de reprise d'activité ». Restaurer 2 To de données depuis un cloud peut prendre 8 heures. Mais avant que le service soit utilisable, il faut aussi redémarrer l'applicatif, rejouer les transactions manquantes, remettre en service les intégrations tierces (paiement, téléphonie, EDI), notifier les utilisateurs, vérifier la cohérence comptable. Le RTO englobe tout cela, pas seulement la copie de fichiers.
Pourquoi la matrice « par type de serveur » est une fausse bonne idée
La majorité des PRA qu'on nous fait relire commencent par un tableau qui liste les serveurs physiques ou virtuels avec, en face de chacun, un RTO et un RPO cibles. Exchange 4 h / 1 h, Active Directory 2 h / 0 h, fichiers 8 h / 24 h, SQL 4 h / 4 h. C'est une approche d'administrateur système. Ce n'est pas une approche de continuité d'activité.
Le problème est que le serveur est un contenant, pas un service. Un même serveur SQL peut porter trois bases de données dont l'impact d'indisponibilité n'a rien à voir :
- La base de la facturation, indisponibilité = blocage de la trésorerie dès la première journée.
- La base de l'extranet commercial, indisponibilité = gêne commerciale, contournable par email ou téléphone.
- La base d'un outil de reporting interne utilisé une fois par mois, indisponibilité pendant une semaine = aucun impact opérationnel.
Si vous fixez un RTO unique au serveur SQL, vous dimensionnez soit trop haut (coût excessif pour la base de reporting), soit trop bas (risque résiduel inacceptable sur la facturation), soit les deux en même temps. La grille par serveur produit systématiquement un PRA qui rassure le prestataire et ruine la DSI.
Le bon niveau d'analyse est le service métier : l'unité fonctionnelle qui produit de la valeur pour l'entreprise, indépendamment de son infrastructure technique sous-jacente. Un service métier peut être porté par un seul serveur, par dix serveurs, par un SaaS externe, ou par une combinaison des trois. Ce qui compte, c'est le coût de son indisponibilité.
Cette approche par service métier est celle retenue par la méthode EBIOS RM de l'ANSSI pour l'analyse de risques, et par la norme ISO 22301 pour le plan de continuité. Elle demande un peu plus de travail en amont, cartographier les services, identifier leurs dépendances, mais elle produit un PRA défendable opérationnellement et financièrement.
Cartographier les services métier d'une PME, huit exemples types
Voici huit services métier qu'on retrouve dans la plupart des PME de 20 à 300 salariés, avec des ordres de grandeur de RTO et RPO indicatifs. Ces valeurs ne sont pas des prescriptions, elles dépendent du secteur, de la saisonnalité, de la taille, du modèle économique. Mais elles donnent un point de départ pour une discussion de CODIR.
| Service métier | Impact indisponibilité | Impact perte de données | RTO indicatif | RPO indicatif |
|---|---|---|---|---|
| Facturation / encaissement | Trésorerie bloquée, relances impossibles, retard DSO | Litiges clients, ressaisie lourde | 4-8 h | 1-4 h |
| Comptabilité / paie | Faible en dehors des clôtures ; critique à J-2 d'une paie | Ressaisie possible mais coûteuse | 24 h (hors clôture) | 24 h |
| Messagerie (Microsoft 365, Google Workspace) | Communication externe rompue, perte de prospects | Perte de preuves, perte de pièces jointes | 2-4 h | 1 h |
| GED / documentation projet | Équipes bloquées en production, ré-export difficile | Perte de versions, confusion métier | 8 h | 4 h |
| ERP industriel / production | Atelier arrêté, commandes non tracées, pénalités de retard | Ordres de fabrication perdus, stocks faussés | 1-2 h | 15 min |
| PLM / bureau d'études | Ingénieurs à l'arrêt, jalons projet repoussés | Perte de révisions, retravail important | 8-24 h | 4 h |
| Télédéclarations (fiscal, social) | Pénalités réglementaires au-delà de la date butoir | Ressaisie lourde, risque URSSAF/DGFiP | 24 h (variable selon échéance) | 24 h |
| Téléphonie / accueil | Appels perdus, image commerciale dégradée | Messages vocaux, historiques CTI | 1-2 h | 24 h (journaux) |
Deux observations importantes sur ce tableau. D'abord, ces RTO et RPO ne sont pas homogènes : la production industrielle demande un RTO plus court que la comptabilité, la téléphonie plus court que la GED. Un PRA uniforme qui viserait par exemple « 4 heures partout » gaspillerait du budget sur la comptabilité et prendrait un risque inacceptable sur la production.
Ensuite, le RTO et le RPO varient dans le temps. La paie a un RTO très tolérant du 5 au 25 du mois, et un RTO de deux heures à J-2 de la date de virement. Un PRA correctement dimensionné intègre cette variabilité, soit via des dispositifs adaptés selon les cycles, soit via des procédures de reprise manuelle documentées pour les pics.
Les cinq erreurs de dimensionnement qu'on voit systématiquement
Ces erreurs reviennent dans la moitié des audits de continuité que nous conduisons. Elles ne sont pas techniques, elles sont méthodologiques. Les corriger ne coûte rien ; les ignorer coûte cher.
Viser RTO zéro et RPO zéro partout
✗ Mauvaise pratique. Mettre un RTO de 15 minutes et un RPO de 0 sur tous les services, par précaution ou par peur de se tromper.
✓ Bonne pratique. Hiérarchiser. Accepter qu'un service puisse avoir un RTO de 24 heures sans que l'entreprise ne s'écroule. L'effort d'analyse est au niveau du CODIR, pas de la DSI seule.
Pourquoi c'est un problème : Descendre sous 15 minutes coûte exponentiellement plus cher à chaque palier. Si tout est critique, rien ne l'est vraiment, et le budget continuité finit par absorber des ressources qui auraient été plus utiles ailleurs (modernisation, productivité, sécurité applicative).
Copier le PRA d'un confrère
✗ Mauvaise pratique. Reprendre le PRA d'une entreprise du même secteur parce que « ils font la même chose que nous ».
✓ Bonne pratique. Refaire l'analyse des services métier en interne. Le PCA d'un concurrent a été dimensionné pour ses contraintes à lui : cycles de facturation, saisonnalité, obligations contractuelles clients, structure actionnariale.
Pourquoi c'est un problème : Deux cabinets d'expertise comptable apparemment identiques peuvent avoir des RTO très différents si l'un travaille majoritairement pour des clients en clôture annuelle et l'autre pour des professions à obligations mensuelles.
Ignorer la charge réseau
✗ Mauvaise pratique. Dimensionner un PRA cloud sans calculer la bande passante nécessaire pour sauvegarder chaque nuit et, surtout, pour restaurer 2 To depuis le cloud.
✓ Bonne pratique. Calculer en amont : volume à transférer, fenêtre disponible, débit Internet symétrique, impact sur la production. Et prévoir une solution de restauration accélérée (envoi physique de disque, lien fibre garanti) pour les gros volumes.
Pourquoi c'est un problème : Restaurer 2 To sur un lien Internet de 100 Mbps prend plus de 48 heures en théorie, et généralement le double dans la pratique. Un RTO de 4 heures devient impossible à tenir, quelle que soit la qualité de la solution de sauvegarde.
Sauvegarder sans jamais restaurer pour de vrai
✗ Mauvaise pratique. Vérifier que les jobs de sauvegarde tournent au vert dans la console et considérer que le sujet est traité.
✓ Bonne pratique. Organiser au moins une restauration réelle par an, sur un service non critique, avec chronomètre. Documenter ce qui a pris du temps, ce qui a manqué, ce qui a été redécouvert sur le moment.
Pourquoi c'est un problème : Une sauvegarde qui tourne au vert n'a aucune valeur si personne ne sait combien de temps il faut pour la remonter, quels mots de passe sont nécessaires, où est stocké le fichier de configuration applicative, et qui doit être prévenu. Le jour du sinistre, ces inconnues prennent des heures.
Confondre haute disponibilité et reprise après sinistre
✗ Mauvaise pratique. Considérer qu'un cluster VMware ou une paire d'hôtes Hyper-V en HA remplace une stratégie de sauvegarde et de PRA.
✓ Bonne pratique. Reconnaître que la haute dispo protège d'une panne matérielle et la sauvegarde protège d'une menace logique (ransomware, corruption, suppression volontaire ou accidentelle, erreur humaine). Les deux sont complémentaires, pas substituables.
Pourquoi c'est un problème : Un ransomware qui chiffre un nœud chiffre presque toujours l'autre dans la foulée, parfois via la réplication elle-même. Sans sauvegarde immuable déconnectée, l'entreprise paie la rançon ou perd l'intégralité de ses données, cluster HA compris.
La règle 3-2-1-0, le socle méthodologique
Formulée à l'origine par Peter Krogh (photographe américain) pour la préservation de bibliothèques numériques, reprise par l'US-CERT en 2012 et relayée en France par l'ANSSI dans ses guides PCA, la règle 3-2-1-0 est devenue le standard méthodologique minimum de toute stratégie de sauvegarde sérieuse.
L'original de production, plus deux sauvegardes indépendantes. Trois copies permettent de tolérer deux pannes simultanées sans perte définitive.
Les deux sauvegardes ne doivent pas être sur la même technologie ni le même type de média. Exemple : un NAS local et un stockage cloud objet.
Une copie géographiquement distante, déconnectée de votre réseau de production. Incendie, dégât des eaux, intrusion physique, ransomware qui se propage par le réseau : cette copie est la dernière ligne.
Le chiffre qui manque le plus souvent. Zéro erreur au test de restauration réel, mené au moins une fois par an. Sans ce test, les 3-2-1 ne garantissent rien.
Le « 0 » est l'ajout moderne à la règle. Il formalise ce que trop de PRA oublient : une sauvegarde n'est valide que si elle a été restaurée. Le test doit reproduire les conditions du sinistre autant que possible, sur une infrastructure différente, sans accès à la production, chronométré, documenté. Les équipes qui font ce test une fois par an détectent en moyenne deux ou trois anomalies à corriger, et sont prêtes le jour du vrai sinistre. Celles qui ne le font pas découvrent les anomalies sous pression, avec les clients et la direction qui appellent toutes les heures.
Variante récente, la règle 3-2-1-1-0 ajoute une copie immuable (immutable, non modifiable ni supprimable pendant une durée définie). C'est une réponse directe aux rançongiciels qui ciblent explicitement les dépôts de sauvegarde avant de chiffrer la production. L'immuabilité est désormais proposée par la plupart des solutions sérieuses ; elle ne dispense pas du test annuel.
Cartographie des dispositifs techniques, du moins cher au plus cher
Sept grandes familles de dispositifs permettent de tenir des RTO et RPO différents. Elles peuvent se combiner (par exemple, sauvegarde immuable pour les postes de travail et BCDR local pour les serveurs critiques). Le coût et la complexité opérationnelle augmentent de manière non linéaire à mesure que le RTO se raccourcit.
En dessous du seuil (bleu), la relation coût/RTO reste maîtrisable. Au-delà (rouge), chaque palier gagné coûte plusieurs fois plus que le précédent, rarement justifié pour une PME sans obligation réglementaire particulière.
| Dispositif | RTO typique | RPO typique | Coût relatif | Limites principales |
|---|---|---|---|---|
| 1. Sauvegarde simple | jours | 24 h | € | Pas de protection contre un rançongiciel qui atteint le dépôt de sauvegarde. |
| 2. Sauvegarde immuable | jours | 1-24 h | €-€€ | Protège contre le chiffrement malveillant mais reste une reprise « à froid » (réinstallation longue). |
| 3. Réplication asynchrone | heures | 15 min - 1 h | €€ | La corruption ou le chiffrement se réplique aussi (fenêtre de détection critique). |
| 4. BCDR local avec bascule VM | 15 min - 1 h | 15 min - 1 h | €€ | Appliance sur site, ne protège pas d'un sinistre physique détruisant le bâtiment. |
| 5. Cloud warm standby | 30 min - 2 h | 5-15 min | €€€ | Coût de stockage et de compute permanent en standby, même sans utilisation. |
| 6. Réplication synchrone multi-site | secondes | ≈ 0 | €€€€ | Exige une latence inter-sites < 5 ms. La corruption logique se propage en temps réel. |
| 7. Cluster HA actif/actif | ≈ 0 | ≈ 0 | €€€€ | Ne protège que des pannes matérielles. Indispensable de coupler à une sauvegarde pour les menaces logiques. |
Deux combinaisons typiques fonctionnent bien pour une PME de 20 à 300 salariés :
- Profil économique (budget maîtrisé, services métier peu intensifs) : sauvegarde immuable locale + sauvegarde immuable cloud. RTO 4-24 heures, RPO 4-24 heures. Couvre 80 % des cas pour un coût raisonnable.
- Profil résilience (production industrielle, ERP critique, service client dépendant) : BCDR local pour les serveurs critiques (RTO < 1 h) + sauvegarde immuable cloud pour les données. Combiner les deux évite à la fois la faillite « temps d'arrêt » et la faillite « perte de données ».
Arbre de décision, six questions pour choisir le bon dispositif
Cet arbre n'est pas une prescription, c'est un chemin d'analyse. À chaque question, la réponse oriente vers un profil de sortie, pas vers un produit. Appliquez-le service métier par service métier, pas globalement.
Combien coûte une heure d'indisponibilité de ce service ?
Moins de 1 000 € → profil économique acceptable. 1 000-10 000 € → profil intermédiaire, RTO à négocier selon les autres services. Plus de 10 000 € → profil résilience, RTO court à justifier.
Combien de données sa perte représenterait en heures de ressaisie ?
Moins de 4 h → sauvegarde journalière suffit. 4-24 h → sauvegardes plus fréquentes ou journalisation applicative. Plus de 24 h → réplication ou BCDR requis.
Ce service a-t-il des dépendances externes (paiement, EDI, tiers SaaS) ?
Oui → le RTO dépend aussi de la réactivité du tiers. Inutile de viser 15 min si votre opérateur de paiement annonce 2 h de relance. Dimensionner au maillon le plus lent.
Le service est-il hébergé en interne ou en SaaS ?
Interne → vous maîtrisez la totalité du PRA. SaaS → vérifier le plan de l'éditeur (RTO contractuel, sauvegardes intégrées, récupération après suppression) et compléter avec une sauvegarde tierce si nécessaire (cas fréquent pour Microsoft 365).
Quel est le mode de travail en secours possible ?
Si l'équipe peut basculer sur papier, Excel ou procédure manuelle pendant 4-24 h → RTO tolérant. Si aucune procédure manuelle n'existe (ex. production industrielle automatisée) → RTO court indispensable.
Y a-t-il une contrainte réglementaire (HDS, RGPD, NIS2 par ricochet) ?
HDS → hébergement certifié obligatoire pour les données de santé, avec contraintes spécifiques de sauvegarde. NIS2 via client régulé → le dispositif doit être documenté et auditable. RGPD → durée de conservation et droit à l'effacement à intégrer.
À l'issue de l'analyse, vous devriez pouvoir classer chaque service métier dans l'un des trois profils suivants :
RTO 8-24 h / RPO 4-24 h. Sauvegarde immuable locale + cloud. Coût maîtrisé. Convient à la bureautique, GED, outils internes non critiques.
RTO 1-4 h / RPO 15 min - 1 h. BCDR local ou réplication asynchrone. Convient à la facturation, messagerie, ERP non industriel, télédéclarations.
RTO < 1 h / RPO < 15 min. BCDR + cloud warm standby, ou réplication sync. Convient à la production industrielle, ERP atelier, téléphonie de relation client.
Calculer un coût de reprise réaliste pour défendre un budget
C'est l'étape qui distingue un PRA « IT sur étagère » d'un PRA défendable en CODIR. Tant que la continuité est présentée comme un coût sans contrepartie mesurée, elle est perçue comme un poste d'arbitrage, les dirigeants demandent à le réduire, et la DSI doit refaire l'exercice tous les ans sans avancer.
La méthode consiste à chiffrer deux courbes et à trouver leur intersection :
- Coût cumulé d'une indisponibilité en fonction de sa durée. Il intègre le chiffre d'affaires manqué, les pénalités contractuelles, le coût du personnel immobilisé, l'impact image, la perte de prospects, la ressaisie a posteriori.
- Coût de la solution nécessaire pour tenir un RTO donné. Il inclut l'investissement initial, le coût récurrent mensuel, le coût des tests annuels, le temps de pilotage interne.
Le RTO optimal n'est ni le plus court possible, ni le plus tolérant. C'est celui où le coût marginal d'une minute gagnée égale le coût marginal d'une minute perdue en indisponibilité.
En pratique, un calcul minimaliste utilisable en CODIR se construit avec trois paramètres :
- Chiffre d'affaires horaire du service. Diviser le CA annuel du périmètre concerné par le nombre d'heures ouvrées (environ 1 800 h pour un horaire standard). Un service qui porte 5 M€ de CA annuel pèse environ 2 800 €/h, avant même de compter les coûts indirects.
- Coefficient d'impact indirect. Coefficient multiplicateur appliqué au CA horaire pour tenir compte des pénalités, du personnel immobilisé (qui coûte et ne produit pas), du retour en arrière comptable, de l'impact image. Entre 1,5 pour un service bureautique et 3 pour une production industrielle à engagement contractuel.
- Durée probable de l'incident moyen. Sans dispositif de PRA, la durée moyenne d'arrêt pour un sinistre significatif (rançongiciel, panne matérielle majeure, sinistre physique) est de 3 à 10 jours ouvrés pour une PME francophone, données observées en ordres de grandeur, variables selon la préparation. À convertir en heures ouvrées pour le calcul : 1 jour ouvré ≈ 8 h.
L'exercice permet de produire en une heure un chiffrage qu'un CODIR peut contester mais rarement balayer : « Une indisponibilité de 5 jours ouvrés (40 h ouvrées) de notre outil de facturation nous coûterait entre 170 et 220 k€ (CA horaire ouvré 2,8 k€/h, coefficient d'impact 1,5 à 2), pour un dispositif de réduction à 4 h qui coûte 18 k€/an. Le ratio de couverture est de l'ordre de 10 à 1. » Cette phrase n'est pas une certitude, c'est un argument défendable.
Rappel important. Ce chiffrage est un outil opérationnel d'aide à la décision. Il ne remplace ni une expertise assurance, ni une analyse juridique des clauses contractuelles (pénalités clients, force majeure, responsabilité civile professionnelle). Pour ces dimensions, consultez un courtier en assurance professionnelle et un avocat spécialisé en droit informatique. Le chiffrage continuité sert à arbitrer les choix techniques ; il ne couvre pas le risque résiduel financier.
À retenir avant le prochain exercice PCA
Les cinq réflexes à avoir
- Partir du service métier, pas du serveur. La liste « Exchange / AD / SQL / fichiers » ne vous dira jamais quel RTO vise votre comptabilité, votre production ou votre facturation.
- Tester une restauration réelle au moins une fois par an. Sans test, les jobs verts dans la console ne garantissent rien. Le « 0 » de la règle 3-2-1-0 est le plus oublié et le plus critique.
- Chiffrer le coût d'arrêt avant de chiffrer la solution. Le budget continuité se défend avec un ratio de couverture, pas avec une conviction technique. Un CODIR arbitrera toujours un coût sans retour chiffré.
- Classifier par service et accepter l'hétérogénéité. Un PCA qui vise « 4 h partout » gaspille soit du budget, soit de la résilience. Un PCA mature a 3 à 5 profils de RTO différents, dimensionnés service par service.
- Revoir le PCA annuellement. Les services métier bougent, les volumes augmentent, les dépendances externes se multiplient. Un PCA « photocopié depuis 2021 » est statistiquement à côté de la réalité actuelle de l'entreprise.
Le RTO et le RPO ne sont pas des chiffres magiques que la DSI pose sur une feuille, ils sont la traduction technique d'une décision économique et stratégique que le dirigeant doit assumer. Un RTO de 4 heures, c'est accepter 4 heures de perte d'activité avant reprise. Un RPO de 1 heure, c'est accepter de ressaisir jusqu'à une heure de données. Ces engagements sont le bon périmètre de discussion entre DSI, DAF et direction. Pas la marque du nœud de stockage.
Sources et références : ISO 22301 (continuité d'activité), ANSSI, Guide PCA et EBIOS Risk Manager, US-CERT 2012 (règle 3-2-1-0), Peter Krogh The DAM Book (formulation initiale de la règle 3-2-1).