Azure : parcours cloud et Azure DevOps 2026

Azure est la plateforme cloud Microsoft : calcul, réseau, stockage, identité et observabilité. Azure DevOps Services est la plateforme SaaS de livraison (Boards, Repos, Pipelines, Artifacts) accessible via https://dev.azure.com/<org>. Ce hub /azure/ est l’entrée umbrella 2026 : cloud Azure + parcours Azure DevOps, sans remplacer le hub dédié /azure-devops/ déjà publié et validé QA.

Sur DevOps Elastic Hayway, l’objectif n’est pas une checklist de captures d’écran. C’est un parcours : comprendre le SDLC, sécuriser l’identité (Microsoft Entra ID, ex‑Azure AD), configurer l’organisation et les projets, planifier avec Boards, versionner avec Repos/Git, industrialiser le pipeline CI/CD, déployer avec Bicep (prioritaire sur ARM), puis observer avec Azure Monitor — le tout en région lab canadacentral et Free tier quand c’est possible.

Pour qui (et pour quoi)

• Débutants cloud / DevOps qui veulent un fil rouge FR autour d’Azure plutôt qu’une playlist dispersée
• Développeurs qui doivent brancher backlog, dépôt Git et pipeline YAML vers App Service, Container Apps ou AKS
• Ops / SRE qui industrialisent identité Entra, agents, OIDC, Bicep et Monitor sans inventer une usine à gaz le premier jour
• Candidats AZ‑400 qui relient certification, méthodologie SDLC et labs pratiques canadacentral

Vous n’avez pas besoin d’un abonnement Azure payant pour découvrir Boards et Repos : le Free tier Azure DevOps suffit pour l’organisation, le projet et un volume raisonnable de minutes hosted. Dès que vous déployez du compute, passez en lab jetable canadacentral avec alertes budgétaires — tout ce qui tourne hors Free ADO peut facturer.

Azure cloud ≠ Azure DevOps (mais les deux se parlent)

Beaucoup de tutoriels mélangent encore les vocabularies. Microsoft Azure est le cloud (abonnements, resource groups, Entra ID, App Service, Monitor). Azure DevOps Services est la forge logicielle SaaS (organisation, projet, Boards, Repos, Pipelines). Un service connection OIDC relie le projet ADO à l’abonnement Azure sans coller un secret longue durée dans le YAML. Ce hub umbrella oriente vers les deux mondes ; le détail Boards→Pipelines→Bicep reste dans Azure DevOps et la catégorie Azure DevOps.

Scope exclusif : Azure DevOps Services (SaaS, dev.azure.com) — pas Azure DevOps Server on‑prem. Concepts proches, identité et patching différents.

Prérequis et Free tier 2026

• Compte Microsoft ou Entra ID avec MFA (Conditional Access si disponible)
• Bases Git / YAML utiles mais pas obligatoires au départ — le hub Git et la leçon Git DVC couvrent le socle
• Budget : Free tier ADO pour org, Boards, Repos et minutes hosted raisonnables
• Ressources Azure à part en canadacentral + alertes budgétaires avant le premier déploiement coûteux
• Socle OS recommandé : Linux ; conteneurs : Docker puis Kubernetes

Parcours d’apprentissage Azure (leçons live)

Le parcours ci‑dessous reprend la grille mega‑menu Azure déjà publiée. Labels en français ; chemins inchangés. Suivez l’ordre fondations → identité → organisation → Boards → Repos → Pipelines & agents → releases & IaC → Monitor. Chaque lien a été vérifié HTTP 200 avant publication de ce hub.

01 — Fondamentaux, certifications et méthodologie

Avant de cliquer dans le portail, posez le cadre : introduction SDLC / DevOps, cartographie certification Azure DevOps (AZ‑400), vocabulaire Agile et panorama des outils. Cette étape évite de confondre « j’ai créé un projet » avec « je comprends le flux de valeur ».

1. SDLC & DevOps — introduction
2. Détails certification Azure DevOps (AZ‑400)
3. Azure DevOps — de quoi s’agit‑il
4. Outils Azure DevOps
5. Terminologie Agile
6. Hub Azure DevOps (pilier P4)
7. Catégorie Azure DevOps

