1. INTERVENANTS

DJEBBOURI Younes
Architecte Azure et DevOps đŸš€đŸ’»âœš

2. PROBLÉMATIQUE

đŸŒȘ Et si ton infra tombait


Tu gĂšres des VMs, du PaaS, du stockage, peut-ĂȘtre des workloads critiques. Tout tourne bien.
Mais as-tu dĂ©jĂ  imaginĂ© ce qui se passe quand tout s’arrĂȘte sans prĂ©venir ?

Une mise à jour réseau qui dégénÚre, un opérateur qui supprime une ressource par erreur, une région Azure qui devient indisponible

Les causes sont multiples.
Et ce jour-lĂ , tu n’auras pas le temps de chercher la doc. Ce qu’il te faut, c’est un plan clair, testĂ©, maĂźtrisĂ©.

🎯 C’est lĂ  qu’interviennent le PRA (Plan de Reprise d’ActivitĂ©) et le PCA (Plan de ContinuitĂ© d’ActivitĂ©).

Ce ne sont pas juste des options qu’on active dans un portail Azure.
Ce sont des choix d’architecture, des scĂ©narios Ă  anticiper, et une orchestration Ă  prĂ©parer Ă  l’avance, bien avant que la panne ne survienne

3. FONDAMENTAUX (PRA vs PCA)

On entend souvent ces deux termes utilisĂ©s indiffĂ©remment, comme s’ils dĂ©signaient la mĂȘme chose.
Mais en réalité, le PCA et le PRA répondent à deux besoins trÚs différents

Le Plan de ContinuitĂ© d’ActivitĂ© (PCA)

Le PCA, c’est ce qui Ă©vite que ton service tombe.
C’est de la rĂ©silience intĂ©grĂ©e Ă  ton architecture : on anticipe, on redonde, on absorbe les chocs

🎯 Objectif : continuer Ă  fonctionner malgrĂ© un incident.

Dans Azure, ça peut vouloir dire :

  • DĂ©ployer en multi-zones pour survivre Ă  la perte d’un datacenter
  • RĂ©partir la charge entre plusieurs rĂ©gions avec Traffic Manager ou Front Door
  • Utiliser un cluster PaaS en gĂ©o-rĂ©plication active (Azure SQL, Cosmos DB
)

📌 Le PCA, c’est proactif : tu prĂ©pares ton infra pour ne jamais t’arrĂȘter.

Le Plan de Reprise d’ActivitĂ© (PRA)

Le PRA, c’est ce qui entre en jeu quand tu n’as pas pu Ă©viter la panne

🎯 Objectif : reprendre rapidement l’activitĂ© aprĂšs un arrĂȘt complet ou partiel

LĂ , on parle de :

  • Restaurer une VM depuis une sauvegarde (via RSV)
  • Basculement orchestrĂ© vers un site secondaire (via ASR)
  • RĂ©tablissement manuel ou semi-automatisĂ© de services critiques

📌 Le PRA, c’est rĂ©actif : il te permet de revenir en ligne proprement, avec un impact minimal sur les donnĂ©es et les utilisateurs

RTO ? RPO ? SLA ? Il faut parler la mĂȘme langue

Avant de dessiner des schĂ©mas ou de dĂ©ployer quoi que ce soit, il faut s’accorder sur les objectifs mĂ©tiers.

Le PRA/PCA ne commence ni avec ASR, ni avec une ligne Terraform.
Il commence avec un tableau blanc, et des questions simples :

  • Combien de temps l’activitĂ© peut-elle ĂȘtre interrompue ?
  • Combien de donnĂ©es peut-on se permettre de perdre ?
  • Quelle est la disponibilitĂ© cible du service ?
  • Quels engagements prend Azure sur les services utilisĂ©s ?

Recovery Time Objective (RTO)

⏱ Combien de temps suis-je prĂȘt Ă  attendre pour que mon systĂšme redevienne opĂ©rationnel ?

Exemples :

  • Site e-commerce → RTO 15 min (vente perdue = argent perdu)
  • Intranet RH → RTO 4h (impact modĂ©rĂ©, tolĂ©rance plus haute)

