Politique de continuité d'activité
Cette politique décrit comment France Nuage maintient ses services disponibles pendant une perturbation et comment il les rétablit après un sinistre. Elle décline, sur le volet continuité, les principes de notre politique de sécurité de l'information et couvre les contrôles A.5.29, A.5.30 et A.8.14 de la déclaration d'applicabilité.
Nos contrôles sont auto-évalués, alignés sur ISO/IEC 27001, non certifiés par un tiers à ce jour. Le statut de chaque mesure ci-dessous reflète cette auto-évaluation.
Objet et périmètre
La politique couvre la disponibilité de la plateforme (console, API, interface en ligne de commande nuage), des services managés que nous opérons, et de l'infrastructure qui les porte dans nos trois datacenters français (Essarts-en-Bocage, Saint-Gilles-Croix-de-Vie et Nantes). Elle traite des perturbations d'origine technique, électrique ou environnementale, ainsi que de la perte d'un site entier.
Principes
- Résilience horizontale : la perte d'un datacenter est un événement prévu et non critique par conception plutôt qu'un scénario catastrophe. Ce parti pris est détaillé dans notre modèle de sécurité.
- La bascule se teste : un plan de reprise qui n'a jamais été exécuté n'est pas un plan. Nous testons la restauration et pas seulement la sauvegarde.
- Compensation assumée : un écart de renforcement sur un site donné est traité comme une mesure compensée par l'architecture, et déclaré comme tel (jamais masqué).
- Aucune dépendance à un hyperscaler : la reprise ne repose sur aucun fournisseur situé hors de notre contrôle.
- Dégrader plutôt que tomber : quand la capacité manque, un service rendu partiellement vaut mieux qu'une indisponibilité totale.
Mesures
| Domaine | Mesure |
|---|---|
| Redondance | Topologie multi-datacenters sur nos trois sites, réplicas de base de données et d'application en anti-affinité inter-zones (les répliques ne partagent pas le même site) et budgets de disruption (A.8.14). |
| Continuité pendant une perturbation | Bascule multi-datacenters appuyée sur des sauvegardes et une restauration testées, constituant notre dispositif de reprise opérationnel (A.5.29). |
| Préparation des TIC | Dispositif éprouvé par des restaurations régulières vers un environnement de contrôle et pas seulement décrit dans un document (A.5.30). |
| Sauvegardes externalisées | Copie des sauvegardes vers un stockage objet géographiquement distinct du site de production (A.8.13, détaillée dans la politique de sauvegardes). |
| Services supports | Onduleurs en place ; sur les sites dépourvus de groupe électrogène, une coupure secteur prolongée est traitée comme une perte de site tolérée, absorbée par l'architecture (A.7.11, partiel). |
| Capacité | Quotas et limites par espace de noms, avec alerting de saturation et de marge, pour que la reprise d'un site ne sature pas les autres (A.8.6). |
| Exploitation | Procédures d'exploitation documentées sous forme de runbooks et de commandes codifiées, utilisables sous stress (A.5.37). |
Responsabilités
- Le RSSI (François-Guillaume Ribreau) est responsable de cette politique et décide d'une bascule volontaire de site.
- L'astreinte exécute la bascule et la restauration en suivant les runbooks, et rend compte de l'écart entre le déroulé prévu et le déroulé réel.
- Chaque responsable de service maintient à jour le runbook de reprise de son périmètre ; un runbook non testé est traité comme une non-conformité.
- Toute anomalie constatée pendant un test de bascule est signalée à security@france-nuage.fr et suivie comme une action corrective.
Statut et trajectoire
La redondance, la continuité pendant une perturbation et la préparation des TIC sont en place et opérationnelles (A.5.29, A.5.30, A.8.14). Deux limites sont assumées. D'abord, les objectifs de reprise et de perte de données maximale admissible (RTO et RPO) par service ne sont pas encore formalisés ni publiés. La cadence quotidienne des sauvegardes et le seuil de fraîcheur surveillé en donnent aujourd'hui la borne pratique. Ensuite, plusieurs contrôles physiques restent partiels site par site (entrée physique, surveillance, services supports). Ils sont compensés par l'architecture multi-datacenters, et leur renforcement se poursuit site par site.
Revue
Cette politique est revue au moins une fois par an, après chaque test de bascule et à chaque évolution significative de notre topologie d'hébergement.
Dernière revue : 31 août 2026.
Voir aussi
- Déclaration d'applicabilité (le statut des contrôles A.5.29, A.5.30 et A.8.14)
- Politique de gestion des incidents (le traitement de l'incident qui déclenche la reprise)
- Politique de journalisation et de supervision (la détection d'une perturbation avant qu'elle ne devienne une perte de service)
- Infrastructure (datacenters, stockage et réseau qui portent nos services)