Plan de reprise d’activité (PRA) : une solution simple et efficace pour protéger votre SI

​Un Plan de Reprise d’Activité (PRA) est indispensable pour garantir le redémarrage des services en cas de sinistre. Bien que les incidents majeurs soient rares, ils se produisent suffisamment régulièrement pour représenter un risque. Si votre système d’information n’est pas redondé en actif/actif sur au moins deux sites, vous risquez de perdre l’accès à vos applications et potentiellement vos données pendant plusieurs jours, paralysant ainsi votre activité, avec des conséquences financières et commerciales importantes. À défaut d’une architecture en Plan de Continuité d’Activité (PCA), la meilleure protection consiste à mettre en place un PRA.

Qu’est-ce qu’un PRA (Plan de Reprise d’Activité) ?

Un PRA, ou Plan de Reprise d’Activité, ou Disaster Recovery Plan (DRP), est un ensemble de dispositifs informatiques, de procédures et méthodes permettant de restaurer de manière fiable des systèmes critiques après incident majeur, dans l’urgence, y compris de nuit ou le week-end.

L’objectif principal est de garantir une reprise rapide et efficace après une défaillance majeure, en minimisant le temps d’arrêt et la perte de données.

Les PRA sont souvent exigés par les assurances, ou pourront jouer sur votre prime d’assurance ou la prise en charge d’un sinistre.

Pourquoi un PRA est-il indispensable ?

Un PRA vise à vous protéger contre un incident majeur tel qu’une cyberattaque, une panne matérielle, un incendie, une catastrophe naturelle, etc. Lorsque ce type d’incident survient, c’est souvent un véritable scénario catastrophe pour votre système d’information.

On a tous en tête l’incendie d’OVH qui s’est déroulé dans la nuit du 9 au 10 mars 2021. Des milliers d’entreprises ont perdu l’accès à leurs serveurs. Beaucoup a été dit sur les entreprises qui n’avaient pas mis en place des sauvegardes sérieuses hébergées sur un autre site. Mais, même pour celles qui en avaient, rétablir les services n’a pas forcément été simple. Redémarrer une infrastructure relativement complexe à partir de presque rien, sur un autre site, avec les modifications d’adressage réseau nécessaires, tout en communiquant sur l’incident et en agissant dans l’urgence sans préparation, est un vrai défi.

Ces accidents peuvent même toucher des infrastructures et des acteurs de haut niveau, que l’on croyait à l’abri. Le 27 avril 2023, le datacenter Global Switch à Clichy a été victime d’un incendie provoqué par une fuite d’eau, avec de multiples répercussions. Ce datacenter est l’un des plus importants de France. De nombreux hébergeurs et infogéreurs y louent de l’espace pour les besoins de leurs clients. Ainsi Ecritel mais aussi la région Paris de Google Cloud ont été impactés. Pour Google, bien qu’Equinix Clichy ne soit qu’un des sites d’hébergement, une des “AZs” de la région France, de nombreux services Google de la zone « europe-west9-a » sont devenus indisponibles. Google informait alors ses clients : « nous prévoyons une indisponibilité générale de la région europe-west9. Il n’y a pas d’heure prévue pour la reprise des opérations dans la région europe-west9 à l’heure actuelle, mais on s’attend à une interruption prolongée. Il est conseillé aux clients de basculer vers d’autres régions s’ils sont touchés.» En clair, activez votre PRA ! Le 27 avril était un jeudi, et le lundi suivant, les services n’étaient toujours pas rétablis…

D’autres incidents, bien que moins spectaculaires ou impactants, se produisent régulièrement. Le 8 novembre 2021, le Mipih, un acteur majeur dans le secteur de la santé, a connu un incident important sur ses infrastructures d’hébergement. Celles-ci sont redevenues disponibles le 10 novembre. En août 2024, des serveurs de l’AP-HP ont été impactés par une panne électrique touchant un prestataire d’hébergement. Les services ont été assez rapidement rétablis, mais cela a nécessité une mobilisation importante des équipes.

Pour quelques incidents commentés publiquement, combien passent inaperçus ? À chaque fois, c’est l’improbable qui se produit. Il est donc impératif de se préparer au maximum.

