★ Classement fondé sur les avis Google vérifiés — mis à jour chaque semaine 100% gratuit · Sans inscription · Sans démarchage
Actualité IT entreprise · 9 septembre 2026 · 8 min

RTO et RPO : deux chiffres que tout dirigeant doit connaître avant de choisir son plan de reprise

RTO et RPO : définition claire pour les PME, différences, exemples concrets et tableau comparatif pour choisir votre plan de reprise informatique.

Ce qu'il faut retenir

  • Le RTO (Recovery Time Objective) est la durée maximale acceptable pendant laquelle votre système informatique peut rester hors service après un incident ; plus ce chiffre est bas, plus la reprise doit être rapide.
  • Le RPO (Recovery Point Objective) indique la quantité maximale de données que vous acceptez de perdre, exprimée en temps : un RPO de 4 heures signifie que vous tolérez de perdre jusqu'à 4 heures de données.
  • Ces deux indicateurs ne sont pas fixés par votre prestataire informatique seul : c'est vous, dirigeant, qui les définissez en fonction de l'impact réel d'une interruption sur votre activité.
  • Un RTO et un RPO mal calibrés peuvent rendre votre plan de reprise inutilisable ou, à l'inverse, vous faire payer pour une protection excessive par rapport à vos besoins réels.

Le RTO et le RPO sont les deux indicateurs fondamentaux de tout plan de reprise d'activité informatique pour une PME : le premier mesure combien de temps vous pouvez vous permettre d'être à l'arrêt, le second combien de données vous pouvez vous permettre de perdre. Comprendre la définition du RTO et du RPO, c'est la condition minimale pour dialoguer utilement avec un prestataire informatique et pour ne pas signer un contrat inadapté à votre réalité.

