PRA et PCA : construire un plan de reprise qui fonctionne vraiment

La différence entre PRA et PCA

Les deux sigles sont souvent confondus, alors qu'ils répondent à des questions distinctes.

• Le PCA, plan de continuité d'activité, vise à maintenir l'activité pendant l'incident. Il couvre les locaux, le personnel, les fournisseurs, les processus — pas seulement l'informatique.
• Le PRA, plan de reprise d'activité, organise le redémarrage des systèmes après l'incident. C'est le volet technique.

Une entreprise peut avoir un excellent PRA et aucun PCA : les serveurs redémarrent en deux heures, mais personne ne sait qui prévient les clients.

Pourquoi tant de PRA échouent le jour J

Dans la plupart des cas, l'échec ne vient pas d'une défaillance technique mais de l'une de ces trois causes :

• Le plan n'a jamais été testé. Il existe sur papier, validé par la direction, rangé dans un dossier partagé — lui-même inaccessible pendant la panne.
• Le plan est périmé. Il décrit une infrastructure vieille de trois ans. Les serveurs virtualisés depuis n'y figurent pas.
• Les dépendances ont été oubliées. On restaure l'application métier, mais pas le contrôleur de domaine dont elle dépend pour l'authentification.

Les cinq étapes d'un PRA crédible

1. Inventorier et hiérarchiser

Toutes les applications ne se valent pas. Classez-les en trois niveaux : vitales (l'activité s'arrête sans elles), importantes (gênant mais tenable quelques jours), secondaires. Cette hiérarchie détermine l'ordre de redémarrage.

2. Fixer les RTO et RPO par application

Le RTO est le délai acceptable avant redémarrage. Le RPO est la quantité de données que vous acceptez de perdre. Ces valeurs se décident avec les métiers, pas entre informaticiens : c'est le directeur commercial qui sait combien coûte une journée sans ERP.

3. Concevoir l'architecture en conséquence

Un RTO de quatre heures et un RTO de quinze minutes n'appellent pas les mêmes moyens — ni les mêmes budgets. C'est l'étape où l'on arbitre entre ambition et coût, en connaissance de cause.

4. Documenter de façon utilisable

Un bon document de reprise se lit sous pression, par quelqu'un qui n'est peut-être pas celui qui l'a écrit. Procédures numérotées, identifiants d'urgence accessibles hors du système en panne, contacts des prestataires, ordre de redémarrage explicite.

5. Tester, et tester encore

Au minimum une fois par an, idéalement deux. Un test complet mobilise du monde et révèle immanquablement des oublis — c'est précisément son intérêt.

Automatiser les tests

C'est là que l'outillage change la donne. Veeam Recovery Orchestrator exécute vos plans de reprise dans un environnement isolé, sans interrompre la production, et produit automatiquement un rapport prouvant que la reprise fonctionne.

Deux bénéfices concrets : vous testez plus souvent, parce que ça ne coûte plus une nuit de travail ; et vous disposez d'une documentation à jour en permanence, utile en cas d'audit ou face à un assureur.

Le contexte marocain

Trois particularités méritent attention :

• La localisation des données. Certains secteurs — public, bancaire, santé — ont des exigences sur le lieu de stockage. Vérifiez-les avant de choisir un cloud.
• La coupure électrique. Au-delà de l'onduleur, prévoyez le scénario d'une coupure prolongée.
• La disponibilité des compétences. Si une seule personne sait redémarrer le système, votre PRA dépend de sa présence. Documentez pour quelqu'un d'autre.

Comment nous procédons

INTELSOLUTION accompagne les entreprises marocaines dans la conception de leur PRA : atelier de hiérarchisation avec vos métiers, définition des RTO et RPO, architecture technique, puis mise en place de l'orchestration automatisée. Nous commençons systématiquement par un test de restauration sur votre environnement actuel — c'est le meilleur moyen de savoir où vous en êtes réellement.