Quels sont les objectifs d’un PRA ?

Un PRA a pour objectif de garantir le rétablissement des systèmes et applications essentiels à l’activité d’une organisation après un incident majeur.

1. Minimiser le temps d’arrêt : réduire au minimum le temps nécessaire pour relancer les activités après un sinistre.
2. Sécuriser les données : garantir l’accès à tout moment à des sauvegardes à jour et externalisées des données. La cohérence des données entre plusieurs bases est aussi critique.
3. Garantir la reprise de service : s’assurer que les services clés puissent redémarrer le plus rapidement possible.
4. Sécuriser les opérations : c’est par la documentation et la répétition des opérations que les équipes seront efficaces le jour J et que les écueils seront évités ou maîtrisés.
5. Respecter les contraintes légales : certaines industries, comme la finance ou la santé, sont soumises à des obligations légales ou sectorielles en termes de reprise d’activité.

Comment mettre en place un PRA ?

Le PRA est un ensemble de moyens techniques et de procédures pour reconstruire le système informatique (SI) suite à un incident. Il comprend :

• Des moyens techniques sur lesquels sera reconstruit le système informatique de secours.
• Des modalités précises de restauration des données, de leur synchronisation, et du taux de perte de données maximal maximum.
• Une procédure de déclenchement et de gestion de la crise, avec le recensement de tous les contacts devant être impliqués, les étapes à suivre et les critères de décision.
• Un test en conditions réelles, effectué à intervalles réguliers (généralement annuels), avec des scénarios qui peuvent varier.

Comment choisir entre PRA et PCA ?

Le Plan de Reprise d’Activité (PRA) et le Plan de Continuité d’Activité (PCA) sont deux approches différentes de la gestion des incidents.

• Le PRA vise à rétablir les systèmes critiques après un incident majeur. Il est activé après l’incident, sur décision conjointe de l’entreprise touchée et de l’équipe technique. Il est généralement plus économique, car les ressources ne sont que réservées ou partiellement consommées, sauf activation du PRA.
• Le PCA vise à éviter l’interruption de l’activité. Il s’agit d’un plan global visant à maintenir les services en fonctionnement même en cas d’incident. Il implique une infrastructure en haute disponibilité, répartie sur deux sites, avec équilibrage de charge et bascule automatique ou manuelle. Cela suppose que vos applications acceptent la répartition de charge. Un PCA est adapté aux applications critiques et performantes, mais il est plus couteux qu’un PRA puisque tout doit être répliqué. Et il est aussi plus délicat à mettre en place.

En résumé, le PCA est une solution préventive et permanente, adaptée aux infrastructures critiques, tandis que le PRA est une solution réactive, simple mais efficace, et plus économique. Point non négligeable, les systèmes de haute disponibilité du PCA peuvent être complexes à gérer, alors que le PRA repose sur des mécanismes plus basiques de réplication.

Éléments essentiels d’un PRA

Un PRA doit impérativement intégrer l’ensemble des éléments suivants :

1. Réplication des systèmes : les infrastructures critiques doivent être répliquées, sans être actives, afin de pouvoir redémarrer sur un autre site.
2. Sauvegarde externalisée des données : la sauvegarde doit être effectuée sur le site sur lequel on veut restaurer, et la restauration doit être testée régulièrement.
3. Automatisation du déploiement des infrastructures : idéalement, les composants de l’infrastructure doivent être automatisés en « Infrastructure as Code » (IaC), via des outils comme Ansible ou Terraform, pour assurer, si besoin, une reconstruction rapide de l’infrastructure de secours.
4. Plan de bascule réseau : ce plan doit permettre de reconfigurer les accès aux applications sur un autre site et de garantir que tous les composants du SI conserveront leurs flux actifs.
5. Monitoring du dispositif de PRA : les réplications et sauvegardes doivent être supervisées.
6. Procédure de déclenchement et gestion de crise : cette procédure recense tous les acteurs nécessaires à l’activation du PRA, avec leurs coordonnées, le processus de décision pour engager le PRA, ainsi que les actions de communication prévues .
7. Procédure de PRA : décrit en détail l’ordonnancement des opérations techniques à réaliser pour construire le système de secours et le mettre en service.
8. Tests réguliers : un PRA non testé régulièrement est inefficace à 80 %. Le test garantit que tous les processus fonctionnent correctement et que les systèmes redémarrent dans les délais fixés.

