L'auditeur demande le plan de continuité. Vous produisez un document de 40 pages, signé en comité de direction. Il demande ensuite : quand avez-vous basculé en dernier sur la région de secours ? Jamais. Quel RTO avez-vous mesuré ? On ne sait pas. Le PCA existe — la capacité, non.
En hébergement, la continuité d'activité se joue à l'intersection de votre application, vos sauvegardes et les engagements de l'hébergeur (SLA, redondance, support incident). Un PDF conforme sans test mesuré ne protège ni vos utilisateurs ni votre responsabilité de traitement en cas de panne prolongée.
Document vs capacité : deux livrables distincts
Le document PCA décrit scénarios, rôles, contacts, priorités de services, critères de déclenchement. Indispensable pour la gouvernance.
La capacité prouve que vous pouvez effectivement reprendre : restauration mesurée, bascule réseau, accès admin de secours, communication client.
| Élément | Document | Capacité prouvée |
|---|---|---|
| Sauvegarde | Politique écrite | Restauration datée < RPO |
| Bascule | Schéma architecture | Test DNS / failover récent |
| Support | Numéro escalade | Ticket chronométré sur exercice |
| Données | Registre traitements | Jeu de test rechargé |
Un PCA non testé est une fiction réglementaire — utile en audit papier, dangereux en incident réel.
Scénarios crédibles en hébergement
Priorisez les ruptures plausibles plutôt que la catastrophe hollywoodienne.
Panne datacenter régional. Votre hébergeur bascule-t-il automatiquement ? Devez-vous restaurer vous-même sur une autre région ?
Ransomware avec chiffrement prod plus backups. Les copies immuables ou hors ligne sont-elles hors périmètre compromis ?
Erreur humaine (DROP, suppression bucket). Point-in-time recovery disponible ? Délai ?
Défaillance prestataire (faillite, résiliation brutale). Plan de réversibilité — voir Réversibilité cloud.
Pour chaque scénario : RPO/RTO cible, propriétaire, dépendance hébergeur, preuve du dernier test.
Ce que le contrat hébergeur doit clarifier
SLA de disponibilité ≠ continuité complète. Lisez les exclusions : maintenance, force majeure, attaques DDoS massives, responsabilité client sur backups.
Exigez : localisation primaire et secours, fenêtre de restauration support, priorisation incident « production down », accès temporaire en cas de perte d'identifiants.
Comparez les acteurs via l'annuaire en croisant SLA, régions et options snapshot — pas le slogan « haute disponibilité ».
Le sommet : la continuité se mesure en minutes, pas en pages
Décider et avancer sans angle mort
Choisissez un scénario réaliste — par exemple restauration complète du staging depuis backup — et chronométrez-le. Documentez les écarts par rapport aux RTO et RPO cibles, puis mettez à jour le PCA avec les résultats datés. Planifiez le prochain test annuel avant la fin de l'exercice. Croisez avec Preuve de restauration et le comparateur pour valider l'hébergeur.
Questions fréquentes
Un PCA fourni par l'hébergeur suffit-il pour un audit ?
Non. Son PCA couvre son infrastructure ; le vôtre couvre application, données, contacts et dépendance à ses SLA. Les deux documents se complètent.
Quelle différence entre RTO et RPO ?
RPO = perte de données maximale acceptable. RTO = délai maximal pour remettre le service en ligne. Les confondre fausse toute promesse de reprise rapide.
À quelle fréquence tester ?
Au minimum annuellement pour traitements sensibles ; après chaque changement majeur d'architecture ou de prestataire. Un test daté vaut plus qu'un PDF récent.
Le multi-région garantit-il la continuité ?
Pas sans réplication, bascule DNS testée et runbook documenté. Multi-région sans test = coquille vide plus chère.
Un PCA crédible tient en une phrase : le dernier test du [date] a restauré [service] en [durée] avec [perte de données].