Plan de Continuité et Kubernetes : résilience cloud pour PME canadiennes

Voici la question que personne ne pose lors de la migration cloud. Pas le CTO, pas le DevOps lead, et certainement pas le consultant qui vous vend la transformation numérique. La voici : "Si notre infrastructure cloud tombe complètement ce soir à 23h, dans combien d'heures nos clients peuvent-ils reprendre leur travail ?"

La plupart des PME canadiennes qui ont migré vers le cloud n'ont pas de réponse claire à cette question. Elles savent que leurs données sont "quelque part sur AWS" ou "dans Azure". Elles ont peut-être des snapshots automatiques. Mais un plan de continuité d'affaires (BCP) cloud testé, documenté, avec des objectifs de reprise chiffrés ? Rarement.

Ce billet — le dernier de notre série Cloud Journey — est le plus critique de tous. Parce que tout ce que nous avons construit ensemble depuis le B01 peut s'effondrer si vous n'avez pas de BCP solide. L'infrastructure as code, la sécurité Zero Trust, le multi-cloud, le FinOps — tout ça devient caduque si une panne majeure vous met hors service pour 48 heures.

BCP cloud : RTO et RPO — définir vos seuils selon votre business

Avant de parler technologie, deux métriques fondamentales que tout responsable technique doit connaître par cœur :

RTO — Recovery Time Objective : Le temps maximum acceptable entre le début d'une panne et la reprise complète du service. Si votre RTO est de 4 heures, votre infrastructure doit être en mesure de reprendre en moins de 4 heures, quoi qu'il arrive. Dépasser ce seuil a des conséquences mesurables : perte de revenus, pénalités contractuelles, atteinte à la réputation.

RPO — Recovery Point Objective : La quantité maximale de données que vous pouvez vous permettre de perdre, exprimée en temps. Un RPO de 15 minutes signifie que vos sauvegardes doivent être suffisamment fréquentes pour que vous ne perdiez jamais plus de 15 minutes de données. Un RPO de 24 heures signifie qu'une journée entière de transactions pourrait disparaître.

Comment définir ces seuils pour votre PME ? Par l'impact business :

• E-commerce / SaaS B2C : Chaque minute d'interruption = revenus perdus. RTO cible : 15-30 min. RPO : 5 min.
• SaaS B2B / Applications métier : Les clients tolèrent une interruption courte. RTO cible : 1-4 heures. RPO : 15-30 min.
• Outils internes / Back-office : L'interruption est gênante mais pas catastrophique. RTO cible : 4-24 heures. RPO : 1-4 heures.
• Services financiers / Santé : Réglementé. RTO et RPO imposés par les normes sectorielles (OSFI, PHIPA). Souvent < 4h et < 1h respectivement.

Une erreur classique : définir des RTO/RPO ambitieux sans évaluer le coût de l'infrastructure nécessaire pour les atteindre. Chaque 10x de réduction du RTO coûte approximativement 3x plus cher en infrastructure. Choisissez en connaissance de cause.

Stratégies de backup cloud : le tableau coût vs RTO

Il n'existe pas une stratégie de backup universelle. Voici les options principales, de la plus économique à la plus robuste :

Snapshots + cold backup : Coût minimal. Vous créez des instantanés réguliers de vos volumes et bases de données, stockés dans un bucket S3/Azure Blob. RTO : 4-24 heures (temps de restoration), RPO : dépend de la fréquence des snapshots. Adapté aux environnements non-critiques. Outil recommandé : AWS Data Lifecycle Manager, Azure Backup, ou Velero pour Kubernetes.

Cross-region replication : Vos données sont répliquées en temps quasi-réel dans une région géographique différente. Si ca-central-1 (Canada) tombe, vous basculez sur us-east-1. RTO : 30-120 min. RPO : 1-5 min. Coût additionnel : les frais de réplication cross-region (généralement 0,02$/GB). Pour les bases de données, utilisez RDS Multi-AZ ou Azure Database geo-replication.

Warm standby : Une infrastructure réduite mais fonctionnelle tourne en permanence dans une région secondaire. Elle reçoit les données en continu, mais traite peu ou pas de trafic. En cas de panne, vous "agrandissez" cette infrastructure (scale-out) et basculez le DNS. RTO : 15-60 min. RPO : 5-15 min. Coût : 20-40% de votre infrastructure principale.

