Le cloud sur lequel entreprises et États s’appuient.

Le cloud, c’est louer de l’informatique — serveurs, stockage, logiciels — par internet au lieu de la posséder. Microsoft exploite des centres de données dans le monde entier ; vous utilisez ce dont vous avez besoin et payez cela.

Trois modèles décrivent ce que Microsoft gère par rapport à vous :

• IaaS (Infrastructure) — vous louez des machines virtuelles nues et gérez le reste. Plus de contrôle.
• PaaS (Plateforme) — vous confiez votre appli ; il exploite les serveurs pour vous.
• SaaS (Logiciel) — vous utilisez un logiciel fini, comme Microsoft 365. Le moins de souci.

Acheter ses propres serveurs, c’est une dépense d’investissement (CapEx) — un gros paiement initial pour du matériel qu’on possède et entretient ensuite. Le cloud transforme cela en dépense d’exploitation (OpEx) — un coût courant qu’on paie à l’usage, comme l’électricité.

C’est le cœur business de l’examen AZ-900, et ce n’est pas que de la comptabilité. L’OpEx permet de démarrer tout petit, sans capital, et de ne payer plus que lorsqu’on grandit et qu’on gagne.

Azure est organisé en régions (zones géographiques de centres de données). Dans beaucoup de régions, il y a des zones de disponibilité — des centres physiquement séparés — pour pouvoir tourner sur plusieurs zones et survivre à la panne d’une seule.

Le modèle de responsabilité partagée est la règle à ne jamais oublier : Microsoft sécurise le cloud lui-même (bâtiments, matériel, réseau) ; vous êtes responsable de vos données, vos comptes et vos paramètres d’accès. Le partage glisse selon le modèle de service — plus de choses sont à vous en IaaS, moins en SaaS — mais vos données et identités sont toujours à vous à protéger.

Azure offre plusieurs façons d’exécuter du code, du plus de contrôle au moins de gestion :

• Machines virtuelles — des ordinateurs complets que vous contrôlez (IaaS).
• App Service — héberger un site ou une API ; Azure gère les serveurs (PaaS).
• Azure Functions — exécuter un petit bout de code sur événement, sans serveur (serverless).
• Azure Kubernetes Service (AKS) — Kubernetes géré pour les conteneurs.

Le savoir-faire est de choisir l’option la plus simple qui convient. Un site web standard va sur App Service, pas sur une VM à corriger vous-même.

Azure Storage contient vos données. Le cheval de bataille est le Blob Storage pour les fichiers — images, vidéos, sauvegardes — avec des niveaux hot, cool et archive qui arbitrent coût contre fréquence d’accès, comme les autres clouds.

Le réseau commence par le réseau virtuel (VNet) — votre réseau privé dans Azure. Les ressources à l’intérieur se parlent en privé, et vous ouvrez l’accès vers l’extérieur délibérément avec les groupes de sécurité réseau (NSG), qui font office de pare-feux.

Microsoft Entra ID (anciennement Azure Active Directory) est le service d’identité d’Azure — il gère qui sont vos utilisateurs et à quoi ils peuvent se connecter. C’est la porte d’entrée de tout.

Deux idées le portent : l’authentification (prouver qui vous êtes) et l’autorisation (ce que vous avez le droit de faire). La fonction de sécurité la plus importante qu’il offre est l’authentification multifacteur (MFA) — exiger une seconde preuve, comme un code sur le téléphone, au-delà du mot de passe.

Une bonne sécurité n’est pas un mur mais plusieurs — la défense en profondeur — pour que si l’un cède, les autres protègent encore. Azure fournit des outils à chaque couche : NSG et Firewall au réseau, Entra ID à l’identité, chiffrement pour les données, et Microsoft Defender for Cloud qui surveille le tout et note votre posture de sécurité.

Pour l’examen et la vraie vie, sachez que les données sont chiffrées au repos (stockées) et en transit (en mouvement) par défaut sur Azure — une base solide offerte.

Le RBAC est la façon de contrôler qui peut faire quoi dans Azure, bâti sur le moindre privilège : accordez à chacun uniquement l’accès que son travail exige. Vous assignez un rôle (un ensemble de permissions) à un utilisateur ou groupe, limité à une ressource, un groupe de ressources ou un abonnement précis.

La structure d’Azure garde les grands parcs propres : un abonnement est une frontière de facturation et de gestion ; les groupes de ressources regroupent des ressources liées pour les gérer et les supprimer ensemble ; les étiquettes (tags) sont des libellés (comme env=prod ou projet=academy) qui aident à suivre coût et propriété.

Azure Policy permet d’appliquer des règles automatiquement — par exemple « personne ne peut créer de ressources hors d’Europe » — pour que les erreurs soient empêchées, pas seulement constatées ensuite.

La plupart des services Azure sont en paiement à l’usage : vous payez ce que vous consommez — le calcul à la seconde, le stockage au gigaoctet, le transfert de données au gigaoctet. Les prix varient selon la région et le niveau de service.

Deux outils aident à planifier : la calculatrice de prix (estimer le coût d’une conception avant de construire) et la calculatrice du coût total de possession (TCO) (comparer le cloud à l’exploitation de ses propres serveurs). Utilisez la calculatrice de prix avant chaque vrai projet — deviner le coût du cloud est la façon dont les factures surprennent.