En résumé

  • Le RTO fixe le délai maximal de reprise après un incident informatique ; il se mesure en minutes, heures ou jours selon votre secteur.
  • Le RPO fixe le volume maximal de perte de données acceptable ; il détermine la fréquence minimale de vos sauvegardes.
  • Les deux chiffres doivent être définis avant de choisir une solution technique, pas après.
  • Un prestataire sérieux vous demande ces valeurs dès le cadrage ; s'il ne le fait pas, c'est un signal d'alerte.
  • RTO et RPO s'inscrivent dans un document formel appelé PRA (Plan de Reprise d'Activité) ou PCA (Plan de Continuité d'Activité).

Définition du RTO et du RPO : ce que signifient vraiment ces sigles

Le RTO, ou Recovery Time Objective, est l'objectif de durée de reprise. Concrètement, c'est la réponse à cette question : si votre serveur tombe en panne ce matin à 9 h, à quelle heure au plus tard votre équipe doit-elle pouvoir reprendre le travail ? Un RTO de 2 heures signifie que vous tolérez 2 heures d'interruption totale. Au-delà, les conséquences sur votre chiffre d'affaires, votre relation client ou vos obligations légales deviennent inacceptables.

Le RPO, ou Recovery Point Objective, est l'objectif de point de reprise. Il répond à une question différente : si vous deviez restaurer vos données maintenant, jusqu'à quel moment dans le passé êtes-vous prêt à remonter ? Un RPO de 24 heures signifie que vous acceptez de perdre une journée entière de saisies, de commandes ou de courriels. Pour un cabinet comptable en période de clôture, ce chiffre est généralement bien trop élevé.

Pourquoi la définition du RTO et du RPO est l'affaire du dirigeant, pas de l'informaticien

Beaucoup de dirigeants de PME délèguent entièrement cette décision à leur prestataire informatique. C'est une erreur de gouvernance. Le prestataire connaît les solutions techniques ; vous seul connaissez l'impact financier d'une heure d'arrêt, les obligations contractuelles vis-à-vis de vos clients, ou le volume de données que génère votre équipe chaque jour.

La méthode la plus simple pour estimer votre RTO : calculez ce qu'une heure d'interruption totale vous coûte réellement (personnel bloqué, commandes perdues, pénalités). La méthode pour estimer votre RPO : identifiez le volume de transactions ou de saisies que vous produisez par heure et demandez-vous combien d'entre elles vous pouvez vous permettre de ressaisir manuellement.

Tableau comparatif : RTO et RPO selon le profil de PME

Ce tableau illustre des ordres de grandeur courants selon les secteurs. Les chiffres sont donnés à titre indicatif pour structurer votre réflexion, non comme des normes absolues.

Profil de PME RTO cible typique RPO cible typique Justification principale
Commerce de détail avec caisse connectée 1 à 4 heures 1 à 2 heures Transactions en temps réel, perte de ventes immédiate
Cabinet comptable ou juridique 4 à 8 heures 4 heures Données critiques en période de clôture ou d'audience
PME industrielle avec ERP 8 à 24 heures 24 heures Production peut fonctionner partiellement sans IT
Agence de services sans stock physique 24 à 48 heures 24 heures Impact client différé, données moins volatiles
E-commerce ou SaaS B2B Moins de 1 heure Moins de 1 heure Disponibilité en ligne = chiffre d'affaires direct

RTO et RPO dans un contrat : ce que vous devez exiger de votre prestataire

Un contrat de maintien en condition opérationnelle ou de sauvegarde sérieux doit mentionner explicitement les valeurs de RTO et de RPO engagées, pas seulement les moyens techniques déployés. La présence d'un GTR (Garantie de Temps de Rétablissement) dans le contrat est liée directement au RTO : vérifiez que la GTR contractuelle est inférieure ou égale à votre RTO cible.

Posez systématiquement ces trois questions à tout prestataire candidat :

  • Quel RTO pouvez-vous garantir par contrat pour mon infrastructure actuelle ?
  • Quelle est la fréquence réelle de mes sauvegardes et quel RPO cela implique-t-il ?
  • Avez-vous déjà testé la restauration complète chez un client comparable à ma PME, et avec quel résultat ?

Pour comparer les offres des prestataires de votre ville, consultez notre annuaire des prestataires informatiques.

Lien entre RPO et stratégie de sauvegarde : fréquence, support et externalisation

Le RPO n'est pas une valeur abstraite : il commande directement votre fréquence de sauvegarde. Si votre RPO est de 2 heures, vos sauvegardes doivent s'effectuer au moins toutes les 2 heures. Si votre RPO est de 24 heures, une sauvegarde nocturne peut suffire, à condition qu'elle soit testée régulièrement.

Les trois paramètres techniques qui découlent du RPO sont :

  • La fréquence des sauvegardes (toutes les heures, toutes les 4 heures, quotidiennement).
  • Le type de sauvegarde (complète, incrémentielle, différentielle).
  • Le lieu de stockage (sur site, dans un datacenter distant, dans le cloud ou une combinaison des trois).

Pour approfondir ce sujet, notre blog dédié aux PME propose des guides pratiques sur les solutions de sauvegarde externalisée.

Comment tester que votre RTO et RPO sont réellement respectés

La plupart des PME ne testent jamais leur plan de reprise avant d'en avoir besoin. C'est une erreur que l'on ne découvre qu'au pire moment. Un prestataire sérieux propose au minimum un test de restauration annuel, avec un compte rendu écrit indiquant le temps réel de restauration et le volume de données effectivement récupéré.

Lors de ce test, demandez les métriques suivantes :

  • Temps de détection de la panne simulée.
  • Temps de déclenchement de la procédure de reprise.
  • Temps de restauration effective des données.
  • Temps de vérification et de validation par vos équipes métier.

La somme de ces quatre durées doit être inférieure à votre RTO contractuel. Si ce n'est pas le cas, votre plan est sur le papier uniquement. Consultez le classement des prestataires pour identifier ceux qui intègrent des tests de reprise dans leurs offres.

Décider : comment choisir vos valeurs de RTO et RPO avant de consulter un prestataire

Avant tout rendez-vous commercial, répondez par écrit à ces quatre questions :

  • Combien de temps mon activité peut-elle fonctionner sans accès au système informatique (commandes en cours, devis, facturation, communication) ?
  • Combien de données je génère par heure en moyenne, et combien seraient perdues si je devais restaurer depuis hier soir ?
  • Ai-je des obligations contractuelles ou réglementaires qui imposent une disponibilité minimale de mes systèmes ?
  • Quel est le coût estimé d'une journée d'arrêt complet pour mon entreprise ?

Les réponses à ces questions définissent vos RTO et RPO cibles. Communiquez-les dès le premier entretien avec chaque prestataire candidat : leur façon de réagir vous en apprendra autant que leurs plaquettes commerciales.

FAQ : RTO et RPO pour les PME

Quelle est la différence concrète entre RTO et RPO pour une PME qui utilise un logiciel de comptabilité ?

Le RTO détermine combien de temps votre comptable peut travailler sans accès au logiciel avant que cela bloque la clôture mensuelle ou le paiement des fournisseurs. Le RPO détermine combien d'écritures comptables vous êtes prêt à ressaisir si la restauration ramène vos données à l'état d'hier soir. Ces deux questions ont des réponses différentes et mènent à des choix techniques différents : un RTO court peut nécessiter un serveur de secours en attente, un RPO court peut nécessiter des sauvegardes toutes les heures.

Mon prestataire parle de GTR : est-ce la même chose que le RTO ?

Pas tout à fait. La GTR (Garantie de Temps de Rétablissement) est l'engagement contractuel du prestataire à rétablir le service en moins d'un certain délai. Le RTO est votre objectif interne, défini par votre activité. Le RTO doit guider votre exigence de GTR : si votre RTO est de 4 heures, votre contrat doit prévoir une GTR inférieure à 4 heures pour avoir une marge de manoeuvre. Une GTR de 8 heures face à un RTO de 4 heures est une incompatibilité contractuelle à signaler avant signature.

Faut-il définir un seul RTO et un seul RPO pour toute l'entreprise ?

Non. Une approche plus fine consiste à classer vos applications et vos données par criticité et à définir des RTO et RPO différents selon les niveaux. Votre logiciel de facturation n'a pas la même criticité que votre outil de veille concurrentielle. Cette segmentation permet d'optimiser le coût de votre plan de reprise en concentrant les efforts techniques sur ce qui compte vraiment pour la continuité de votre activité, sans sur-protéger des données secondaires.

À lire aussi