Plan de reprise informatique : fixer les objectifs RTO et RPO
Combien de temps un service peut-il rester arrêté, et combien de données peut-on perdre ? Ces deux questions, posées aux métiers avant d'acheter quoi que ce soit, structurent tout le plan de reprise.
Lundi, 7 h 10. Le serveur qui héberge la gestion des dossiers ne redémarre pas. L’équipe informatique sait restaurer la sauvegarde de la nuit ; elle ne sait pas si la direction préfère attendre six heures une restauration complète ou repartir dans une heure sur une version partielle. Personne n’a posé la question avant. C’est le rôle d’un plan de reprise informatique : décider à froid ce qu’on n’a pas le temps de décider à chaud.
Deux objectifs, deux questions aux métiers
Tout le plan repose sur deux valeurs, fixées service par service.
Le RTO (recovery time objective, durée maximale d’interruption admissible) répond à la question : au bout de combien de temps l’arrêt de ce service devient-il inacceptable ? Le RPO (recovery point objective, perte de données maximale admissible) répond à une autre question : quelle quantité de travail, exprimée en durée, accepte-t-on de perdre et de ressaisir ?
Ces deux valeurs ne relèvent pas de l’équipe informatique. Elle sait ce que coûte chaque niveau de protection ; seuls les métiers savent ce que coûte l’arrêt. Le dialogue entre les deux est le cœur du travail.
Fixer les objectifs : la méthode
- Lister les services du point de vue des utilisateurs (paie, accueil du public, facturation, messagerie), et non les serveurs. Un service s’appuie souvent sur plusieurs systèmes ; un système sert souvent plusieurs services.
- Mesurer l’impact d’un arrêt dans le temps : que se passe-t-il au bout d’une heure, d’une journée, d’une semaine ? Pertes financières, obligations légales, sécurité des personnes, image. Cette analyse d’impact sur l’activité est décrite par la norme ISO 22301.
- Fixer RTO et RPO avec le responsable métier, au point où l’impact devient inacceptable. Noter la valeur, la justification et le nom de la personne qui l’a validée.
- Tracer les dépendances. Un service qui doit repartir en deux heures ne peut pas dépendre d’un annuaire, d’un réseau ou d’un fournisseur qui repart en deux jours.
- Regrouper en classes. Trois ou quatre classes suffisent ; au-delà, personne ne s’en souvient le jour de l’incident.
- Choisir les moyens pour chaque classe, puis chiffrer. Si le coût est hors de portée, revenir vers le métier : soit l’objectif bouge, soit le budget.
Classes de services et moyens associés
Le tableau ci-dessous donne un ordre d’idée. Les valeurs sont indicatives et dépendent de chaque organisation.
| Classe | RTO / RPO indicatifs | Moyens habituels | Exemples de services |
|---|---|---|---|
| Vitale | Moins d’une heure / quelques minutes | Réplication vers un second site, bascule préparée | Régulation d’urgence, paiements |
| Critique | Quelques heures / une heure | Sauvegardes fréquentes, environnement de reprise prêt | Dossiers usagers, facturation |
| Importante | Un à deux jours / une journée | Sauvegarde quotidienne, restauration documentée | Intranet, gestion de projet |
| Différable | Une semaine / une semaine | Sauvegarde hebdomadaire, reconstruction | Archives consultées rarement, outils de test |
La réplication copie aussi les erreurs : un fichier chiffré par un rançongiciel est répliqué en quelques secondes. Elle ne remplace pas une sauvegarde isolée, hors ligne ou non modifiable, qui reste la seule protection fiable contre ce type d’attaque.
Ce que le plan doit contenir
Un plan de reprise utile est court. Il est lu dans l’urgence, parfois sans accès au réseau : il doit exister sur papier ou sur un support indépendant du système d’information. Il contient, pour chaque classe : les services concernés et leur ordre de redémarrage ; les personnes à appeler, avec des suppléants ; les procédures techniques pas à pas ; les critères qui déclenchent la bascule ; la façon de revenir à la situation normale.
Pour les organisations soumises au règlement DORA, applicable depuis le 17 janvier 2025, ou à la directive NIS 2, la continuité et la reprise font partie des mesures attendues. Le plan devient alors une pièce que l’autorité de contrôle peut demander, avec la preuve de ses tests.
Les dépendances qu’on oublie
Les exercices de reprise échouent rarement sur le système principal. Ils échouent sur ce dont il dépend et que personne n’avait listé. L’annuaire qui gère les comptes : sans lui, personne ne se connecte au système restauré. Les certificats et les clés de chiffrement : une sauvegarde chiffrée dont la clé était stockée sur le serveur perdu est illisible. Le service de noms de domaine, le réseau, l’accès distant des administrateurs. Les licences liées à un matériel précis. Les fournisseurs en nuage, dont les propres engagements de reprise doivent être compatibles avec les vôtres.
Pour chaque service vital ou critique, une carte des dépendances tient sur une page. Elle dit ce qui doit repartir avant, et dans quel ordre. Elle se vérifie à chaque exercice et se met à jour à chaque changement d’architecture.
Le RTO d’un service ne peut pas être meilleur que celui de sa dépendance la plus lente. Un service « vital » qui repose sur un annuaire « important » est, en pratique, un service important.
Tester, sinon rien
Une sauvegarde qui n’a jamais été restaurée est une hypothèse. Les exercices peuvent être progressifs : restaurer un fichier, puis une base complète sur un environnement isolé, puis basculer un service entier pendant une période creuse. Chaque exercice se mesure : le temps réel de reprise est-il sous le RTO ? La donnée restaurée est-elle sous le RPO ? Les écarts alimentent la révision du plan.
Le premier pas est modeste : réunir pendant une heure les responsables des trois services les plus sensibles et leur poser les deux questions. Les réponses suffisent souvent à montrer où le dispositif actuel ne tient pas. Pour les équipes qui veulent structurer la démarche dans un cadre de pilotage, la page gouvernance présente l’approche de DOSOBE.
Pour approfondir : Gouvernance & traçabilité
Questions fréquentes
Quelle différence entre plan de reprise et plan de continuité ?
Le plan de continuité d'activité couvre toute l'organisation : locaux, personnes, fournisseurs, communication. Le plan de reprise informatique en est la partie technique : il décrit comment remettre en service les systèmes après un incident.
Une sauvegarde quotidienne suffit-elle ?
Elle donne un RPO d'environ une journée, et seulement si elle est restaurable. Pour un service où une journée de saisie perdue est inacceptable, il faut des sauvegardes plus fréquentes ou une réplication. Contre les rançongiciels, au moins une copie doit être hors ligne ou non modifiable.
Les objectifs RTO et RPO sont-ils exigés par la réglementation ?
Pour les entités financières soumises à DORA, applicable depuis le 17 janvier 2025, la continuité et la reprise des systèmes de TIC font partie des exigences. La directive NIS 2 cite aussi la continuité des activités, dont la gestion des sauvegardes et la reprise. Les valeurs elles-mêmes restent à fixer par chaque organisation.