Ce qu'il faut retenir
- Le RTO (Recovery Time Objective) est la durée maximale acceptable pendant laquelle votre système peut rester hors ligne 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 écoulé depuis la dernière sauvegarde valide.
- Un prestataire informatique sérieux vous demande de définir ces deux valeurs avant de concevoir votre plan de sauvegarde, pas après.
- Si votre contrat ne mentionne ni RTO ni RPO, vous n'avez aucune garantie contractuelle sur votre capacité à rebondir en cas de sinistre.
Le temps de restauration, le RTO et le RPO sont les deux indicateurs qui mesurent concrètement votre résilience informatique : le premier dit combien de temps vous pouvez vous permettre d'être à l'arrêt, le second dit combien de données vous pouvez vous permettre de perdre. Sans ces deux chiffres inscrits noir sur blanc dans votre contrat, votre plan de continuité repose sur des promesses verbales.
En résumé
- Le RTO fixe le délai maximum de remise en service de vos systèmes après un sinistre.
- Le RPO fixe le point de données le plus ancien acceptable pour reprendre l'activité.
- Ces deux valeurs doivent être définies par le métier, pas imposées par l'informatique.
- Un écart entre RTO/RPO cibles et les capacités réelles de votre prestataire est un risque financier direct pour votre entreprise.
- Tester régulièrement la restauration est la seule façon de vérifier que les engagements sont tenus.
RTO et RPO : deux questions simples, deux réponses qui engagent tout
Imaginez un incendie dans votre salle serveur un mardi matin. Deux questions se posent immédiatement. Combien de temps vos équipes, vos clients, vos fournisseurs peuvent-ils attendre que les systèmes redémarrent ? Et jusqu'à quand pouvez-vous remonter dans le temps pour retrouver des données exploitables ?
La réponse à la première question, c'est votre RTO. La réponse à la seconde, c'est votre RPO. Ces deux indicateurs ne sont pas des concepts réservés aux grandes entreprises : une PME de vingt personnes dont le logiciel de facturation est indisponible deux jours perd des commandes, perd de la crédibilité, parfois perd des clients. Fixer un RTO à 4 heures et un RPO à 24 heures, c'est décider, en connaissance de cause, de ce que vous êtes prêt à subir.
Comment définir votre RTO et votre RPO selon votre activité
La démarche commence toujours par une analyse métier, pas par une discussion technique. Vous listez vos processus critiques, vous évaluez le coût d'une heure, d'une journée, d'une semaine d'interruption pour chacun, puis vous remontez vers votre prestataire avec des exigences chiffrées.
Quelques questions à vous poser :
- Quels processus s'arrêtent immédiatement si votre serveur de fichiers est inaccessible ?
- Quelle est la fréquence de vos transactions les plus sensibles (devis, commandes, encaissements) ?
- Avez-vous des obligations contractuelles ou réglementaires de disponibilité vis-à-vis de clients ou d'autorités ?
- Disposez-vous de procédures manuelles de secours, et combien de temps peuvent-elles tenir ?
Les réponses déterminent vos valeurs cibles. Un cabinet comptable en période de clôture fiscale n'a pas le même RPO qu'un bureau d'architecture entre deux projets.
Tableau comparatif : RTO et RPO selon le type de système
| Type de système | RTO cible courant | RPO cible courant | Impact d'un dépassement |
|---|---|---|---|
| ERP ou logiciel de gestion central | 2 à 4 heures | 1 à 4 heures | Arrêt de la production ou de la facturation |
| Messagerie d'entreprise | 1 à 2 heures | 24 heures | Perte de communication client et fournisseur |
| Serveur de fichiers partagés | 4 à 8 heures | 24 heures | Travail en doublon, versions de documents perdues |
| Site web vitrine | 8 à 24 heures | 48 heures | Perte de visibilité, impact modéré sur le chiffre d'affaires |
| Système de caisse ou de réservation en ligne | Moins d'1 heure | 15 à 60 minutes | Perte directe de ventes et d'expérience client |
Ces plages sont des repères issus des pratiques observées chez les prestataires que nous recensons. Elles ne valent que si elles sont testées et contractualisées.
Ce que doit contenir votre contrat de sauvegarde et de restauration
Un bon contrat de prestation informatique précise, pour chaque système couvert : la fréquence des sauvegardes, leur durée de rétention, le RTO garanti, le RPO garanti, et les conditions de déclenchement du plan de reprise. Il indique aussi qui décide de déclencher le plan, en quelle heure, et qui en informe qui.
Si votre contrat actuel ne contient aucune de ces mentions, consultez notre blog pour comprendre comment renégocier vos engagements de service, ou comparez directement les prestataires informatiques référencés sur notre site pour trouver un interlocuteur qui propose des SLA documentés.
Les erreurs fréquentes sur le temps de restauration en PME
La première erreur est de confondre sauvegarde et restauration. Avoir une sauvegarde ne garantit pas de pouvoir restaurer dans les temps. La deuxième erreur est de ne jamais tester. Un prestataire qui ne propose pas de test de restauration au moins une fois par an ne peut pas garantir son RTO. La troisième erreur est de ne définir aucun RTO, laissant le prestataire décider seul de ce qui est « raisonnable ».
La quatrième, enfin, est de traiter RTO et RPO comme des valeurs fixes. Vos besoins évoluent avec votre activité : une nouvelle ligne de produits, un changement de logiciel comptable, un pic saisonnier. Revoyez ces indicateurs au moins une fois par an avec votre prestataire.
Comment évaluer votre prestataire actuel sur ces critères
Posez trois questions directes lors de votre prochain point avec votre prestataire informatique. Premièrement : quel est le RTO garanti pour mon ERP ? Deuxièmement : quand avez-vous réalisé le dernier test de restauration complète, et quel en est le résultat documenté ? Troisièmement : si je dois déclencher le plan de reprise un samedi à 7 heures du matin, qui je contacte et en combien de temps intervenez-vous ?
Si les réponses sont vagues, imprécises ou renvoyées à un document introuvable, c'est un signal d'alerte. Consultez notre classement des prestataires informatiques pour vous repérer parmi ceux qui documentent leurs engagements de service.
Prendre une décision : par où commencer
Si vous n'avez pas encore de RTO ni de RPO définis, commencez par une réunion interne de deux heures avec vos responsables de service. Listez les cinq systèmes les plus critiques, évaluez l'impact d'une coupure de 4 heures, de 24 heures, de 72 heures sur chacun. Vous aurez déjà une base de négociation solide pour votre prochain échange avec votre prestataire.
Si vous souhaitez changer de prestataire ou en comparer plusieurs, notre annuaire recense des prestataires informatiques par ville avec leurs spécialités, dont la gestion de la continuité et de la reprise d'activité.
FAQ
Quelle différence y a-t-il entre un plan de reprise d'activité et un plan de continuité d'activité ?
Le plan de continuité d'activité (PCA) vise à maintenir les fonctions essentielles pendant un incident, souvent via des procédures dégradées ou des sites de repli. Le plan de reprise d'activité (PRA) organise le retour à la normale après un sinistre. Le RTO et le RPO s'appliquent aux deux, mais le PRA est celui qui engage directement votre prestataire informatique sur des délais techniques précis.
Mon prestataire me dit que mes sauvegardes sont quotidiennes. Cela suffit-il ?
Une sauvegarde quotidienne implique un RPO de 24 heures au maximum : vous pouvez perdre jusqu'à une journée entière de données. Si votre activité génère des transactions importantes chaque heure (commandes, encaissements, fiches clients mises à jour), 24 heures de perte est un risque significatif. La fréquence de sauvegarde doit être calée sur votre RPO cible, pas sur la configuration par défaut du logiciel de votre prestataire.
Est-il possible de tester soi-même la restauration sans mettre en danger la production ?
Oui, à condition que votre prestataire dispose d'un environnement de test isolé. Un test de restauration sérieux consiste à remonter une sauvegarde sur un serveur distinct, à vérifier l'intégrité des données et à mesurer le temps effectivement écoulé. Ce test ne touche pas à la production si l'infrastructure est correctement conçue. Exigez un compte-rendu écrit à chaque test, avec l'heure de début, l'heure de fin et les éventuelles anomalies constatées.
