Microsoft AZ-900: Concepts du Cloud — Guide d'étude

By Laurynas Brazys · 22 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure AZ-900 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Le cloud computing fournit des ressources informatiques mesurées sur Internet avec un provisionnement rapide, une portée mondiale et une résilience intégrée. La migration d’une infrastructure sur site vers Azure modifie à la fois les choix technologiques et les modèles opérationnels : la planification de la capacité cède la place à la mise à l’échelle élastique, les dépenses d’investissement se transforment en dépenses opérationnelles, et la maintenance matérielle devient une responsabilité de la plateforme. Comprendre ces concepts est essentiel pour sélectionner les bons services, concevoir une architecture pour la disponibilité et maîtriser les coûts.

Caractéristiques principales du cloud : scalabilité, élasticité, agilité et résilience

La scalabilité (ou mise à l’échelle) est la capacité d’une charge de travail à gérer une demande accrue en ajoutant des ressources. Dans Azure, cela prend deux formes : la mise à l’échelle verticale (scale up) en choisissant des tailles de VM plus grandes ou des plans App Service supérieurs, et la mise à l’échelle horizontale (scale out) en ajoutant plus d’instances via Virtual Machine Scale Sets (VMSS), des pools de nœuds Azure Kubernetes Service (AKS), ou la mise à l’échelle automatique d’App Service. La mise à l’échelle dans la direction opposée réduit la capacité et les coûts lorsque la demande diminue. La conception de niveaux sans état (stateless) et l’externalisation de l’état (par exemple vers Azure Cache for Redis ou Azure SQL Database) rendent la mise à l’échelle horizontale prévisible et rapide. L’élasticité est une mise à l’échelle automatisée et pilotée par des politiques qui aligne en permanence la capacité sur la charge. Les règles de mise à l’échelle automatique d’Azure Monitor, l’autoscaler de cluster AKS et les options serverless telles qu’Azure Functions ou les plans Consommation/Premium élastique augmentent et réduisent les ressources en temps quasi réel. Les architectures élastiques minimisent la capacité inutilisée et sont bien adaptées aux charges de travail saisonnières ou avec des pics d’activité, alignant précisément les dépenses sur l’utilisation. L’agilité est la vitesse à laquelle les équipes livrent les changements. Le déploiement de ressources Azure via des modèles Bicep ou ARM, des pipelines GitHub Actions ou Azure DevOps, et des abstractions de ressources comme App Service ou AKS permettent des livraisons fréquentes et à faible risque. Le provisionnement en libre-service via le RBAC et les garde-fous de politique réduisent les temps d’attente tout en maintenant la gouvernance. L’agilité est le produit à la fois de la plateforme et des pratiques organisationnelles ; plus la plateforme abstrait les tâches lourdes et indifférenciées, plus les équipes peuvent avancer rapidement. La tolérance aux pannes et la reprise après sinistre traitent différentes étendues de défaillance. La tolérance aux pannes atténue les défaillances de composants et de datacenters au sein d’une région en utilisant les groupes à haute disponibilité (Availability Sets) (répartissant les VM sur des domaines de panne/mise à jour), les zones de disponibilité (Availability Zones) (des datacenters physiquement séparés au sein d’une région), des équilibreurs de charge et des chemins de données redondants. La reprise après sinistre prépare aux pannes au niveau de la région avec la réplication inter-régions (stockage GRS/RA-GRS, géo-réplication active Azure SQL, écritures multi-régions Cosmos DB) et des outils de récupération comme Azure Site Recovery. Définissez des objectifs clairs de RTO/RPO et testez le basculement pour vous assurer que la conception répond aux objectifs de continuité d’activité.

Modèles de service et responsabilité partagée