9. Maintien en conditions opérationnelles (MCO) du PRA : un système d’information évolue constamment. Chaque changement doit faire l’objet d’une évaluation de son impact sur le PRA et des évolutions à prendre en compte.

Outils pour faciliter le déclenchement du PRA :

• Automatisation : des outils comme Terraform ou Ansible peuvent faciliter le déploiement automatisé des infrastructures sur le site de secours.
• Supervision très complète de tous les composants de l’infrastructure pour évaluer précisément la situation.
• Sécurisation des outils et externalisation sur un autre site des outils d’accès, de supervision et de communication pour éviter de les perdre en même temps que le SI.

Environnements, types de PRA et SLA

Le périmètre d’un PRA se limite en général à l’environnement de production et aux applications critiques, en tenant compte des dépendances entre elles. Il peut également inclure les environnements de développement et de test si l’application concernée évolue rapidement.

SLA et types de PRA

Le PRA est défini par des objectifs de niveaux de service (SLA) qui déterminent la rapidité de reprise des activités.

• PRA froid : solution économique, mais la reprise des services est plus lente et peut prendre jusqu’à une semaine.
• PRA tiède : offre un compromis entre coût et rapidité, avec un temps de rétablissement de 2 à 4 jours.
• PRA chaud : permet une restauration quasi immédiate ( 4 à 48 heures), mais nécessite une infrastructure redondante et prête à être utilisée.

Délais et perte de données

Un PRA doit impérativement avoir des objectifs précis :

• Le délai de bascule RTO (Recovery Time Objective) : temps nécessaire pour redémarrer les services.
• La perte de données acceptée =  RPO (Recovery Point Objective) : taux de données perdues tolérable, ou le point auquel on sera capable de restaurer ou revenir dans le passé.
• Mode dégradé ou pas : il s’agit de définir si vous pouvez tolérer une diminution des performances ou si vos services doivent fonctionner à pleine capacité immédiatement.

Coût de la mise en place d’un PRA

Le coût d’un PRA est totalement variable d’une entreprise à l’autre. Il comprend les plusieurs postes :

• La réservation de ressources : les machines virtuelles (VM) sont répliquées mais non actives, ce qui évite la consommation de CPU/RAM, mais vous payez pour la réservation de ressources. L’espace de stockage des réplications est, lui, consommé en permanence, bien que ce ne soit pas le poste le plus important.
• Les coûts de transfert de données : ils sont proportionnels au nombre de serveurs et aux volumes de données à transférer. Ce n’est généralement pas le poste le plus coûteux.
• Des tests réguliers : ils doivent être effectués au moins une fois par an pour garantir l’efficacité du PRA, et potentiellement après un changement majeur. Cela comprend la préparation, la mise à jour de la documentation, la réalisation du test avec bascule aller, et potentiellement le retour arrière.
• Une maintenance continue : un PRA doit être régulièrement mis à jour pour refléter les changements de votre infrastructure, ce qui nécessite une évaluation de l’impact de chaque modification.

Au global, il est donc nécessaire de prévoir :

• Une prestation initiale ponctuelle pour la mise en place du PRA, incluant une première validation.
• Une prestation récurrente pour la réservation de ressources, le maintien en conditions opérationnelles (MCO) et l’adaptation du PRA. Un lissage du coût du test annuel est généralement inclus dans l’abonnement.
• Des prestations ponctuelles pour la mise à niveau du PRA en cas de changements significatifs dans votre infrastructure.
• Des prestations facturées au temps passé pour un retour arrière ou rétablir un nouveau PRA après activation, dont les coûts sont imprévisibles.

Procédure de déclenchement du PRA

Le déclenchement du PRA est un processus critique qui doit être clairement défini et documenté pour une prise de décision rapide et efficace. Cette procédure est trop souvent négligée.