Active-Active multi-région : Deux régions ou plus traitent le trafic simultanément via un load balancer global. En cas de panne d'une région, les autres absorbent automatiquement le trafic. RTO : < 5 min. RPO : < 1 min. Coût : doublez ou triplez votre infrastructure. Réservé aux applications critiques.

Kubernetes pour la résilience : ce que l'orchestration change vraiment

Kubernetes n'est pas juste un orchestrateur de conteneurs. C'est, correctement configuré, un système de résilience autonome qui résout des problèmes que vous passiez auparavant des heures à gérer manuellement.

Auto-healing : Si un Pod crashe, Kubernetes le redémarre automatiquement. Si un Node (VM) tombe, Kubernetes reschedule tous ses Pods sur les Nodes disponibles. Ce comportement est intégré, pas une option payante. Pour une PME, ça signifie que les pannes de niveau "serveur qui plante" sont gérées sans intervention humaine, souvent en moins de 2 minutes.

Rolling deployments : Les mises à jour se déploient progressivement, sans downtime. Kubernetes remplace les anciens Pods un par un, attend que le nouveau soit healthy avant de continuer. Si le nouveau Pod échoue son health check, le déploiement s'arrête automatiquement (rollout pause). Résultat : zéro downtime deployment pour vos updates applicatives.

Health checks proactifs : Définissez des livenessProbe et readinessProbe pour chaque application. La livenessProbe détecte si l'application est en vie (sinon → redémarrage automatique). La readinessProbe détermine si le Pod est prêt à recevoir du trafic (sinon → retiré du load balancer). Ces deux mécanismes éliminent la majorité des incidents de production liés aux états intermédiaires d'application.

Resource requests et limits : Kubernetes garantit à chaque Pod un minimum de CPU/RAM (requests) et l'empêche de consommer au-delà d'un maximum (limits). Fini les situations où une application "runaway" mange toutes les ressources du serveur et fait planter les autres. L'isolation est au niveau du kernel Linux via cgroups.

Architecture haute disponibilité : multi-AZ, load balancing, circuit breaker

La haute disponibilité n'est pas un état — c'est une architecture. Voici les piliers :

Multi-AZ (Availability Zones) : Déployez vos workers Kubernetes sur au minimum 2 zones de disponibilité de votre région cloud. Les AZs sont des datacenters physiquement séparés, avec alimentation et réseau indépendants. Une panne d'AZ (événement rare mais réel) n'impacte pas vos autres AZs. Coût additionnel : quasi nul, juste la duplication des ressources. Configuration : NodeAffinity + PodAntiAffinity dans vos manifests Kubernetes.

Load balancing applicatif : En front de votre cluster K8s, un load balancer distribue le trafic entrant. Sur AWS : ALB (Application Load Balancer) avec intégration AWS Load Balancer Controller pour K8s. Sur Azure : Azure Application Gateway. Sur GCP : Cloud Load Balancing. L'Ingress Controller (nginx-ingress ou Traefik) gère le routage interne au cluster.

Circuit breaker pattern : Inspiré de l'électronique, ce pattern protège votre système contre les pannes en cascade. Si un service dépendant (ex : API externe) commence à répondre lentement, le circuit breaker "ouvre" la connexion et renvoie une réponse dégradée plutôt que d'accumuler les timeouts. Implémentations pour K8s : Istio (service mesh complet) ou Envoy (plus léger). Pour les PME, la bibliothèque Resilience4j (Java) ou Circuit Breaker de Go offrent une implémentation applicative sans infrastructure supplémentaire.

Disaster Recovery cloud : Pilot Light, Warm Standby, Active-Active

Choisir la bonne stratégie DR, c'est trouver l'équilibre entre RTO cible et budget disponible :

Pilot Light (Veilleuse) : Seuls les composants critiques (base de données répliquée, images AMI/container à jour) sont maintenus dans la région DR. En cas de disaster, vous allumez le reste de l'infrastructure via Terraform et redirigez le DNS. RTO : 1-4 heures. C'est la stratégie recommandée pour les PME dont le budget DR est limité mais qui ont besoin d'un vrai plan. Coût mensuel typique : 5-15% de l'infrastructure principale.

Warm Standby : Une version réduite mais opérationnelle de votre infrastructure tourne en permanence dans la région DR. Quand la disaster frappe, vous scalez cette infrastructure au niveau production et basculez le trafic. RTO : 15-60 min. Recommandé pour les PME avec des SLAs clients contractuels. Coût mensuel : 20-40% de l'infra principale.

