Lorsqu’une PME commence à structurer son Plan de Reprise Informatique, deux acronymes reviennent systématiquement : RTO et RPO. Ils sont souvent mentionnés ensemble, parfois confondus, et rarement définis avec la précision qu’ils méritent.

Pourtant, c’est sur ces deux chiffres que repose toute la cohérence — et tout le réalisme — d’un plan de reprise.

Ce guide vous explique ce que signifient concrètement le RTO et le RPO, comment les calibrer selon la criticité de votre activité, et pourquoi des objectifs mal définis peuvent rendre votre PRI inutile en situation réelle.

Définitions : RTO et RPO en langage clair

Le RTO — Recovery Time Objective

Le RTO est la durée maximale acceptable d’interruption d’un service informatique après un incident. Il répond à la question : combien de temps votre entreprise peut-elle fonctionner sans ce service avant que l’impact devienne critique ?

Exemple : votre ERP est indisponible. Si votre activité peut absorber 4 heures d’interruption avant de subir des conséquences graves — retards de livraison, impossibilité de facturer, perte de commandes — votre RTO pour cet ERP est de 4 heures.

Un RTO de 4 heures signifie que votre prestataire doit être en mesure de remettre le service en état de fonctionnement technique dans ce délai, à partir du moment où il a pris en charge l’incident.

Le RPO — Recovery Point Objective

Le RPO est la perte de données maximale acceptable, mesurée en temps. Il définit jusqu’à quel point dans le passé vos données doivent être restaurées. Il répond à la question : combien d’heures ou de jours de données pouvez-vous vous permettre de perdre ?

Exemple : vos données de production sont sauvegardées toutes les 4 heures. En cas d’incident survenant 3h30 après la dernière sauvegarde réussie, vous perdez 3h30 de données. Si cette perte est acceptable pour votre activité, votre RPO est de 4 heures.

Un RPO de 24 heures — autrement dit une sauvegarde quotidienne — signifie que vous acceptez de perdre une journée complète de données en cas de sinistre. Pour certains services, c’est tolérable. Pour d’autres — une base de données de commandes, un CRM actif — c’est inacceptable.

En résumé
RTO = temps maximal d’arrêt acceptable.
RPO = volume maximal de données perdues acceptable.
Les deux sont indépendants et doivent être définis par service, pas pour l’ensemble du système d’information.

Les 4 niveaux de criticité et leurs objectifs associés

Tous les services informatiques d’une PME n’ont pas le même impact sur l’activité en cas d’indisponibilité. Définir des objectifs RTO et RPO identiques pour tous est à la fois coûteux et irréaliste. La bonne pratique consiste à établir une matrice de criticité.

Criticité Caractéristiques RTO cible RPO cible Exemples typiques
CRITIQUE Arrêt immédiat de l’activité si indisponible. Impact client, financier ou légal immédiat. 4 h ouvrées 4 h ERP, CRM, messagerie, Active Directory, base de données de production
IMPORTANT Gêne significative sans arrêt total. Impact dans les heures qui suivent. 8 h ouvrées 12 h Serveurs applicatifs secondaires, outils RH, comptabilité
STANDARD Impact modéré, récupérable sous 24 h sans perte financière majeure. 24 h ouvrées 24 h Serveurs de fichiers, outils de reporting, archives
FAIBLE Aucun impact opérationnel immédiat. Gêne administrative uniquement. 48 h ouvrées 7 j Environnements de test, archives historiques, Active Directory de développement

Cette matrice doit être construite avec les responsables métier — et pas uniquement avec l’équipe informatique. La criticité d’un service se mesure à son impact sur l’activité, pas à sa complexité technique.

Les erreurs courantes dans la définition des objectifs RTO/RPO

Erreur n°1 : viser le RTO le plus court possible pour tous les services

Un RTO de 4 heures pour un service critique est pertinent et atteignable. Le même objectif pour l’ensemble du système d’information, y compris les services à faible criticité, multiplie les coûts d’infrastructure — stockage, bande passante, licences, hébergement — sans apport opérationnel réel.

Un PRI bien dimensionné est un PRI différencié.

Erreur n°2 : confondre heures calendaires et heures ouvrées

Un RTO de 4 heures semble court. Mais si votre prestataire calcule ce délai en heures ouvrées — c’est-à-dire en excluant les nuits, week-ends et jours fériés — un incident survenu un vendredi à 16h30 peut légitimement être résolu le lundi à 12h sans dépassement du SLA.

C’est un point contractuel essentiel à vérifier et à faire préciser dans votre annexe technique.

Erreur n°3 : définir les objectifs sans tester leur faisabilité

Un RPO de 4 heures implique des sauvegardes ou des réplications toutes les 4 heures. Un RTO de 4 heures implique une infrastructure de reprise dimensionnée pour restaurer vos services critiques dans ce délai.

Si ces conditions techniques ne sont pas réunies — bande passante insuffisante, volumétrie sous-estimée, machines non priorisées, runbook inexistant — les objectifs deviennent des aspirations, pas des engagements.

Point de vigilance
Des objectifs RTO et RPO n’ont de valeur contractuelle que s’ils sont mesurés lors de tests réguliers. Un PRI non testé est un PRI dont personne ne connaît les vraies performances.

Comment Alticap formalise vos objectifs RTO/RPO dans le contrat MCO PRI

La définition des objectifs RTO et RPO est l’une des premières étapes de la mise en place d’un contrat MCO PRI Alticap. Elle se traduit concrètement par la construction d’une annexe technique, qui comprend :

  • Un relevé de configuration nominatif : liste de toutes les VMs, serveurs physiques, bases de données et applications dans le périmètre du PRI.
  • Une matrice de criticité co-construite avec le client : impact métier à 1h, 4h et 24h pour chaque élément.
  • Un plan de sauvegarde détaillé : fréquences, rétentions, horaires planifiés et RPO résultant par service.
  • Un tableau RTO par niveau de criticité : objectifs contractualisés, conditions de calcul en heures ouvrées, procédure d’escalade en cas de dépassement.

Cette annexe technique est révisée annuellement et mise à jour sous 30 jours après toute modification du système d’information du client — ajout de VM, migration, changement d’application critique.

C’est cette mise à jour continue qui garantit que les objectifs restent cohérents avec la réalité de votre infrastructure.

Questions fréquentes

Quelle différence entre RTO et temps de rétablissement réel ?

Le RTO est un objectif contractuel. Le temps de rétablissement réel est ce qui est effectivement mesuré lors d’un sinistre ou d’un test.

L’écart entre les deux est précisément ce que permettent de détecter et de corriger les tests réguliers d’activation du PRI. Un bon prestataire vous communique les mesures réelles à chaque test, pas seulement l’objectif théorique.

Peut-on modifier les objectifs RTO/RPO en cours de contrat ?

Oui, par voie d’avenant. Toute modification des objectifs contractuels entraîne une révision de l’annexe technique et peut impliquer une adaptation tarifaire si elle nécessite un changement de volumétrie, de fréquence de sauvegarde ou de capacité d’hébergement.

Votre SI est-il prêt à redémarrer après un incident majeur ?

Nos experts Alticap analysent votre infrastructure, co-construisent votre annexe technique et vous accompagnent dans la mise en place d’un PRI adapté à votre activité.

→ Demander un audit PRI gratuit :
https://www.alticap.com/je-souhaite-etre-contacte