Les modèles de service cloud déterminent ce que vous gérez par rapport à ce qu’Azure gère. L’Infrastructure en tant que service (IaaS) expose les briques de base brutes de calcul, de stockage et de réseau. Vous contrôlez l’OS invité, le runtime et les applications — idéal lorsque vous avez besoin d’images personnalisées, de middleware spécialisé ou d’un contrôle total. La Plateforme en tant que service (PaaS) abstrait l’OS et une grande partie du middleware, fournissant des runtimes, des bases de données et des services d’intégration gérés pour que les équipes puissent se concentrer sur le code et les données. Le Logiciel en tant que service (SaaS) fournit des applications complètes consommées via un navigateur ou une API avec une configuration minimale et aucune obligation d’hébergement d’application. Le modèle de responsabilité partagée clarifie les frontières opérationnelles. En IaaS, Azure gère le datacenter physique, les hôtes et l’hyperviseur ; vous vous occupez des correctifs de l’OS, du durcissement, des mises à jour applicatives, de l’identité et des accès, et de la gouvernance des données. En PaaS, Azure gère également l’OS et le middleware de la plateforme ; vous gérez le code de l’application, la configuration et les données. En SaaS, Azure (ou le fournisseur SaaS) exploite l’ensemble de la pile ; vous gérez les utilisateurs, les accès, la classification des données et la configuration de l’utilisation. Dans tous les modèles, les clients conservent la responsabilité de l’identité, des autorisations, de la sécurité des points de terminaison et des politiques de protection des données. Le choix du bon modèle affecte les objectifs de disponibilité et les coûts. Le déploiement de machines virtuelles Azure est une tâche IaaS ; les API web sur Azure App Service ou les conteneurs sur AKS relèvent du PaaS ; Microsoft 365 et Dynamics 365 sont du SaaS. Privilégiez le PaaS et le SaaS lorsque c’est possible pour accélérer la livraison et réduire la charge opérationnelle, en réservant l’IaaS aux charges de travail qui nécessitent un contrôle au niveau de l’OS ou qui ont des dépendances héritées.

• IaaS
  • Services Azure typiques : Azure Virtual Machines, VM Scale Sets, Azure Disks, Virtual Network
  • Ce que vous gérez : OS invité, correctifs, runtime, applications, données, sauvegardes, AV/EDR
  • Quand choisir : Contrôle total de l’OS, middleware personnalisé, lift-and-shift
• PaaS
  • Services Azure typiques : Azure App Service, Azure SQL Database/Managed Instance, AKS, Azure Functions, Azure Integration Services
  • Ce que vous gérez : Code/configuration, schéma, données, identité et accès
  • Quand choisir : Livraison plus rapide, scalabilité/haute disponibilité intégrées, opérations réduites
• SaaS
  • Services Azure typiques : Microsoft 365, Dynamics 365, Power BI, Azure DevOps Services
  • Ce que vous gérez : Utilisateurs, rôles, utilisation/configuration des données
  • Quand choisir : Applications complètes avec une gestion minimale

Modèles de déploiement et portée de la mise à l’échelle

Le cloud public déploie des charges de travail dans des datacenters appartenant à Microsoft, partagés entre plusieurs locataires avec une isolation logique. Il offre le catalogue le plus large, une portée mondiale, un provisionnement rapide et un modèle purement « pay‑as‑you‑go » (paiement à l’utilisation). Le cloud privé dédie une infrastructure à une seule organisation, souvent pour des raisons réglementaires ou de souveraineté des données, et peut s’exécuter sur des piles validées par Azure telles que Azure Stack Hub ou Azure Stack HCI. Le cloud hybride connecte les environnements sur site (on-premises) et Azure avec une identité, des politiques et une mise en réseau cohérentes, permettant des migrations par phases et la localité des données tout en tirant parti de l’élasticité du cloud là où c’est pertinent. La mise à l’échelle globale par rapport à la mise à l’échelle locale concerne la portée des améliorations de disponibilité et de performance. La mise à l’échelle locale maintient le trafic à l’intérieur d’une région, en utilisant les Availability Zones, les VM Scale Sets, Application Gateway et Azure Load Balancer pour ajouter des instances et isoler les défaillances de datacenter. La mise à l’échelle globale répartit le trafic entre les régions en utilisant Azure Front Door (équilibrage de charge global moderne de couche 7 avec WAF, basé sur anycast), Azure Traffic Manager (équilibrage de charge basé sur le DNS) et des services de données géo-répliquées comme la géo-réplication Azure SQL ou la distribution multi-région de Cosmos DB. Les architectures multi-régions actif/actif améliorent la latence et la résilience, mais nécessitent une planification minutieuse de la cohérence des données et des coûts. Le choix d’un modèle de déploiement commence souvent par les contraintes de conformité et de connectivité et évolue avec le cycle de vie de l’application. Les nouvelles applications web « greenfield » (partant de zéro) atterrissent fréquemment dans le PaaS du cloud public pour la vitesse et l’évolutivité. Les systèmes métier complexes avec des dépendances peuvent commencer en mode hybride — en conservant certains services sur site tandis que les front-ends et les niveaux sans état (stateless) sont déplacés vers Azure — avant de terminer la transition à mesure que les dépendances sont modernisées.