1. Identification de la crise : qualification de l’incident en incident majeur, empêchant un retour rapide à la normale. C’est à l’hébergeur/infogéreur de poser le diagnostic.
2. Activation de la cellule de crise, tous les interlocuteurs de la cellule de crise doivent être identifiés et joignables 24/7. Cette cellule prend les décisions, suit l’évolution des opérations et gère la communication interne et externe.
3. Décision d’activer le PRA : la cellule de crise décide d’activer le PRA en fonction de la gravité de l’incident et de l’impossibilité de restaurer les systèmes dans un délai acceptable.
4. Communication en temps réel avec les parties prenantes : équipes IT, direction, prestataires et clients.
5. Activation du PRA : l’infrastructure de secours est mise en marche, incluant le démarrage des serveurs, la restauration des données, la relance des services applicatifs, et redirection des flux réseau. Des tests sont effectués pour valider la reprise complète des services avant de réouvrir l’accès aux utilisateurs.
6. Retour à la normale : une fois le PRA activé, deux scénarios sont possibles.
   • Soit le PRA est un miroir de l’infrastructure, et il est possible de rester en l’état. Dans ce cas, il faut simplement prévoir de remettre en place un PRA, soit sur le site initial à nouveau disponible, soit sur un nouveau site si son indisponibilité se prolonge.
   • Soit le PRA est un mode dégradé et le retour arrière est à la fois possible et souhaitable. Il faut alors prévoir une nouvelle bascule des services.

Coûts post-activation d’un PRA : il est à noter que les prestations et temps passés post activation ne sont en général pas inclus dans le contrat de PRA car ils sont presque impossibles à évaluer à l’avance tant cela dépend du cas de figure rencontré.

Les solutions de PRA cloud d’Alfa Safety

Alfa-Safety propose une solution simple  et très performante de PRA cloud avec un délai de bascule de 4h à 24h maximum, permettant une reprise rapide et efficace en cas de crise, sans intervention technique du client.

• Infrastructures rigoureusement identiques : nos deux sites principaux disposent des mêmes infrastructures Nutanix, d’une structure réseau identique complètement redondée, et d’une externalisation de tous les outils d’exploitation.
• Solution simple : Alfa-Safety assure, sur un site éloigné géographiquement, la réplication automatique et complète de l’environnement que vous avez choisi de protéger.
• Bascule en toute autonomie : nos équipes prennent en charge l’ensemble du processus de reprise, sans intervention du client, même pour les bascules réseau, ce qui garantit un délai de mise en œuvre rapide.
• Délai d’activation garanti : le redémarrage est assuré avec un délai d’activation garanti (SLA) entre 4 heures et 24/48 heures, en fonction de la configuration.
• Des tests réguliers, annuels ou bi-annuels, sont effectués pour vérifier la robustesse du plan.
• Évolutivité du PRA : en tant qu’hébergeur/infogéreur, nous intégrons tous les changements nécessaires.
• Budget maîtrisé grâce à l’utilisation de ressources réservées, non actives en permanence.

En synthèse, on ne se prépare jamais assez à un sinistre majeur. Aujourd’hui, les incidents de production sont assez rares car les systèmes et les infrastructures sont devenues fiables. La probabilité d’un sinistre majeur est faible mais il a de fortes chances d’être un vrai scénario catastrophe.

Reste à choisir entre PRA et PCA :

• Le PCA est perçu comme plus moderne et supérieur, mais il comporte des complexités techniques et sera plus coûteux qu’un PRA, sauf peut-être pour des infrastructures de grande envergure.
• Un bon PRA peut être très rapide à mettre en œuvre pour une bascule en 4h à 8h en 24/7. C’est une solution qui a le mérite de la simplicité, elle est économique et robuste à partir du moment où elle est bien maintenue et testée régulièrement.

Chez Alfa-Safety, nous avons une véritable expérience et pratique du PRA. Nous avons des clients importants qui fonctionnent sans PCA, avec un PRA, mais nous savons tenir pour eux sur nos infrastructures des délais de reprise en 4 heures calendaires. Pour tout savoir sur les architectures avec PRA sur notre cloud Alfa-Safety, retrouvez  ici notre page dédiée au sujet sur notre site web.

N’attendez pas qu’un incident survienne pour agir : contactez-nous pour discuter de la solution adaptée à vos besoins.