Combien de temps pouvez-vous travailler sans informatique ? Et combien de travail pouvez-vous perdre ?
Actualités
6 Min
RTO et RPO : combien de temps sans informatique, combien de travail perdu. Deux questions de dirigeant, expliquées simplement avec une méthode en 3 étapes.
🎯 L'essentiel
Le RTO, c'est le temps maximal pendant lequel un service peut rester arrêté. Le RPO, c'est la quantité maximale de travail que vous acceptez de perdre. Ce sont deux questions de dirigeant, pas d'informaticien.
Une image suffit : le document que vous écriviez quand l'ordinateur a planté. Ce que vous avez tapé depuis le dernier enregistrement, c'est le RPO. Le temps avant de pouvoir retravailler, c'est le RTO.
Ces deux valeurs se fixent service par service : la comptabilité, la messagerie et le logiciel de production n'ont pas les mêmes exigences.
Plus elles sont courtes, plus la solution technique est coûteuse. « Zéro et zéro » existe, et c'est la réponse la plus chère du marché.
Un objectif annoncé n'a de valeur que s'il a été mesuré lors d'un test réel de restauration.
📌 Pourquoi ce sujet maintenant
Octobre est la période où se préparent les budgets de l'année suivante. Fixer des objectifs de reprise maintenant permet de dimensionner les investissements de sauvegarde et de continuité sur des besoins réels, plutôt que sur une intuition.
Vous avez sûrement vécu cette scène. Un document ouvert depuis une heure, l'ordinateur qui se fige, l'écran qui s'éteint. Deux questions vous traversent l'esprit en même temps : qu'est-ce que j'ai perdu, et dans combien de temps est-ce que je peux m'y remettre ?
Ces deux questions ont un nom dans le jargon informatique. On les appelle RPO et RTO. Les sigles sont intimidants, les questions ne le sont pas du tout.
ℹ️ Les deux définitions, sans jargon
RPO (de l'anglais Recovery Point Objective) : la quantité maximale de travail que vous acceptez de perdre. Dans l'exemple du document, c'est tout ce que vous avez tapé depuis le dernier enregistrement. Il se mesure en temps : une heure, une journée.
RTO (de l'anglais Recovery Time Objective) : la durée maximale pendant laquelle un service peut rester arrêté avant que la situation devienne inacceptable. Dans l'exemple, c'est le temps avant de pouvoir retravailler.
Pourquoi ce sont des questions de dirigeant
Un informaticien peut vous dire combien de temps prendrait une restauration. Il ne peut pas vous dire combien de temps votre entreprise peut se permettre d'attendre. Cette réponse dépend de vos clients, de vos engagements, de votre saisonnalité et de votre trésorerie.
C'est pour cela que la question doit être posée par la direction, avec les responsables de chaque service, avant d'être confiée à la technique.
Un service n'est pas l'autre
L'erreur classique est de fixer une seule valeur pour toute l'entreprise. En réalité, chaque service a ses propres besoins. Voici des exemples courants, à adapter à votre activité :
Le logiciel de production ou de prise de commande. S'il s'arrête, plus rien ne sort. Arrêt toléré : quelques heures au maximum. Perte de données tolérée : très faible, parce que chaque commande perdue doit être ressaisie ou est perdue.
La messagerie. Une demi-journée sans mail est pénible mais rarement fatale. La perte des messages reçus pendant l'incident, en revanche, peut poser problème.
La comptabilité. Souvent supportable pendant un ou deux jours hors période de clôture. Beaucoup moins la dernière semaine du mois.
Les dossiers partagés. Variable selon l'activité. Pour un bureau d'études, c'est le cœur du métier. Pour d'autres, une journée de délai est acceptable.
💡 La réponse que tout le monde donne en premier
Demandez à n'importe quel dirigeant ses objectifs de reprise : la réponse spontanée est « zéro interruption et zéro perte ». C'est humain.
C'est aussi la réponse la plus chère du marché. Elle suppose des infrastructures doublées et synchronisées en permanence. Pour la grande majorité des PME, elle n'est ni nécessaire, ni justifiable.
Ce que ces valeurs changent concrètement
Le RPO détermine principalement la fréquence des sauvegardes. Une sauvegarde par nuit, c'est accepter de perdre jusqu'à une journée de travail. Si ce n'est pas acceptable pour un service, il faut sauvegarder plus souvent, ou répliquer les données en continu vers une autre machine.
Le RTO détermine principalement l'architecture de reprise. Restaurer un serveur complet depuis une sauvegarde peut prendre des heures. Si c'est trop long, il faut un environnement prêt à prendre le relais, par exemple une machine virtuelle répliquée qu'on peut démarrer rapidement sur un autre serveur.
Plus les valeurs sont courtes, plus la solution coûte cher. Fixer des objectifs réalistes, c'est donc aussi éviter de payer pour une protection dont vous n'avez pas besoin.
⚠️ L'écart entre l'objectif et la réalité
Un objectif de reprise de quatre heures écrit dans un document n'a de valeur que si quelqu'un a mesuré, lors d'un vrai test, qu'une restauration prend effectivement moins de quatre heures.
Dans la pratique, le premier test révèle souvent une durée réelle bien supérieure à celle qu'on imaginait. C'est le sens du « zéro erreur de restauration » de la règle 3-2-1-1-0, et de la restauration chronométrée dans un autre environnement que nous recommandions à propos du cloud et de la sauvegarde.
La méthode, en trois étapes
1. Listez vos services critiques. Cinq ou six, pas plus. Ceux sans lesquels une partie de l'entreprise s'arrête.
2. Posez deux questions pour chacun, aux responsables concernés. Combien de temps pouvons-nous tenir sans ce service ? Combien de travail pouvons-nous accepter de perdre ? Les réponses en heures, pas en adjectifs.
3. Confrontez ces réponses à l'existant. Avec votre prestataire : la fréquence de sauvegarde actuelle respecte-t-elle le RPO souhaité ? Le temps de restauration mesuré respecte-t-il le RTO ? Les écarts deviennent votre liste de priorités.
Cette démarche est le point de départ de tout plan de reprise sérieux.
Les questions à poser à votre prestataire
À quelle fréquence nos données sont-elles sauvegardées, service par service ?
Si notre serveur principal devient inutilisable, combien de temps faut-il pour que l'équipe puisse retravailler ? Une durée mesurée, pas estimée.
Quel serait le coût pour réduire ce délai de moitié ? La réponse vous dira si l'effort se justifie.
🧭 Ce que nous faisons sur ce sujet
Nous aidons nos clients à fixer leurs objectifs de reprise service par service, puis à construire la solution qui les respecte, sans surdimensionner : fréquence de sauvegarde, réplication des machines virtuelles critiques, environnement de reprise.
Notre Plan de Reprise Informatique s'appuie sur Proxmox Backup Server, Veeam, Beemo ou ARX One selon le contexte, et inclut des tests qui mesurent les délais réels, pas théoriques.
❓ Questions fréquentes
Quelle est la différence entre RTO et RPO ?
Le RTO est la durée maximale pendant laquelle un service peut rester arrêté. Le RPO est la quantité maximale de données que vous acceptez de perdre, exprimée en temps. L'un mesure l'interruption, l'autre la perte.
Comment calculer son RTO ?
En posant la question aux responsables métier : à partir de combien d'heures d'arrêt la situation devient-elle inacceptable pour les clients, la production ou la trésorerie ? La réponse se fixe service par service, puis se vérifie par un test de restauration.
Une sauvegarde par nuit, c'est suffisant ?
Cela correspond à un RPO d'environ une journée : vous acceptez de perdre jusqu'à une journée de travail. C'est suffisant pour beaucoup de services, mais pas pour un logiciel de commande ou de production où chaque saisie compte.
Peut-on viser zéro interruption et zéro perte ?
C'est techniquement possible, mais cela suppose des infrastructures doublées et synchronisées en permanence. Le coût est rarement justifié pour une PME. Des objectifs réalistes, service par service, protègent mieux le budget.
Sources & Références
Définitions usuelles du Recovery Time Objective et du Recovery Point Objective, telles que reprises par les éditeurs de sauvegarde et les référentiels de continuité d'activité.
Rédigé par Sylvain Sarazin
J’aide les entreprises et collectivités à repartir vite après un incident informatique.
Artisan de la résilience IT
Similar Topic