• Public
  • Propriété/Emplacement : Régions appartenant à Microsoft
  • Accès typique : Internet/VPN/ExpressRoute
  • Cas d’usage : Mise à l’échelle élastique, portée mondiale, innovation rapide
  • Exemples Azure : La plupart des services Azure, Azure Front Door, Azure App Service
• Privé
  • Propriété/Emplacement : Infra dédiée au client (sur site ou hébergée)
  • Accès typique : Réseaux privés
  • Cas d’usage : Souveraineté, charges de travail isolées, conformité stricte
  • Exemples Azure : Azure Stack Hub, Azure Stack HCI, AKS on HCI
• Hybride
  • Propriété/Emplacement : Mélange de sur site (on-prem) et d’Azure
  • Accès typique : VPN de site à site ou ExpressRoute
  • Cas d’usage : Migration par phases, localité des données, intégration d’héritage (legacy)
  • Exemples Azure : Azure VPN Gateway, ExpressRoute, Azure Arc

Modèles de coûts : CapEx vs OpEx, tarification à la consommation, paiement à l’utilisation et capacité réservée

L’approvisionnement sur site (on-premises) est généralement une dépense d’investissement (CapEx) : des achats initiaux importants de serveurs, de stockage et de réseau, amortis sur plusieurs années. Azure inverse ce modèle pour en faire une dépense d’exploitation (OpEx) : les services sont mesurés et facturés en fonction de la consommation réelle — secondes de CPU, Go-mois, transactions — déplaçant les dépenses au moment où la valeur est réalisée. Cette tarification basée sur la consommation réduit le sur-provisionnement et lie les coûts aux modèles d’utilisation. Le paiement à l’utilisation (pay-as-you-go) maximise la flexibilité : démarrez et arrêtez les ressources à volonté sans engagement de durée. Pour les charges de travail stables, Azure propose des remises basées sur la réservation telles que les Reserved Virtual Machine Instances, la capacité réservée Azure SQL Database, les réservations de RU/s pour Cosmos DB et la capacité de stockage réservée. Des engagements d’un ou trois ans peuvent générer des économies significatives tout en permettant en option la flexibilité de la taille des instances et une portée partagée entre les abonnements. Les options complémentaires incluent les Azure Savings Plans for Compute, qui appliquent des tarifs réduits à l’ensemble des services de calcul éligibles, et les Spot VMs pour les charges de travail interruptibles de type batch, avec des remises importantes. Une gouvernance efficace des coûts associe le bon modèle commercial à des contrôles d’ingénierie. L’Autoscale réduit la capacité inutilisée ; les niveaux serverless éliminent l’infrastructure lorsqu’elle est inactive ; Azure Hybrid Benefit applique les licences Windows Server et SQL Server existantes ; la tarification Dev/Test réduit les dépenses hors production. Azure Cost Management + Billing fournit des budgets, la détection d’anomalies et l’allocation des coûts pour une optimisation continue.

• Paiement à l’utilisation (Pay-as-you-go)
  • Engagement : Aucun
  • Remise typique vs PAYG : 0 %
  • Flexibilité : Maximale ; démarrer/arrêter à tout moment
  • Idéal pour : Charges de travail imprévisibles ou de courte durée
• Reserved VM Instances / Capacité réservée
  • Engagement : 1 an ou 3 ans
  • Remise typique vs PAYG : Jusqu’à ~72 % (avec Azure Hybrid Benefit)
  • Flexibilité : Portée partageable ; échange autorisé ; frais d’annulation anticipée
  • Idéal pour : Calcul stable 24h/24 7j/7, bases de données, Cosmos DB
• Savings Plan for Compute
  • Engagement : Engagement de dépense sur 1 an ou 3 ans
  • Remise typique vs PAYG : Jusqu’à ~65 %
  • Flexibilité : S’applique aux VM, AKS, Functions Premium, App Service
  • Idéal pour : Calcul mixte avec des types d’instances variables
• Spot VMs
  • Engagement : Aucun (dépendant de la capacité)
  • Remise typique vs PAYG : Jusqu’à ~90 %
  • Flexibilité : Peut être évincé ; pas de SLA
  • Idéal pour : Traitements par lots (batch), sans état (stateless), CI, tâches de rendu

Cas pratique : PeakGear Retail : mise à l’échelle saisonnière avec maîtrise des coûts et résilience