02 — Identité Microsoft Entra ID

L’identité porte tout le reste. Microsoft Entra ID (ex‑Azure Active Directory) gère utilisateurs, groupes, MFA et Conditional Access. Ajoutez des utilisateurs AD, puis mappez‑les dans l’organisation ADO avec des permissions minimales. Sans cette étape, les labs « admin forever » deviennent une dette de sécurité.

1. Azure Active Directory (Microsoft Entra ID)
2. Ajouter des utilisateurs Azure AD
3. Ajouter des utilisateurs et définir les permissions

03 — Organisation, projets et processus

L’organisation est l’unité de facturation et de gouvernance. Le projet isole backlog, repos et pipelines. Les process templates (Agile recommandé pour les labs) et les équipes de projet structurent Area Paths / Iteration Paths. Configurez d’abord l’organisation, puis créez un projet Private Git Agile — c’est le socle de tout tutoriel suivant.

1. Processus de projet Azure
2. Organisation et sa configuration
3. Projets Azure
4. Équipes de projet

04 — Azure Boards (planification & sprints)

Boards n’est pas un Kanban cosmétique : c’est le système de work items (Epic, Feature, User Story, Task, Bug) qui trace la valeur. Lier un commit ou une PR à un work item transforme le sprint en preuve d’audit. Les labs Boards et Sprint montrent le flux réel : backlog → sprint board → done, avec capacité et burndown.

1. Azure Boards
2. Lab Azure Boards
3. Lab Sprint Azure

05 — Repos et Git (versionnement)

Azure Repos impose Git pour les labs modernes (évitez TFVC). Branch policies sur main (reviewers, build validation, work item linked) évitent le push direct en prod. Les pull requests sont le point de contrôle qualité avant le YAML. Si vous venez de GitHub, le modèle mental est familier ; les permissions et service hooks diffèrent légèrement. Renforcez le socle avec le tutoriel Git DVC du site.

1. Azure Repos
2. Git — système de contrôle de version distribué
3. Jenkins avec Azure Repos

06 — Pipelines, agents et CI/CD

Cœur de la livraison : pipelines classic et YAML, CI/CD depuis GitHub, agents Microsoft‑hosted versus self‑hosted. Préférez le YAML versionné dans le dépôt. Microsoft‑hosted (ubuntu-latest) pour démarrer vite ; self‑hosted quand vous avez besoin d’outils privés, d’accès réseau restreint ou de caches lourds. La leçon self‑hosted est volontairement détaillée — c’est souvent là que les labs « cassent » en entreprise.

1. Concepts de pipeline CI/CD
2. Azure Pipelines
3. Azure Pipeline avec GitHub
4. Agents Microsoft‑hosted
5. Agents self‑hosted

07 — Releases & IaC (Bicep > ARM)

Le passage CI → CD avec gouvernance humaine : pipelines de release, portes d’approbation, scénarios Web App. Côté infrastructure as code, Bicep est prioritaire sur ARM pour tout nouveau lab. La leçon ARM reste le pont pour lire les exports du portail et l’existant. Déployez depuis un pipeline avec OIDC / Workload Identity Federation — jamais un secret longue durée dans le YAML.

1. Pipeline de release Azure
2. Templates ARM (pivot Bicep)

Chaîne maillée typique : Repos → Pipelines YAML → image Docker → déploiement App Service / ACA / Kubernetes via OIDC → Bicep pour le socle infra → Azure Monitor. Terraform reste un voisin utile (hub Terraform) ; ici le fil rouge Microsoft reste Bicep.

08 — Monitoring Azure

Un pipeline vert ne prouve pas que l’app survit la nuit. Azure Monitor relie métriques, journaux d’activité et alertes. Apprenez à distinguer un échec d’infra d’un bug applicatif, et à poser des alertes actionnables plutôt qu’une pluie de mails. Clôturez chaque projet de déploiement par une passe observabilité.

1. Monitoring Azure

Architecture en une minute : identité → org → OIDC

L’identité (compte Microsoft ou Entra ID avec MFA) porte l’organisation. L’organisation gère billing, users et policies. Le projet contient backlog, repos et pipelines. Les service connections OIDC relient le projet à Azure sans coller un secret dans le YAML. Snapshot mental à garder pour chaque tutoriel.

