Le délai de restauration (RTO) de vos systèmes critiques est-il connu et documenté ?
En bref — ce que vous devez retenir
Le RTO (Recovery Time Objective) est le temps maximum acceptable pour restaurer un système après un incident. Sans le définir, vous ne savez pas si votre infrastructure est capable de tenir cet engagement. Le définir vous force à tester et à investir là où ça compte vraiment.
Glossaire
Recovery Time Objective
Objectif de Temps de Reprise
Durée maximale acceptable pour remettre un système en service après un incident. Exemple : « notre site doit être de nouveau en ligne en moins de 4 heures ».
Le RTO répond à la question : combien de temps mon entreprise peut-elle fonctionner sans tel système ? Pour un e-commerçant, le RTO de la boutique en ligne est peut-être 4 heures. Pour un cabinet médical, le logiciel de gestion des rendez-vous a peut-être un RTO de 24 heures.
Sans RTO défini, les incidents sont gérés "au feeling". Les équipes passent des jours à restaurer un système non critique pendant qu'un système vital reste inaccessible. Le RTO priorise les efforts et détermine le niveau d'investissement nécessaire en redondance.
Le RTO doit aussi prendre en compte la chaîne de dépendances : si votre ERP dépend d'un serveur de base de données et d'un serveur d'application, le RTO de l'ERP implique de restaurer les deux dans le bon ordre. Sans cartographie de ces dépendances, la restauration dure toujours plus longtemps que prévu.
Le RTO n'est crédible que s'il est régulièrement testé. Beaucoup d'entreprises découvrent lors d'un vrai incident que leur plan théorique prend 3 fois plus longtemps en pratique — à cause des problèmes de compatibilité, des licences à réactiver, ou simplement du stress et de la panique qui ralentissent toutes les opérations.
Crash serveur un Black Friday. Sans RTO défini, l'équipe a perdu 6 heures à restaurer le système CRM non urgent pendant que le site de vente restait hors ligne. Perte estimée : 25 000 € de commandes non passées.
"On a réalisé lors d'un crash que notre logiciel de gestion des patients prenait 18 heures à restaurer. Notre RTO implicite était 2 heures. On a dû tout passer en papier pendant 2 jours."
"On avait documenté un RTO de 4 heures pour notre logiciel de transactions. Lors d'un crash, on a pris 14 heures. La procédure de restauration n'avait jamais été testée : le serveur de secours avait un certificat SSL expiré, et la documentation était obsolète depuis 2 ans."
Obtenez votre score cybersécurité en 25 minutes et un plan d'action concret.