Microsoft Azure : premiers pas et architecture pour bien démarrer

Avant de cliquer partout dans le portail Azure en espérant que ça marche, mieux vaut comprendre comment Microsoft organise ses briques : qui contient quoi, où sont physiquement les données, et comment structurer un compte pour ne pas se retrouver avec 40 ressources en vrac sans savoir laquelle facture quoi. Ce tutoriel pose les fondations théoriques et pratiques pour se lancer sereinement sur Azure.

La hiérarchie de gestion Azure

Azure organise tout selon une hiérarchie à quatre niveaux, du plus englobant au plus précis :

1. Le tenant (locataire Microsoft Entra ID)

C’est le sommet de la pyramide : une instance dédiée de Microsoft Entra ID (l’ex-Azure Active Directory), représentant votre organisation. Un tenant contient les identités (utilisateurs, groupes) qui peuvent ensuite se voir attribuer des droits sur les abonnements Azure.

2. Les groupes d’administration (Management Groups)

Ils permettent de regrouper plusieurs abonnements pour leur appliquer des règles communes en une seule fois : politiques de conformité (Azure Policy), attribution de rôles (RBAC), restrictions budgétaires. Typiquement utile dès qu’une entreprise gère plus de deux ou trois abonnements et veut éviter de configurer les mêmes règles autant de fois qu’elle a d’abonnements.

3. Les abonnements (Subscriptions)

C’est l’unité de facturation et le périmètre technique de base : chaque abonnement a ses propres quotas, sa propre facture, et sert souvent de frontière entre environnements (production / test / développement) ou entre projets. Les identifiants de zones de disponibilité, notamment, sont propres à chaque abonnement — deux abonnements différents peuvent numéroter leurs zones différemment pour une même région, à vérifier avant de concevoir une architecture multi-abonnements.

4. Les groupes de ressources (Resource Groups)

Un groupe de ressources est un conteneur logique qui rassemble les ressources d’un même projet ou d’une même application (VM, base de données, réseau virtuel…), pour les gérer, sécuriser et supprimer ensemble. Bonne pratique : tout ce qui a le même cycle de vie va dans le même groupe de ressources — supprimer le groupe supprime tout ce qu’il contient, ce qui est redoutablement pratique pour nettoyer un environnement de test… et redoutable tout court si on se trompe de groupe.

5. Les ressources

La brique de base : une VM, un compte de stockage, une base SQL, une application web, un réseau virtuel. Chaque ressource appartient à un seul groupe de ressources et existe dans une région précise.

Régions, paires de régions et zones de disponibilité

Azure est déployé dans plus de 60 régions à travers le monde, chacune étant une zone géographique contenant un ou plusieurs datacenters. Choisir la bonne région, c’est arbitrer entre la latence pour vos utilisateurs, la conformité réglementaire (souveraineté des données) et parfois le prix, qui varie d’une région à l’autre.

• Paires de régions (region pairs) : la plupart des régions sont associées à une région jumelle, généralement dans le même pays ou la même zone géopolitique, distante d’au moins quelques centaines de kilomètres. Microsoft coordonne les mises à jour de plateforme pour ne jamais mettre à jour les deux régions d’une paire simultanément, et priorise le rétablissement de l’une d’elles en cas d’incident majeur affectant plusieurs régions.
• Zones de disponibilité (Availability Zones) : à l’intérieur d’une région, il s’agit de regroupements logiques d’un ou plusieurs datacenters physiquement séparés, avec leur propre alimentation électrique, refroidissement et réseau. Elles sont généralement distantes de quelques kilomètres, dans un rayon de 100 km, pour offrir à la fois une faible latence entre elles et une réelle indépendance face à une panne locale (coupure électrique, incident réseau). Toutes les régions ne proposent pas de zones de disponibilité — c’est un point à vérifier avant de concevoir une architecture qui en dépend.

Les grandes catégories de services

Le catalogue Azure est large, mais la majorité des projets tournent autour de quelques familles :

