Cours Azure — tenant, abonnements, Microsoft Entra ID, machines virtuelles, stockage, réseau, coûts et Azure CLI en lecture

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. expliquer la hiérarchie tenant, groupes d'administration, abonnements, groupes de ressources, ressources ;
2. expliquer le rôle de Microsoft Entra ID et le contrôle d'accès Azure RBAC (principal, rôle, étendue) ;
3. décrire une machine virtuelle Azure et les ressources qui l'accompagnent (et sont facturées) ;
4. décrire un compte de stockage, ses services et ses options de redondance ;
5. décrire un réseau virtuel, ses sous-réseaux et ses groupes de sécurité réseau ;
6. poser un budget et une alerte dans Cost Management, et lire l'analyse des coûts ;
7. utiliser l'Azure CLI en lecture pour inspecter un abonnement sans le modifier ;
8. supprimer proprement les ressources de test (groupe de ressources).

Prérequis

• Cours « Concepts du cloud » (IaaS, régions, zones, responsabilité partagée, coûts).
• Notions de réseau IP, de pare-feu et de ligne de commande.
• Aucun compte n'est requis pour lire. Pour pratiquer : un abonnement jetable dédié, aucun lien avec un usage professionnel, des données fictives, un budget posé avant la première ressource.

Parcours et chapitres

1. Tenant, abonnements et groupes de ressources

Faits tirés de « What is Azure Resource Manager? » (page du 2026-08-04) et du guide d'organisation du Cloud Adoption Framework (page du 2025-06-18) :

