Services
Partenaires
Cas d'usage
Nos clients
La société
Contact
FRENDE
Continuité & reprise

Assurer la continuité d'activité

Après un incident majeur, une seule question compte : en combien de temps redevenez-vous opérationnel, et avec quelles données ? Y répondre suppose des objectifs assumés par le métier et un dispositif réellement testé — pas un classeur mis à jour une fois par an.

L'enjeu

Des objectifs assumés, et la preuve qu'ils tiennent

La continuité repose sur deux grandeurs simples. Le RPO définit la perte de données tolérable : jusqu'où peut-on revenir en arrière ? Le RTO définit le délai acceptable avant remise en service. Ces deux valeurs sont des décisions métier, pas des paramètres techniques — c'est pourquoi elles se déterminent avec les directions concernées, sur la base d'une analyse d'impact.

L'erreur classique consiste à afficher des objectifs ambitieux que l'infrastructure ne peut pas tenir : sauvegardes trop espacées, restaurations jamais chronométrées, dépendances oubliées. Le jour de l'incident, l'écart se paie comptant.

Nous rendons ce dispositif crédible : hiérarchiser les activités, fixer des objectifs atteignables, aligner l'architecture de sauvegarde et de reprise, puis vérifier par des tests de restauration et un exercice de crise que l'ensemble fonctionne — équipes comprises.

Ce qui est en jeu
  • RTO et RPO affichés mais jamais vérifiés
  • Sauvegardes non testées, ou accessibles depuis le domaine compromis
  • Dépendances critiques (fournisseurs, cloud) non prises en compte
  • Aucune organisation de crise identifiée ni entraînée
  • Documentation de reprise obsolète ou stockée sur le système à restaurer
Schéma

Les deux fenêtres qui déterminent votre reprise

Fenêtres RPO et RTO autour d'un sinistre RPO perte de données tolérée RTO délai de remise en service SINISTRE Dernièresauvegarde saineReprisedu service avantaprès
Le RPO mesure la perte de données acceptable avant le sinistre ; le RTO, le délai de remise en service après. Tout le dispositif se cale sur ces deux valeurs.
Notre approche

Comment nous procédons

Du métier vers la technique : on décide ce qui doit repartir en premier, puis on construit les moyens correspondants.

01

Analyse d'impact (BIA)

Identification des activités essentielles, de leurs délais d'indisponibilité tolérables et de leurs dépendances — applications, données, fournisseurs et personnes clés.

02

Objectifs RTO / RPO

Définition avec les métiers des objectifs par activité, en confrontant l'ambition au coût. C'est l'étape où l'on arbitre explicitement plutôt que d'hériter d'objectifs implicites.

03

Plans PCA et PRA

Formalisation du fonctionnement en mode dégradé (PCA) et des procédures de reprise technique (PRA) : ordre de redémarrage, prérequis, rôles et moyens de communication de secours.

04

Alignement technique

Mise en cohérence des sauvegardes et de l'architecture avec les objectifs : fréquence, immuabilité, isolation des copies vis-à-vis du domaine, et restaurations chronométrées.

05

Exercices et maintien

Exercice de crise (table top) et tests de restauration réels, puis mise à jour du dispositif. Un plan vit : il se réévalue à chaque changement significatif du système d'information.

Services mobilisés

Plusieurs expertises, un seul interlocuteur

La continuité mêle gouvernance, architecture et retour d'expérience d'incidents réels — nous apportons les trois.

Livrables
  • Analyse d'impact sur les activités (BIA)
  • Objectifs RTO et RPO validés par les métiers
  • Plans de continuité (PCA) et de reprise (PRA)
  • Recommandations sur les sauvegardes et l'architecture
  • Compte rendu d'exercice et de tests de restauration
Questions fréquentes

Questions fréquentes

Le PCA organise la poursuite de l'activité pendant l'incident, y compris en mode dégradé — souvent avec des solutions de contournement. Le PRA décrit la remise en service technique des systèmes. Les deux sont nécessaires : l'un protège le métier, l'autre restaure l'informatique.

Un test de restauration au moins annuel pour les systèmes critiques, complété par un exercice de crise. Beaucoup d'organisations découvrent à cette occasion qu'une sauvegarde ne se restaure pas, ou que la procédure était stockée sur le serveur à restaurer.

Rarement en l'état. Face aux rançongiciels, ce qui compte est qu'une copie soit isolée du domaine, immuable et restaurable dans le délai visé. Nous vérifions ces trois propriétés plutôt que la seule existence de la sauvegarde.

Oui, tous ces référentiels exigent un dispositif de continuité éprouvé. Le travail mené ici alimente directement ces démarches, et inversement : si vous en conduisez déjà une, nous capitalisons sur l'existant.

En combien de temps repartiriez-vous ?

Une analyse d'impact et un test de restauration donnent une réponse factuelle — souvent différente de celle attendue.