• Calcul : machines virtuelles (Azure VM), conteneurs (Azure Container Apps, AKS pour Kubernetes), App Service pour héberger des applications web sans gérer de serveur, Functions pour du code déclenché à l’événement (serverless).
• Stockage : comptes de stockage (Blob pour les fichiers, Files pour du partage réseau, disques managés pour les VM).
• Réseau : réseaux virtuels (VNet), équilibreurs de charge, VPN Gateway et ExpressRoute pour relier votre réseau local à Azure, DNS.
• Bases de données : Azure SQL Database, Cosmos DB (NoSQL multi-modèle), Azure Database for PostgreSQL/MySQL.
• Identité et sécurité : Microsoft Entra ID, Key Vault pour les secrets/certificats, Defender for Cloud.
• Supervision : Azure Monitor, Log Analytics, Application Insights.

Étape 1 — Créer un compte

1. Rendez-vous sur la page d’inscription du compte gratuit Azure et connectez-vous avec un compte Microsoft (ou créez-en un).
2. Une vérification d’identité (téléphone, carte bancaire) est demandée — la carte sert uniquement à confirmer que vous êtes une personne réelle et à éviter les abus ; elle n’est pas débitée automatiquement au-delà des crédits gratuits sans action explicite de votre part.
3. Une fois le compte créé, un abonnement de type « Azure gratuit » ou « Pay-As-You-Go » (selon l’offre en cours) est provisionné, avec un tenant Entra ID associé automatiquement si vous n’en aviez pas déjà un.

Étape 2 — Premiers pas dans le portail

1. Connectez-vous sur portal.azure.com. Le tableau de bord est vide au départ — normal, rien n’a encore été créé.
2. Créez un premier groupe de ressources : menu Groupes de ressources → Créer, choisissez l’abonnement, donnez un nom explicite (par exemple « rg-test-webapp ») et sélectionnez une région proche de vous ou de vos utilisateurs.
3. Depuis ce groupe de ressources, cliquez sur Créer pour ajouter une première ressource — une machine virtuelle Linux ou Windows de petite taille (B1s) est un bon premier test, sans faire exploser le crédit gratuit.
4. Une fois la ressource déployée, explorez son Vue d’ensemble (métriques de base), son onglet Identity/Access (IAM) pour voir qui a accès, et son onglet Coûts le cas échéant.
5. Supprimez la ressource de test en supprimant directement le groupe de ressources qui la contient — un bon réflexe à prendre dès le début pour ne pas laisser traîner (et facturer) des ressources oubliées.

Étape 3 — Comprendre les rôles et les accès (RBAC)

Le contrôle d’accès basé sur les rôles (Azure RBAC) permet d’attribuer des permissions précises à un utilisateur, un groupe ou une application, à différents niveaux de la hiérarchie (tenant, groupe d’administration, abonnement, groupe de ressources, ou ressource individuelle). Un rôle attribué à un niveau élevé est hérité par tout ce qui se trouve en dessous — attribuer « Propriétaire » au niveau de l’abonnement donne donc les pleins pouvoirs sur tout ce qu’il contient, à manier avec la même prudence qu’un accès administrateur de domaine.

Bonne pratique de départ : donnez le rôle le plus restrictif possible au niveau le plus bas possible (par exemple « Contributeur » sur un seul groupe de ressources plutôt que sur tout l’abonnement), et élargissez seulement si le besoin se confirme.

Suivi et maîtrise des coûts

• Cost Management + Billing : suivez la consommation par abonnement, groupe de ressources ou service, et configurez des budgets avec alertes par e-mail avant de dépasser un seuil.
• Azure Advisor : suggestions automatiques pour redimensionner ou arrêter des ressources sous-utilisées.
• Pensez à éteindre (deallocate) les VM de test quand vous ne vous en servez pas — une VM arrêtée depuis le portail mais non désallouée continue d’être facturée pour le calcul, seul le disque cesse d’être le poste de coût principal.

Pour aller plus loin

Une fois cette structure comprise, les étapes naturelles suivantes sont d’explorer Azure Policy pour imposer des règles de gouvernance (régions autorisées, tags obligatoires…), Azure Resource Manager (ARM) templates ou Bicep pour déployer votre infrastructure de façon reproductible plutôt qu’en cliquant dans le portail, et les tags de ressources pour retrouver facilement qui a créé quoi et pourquoi, six mois plus tard, quand plus personne ne s’en souvient.