• Azure Resource Manager est la couche de déploiement et de gestion : toutes les demandes (portail, CLI, API, SDK) passent par lui, qui les authentifie et les autorise.
• Quatre niveaux d'étendue : groupes d'administration, abonnements, groupes de ressources, ressources. Les réglages (politiques, contrôle d'accès, budgets) descendent des niveaux supérieurs aux niveaux inférieurs.
• Un abonnement sert à séparer les environnements (développement, test, production) pour l'isolation et le suivi des coûts.
• Un groupe de ressources est un conteneur de ressources liées qui partagent le même cycle de vie (on les déploie, met à jour et supprime ensemble). Une ressource appartient à un seul groupe ; elle peut être déplacée.
• Un groupe de ressources a une région, où sont stockées les métadonnées ; ses ressources peuvent être ailleurs, mais il est recommandé d'utiliser la même région.
• Supprimer un groupe de ressources supprime toutes ses ressources.
• Les étiquettes (tags) décrivent et ventilent les coûts ; un groupe n'hérite pas ses étiquettes à ses ressources. Le nom d'une ressource ne peut pas être changé après sa création.
• Un abonnement est rattaché à un tenant Microsoft Entra : voir chapitre 2 (lien exact tenant-abonnement non relu sur une page dédiée : non vérifié).

2. Microsoft Entra ID et RBAC

Microsoft Entra ID est le service d'identité et d'accès dans le cloud de Microsoft : authentification, application de politiques, protection des utilisateurs, appareils, applications et ressources (page « What is Microsoft Entra? », du 2026-06-18 avec mise à jour 2026-09-08). Éléments utiles :

• Tout abonné à Microsoft 365, Azure ou Dynamics CRM Online utilise déjà Entra ID : chaque tenant est un tenant Microsoft Entra.
• Un annuaire reçoit un domaine initial de la forme <DOMAINE>.onmicrosoft.com ; des domaines personnalisés peuvent s'ajouter.
• Les niveaux de licence cités : Entra ID Free, P1, P2 (autres produits séparés). Le contenu de chacun est non lu.
• L'ancien nom du service (Azure Active Directory) n'est pas rappelé sur les pages lues : non vérifié.

Azure RBAC (page « What is Azure RBAC ? », mise à jour 2025-10-15) gère l'accès aux ressources Azure. Une attribution de rôle = trois éléments :

Autres faits : le modèle est additif (les permissions effectives sont la somme des attributions) ; les attributions sont transitives pour les groupes ; une attribution de refus bloque l'accès ; le service est gratuit et inclus dans l'abonnement.

3. Machines virtuelles

D'après « Overview of virtual machines in Azure » (page mise à jour le 2026-08-03) :

• Une machine virtuelle Azure donne la souplesse de la virtualisation sans acheter de matériel, mais le client reste responsable de configurer, de patcher et d'installer les logiciels (responsabilité IaaS).
• À réfléchir avant création : noms, région (elle fixe où sont stockés les disques), taille, nombre maximal de machines, système, configuration au démarrage, ressources associées.
• Ressources créées avec la machine, et facturées à part : réseau virtuel, carte réseau (pas de coût propre), adresse IP privée et parfois publique (facturée), groupe de sécurité réseau (gratuit), disque système et disques de données (facturés au tarif des disques managés), parfois une licence de système. Par défaut elles vont dans le même groupe de ressources.
• Facturation : un tarif horaire selon la taille et le système ; pour les heures partielles, seules les minutes utilisées sont facturées ; le stockage est facturé séparément.
• Quota par défaut mentionné : 20 cœurs de machines virtuelles au total par région et par abonnement, relevable par demande (valeur de la page à la date de consultation, changeante). Même avec quota, un déploiement peut échouer faute de capacité.
• Disponibilité : des zones de disponibilité garantissent la connectivité à au moins une instance 99,99 % du temps avec deux instances ou plus dans deux zones ou plus de la même région (engagement de la page, à relire).
• Disques managés : Azure gère les comptes de stockage ; on choisit taille et performance (Standard ou Premium).
• Stockage temporaire local de certaines tailles : données perdues à la désallocation ou à la suppression.
• SSH : Azure peut créer et stocker une paire de clés ; la clé privée reste chez vous ; sinon nom d'utilisateur et mot de passe.

4. Stockage

D'après « Storage account overview » (page mise à jour le 2026-07-16) :

• Un compte de stockage contient les objets de données : blobs, fichiers, files, tables. Il fournit un espace de noms unique, accessible par HTTP/HTTPS.
• Type recommandé pour la plupart des scénarios : Standard à usage général v2 ; il existe des types Premium (blocs, partages de fichiers, pages) à base de SSD. Le type d'un compte ne peut pas être changé après création.
• Nom : 3 à 24 caractères, chiffres et minuscules, unique dans tout Azure.
• Redondance : LRS (locale), ZRS (entre zones), GRS, RA-GRS, GZRS, RA-GZRS (géographique) ; disponibilité variable selon le type de compte et la région.
• Chiffrement côté service automatique pour toutes les données au repos.
• Services : Blob (objet), Files (partages SMB/NFS), disques managés (bloc, voir chapitre 3).
• Facturation selon région, type de compte, niveau d'accès (chaud, froid), capacité, redondance, transactions et sortie de données hors d'une région.
• Retirés ou en retrait : comptes classiques (retirés le 2024-08-31), usage général v1 (en retrait).

5. Réseau virtuel

D'après « What is Azure Virtual Network? » (page mise à jour le 2026-02-13) :

• Un réseau virtuel (VNet) est la brique de base du réseau privé dans Azure ; il permet aux ressources de communiquer entre elles, avec Internet et avec le site de l'entreprise.
• Par défaut, les ressources d'un réseau virtuel peuvent sortir vers Internet ; l'accès entrant exige une adresse IP publique ou un équilibreur de charge public.
• Filtrage : groupes de sécurité réseau (NSG), règles par adresse, port et protocole, entre sous-réseaux ; appliances virtuelles.
• Routage : Azure route par défaut entre sous-réseaux, réseaux connectés, site distant et Internet ; tables de routage personnalisées possibles.
• Connexions : appairage de réseaux virtuels (même région ou non), VPN point à site, VPN site à site, ExpressRoute (liaison privée, hors Internet), points de terminaison de service, Private Link.
• Un réseau virtuel et ses sous-réseaux couvrent toutes les zones d'une région.
• Le réseau virtuel est gratuit ; les ressources associées sont facturées.
• Pour déplacer une machine dans un autre réseau virtuel : la supprimer et la recréer (disques conservables).

6. Cost Management : budgets, alertes et analyse

D'après « Quickstart: Start using cost analysis » (page mise à jour le 2026-03-17 ; page du stockage pour les budgets) :

• Cost Management se consulte par analyse des coûts : vues intelligentes et vues personnalisables, ventilées par abonnement, groupe de ressources, ressource, service ; prévision ; export en CSV, Excel ou Power BI.
• Il faut au moins un accès en lecture ; un nouvel abonnement peut mettre 48 heures à apparaître. Cost Management n'est pas disponible pour certains types d'abonnement (classiques Cloud Solution Provider, parrainés).
• On peut créer un budget (mensuel, trimestriel, annuel) depuis l'indicateur « Budget », et configurer des alertes d'anomalie.
• Recommandation de la page : vérifier le coût chaque semaine, et chaque jour pendant la première semaine ou deux après un déploiement.
• Dans l'analyse, on peut ouvrir l'écran d'une ressource, d'un groupe ou d'un abonnement pour arrêter ou supprimer des ressources et éviter des frais.
• Le crédit d'un abonnement (prépaiement, plans) n'apparaît pas toujours dans l'analyse.

Procédure recommandée, avant toute ressource :

1. créer un budget mensuel bas sur l'abonnement de test ;
2. configurer des alertes (seuils sur le réel et la prévision) vers une adresse surveillée ;
3. étiqueter chaque ressource (projet=test) ;
4. ouvrir l'analyse des coûts à J+1 et J+2.

7. Azure CLI en lecture seule

La page « What is the Azure CLI? » (2026-09-01) décrit un outil multiplateforme (Linux, macOS, Windows, Docker, Cloud Shell) ; sortie en JSON par défaut (--output table pour la lisibilité) ; version courante 2.91.0 à la date de consultation. L'installation modifie le poste et n'est pas détaillée ici.

Étape 1 — connexion (action à effet local)

az login

• Contexte : Azure CLI récent ; sur macOS, connexion par navigateur. L'authentification multifacteur est exigée pour les identités d'utilisateur.
• Droits : un compte Entra de test ; aucun rôle particulier pour se connecter.
• Effet : ouvre le navigateur et stocke localement des jetons d'actualisation (refresh tokens) ; propose de choisir un abonnement par défaut.
• Vérification : la liste des abonnements s'affiche puis az account show répond.
• Retour arrière : az logout ; az account clear vide le cache des abonnements.

Étape 2 — savoir où l'on est (avant toute autre commande)

az account showaz account list --output table

• Contexte : après az login.
• Droits : aucun droit particulier.
• Effet : lecture. La sortie contient l'identifiant d'abonnement et du tenant : les traiter comme sensibles (ni message, ni dépôt, ni capture, ni prompt).
• Vérification : l'abonnement actif est bien celui de test ; sinon s'arrêter (az account set change d'abonnement et n'a d'effet que local).
• Retour arrière : sans objet.

Étape 3 — inspecter (lecture)

az account list-locations --output tableaz group list --output tableaz resource list --resource-group <GROUPE-RESSOURCES> --output tableaz vm list --resource-group <GROUPE-RESSOURCES> --output tableaz storage account list --resource-group <GROUPE-RESSOURCES> --output tableaz network vnet list --resource-group <GROUPE-RESSOURCES> --output tableaz role assignment list --resource-group <GROUPE-RESSOURCES> --output table

• Contexte : Azure CLI 2.x, abonnement de test actif. Noms de sous-commandes d'après la structure de la référence CLI ; syntaxe exacte de chaque commande à confirmer dans la référence de la version installée.
• Droits : rôle Lecteur sur l'étendue interrogée. Une erreur d'autorisation est normale si le rôle est restreint : ne pas élargir le rôle pour « faire marcher ».
• Effet : lecture seule, aucune ressource créée ni modifiée. Les sorties contiennent des identifiants.
• Vérification : sur un abonnement neuf, les listes sont vides ; les emplacements listent les régions disponibles.
• Retour arrière : sans objet.

8. Création et suppression de ressources (à ne pas lancer sans validation)

Ces commandes servent à comprendre l'enchaînement et le retour arrière ; elles ne sont pas à exécuter dans le cadre du cours. Syntaxes à reconfronter à la référence de la version installée : non vérifié. La page CLI confirme l'existence de az group create et az storage account create avec ces paramètres de base.

Attention, effet notable. Cette commande peut créer ou modifier une configuration. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

az group create --name <GROUPE-RESSOURCES> --location <REGION>

• Contexte : abonnement de test confirmé par az account show ; région explicite.
• Droits : rôle permettant de créer des groupes de ressources (par exemple Contributeur sur l'abonnement).
• Effet : crée un conteneur vide, sans coût propre ; il stocke des métadonnées dans la région indiquée.
• Vérification : az group list --output table le liste.
• Retour arrière : supprimer le groupe (commande suivante).

Attention, effet notable. Cette commande peut créer ou modifier une configuration. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

az storage account create --name <NOM-COMPTE-STOCKAGE> --resource-group <GROUPE-RESSOURCES> --location <REGION> --sku Standard_LRS --kind StorageV2

• Contexte : groupe de test existant ; nom unique dans Azure, 3 à 24 caractères, minuscules et chiffres, sans information sensible (il apparaît dans les URL).
• Droits : rôle permettant de créer des comptes de stockage.
• Effet : crée un compte de stockage facturé à l'usage (capacité, transactions, sortie de données) ; son type ne pourra plus être changé.
• Vérification : az storage account list --resource-group <GROUPE-RESSOURCES> --output table.
• Retour arrière : supprimer le compte ou, plus simple, le groupe de ressources.

Attention, effet notable. Cette commande peut supprimer ou retirer des éléments. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

az group delete --name <GROUPE-RESSOURCES>

• Contexte : groupe de test, nom relu deux fois, aucune ressource utile à l'intérieur (lister avant avec az resource list --resource-group <GROUPE-RESSOURCES> --output table).
• Droits : rôle permettant de supprimer le groupe et ses ressources.
• Effet : supprime le groupe et toutes ses ressources, définitivement : données et disques compris. La demande de confirmation par défaut de cette commande n'a pas été relue (non vérifié) ; n'ajouter aucune option qui la supprime sans relecture.
• Vérification : az group list --output table ne montre plus le groupe ; le lendemain, l'analyse des coûts n'a plus de ligne croissante.
• Retour arrière : aucun : prévoir une sauvegarde avant.

9. Nettoyage des ressources de test

1. lister le contenu du groupe d'essai, vérifier qu'il ne contient rien d'utile ;
2. supprimer le groupe de ressources (supprime tout ce qu'il contient) ;
3. contrôler qu'aucune ressource d'essai n'a été créée hors du groupe (listes d'abonnement) ;
4. garder le budget et les alertes ;
5. le lendemain, rouvrir l'analyse des coûts : plus aucune ligne qui croît.

Exercices et vérifications de fin de cours

Tous sont sur papier ou en lecture seule.

1. Hiérarchie. Redessiner tenant, groupes d'administration, abonnement, groupe de ressources, ressource, et dire à quel niveau se posent budget, politique, rôle.
2. RBAC. Écrire la phrase « attribuer le rôle Lecteur au groupe <GROUPE> sur le groupe de ressources <GROUPE-RESSOURCES> » et nommer le principal, le rôle, l'étendue.
3. Machine virtuelle. Lister les ressources créées avec une machine et celles qui continuent de coûter si elle est éteinte.
4. Stockage. Choisir un type de compte et une redondance pour des sauvegardes de test, et justifier.
5. Réseau. Dire pourquoi une machine d'essai n'a pas besoin d'adresse publique.
6. Coûts. Définir un budget mensuel fictif, trois seuils d'alerte, et le calendrier de contrôle de la première semaine.
7. CLI. Pour chaque commande du chapitre 7, dire ce qu'elle lit et quel rôle suffit.
8. Nettoyage. Expliquer pourquoi supprimer le groupe de ressources suffit, et ce qu'il faut tout de même vérifier.

Critères de réussite

• Placer tenant, abonnement, groupe de ressources, ressource sur un schéma.
• Distinguer Entra ID (identités) et RBAC (accès aux ressources Azure).
• Savoir que supprimer un groupe de ressources supprime tout son contenu.
• Poser un budget et une alerte avant toute ressource, et savoir que l'alerte ne bloque rien.
• Lancer uniquement des commandes de lecture, après az account show.
• Savoir qu'aucun jeton, mot de passe ou secret de principal de service ne se range dans un fichier, un dépôt ou un prompt.
• Dire ce qui n'a pas été vérifié.