Scénario : PeakGear Retail exploite un site de e-commerce avec des pics de trafic prévisibles en fin de mois et pendant les vacances. L’entreprise souhaite migrer ses VM sur site vers Azure, réduire les dépenses d’investissement, maintenir un objectif de disponibilité de 99,99 % pour le niveau web et mettre en œuvre un plan de reprise d’activité avec un RTO de quatre heures et un RPO de 15 minutes. La gestion des identités doit s’intégrer avec les utilisateurs existants via Microsoft Entra ID.

Défi : Concevoir une architecture et un modèle de coûts Azure qui permettent une mise à l’échelle élastique pour les pics de trafic, une tolérance aux pannes au niveau de la zone, une reprise d’activité inter-région et une simplicité opérationnelle, tout en minimisant les coûts pendant les périodes creuses.

Approche recommandée :

1. Déployer l’API web et la vitrine sur Azure App Service (PaaS) en utilisant des plans Premium v3 pour bénéficier de la mise à l’échelle automatique intégrée, de l’application de correctifs de plateforme gérée et des options de redondance de zone.
2. Placer deux instances App Service ou plus derrière Azure Front Door Standard/Premium pour un point d’entrée anycast mondial, la terminaison SSL, le WAF et le routage basé sur le chemin ; activer les sondes d’intégrité et l’affinité de session si nécessaire.
3. Utiliser Azure SQL Database Business Critical avec redondance de zone dans la région principale ; configurer la géo-réplication active vers une région secondaire jumelée en visant un RPO de 15 minutes.
4. Stocker le contenu statique dans Azure Storage avec RA-GRS ; le placer derrière Azure CDN from Microsoft pour décharger la bande passante et améliorer la latence.
5. Mettre en œuvre des règles de mise à l’échelle automatique basées sur le CPU, les requêtes et la profondeur de la file d’attente pour effectuer un scale-out pendant les pics et un scale-in pendant les périodes calmes ; pour les tâches en arrière-plan, utiliser les plans Azure Functions Consumption ou Elastic Premium.
6. Atteindre une disponibilité de 99,99 % pour le niveau web en activant la redondance de zone (multi-zone) pour le plan App Service ou en répartissant les instances sur plusieurs zones de disponibilité (Availability Zones) là où c’est pris en charge.
7. Adopter initialement le paiement à l’utilisation (pay-as-you-go) pour plus de flexibilité ; pour la capacité de base stable identifiée après 30 jours, acheter une instance réservée (Reserved Instance) d’un an pour les plans App Service (via un Savings Plan for Compute couvrant App Service) et de la capacité réservée pour SQL Database afin de réduire les coûts de fonctionnement.
8. Intégrer Microsoft Entra ID pour l’accès des utilisateurs et des administrateurs ; appliquer le principe du moindre privilège avec les rôles intégrés et l’accès conditionnel ; protéger les secrets dans Azure Key Vault, référencé par App Service et les pipelines de déploiement.
9. Définir et tester les procédures de reprise d’activité (runbooks) : basculer SQL vers la région secondaire, mettre à jour les priorités d’origine de Front Door pour activer la région secondaire, et valider la santé de l’application dans le respect d’un RTO de quatre heures.
10. Mettre en œuvre Azure Monitor et Log Analytics pour centraliser les métriques, les traces et les journaux ; configurer des alertes et des tableaux de bord ; définir des budgets et des alertes d’anomalie dans Azure Cost Management pour optimiser continuellement les dépenses.

Justification pour Azure : Les services PaaS (App Service et Azure SQL Database) maximisent l’agilité et déchargent la maintenance du système d’exploitation et de la plateforme dans le cadre du modèle de responsabilité partagée, tout en permettant la mise à l’échelle automatique pour l’élasticité. Le déploiement redondant interzone et la réplication multi-région assurent la tolérance aux pannes au sein d’une région et la reprise d’activité entre les régions, répondant ainsi aux RPO/RTO spécifiés. Front Door fournit une entrée globale, un routage basé sur l’état de santé et une protection WAF. Commencer avec le paiement à l’utilisation préserve la flexibilité pendant la migration ; s’engager sur de la capacité réservée ou un Savings Plan pour la ligne de base mesurée réduit les coûts pour une utilisation stable, tandis que la mise à l’échelle automatique réduit les dépenses pendant les périodes creuses. Microsoft Entra ID centralise la gestion des identités et des accès, et Azure Monitor avec Cost Management maintient une visibilité opérationnelle et financière.

Tous les domaines · Architecture Azure et infrastructure mondiale →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Microsoft →