Le paiement à l’usage est flexible mais pas toujours le moins cher. Si vous savez que vous ferez tourner un serveur un an ou plus, une instance réservée vous y engage en échange d’une forte remise. Le bon dimensionnement, c’est choisir une VM adaptée au besoin réel, pas la plus grosse « par sécurité ».

Microsoft Cost Management montre où va réellement votre argent — par service, par groupe de ressources, par étiquette — et permet de poser des budgets avec alertes. Posez un budget dès le premier jour et laissez Azure vous envoyer un e-mail bien avant d’atteindre votre limite.

Un administrateur vit dans l’identité. Dans Entra ID vous créez des utilisateurs, les regroupez en groupes, et accordez l’accès au groupe — ainsi un nouvel arrivant obtient le bon accès simplement en rejoignant le groupe, et le perd en le quittant. C’est bien plus évolutif que des attributions personne par personne.

Vous ferez beaucoup de cela avec l’Azure CLI (az) — scriptable et reproductible — et Cloud Shell, un terminal dans le navigateur avec az prêt.

Au-delà de comprendre le RBAC, l’administrateur l’attribue correctement. Les règles pratiques : attribuer les rôles à des groupes, pas à des individus ; limiter au niveau le plus étroit qui fonctionne (groupe de ressources plutôt qu’abonnement) ; et auditer régulièrement les attributions pour retirer les accès devenus inutiles.

L’accès conditionnel (une fonction d’Entra ID) permet de poser des règles de connexion intelligentes : « exiger la MFA lors d’une connexion hors du bureau », ou « bloquer les connexions depuis des pays où nous n’opérons jamais ». Il applique la sécurité selon le contexte, et non une règle uniforme qui frustre tout le monde.

L’administrateur crée des VM à la bonne taille, image et disque, dans la bonne région, et sait les redimensionner quand les besoins changent. Vous choisissez une série de VM pour la charge (usage général, optimisée calcul, optimisée mémoire) et attachez des disques gérés pour le stockage.

Une seule VM est un point de défaillance unique. Pour la fiabilité, répartissez sur un groupe de disponibilité ou des zones de disponibilité pour qu’une panne matérielle ne vous arrête pas. Pour gérer une charge variable, utilisez un Virtual Machine Scale Set — un groupe de VM identiques qui grandit et rétrécit automatiquement avec la demande.

Associez un scale set à un équilibreur de charge et vous avez un système qui absorbe un pic de trafic puis redescend pour économiser quand c’est calme.

Tout ne devrait pas être une VM. App Service héberge applications web et API comme plateforme gérée — vous déployez du code ou un conteneur et Azure gère serveurs, correctifs, mise à l’échelle et certificat HTTPS. Pour les systèmes riches en conteneurs, Azure Container Apps ou AKS exécutent vos conteneurs gérés.

Les données vivent dans un compte de stockage, qui contient des blobs (fichiers), des partages de fichiers, des files et des tables. L’administrateur règle le niveau d’accès (hot/cool/archive), configure la redondance (combien de copies, et si elles sont inter-régions) et contrôle l’accès avec des jetons SAS — des clés à durée limitée qui accordent exactement l’accès nécessaire puis expirent.

Deux bases gérées couvrent la plupart des besoins. Azure SQL Database est du SQL Server géré — relationnel, familier, avec sauvegardes et haute disponibilité pris en charge. Azure Cosmos DB est une base NoSQL distribuée mondialement, pour les applis qui ont besoin de faible latence partout et de données flexibles.

Choisissez le relationnel (Azure SQL) pour des données structurées et liées (finance, inventaire) ; choisissez Cosmos DB quand vous avez besoin de portée mondiale et de documents flexibles (un catalogue produit servant plusieurs pays). Dans les deux cas, « géré » signifie exploiter une vraie base sans être un DBA à plein temps.

Un administrateur incapable de restaurer les données ne fait pas son travail. Azure Backup protège VM, bases et fichiers sur un planning, et Azure Site Recovery peut basculer tout un système vers une autre région en cas de sinistre.

L’administrateur conçoit le réseau : des VNets divisés en sous-réseaux, connectés entre eux par peering, protégés par des NSG, et nommés avec Azure DNS. Une conception réseau propre — des sous-réseaux séparés pour les niveaux web, appli et base — est à la fois plus sûre et plus facile à raisonner.

Pour connecter Azure à un bureau ou à un autre cloud, une passerelle VPN crée un tunnel sécurisé sur internet.

Azure Monitor rassemble métriques et journaux de tout ce que vous exécutez ; Log Analytics permet de les interroger ; les alertes vous préviennent quand un seuil est franchi. L’administrateur construit des tableaux de bord pour les signaux qui comptent et branche les alertes sur e-mail ou SMS — la même discipline des signaux d’or, native à Azure.

Cliquer dans le portail est bien pour apprendre ; la vraie administration, c’est l’infrastructure en code. Le langage IaC natif d’Azure est Bicep (une couche propre et lisible au-dessus des modèles ARM) — vous décrivez vos ressources dans un fichier, le versionnez dans Git, et le déployez de façon reproductible. Terraform marche aussi sur Azure, si vous préférez un seul outil pour tous les clouds.