Active-Active : Les deux (ou plus) régions traitent du trafic en production en permanence. Le basculement est automatique et transparent pour les utilisateurs. RTO : < 5 min, souvent < 1 min. Nécessite une architecture applicative compatible (stateless, synchronisation distribuée des données). Réservé aux applications où une minute d'interruption coûte plus cher que l'infrastructure DR complète. Coût : 80-100% additionnel.

Tests de résilience : chaos engineering et fire drills

Un BCP non testé est une fiction. La vraie question n'est pas "avons-nous un plan ?" mais "avons-nous prouvé que ce plan fonctionne ?"

Chaos engineering : Introduire des pannes contrôlées en production (ou en staging) pour valider la résilience de votre système. Netflix a popularisé cette approche avec son Simian Army (Chaos Monkey, Latency Monkey, etc.). Pour les PME, LitmusChaos est l'outil open-source le plus accessible : il s'intègre directement avec Kubernetes et permet de simuler des pannes de Pods, de Nodes, des latences réseau, des erreurs de disque. Commencez par des expériences simples : tuer un Pod aléatoirement, simuler une latence de 200ms sur un service critique. Observez comment votre système réagit avant que la vraie panne le fasse pour vous.

Fire drills (Exercices de reprise) : Une fois par trimestre minimum, simulez un scenario de disaster complet. Coupez la région primaire dans votre lab (ou staging). Chronométrez le temps de reprise réel. Documentez les blocages (le DBA qui n'a plus accès au vault, le process de failover qui nécessite une intervention manuelle non documentée). Chaque fire drill révèle des gaps que votre documentation théorique ne voyait pas.

Runbooks : Documentez chaque procédure de reprise comme si vous deviez l'exécuter à 3h du matin, fatigué, sous pression. Les runbooks doivent être des listes de commandes copiables, pas des descriptions conceptuelles. Stockez-les dans votre git repo (accessibles même si votre Notion ou Confluence est down), et testez-les lors de chaque fire drill.

Conformité et BCP : exigences sectorielles canadiennes

En Canada, les exigences de continuité d'activité ne sont pas optionnelles dans plusieurs secteurs :

OSFI E-21 (Secteur financier) : La ligne directrice E-21 du Bureau du surintendant des institutions financières impose des exigences explicites de résilience opérationnelle, incluant la définition de RTO/RPO, les tests réguliers de reprise, et la documentation des dépendances critiques. Les institutions financières (banques, assureurs, coopératives de crédit) sous réglementation fédérale doivent démontrer leur conformité. Les fintechs travaillant avec ces institutions héritent indirectement de ces exigences via leurs contrats.

PHIPA (Secteur de la santé en Ontario) : La Personal Health Information Protection Act exige que les dépositaires d'informations de santé maintiennent des mesures de sécurité administratives, techniques et physiques pour protéger les données, incluant des plans de continuité pour assurer la disponibilité des données de santé. Une perte de données de santé suite à une panne non couverte par un BCP peut constituer une violation.

LPRPDE / Loi 25 (Fédéral + Québec) : La Loi sur la protection des renseignements personnels et les documents électroniques, et son équivalent québécois, imposent des obligations de notification en cas de "atteinte aux mesures de sécurité" ayant un risque réel de préjudice. Un incident cloud ayant entraîné une perte de données pourrait déclencher ces obligations. Avoir un BCP documenté et testé démontre la diligence raisonnable exigée.

Recommandation pratique : si vous êtes dans un secteur réglementé, faites réviser votre BCP par un conseiller en conformité. La documentation de vos RTO/RPO, de vos tests réguliers, et de vos procédures de notification constitue votre bouclier en cas d'audit.

Stack recommandée PME pour le BCP Kubernetes

Voici la stack que nous recommandons et utilisons chez BOTUM pour les PME ayant un cluster Kubernetes :

Velero (Backup Kubernetes) : L'outil de référence pour les backups de clusters K8s. Velero sauvegarde les ressources Kubernetes (Deployments, Services, ConfigMaps, Secrets) ET les volumes persistants (PVCs). Il supporte S3, Azure Blob, GCS comme destinations. Configuration type : backup toutes les heures, rétention 7 jours, snapshot quotidien avec rétention 30 jours. La restauration d'un namespace complet prend généralement < 10 minutes.

ArgoCD ou Flux (GitOps pour DR) : Votre cluster DR ne doit pas être configuré manuellement — il doit être synchronisé depuis votre git repo via GitOps. Si votre cluster primaire tombe, votre cluster DR est déjà à jour de votre dernière configuration. ArgoCD offre une UI intuitive, Flux est plus lightweight. Les deux s'intègrent avec Velero pour une stratégie DR complète. En cas de disaster : 1) Basculez le DNS vers le cluster DR. 2) ArgoCD/Flux a déjà déployé toutes vos applications. 3) Velero restaure les données.

Cloudflare (DNS Failover) : Cloudflare Load Balancing avec health checks permet de basculer automatiquement le DNS de votre région primaire vers votre région DR dès qu'un health check échoue. TTL configurable à 30 secondes pour une propagation rapide. Le plan Cloudflare Business (200$/mois) suffit pour la plupart des PME. Alternative moins chère : Route 53 Health Checks sur AWS.

Monitoring et alerting : Prometheus + Alertmanager pour les métriques K8s, avec alertes PagerDuty ou OpsGenie pour l'astreinte. Définissez des SLOs (Service Level Objectives) dans Prometheus et alertez quand vous approchez du seuil (ex : alerte à 99,9% disponibilité au lieu d'attendre la panne à 99,5%).