Entra ID / Microsoft (MFA)
  └── Organisation ADO
        └── Projet (Agile, Git, Private)
              ├── Boards · Repos · Pipelines · Artifacts
              └── Service connections (OIDC → Azure canadacentral)

Bonnes pratiques jour 1

• MFA + Conditional Access ; projet Private ; process Agile
• Pipelines YAML versionnés dans Git ; démarrer en Microsoft‑hosted (ubuntu-latest)
• Secrets : Variable groups + Key Vault ; OIDC vers Azure plutôt que PAT longue durée
• Bicep > ARM pour le nouveau code ; branch policies + PR sur main ; lier les work items aux commits
• Lab Azure : région canadacentral + alertes budget avant le premier déploiement coûteux
• Ordre recommandé : fondations → Entra → organisation → Boards → Repos → YAML → agents → release → Bicep → Monitor

Quick start (10 minutes)

1. Activez la MFA sur le compte d’identité avant de créer quoi que ce soit.
2. Ouvrez dev.azure.com → Create organization (nom stable).
3. New project ado-lab : Private · Git · process Agile.
4. Vérifiez Boards, Repos, Pipelines et Artifacts dans le menu latéral.
5. Suivez le tutoriel Organisation et configuration, puis revenez à ce hub.

az extension add --name azure-devops
az devops configure --defaults organization=https://dev.azure.com/<ORG> project=ado-lab
az devops project list -o table

Ce que vous saurez faire

Comment utiliser ce hub

Lisez dans l’ordre 01 → 08 pour une première base Azure, ou sautez à l’étape qui bloque votre projet. Chaque lien dsh-path ouvre un tutoriel déjà publié. Le hub /azure-devops/ reste le pilier P4 détaillé ; /azure/ est l’umbrella mega‑menu et l’entrée SEO.

Sur mobile, privilégiez fondations → Entra → organisation → Boards avant Pipelines et Bicep. Ensuite élargissez : DevOps, AWS (comparatif cloud), Terraform (IaC multi‑cloud).

Continuer sur le site

FAQ

Quelle différence entre /azure/ et /azure-devops/ ?

/azure/ est le hub umbrella cloud + Azure DevOps (mega‑menu, SEO, maillage). /azure-devops/ est le hub pilier P4 détaillé Boards → Repos → Pipelines → Bicep → Monitor. Les deux coexistent : commencez ici, approfondissez là‑bas.

Par où commencer concrètement ?

Intro SDLC / DevOps → Entra ID → Organisation → Boards → Repos → Pipelines. Puis hub Azure DevOps.

Faut‑il apprendre ARM avant Bicep ?

Non — Bicep d’abord pour tout nouveau projet. ARM reste utile pour lire les exports : commencez par Templates ARM comme pont, puis écrivez le nouveau code en Bicep.

Le Free tier suffit‑il pour apprendre ?

Oui pour créer une organisation, Boards, Repos et un volume raisonnable de minutes d’agents hosted. Le compute Azure (VM, App Service, etc.) facture l’abonnement séparément : posez des alertes budgétaires en canadacentral avant le premier déploiement.

PAT ou OIDC pour déployer vers Azure ?

PAT pour lab Git/CLI : courte durée, scopes minimaux, hors dépôt. Pour déployer depuis un pipeline : OIDC / Workload Identity. Évitez les secrets longue durée dans le YAML du pipeline.

Points clés

• Hub umbrella /azure/ + pilier /azure-devops/ : cloud Microsoft + forge ADO Services
• MFA avant l’org ; Free tier pour démarrer ; lab Azure en canadacentral
• Ordre : fondations → Entra → organisation → Boards → Repos → YAML → agents → release → Bicep → Monitor
• Bicep > ARM · OIDC > secrets longs · YAML > UI seule pour le code de pipeline
• Mega‑menu Azure entièrement maillé vers des tutoriels live HTTP 200

Commencer maintenant

1. Créer l’org + projet ado-lab (Private, Git, Agile)
2. Suivre Organisation et configuration
3. Enchaîner Boards puis Pipelines
4. Approfondir sur https://devopelastichayway.com/azure-devops/