🎯 Le RTO dĂ©termine les outils qu’on va mobiliser :
👉 Orchestration automatique ? RedĂ©ploiement manuel ? Cluster actif/passif ?

Recovery Point Objective (RPO)

📉 Combien de donnĂ©es puis-je perdre sans que cela devienne critique ?

Exemples :

  • Base de donnĂ©es client → RPO 5 min (toute perte est critique)
  • Fichiers partagĂ©s d’archives → RPO 24h (peu d’écritures frĂ©quentes)

🎯 Le RPO influence directement la frĂ©quence de rĂ©plication ou de sauvegarde.

Service Level Agreement (SLA)

🔐 Engagement contractuel d’Azure sur la disponibilitĂ© d’un service.

Service AzureSLA Standard
Azure VM avec 1 instance99.9%
Azure VM dans un AS + 2 zones99.99%
Azure SQL avec geo-replica99.99%
Azure Storage RA-GRS99.99% lecture
Azure Front Door99.99% globalement
Azure Trafic Manager100%
⚠ Ces chiffres ne couvrent que la couche Azure.
Ils ne garantissent pas que ton application respecte ce mĂȘme niveau de dispo

Service Level Objective (SLO)

🧭 L’objectif interne, que tu te fixes vis-Ă -vis des mĂ©tiers.

Exemple :

  • L’équipe Cloud vise 99.95% de dispo pour un portail client.
  • L’équipe DevOps impose un RTO < 30 min pour toute app exposĂ©e.

🎯 Le SLO est plus exigeant que le SLA. Il est souvent contractualisĂ© en interne avec les mĂ©tiers.

🟱 RĂ©sumĂ© :
– Ton RTO guide la vitesse de reprise
– Ton RPO dĂ©finit la perte de donnĂ©es acceptable
– Le SLA, c’est ce qu’Azure promet
– Le SLO, c’est ce que toi tu dois garantir
👉 Et c’est en croisant les exigences mĂ©tiers avec les limites techniques qu’on bĂątit une vraie stratĂ©gie PRA/PCA.

Outils Azure dans une stratégie PRA / PCA

Azure fournit toutes les briques pour construire une stratégie de résilience solide.
Mais attention : c’est à toi de les assembler intelligemment, selon ton contexte, tes contraintes, et ton budget.

Voici les principaux outils à connaßtre et comment les utiliser dans une approche structurée PRA / PCA

Catégorie 1 : Sauvegarde & restauration

OutilRĂŽle principalDĂ©tails
Recovery Services Vault (RSV)Sauvegarde des VMs, fichiers, basesIntégration native avec Azure VM, Azure SQL, SAP HANA, etc.
Azure Backup CenterSupervision centraliséeVue globale multi-vaults, alertes, conformité
Snapshot managésRestauration rapide de disquesIdéal pour les sauvegardes à chaud ou hors RSV
Azure File Share BackupProtection des partages de fichiersCompatible avec Azure Files (Standard/Premium)
⚠ Retenir : les sauvegardes protĂšgent tes donnĂ©es, pas ton application dans son ensemble.

Catégorie 2 : Réplication & failover

OutilRĂŽle principalDĂ©tails
Azure Site Recovery (ASR)RĂ©plication des VM (Azure↔Azure ou OnPrem↔Azure)Orchestration, test plan, failover et fallback
Azure SQL Geo-ReplicationContinuité PaaS SQLActive/Passive ou Failover Group automatique
Azure Storage GRS / RA-GRSRedondance inter-régionRésilience sur les blobs, table, queues
Azure PostgreSQL / Cosmos DB DRRéplication PaaS managéeGeo-redundant avec bascule contrÎlée ou automatique
⚠ ASR est l’outil le plus complet pour IaaS, mais il ne couvre pas tout (ex : App Services, etc.).

Catégorie 3 : Routage & supervision multi-région

