Contexte
Jusqu’en 2026, la résilience du SI repose essentiellement sur le socle interne : le cluster hyperconvergé HPE Simplivity avec VMware HA, et des sauvegardes quotidiennes Veeam vers un stockage local et vers Azure Blob.
Ce socle couvre la panne matérielle. Il ne couvre pas le scénario où le site ou le cluster lui-même devient indisponible. Le rapport de synthèse cybersécurité de 2024 identifiait d’ailleurs l’étude d’un PRA comme un chantier restant ouvert.
En juillet 2026, j’ai ouvert ce chantier pour traiter ce scénario, avec une contrainte simple : un PRA doit être réellement déployable et son coût doit être arbitrable par la direction.
Rôle
- J’ai mené le projet seul, de l’analyse jusqu’à la maquette de reprise.
- J’ai rédigé le document de continuité et de reprise soumis à la validation de la direction.
- J’ai conçu l’architecture de reprise dans Azure et réalisé la maquette de bascule.
- J’ai industrialisé le déploiement de l’environnement de reprise en Terraform et Ansible.
- J’ai chiffré le dispositif en distinguant le coût permanent du coût déclenché au moment du sinistre.
Périmètre / fonctionnalités
- Liaison VPN entre le site et l’environnement de reprise Azure.
- Machine virtuelle Veeam hébergée dans Azure, chargée de récupérer les images de sauvegarde déjà déposées sur Azure Blob et de les redéployer en machines virtuelles Azure.
- Pré-provisionnement des éléments les plus lents et les plus sensibles à configurer en situation de crise : adressage IP public, passerelle VPN, réseau et règles associées, VM Veeam conservée sous forme de snapshot.
- Description de l’infrastructure de reprise en Terraform et configuration en Ansible, pour rejouer un déploiement reproductible plutôt que de reconstruire manuellement sous pression.
- Document de continuité et de reprise couvrant les scénarios retenus, le périmètre des services repris, l’ordre de reprise, le niveau de perte accepté et le coût associé.
Décisions / arbitrages
- Acheter du délai, pas de la capacité : j’ai choisi de payer par anticipation ce qui est le plus long et le plus risqué à configurer en situation dégradée, et de laisser en coût déclenché ce qui ne sert qu’au moment de la bascule. Le surcoût permanent reste contenu ; ce qui est acheté, c’est la vitesse de reprise.
- Snapshot plutôt que machine allumée : j’ai conservé la VM Veeam sous forme de snapshot pour éviter de payer toute l’année une machine dédiée à un usage exceptionnel.
- Réutiliser la chaîne de sauvegarde existante : j’ai construit la reprise sur le dépôt Azure Blob déjà alimenté par les sauvegardes quotidiennes, plutôt que d’ajouter une chaîne de réplication supplémentaire à maintenir.
- Infrastructure as Code : j’ai retenu Terraform et Ansible parce qu’un PRA qui n’existe que sur le papier ne se vérifie pas. Décrire l’environnement en code le rend testable hors crise et documenté par construction.
- Cloud d’abord, second site ensuite : une reprise sur un second site physique repose sur des mécanismes proches, mais demande davantage de temps et d’investissement. Je l’ai positionnée comme une étape ultérieure plutôt que comme un préalable.
- Niveau de service assumé et validé : j’ai fait valider par la direction un retour progressif des services à l’échelle de quelques heures, avec une perte de données bornée par la politique de rétention des sauvegardes. Le détail des objectifs de reprise reste interne.
Résultats / apports
- L’entreprise passe d’une absence de PRA à un dispositif de reprise réel, maquetté, documenté et dont le coût est chiffré.
- La résilience ne repose plus uniquement sur les serveurs virtualisés du site.
- L’environnement de reprise est redéployable à l’identique, ce qui permet de le tester sans attendre un sinistre.
- La direction dispose d’une lecture explicite du couple coût / niveau de service, et non d’un principe abstrait de continuité.
- Le dispositif est fonctionnel au dernier pointage documenté, en août 2026, et reste en cours d’affinage : élargissement du périmètre repris, campagnes de test de bascule et étude d’une reprise sur un second site.