Cas concret BOTUM : incident prod, RTO atteint en 23 minutes

En novembre 2024, notre cluster K8s de production chez BOTUM a subi une panne majeure suite à une mise à jour de nœud mal orchestrée qui a corrompu l'etcd. À 14h37, les services applicatifs commencent à rendre des erreurs 503. À 14h41, l'alerte Alertmanager se déclenche. L'équipe est notifiée via PagerDuty.

Ce qui s'est passé :

• T+0 : Détection automatique via Alertmanager (etcd cluster unhealthy)
• T+4min : L'ingénieur d'astreinte confirme la corruption etcd via kubectl
• T+8min : Décision de basculement vers le cluster DR (Warm Standby)
• T+10min : Cloudflare DNS failover déclenché (TTL 30s)
• T+12min : ArgoCD sur cluster DR confirme que toutes les apps sont déployées et saines
• T+18min : Velero restore des dernières données (RPO : 8 minutes de données perdues)
• T+23min : 100% du trafic sur cluster DR, services opérationnels

Ce qui nous a sauvés : Le cluster DR était déjà synchronisé via ArgoCD depuis le même repo git que le cluster primaire. Nous n'avons pas eu à reconfigurer quoi que ce soit. Velero avait effectué un snapshot 8 minutes avant l'incident. Le runbook de basculement avait été testé lors du fire drill de septembre — l'ingénieur connaissait les commandes par cœur.

Ce qu'on aurait pu mieux faire : Nos alertes de pre-failure sur l'état de l'etcd auraient dû déclencher une intervention avant la corruption complète. Depuis, nous avons ajouté des alertes sur les métriques etcd_server_has_leader et etcd_disk_wal_fsync_duration. La prochaine panne similaire sera détectée 20 minutes plus tôt.

Coût de l'incident : 23 minutes de downtime partiel. Aucune perte de données client (RPO atteint). Impact business : négligeable. Sans le BCP : estimation 4-6 heures de downtime complet, perte de données potentielle, et une nuit blanche pour toute l'équipe.

Conclusion : Cloud Journey — fin de série, début de la résilience

Nous voilà à la fin de 18 billets qui ont couvert l'ensemble du parcours cloud d'une PME canadienne : de la première migration (B01) jusqu'à la résilience opérationnelle totale (B18). Nous avons traversé l'infrastructure as code, le finops, la sécurité Zero Trust, le multi-cloud, et maintenant la continuité d'affaires.

Si vous deviez retenir une seule chose de ce billet final : la résilience n'est pas un état que vous atteignez, c'est une pratique que vous exercez. Un BCP non testé n'est pas un BCP. Un cluster Kubernetes sans health checks n'est pas haute disponibilité. Un plan de DR sans fire drill régulier est une illusion de sécurité.

Commencez là où vous êtes. Si vous n'avez pas de Velero, installez-le cette semaine. Si vous n'avez pas de runbooks, écrivez-en un pour votre scenario le plus probable. Si vous n'avez jamais fait de fire drill, planifiez-en un pour le mois prochain. La résilience se construit étape par étape, pas en une seule nuit.

Merci d'avoir suivi cette série Cloud Journey. Les équipes BOTUM sont là pour vous accompagner dans chacune de ces étapes — de l'architecture au déploiement, de la conformité aux tests de résilience.