Une panne de serveur ne prévient jamais. Le guide ANSSI le rappelle : les PME sont particulièrement à risque faute de dispositifs de protection adaptés. Or ce qui distingue une entreprise qui repart en quelques heures d’une autre qui perd des clients tient à une décision de direction, pas à un réglage technique : le temps d’arrêt qu’elle peut absorber, et les données qu’elle accepte de perdre. Le RTO et le RPO ne sont donc pas des paramètres réservés aux ingénieurs. Ce sont des engagements contractuels, mesurables, que la direction signe et qu’un logiciel cybersécurité seul ne suffit jamais à tenir.
Ce tutoriel sort ces deux acronymes du débat technique. Vous verrez pourquoi le sujet engage d’abord la direction, puis comment traduire vos engagements clients en limites chiffrées, fixer votre RTO à partir de votre chiffre d’affaires, déterminer votre RPO selon ce que vous acceptez de perdre, exiger une restauration démontrée plutôt qu’une sauvegarde déclarée, et faire valider votre délai d’arrêt maximal par la direction. Nous terminerons par ce qu’un partenaire IT doit prouver concrètement et par les éléments à réunir sous trente jours.
Pourquoi le RTO et le RPO sont un sujet de cybersécurité TPE-PME, pas un débat technique
L’ANSSI a déjà posé ce diagnostic (voir ci-dessus) ; les mesures simples réduisent le risque, la continuité en fait partie : deux chiffres mesurables la pilotent, pas de bonnes intentions.
Le guide PCA du SGDSN (2013) situe la responsabilité au niveau du dirigeant, public ou privé, à qui il revient de garantir la continuité de l’organisation. Le délai d’arrêt maximal relève donc de l’entreprise, pas de l’informaticien. Il observe que les organisations ayant anticipé la continuité sont « les plus résilientes », et sa fiche 19 propose un arbitrage coût / avantage entre protection et impact d’interruption.
Nuance : ce cadre SGDSN date de 2013. Sa logique reste valable, mais son actualité doit être revérifiée avant de le citer en 2026 dans un document contractuel.
Conséquence : un dirigeant qui cherche un logiciel de cybersécurité ou une sauvegarde choisit d’abord un niveau de service à tenir, puis la technologie. Un audit cybersécurité PME avant tout achat évite l’erreur coûteuse d’investir dans un outil sans délai d’arrêt maximal défini.
RTO et RPO : deux acronymes, deux questions distinctes
Le RTO et le RPO répondent à deux questions distinctes.
Le RTO, un délai. Recovery Time Objective : pendant combien de temps l’activité peut-elle être interrompue avant que la situation devienne inacceptable ? La réponse est une durée, exprimée en heures.
Le RPO, une quantité de travail perdu. Recovery Point Objective : jusqu’à quel point du passé acceptez-vous de remonter ? La réponse s’exprime en heures ou minutes de saisie perdues, jamais en euros ni en gigaoctets.
Deux erreurs classiques. Acheter des sauvegardes très fréquentes en croyant accélérer le retour en service ; négliger la fréquence de sauvegarde en supposant une reprise rapide. La première confond RPO et RTO, la seconde suppose un RTO non démontré.
Le vocabulaire vient du cadre de continuité : le guide PCA du SGDSN distingue l’objectif de continuité en mode dégradé et l’objectif de reprise d’activité (fiche 15). Le RTO et le RPO en sont la traduction chiffrée pour un système d’information donné.
Ce cadre impose de mesurer d’abord les conséquences d’une interruption de service (fiche 8) : sans cette étape, le chiffre retenu reste une opinion, pas un engagement.
Ces deux promesses, disponibilité et intégrité des dossiers, sont celles que les étapes suivantes vous aideront à chiffrer. Cette promesse suppose une copie vérifiée hors site, comme le détaille notre article sur le NAS local et la copie offsite vérifiée.
Etape 1 : traduire vos engagements clients en limites chiffrées
Vos deux chiffres ne se déduisent pas d’un catalogue : ils se lisent dans vos engagements. Relisez vos contrats, conditions générales et devis : délais de livraison, délais de réponse, astreintes, pénalités, disponibilité promise. Un engagement écrit non chiffré cesse d’être un engagement dès le premier litige.
Observez ensuite vos clients pendant une panne. Ils appellent, relancent, menacent de partir : ce délai de patience est votre RTO réel, même s’il n’a jamais été écrit. Il ne se lit ni dans un taux de résolution ni dans un rapport de tickets, comme le rappelle notre analyse sur le support informatique en PME.
Classez alors les activités par criticité : facturation et encaissement, accès aux dossiers clients, messagerie, téléphonie, plateformes de commande. Un RTO unique appliqué à tout coûte cher sans protéger l’essentiel.
Intégrez enfin les obligations externes : transports, paiements, fournisseurs, exigences de donneurs d’ordre, échéances fiscales et sociales, qui tombent quelles que soient vos pannes.
Concluez par une phrase utilisable en direction : « une interruption de notre facturation au-delà de X heures entraîne un risque commercial et contractuel que nous refusons ». Sans elle, aucun arbitrage budgétaire n’est possible.
Etape 2 : fixer le RTO à partir du chiffre d’affaires
Votre phrase de direction tient en une ligne ; il reste à la chiffrer.
Une méthode recommandée, à valider en direction et non une doctrine figée : divisez votre chiffre d’affaires annuel par le nombre d’heures réellement ouvrées et facturables de l’année. Vous obtenez un ordre de grandeur de la valeur d’une heure d’activité.
Affinez par processus : une heure d’arrêt sur la chaîne de facturation ne pèse pas le même poids qu’une heure perdue sur un dossier de projet interne. Seule la valeur horaire du processus critique autorise un investissement de continuité, et c’est là qu’il faut regarder le coût réel d’une infogérance informatique avant d’arbitrer.
Posez ensuite la question à la direction : à partir de quelle durée d’arrêt suis-je prêt à perdre un client, ou à rendre des comptes à mon banquier, à un donneur d’ordre, à mon assureur ? Cette durée est votre RTO.
Confrontez-le aux scénarios réels : panne disque, perte d’un serveur, rançongiciel chiffrant les fichiers, indisponibilité d’un service cloud, coupure internet ou électrique, suppression humaine. Chacun impose un délai de remise en service différent.
Répartissez enfin ce délai en cinq temps : détection, décision, restauration technique, vérification fonctionnelle, remise en service. Le RTO signé porte sur le total, y compris le temps passé à décider qui déclenche la procédure.
Verrou : écrit et signé, le chiffre devient un engagement de service vérifiable. Non écrit, il ne sera pas respecté le jour de l’incident, faute d’avoir été priorisé.
Etape 3 : fixer le RPO à partir de ce que vous acceptez de perdre
Après le délai d’arrêt vient la perte de données. Le RPO se choisit avec les responsables métier, pas avec l’administrateur système : jusqu’à quelle heure de travail pouvez-vous reconstituer à la main sans bloquer l’activité ni fausser la comptabilité ?
Les réponses diffèrent selon le système. Des écritures comptables saisies le matin sont irrécupérables si elles disparaissent. Une journée de courriels se reconstitue en partie. Un dossier client non sauvegardé depuis 48 heures devient un problème de confiance.
Le RPO commande la fréquence et le type de sauvegarde. Une sauvegarde manuelle de fin de journée implique un RPO pouvant atteindre 24 heures, rarement compatible avec un engagement client sérieux. En dessous de 24 heures de perte admissible, l’ANSSI recommande la réplication.
Cohérence avec l’emplacement des copies : plus la copie est éloignée, plus le RTO s’allonge. Un RPO court est inutile si la remise en service prend trois jours.
Documentez ce RPO par système et par type de donnée dans un tableau validé par la direction : ce n’est pas une préférence technique, mais un choix d’entreprise assumé. Cette discipline rejoint celle exigée lors d’un onboarding IT externalisé.
Etape 4 : exiger une restauration démontrée, pas une sauvegarde déclarée
Votre tableau RPO validé ne vaut que si quelqu’un peut le tenir en conditions réelles. Le cadre SGDSN tranche : la section 2.3.10 du guide PCA est intitulée « Faire évoluer le plan : exercices et retours d’expérience », et la fiche 26 traite du maintien en condition opérationnelle du plan. Un plan non exercé n’est pas un plan validé.
Un outil de sauvegarde qui n’a jamais restauré ne répond ni au RTO, ni au RPO. Il produit des fichiers que personne n’a vérifiés. Vos deux chiffres restent alors des intentions.
Exigez un test documenté et daté : date, périmètre restauré, données réellement récupérées, horodatage de début et de fin, durée totale en heures, anomalies et corrections. Comparez ensuite la durée mesurée au RTO signé et le point de restauration atteint au RPO signé. Un écart non expliqué est une alerte immédiate, pas un détail à reporter.
Un test partiel ne prouve rien : restaurer un fichier isolé ou une base de test ne démontre pas qu’un serveur complet ou une boîte mail revient en service dans le délai promis aux clients.
Planifiez ce test à intervalle régulier et après chaque changement d’infrastructure, de version ou de fournisseur. Une restauration validée un an plus tôt sur un système modifié depuis n’a aucune valeur probante.
Reliez chaque test aux exercices et RETEX du cadre SGDSN : ce qui se corrige après un test évitera un blocage le jour de la vraie panne. Cette discipline rejoint la pression documentaire sur les sous-traitants décrite dans notre guide NIS2 und NISG 2026.
Etape 5 : faire signer le délai d’arrêt maximal par la direction
Une restauration démontrée n’engage encore personne. Pour la transformer en engagement de l’organisation, réunissez le RTO, le RPO, le périmètre couvert, les exclusions assumées et la fréquence des tests sur une page unique, puis faites-la signer par la direction. La validation par le service informatique seul ne suffit pas : la signature du dirigeant transforme un réglage technique en engagement et débloque le budget de continuité.
Cette signature est un arbitrage, pas une formalité. La fiche 19 du guide SGDSN, « Le bilan coût/avantage d’un PCA : comment arbitrer ? », est le cadre officiel de cet arbitrage. Seule la direction peut comparer les deux.
Prévoyez le dépassement : qui prévient les clients, avec quel message, dans quel délai, sous quelle responsabilité. Un RTO dépassé sans procédure de communication transforme une panne en incident de réputation.
Enfin, datez la signature et révisez-la à chaque évolution majeure : nouveau client important, nouveau service critique, nouveau site, nouveau prestataire. Un RTO validé il y a trois ans sur une activité changée n’engage plus personne. Le partenaire qui tiendra ce document se choisit avec la même rigueur : Comment choisir un prestataire informatique pour votre PME.
Ce qu’un partenaire IT doit démontrer concrètement
La page signée en main, le choix du partenaire se ramène à un test simple : parle-t-il en RTO et en RPO ? Qui ne répond qu’en téraoctets ou en fréquence de sauvegarde n’a pas compris la question. Les briques à vérifier sont concrètes : serveurs virtualisés, serveurs de fichiers et sauvegardes locales ou hybrides sur NAS, environnements Microsoft 365 (messagerie, espaces de travail, identités), pare-feu et accès distants sécurisés, supervision avec remédiation et gestion des correctifs. Exigez la preuve, pas la promesse : un compte rendu de restauration daté, périmètre et durée mesurée, sur une infrastructure comparable à la vôtre. Un partenaire qui le fournit travaille déjà en logique de continuité.
Sans ces deux chiffres signés, l’outillage reste une dépense non vérifiable. Pour trier ces promesses, ce guide des Managed IT-Services détaille les clauses.
Ce que vous devez avoir en main dans les trente jours
La preuve exigée du partenaire doit devenir la vôtre. En trente jours, cinq livrables suffisent.
- Vos deux chiffres. Un RTO en heures par activité critique, un RPO en heures par type de donnée, dérivés de votre chiffre d’affaires et de vos engagements clients, jamais d’un catalogue de produits.
- La page signée. La direction valide le RTO, le RPO et les exclusions, explicitement écrites : ce que vous choisissez de ne pas protéger doit être nommé, pas oublié.
- Une première restauration démontrée. Documentée, avec durée mesurée face au RTO et point de reprise atteint face au RPO.
- La répétition planifiée. Un compte rendu daté à chaque exercice : c’est la seule preuve durable devant un client, un assureur ou un donneur d’ordre.
- La discipline ANSSI. Quelques mesures simples, tenues dans la durée, réduisent nettement le risque.
Conclusion
RTO et RPO ne sont pas un débat technique : ce sont deux limites que votre PME choisit, signe et vérifie. Retenez trois points. D’abord, traduisez vos engagements clients et votre chiffre d’affaires en un délai d’arrêt maximal et une perte de données acceptable. Engagez-les par écrit et vérifiez-les par la preuve, c’est l’objet de chaque étape de ce guide.
Prochaine étape : consultez le guide des Managed IT-Services mentionné plus haut, puis fixez une première restauration mesurée dans les trente jours. Vos deux chiffres deviennent alors un cap clair, et votre outillage une valeur vérifiable.