OutilRĂŽle principal DĂ©tails
Azure Front DoorRoutage mondial avec failover automatiqueIdéal pour apps web, supporte le health check
Azure Traffic ManagerDNS load balancingBascule conditionnelle basée sur la dispo régionale
Azure DNSGestion centralisée des zones DNSImportant pour basculer les endpoints rapidement
Application Insights / Log AnalyticsVisibilitĂ© temps rĂ©elAlerting + dĂ©tection d’anomalies (down, latence, etc.)
⚠ Le routage, c’est le point faible de 80% des plans PRA non testĂ©s.

Catégorie 4 : Orchestration & test

OutilRĂŽle principalDĂ©tails
Azure Automation / RunbooksExécution de tùches répétablesIdéal pour exécuter un scénario de bascule custom
Logic AppsOrchestration visuelle + intégration ITSMIntégration facile avec ITSM, Slack, Teams, etc.
Azure Chaos StudioSimulation d’incidentsInjection de pannes sur VM, rĂ©seau, etc.
Azure Blueprints / Bicep / TerraformRedéploiement infraEn cas de DR total, tu dois savoir reconstruire rapidement
⚠ Un PRA sans test rĂ©gulier = illusion de sĂ©curitĂ©.
La vraie maturitĂ©, c’est l’automatisation du test de reprise.

Idées reçues et piÚges fréquents

Un PRA/PCA mal pensĂ©, c’est souvent un faux sentiment de sĂ©curitĂ©.
Et ce n’est pas la technologie qui manque, c’est la connaissance des risques et le rĂ©alisme dans les choix.

Voici les erreurs les plus courantes qu’on voit en entreprise, mĂȘme dans des architectures cloud avancĂ©es.

“Azure garantit la haute disponibilitĂ©, je suis tranquille”

Pas tout à fait. Azure te garantit la disponibilité de ses services, pas celle de ton application.

  • Une rĂ©gion peut tomber (ex : incidents West Europe 2023).
  • Un service peut ĂȘtre partiellement dĂ©gradĂ© (ex : App Service plan bloquĂ©).
  • Un bug dans ton dĂ©ploiement n’est pas couvert par le SLA Azure.

🎯 C’est Ă  toi de concevoir une rĂ©silience applicative au-dessus des SLA Azure.

“On testera le failover en cas d’incident”

Erreur critique. Le test à froid, c’est trop tard.

  • Les DNS ne basculent pas automatiquement.
  • Le vault est peut-ĂȘtre incomplet.
  • Le script de relance a Ă©tĂ© modifiĂ© et plus personne ne le connaĂźt.
  • La rĂ©plication ne couvrait pas tous les disques.

🎯 Un PRA/PCA non testĂ© = un PRA/PCA inexistant.

“On veut 0 perte, 0 interruption, 0 impact
 et 0 coĂ»t”

Ça n’existe pas.
Chaque seconde de dispo a un coût. Chaque RPO plus bas consomme plus de ressources.

🎯 Le bon Ă©quilibre, c’est celui oĂč le risque mĂ©tier est alignĂ© avec le budget rĂ©el et la technologie maĂźtrisĂ©e

À retenir

  • Un PRA/PCA, c’est d’abord une dĂ©marche mĂ©tier avant d’ĂȘtre technique.
  • Sauvegarde ≠ reprise. SLA Azure ≠ continuitĂ© applicative.
  • Sans test, sans orchestration, et sans documentation claire, ton plan ne sert Ă  rien.

PROCHAIN ARTICLE

Dans cette seconde partie, on entre dans le concret đŸ’Ș :

Sauvegardes, réplications, orchestration :
tout ce qu’il faut pour bñtir un PCA IaaS solide, sans illusions.

Au programme :

  • Azure Backup / RSV : ce que ça protĂšge
 et ce que ça ne fait pas
  • Azure Site Recovery : architecture, bascule rĂ©gionale, piĂšges rĂ©els
  • Comment structurer un plan de reprise avec des VM, du rĂ©seau, et des dĂ©pendances
  • Pourquoi 90% des tests ASR Ă©chouent la premiĂšre fois (et comment Ă©viter ça)

🎯 Objectif : poser les fondations d’un plan PRA rĂ©aliste, adaptĂ© Ă  ton infra, et surtout testable.