À la fin de ce tutoriel, vous saurez choisir et utiliser un agent Microsoft-hosted dans Azure Pipelines : pools, images (ubuntu-latest, Windows, macOS), variables d’agent, limites du Free tier, et bonnes pratiques pour économiser les minutes — sans secrets en clair.

Niveau : Débutant · Temps estimé : 35–50 min · Versions testées : Azure DevOps Services (portail 2026), Microsoft-hosted agents · Dernière vérification : 2026-09-10

Slug WP (menu live) : azure-devops-microsoft-hosted-agents (post ID 1045) · Slug tutoriel : azure-pipelines-agents-microsoft-hosted · Série : Azure DevOps P4 (ADO Services + Bicep) · Région lab Azure : canadacentral (hors provisioning agent ; région des labs Azure suivants)

Prérequis

• Azure Pipelines YAML : introduction : pipeline ado-lab-ci, azure-pipelines.yml sur main, au moins un run réussi
• Projet ado-lab + droits lecture Pipelines
• Notion Free tier ADO (#1) : minutes Microsoft-hosted limitées
• Budget : quelques minutes de run pour les expériences d’image

Coût estimé : 0 € hors quota Free. Les images Microsoft-hosted sont facturées en minutes d’agent (pas de VM Azure à votre charge pour ce mode).

Ce que nous allons construire

Organisation ADO
  └── Project ado-lab
        └── Pipeline ado-lab-ci
              ├── pool / vmImage (Microsoft-hosted)
              ├── Job sur ubuntu-latest (défaut lab)
              ├── (Option) job Windows / info image
              └── Observation : Agent.Name, Agent.OS, outils préinstallés
Free tier
  └── Suivi minutes + bonnes pratiques anti-gaspillage

(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « Pool Microsoft-hosted : images ubuntu-latest, windows-latest, macos et quotas Free ».)

Ce chapitre explique où tourne votre YAML. Microsoft-hosted : maintenance MS, VM fraîche par job (disque local non durable), pool Azure Pipelines, exécution sur VM ou conteneur. Suite (#8) : agent self-hosted si Free tier / outils custom / réseau privé.

Étape 1 — Hosted vs self-hosted en une minute

Critère	Microsoft-hosted	Self-hosted (#8)
Qui gère la VM	Microsoft	Vous
Patch OS / outils	Image mise à jour par MS	Votre responsabilité
Facturation lab	Minutes Free / payantes	Coût infra + 0 min hosted
Isolation run	VM éphémère par job	Machine partagée possible
Outils exotiques	Ce qui est sur l’image	Vous installez

Pour P4 débutant : Microsoft-hosted d’abord. Passez self-hosted si minutes épuisées, besoin réseau privé, ou logiciels absents des images.

Étape 2 — Pools et vmImage dans le YAML

Dans le portail : Project settings → Agent pools. Vous verrez notamment Azure Pipelines (pool Microsoft-hosted de l’org).

Dans le YAML (#6) :

pool:
  vmImage: ubuntu-latest

Équivalent explicite (souvent superflu en Services) :

pool:
  name: Azure Pipelines
  vmImage: ubuntu-latest

Images courantes (libellés « latest » = alias vers une version supportée ; Microsoft documente le mapping) :

vmImage	Usage lab typique
ubuntu-latest	Scripts bash, Docker, Node, .NET, Python, Bicep CLI souvent disponible ou installable
windows-latest	MSBuild, PowerShell Windows, certains SDKs Microsoft
macOS-latest	Builds Apple / Xcode (plus rare en lab ADO FR ; minutes souvent plus « coûteuses » selon offre)

Préférez ubuntu-latest pour la série P4 sauf besoin Windows explicite.

Étape 3 — Inspecter l’agent depuis un job

Ajoutez temporairement (branche feature) un step d’introspection :

# fragment à merger ou run sur feature — pas de secrets
trigger:
  - main

pool:
  vmImage: ubuntu-latest

steps:
  - script: |
      echo "Agent.Name=$(Agent.Name)"
      echo "Agent.OS=$(Agent.OS)"
      echo "Agent.Version=$(Agent.Version)"
      echo "Agent.MachineName=$(Agent.MachineName)"
      echo "Build.DefinitionName=$(Build.DefinitionName)"
      which git docker node npm python3 az bicep 2>/dev/null || true
      git --version
      docker --version || true
      node --version || true
    displayName: "Inspecter agent Microsoft-hosted"

cd ~/labs/ado-lab
git checkout -b feature/hosted-agent-inspect
# éditez azure-pipelines.yml avec le fragment ci-dessus
git add azure-pipelines.yml
git commit -m "ci: inspect Microsoft-hosted agent"
git push -u origin feature/hosted-agent-inspect

Créez une PR ou Run pipeline sur la branche. Dans les logs : OS Linux, outils préinstallés. Retirez ou réduisez ce step après observation pour alléger les runs.

Logiciels préinstallés : doc Microsoft « Software » par image (versions Node/Java évoluent — relisez la doc du jour). Portail job/agent : inventaire OS/outils (équivalent du lien software list) — basez vos steps dessus, pas sur votre laptop.

Jobs sur la VM ou en conteneur

Microsoft-hosted : job sur la VM (lab P4) ou en conteneur. Exemple :

pool:
  vmImage: ubuntu-latest
container: ubuntu:22.04
steps:
  - script: cat /etc/os-release | head -n 5
    displayName: "Smoke test container job"

VM + couche conteneur = éphémères après le job. Outils absents de l’image : container: documenté ou self-hosted (#8), pas d’installs lourds à chaque run Free.

Étape 4 — Multi-job / autre image (option pédagogique)

Pour comparer rapidement (consomme 2× minutes) :

trigger:
  - main

jobs:
  - job: Linux
    pool:
      vmImage: ubuntu-latest
    steps:
      - script: uname -a
        displayName: "uname Linux"

  - job: Windows
    pool:
      vmImage: windows-latest
    steps:
      - powershell: Write-Host $env:OS; Get-ComputerInfo | Select-Object WindowsProductName
        displayName: "Info Windows"

En lab Free : lancez une seule fois, puis revenez à un seul job ubuntu-latest pour #9. Les jobs parallèles multiplient la consommation.

Étape 5 — Limites Free et bonnes pratiques minutes

Vérifiez dans l’org : Organization settings → Billing / Parallel jobs (libellés UI 2026). Notes pédagogiques (valeurs indicatives — toujours confirmer dans le portail) :

• Org Free : souvent 1 parallel job Microsoft-hosted public projects vs constraints private ; minutes mensuelles plafonnées (ordre de grandeur historique ~1 800 min — vérifiez 2026).
• Files d’attente : si le parallel job est occupé, le run attend.
• Images macOS : parfois hors Free ou avec quotas distincts selon l’offre.

Économiser :

1. Triggers ciblés (main + pr: main) — pas toutes les branches.
2. Paths filters si monorepo plus tard (paths: include/exclude).
3. Éviter schedule agressifs en lab.
4. Steps d’install lourds : cache (#9+) plutôt que re-download systématique.
5. Ne pas laisser des runs « Debug » en boucle.
6. Self-hosted (#8) pour expérimentations chatty.

# Exemple filtre chemins (aperçu) — adapter aux dossiers réels
trigger:
  branches:
    include:
      - main
  paths:
    exclude:
      - docs/**
      - README.md

Étape 6 — Sécurité et éphémérité

• Chaque job Microsoft-hosted démarre en général sur une VM propre : disque local non durable entre runs.
• Ne stockez pas de secrets « pour le prochain run » sur l’agent ; utilisez Variable groups / Key Vault (#11) et service connections OIDC (#12).
• Les logs peuvent fuiter des variables mal marquées secrètes — revue avant merge.
• Images = surface d’attaque partagée gérée par Microsoft ; vous restez responsable du contenu du YAML et des credentials injectés.

Étape 7 — Vérification de fin de parcours

1. Agent pools → Azure Pipelines localisé.
2. ado-lab-ci sur vmImage: ubuntu-latest (ou choix justifié).
3. Run d’inspection : Agent.OS / outils visibles.
4. Billing / parallel jobs consultés (même Free).
5. Aucun secret dans le YAML ni les logs.

Nettoyage

• YAML minimal (préparation #9) ; Cancel les runs inutiles.
• Notez le quota restant hors Git public ; floutez les noms d’org sur captures publiques.

Lab bonus (8–10 min) — comparer une image et annuler un run

1. Branche feature/hosted-windows-once, pool uniquement :

pool:
  vmImage: windows-latest

2. Step PowerShell minimal :

steps:
  - powershell: |
      Write-Host "Agent.OS=$env:AGENT_OS"
      Get-ComputerInfo | Select-Object WindowsProductName
    displayName: "Inspect Windows hosted"

3. Run une seule fois ; notez la durée (cold start souvent plus long).
4. Revenez tout de suite à ubuntu-latest pour #9.
5. Run Windows en file → Cancel.

Scénario terrain

Minutes Free qui fondent (toutes branches + macOS oublié) → auditez Billing / Parallel jobs, restreignez trigger + paths, standardisez ubuntu-latest, réservez self-hosted (#8) aux outils custom / réseau privé. Notez le quota hors dépôt public.

Checklist anti-gaspillage hosted

1. Un seul vmImage justifié par pipeline (ubuntu-latest par défaut P4).
2. Pas de jobs: multi-OS en routine lab.
3. Cancel des runs en Waiting / inutiles.
4. Paths exclude pour docs/** si monorepo doc-heavy.
5. Pas de schedule cron agressif sur org Free.

Choisir l’image hosted sans se tromper

Le pool Azure Pipelines est le point d’entrée Microsoft-hosted de l’organisation : vous n’installez rien, vous choisissez une vmImage. En pratique P4, ubuntu-latest couvre bash, Git, Docker, Node et une grande partie des labs Bicep/CLI. Passez à windows-latest seulement pour MSBuild, installers Windows ou scripts PowerShell Desktop ; macOS-latest reste exceptionnel (Xcode / Apple) et peut consommer le Free tier plus vite.

Rappel issu de la page live : maintenance et upgrades sont gérés par Microsoft ; chaque job démarre sur une machine propre ; le filesystem local du job (checkout, npm install, artefacts temporaires) ne survit pas au job suivant. D’où l’intérêt des artefacts publiés, du cache pipeline et des Variable groups — jamais d’état « pour le prochain run » sur le disque de l’agent.

Quand un outil manque sur l’image du jour, trois leviers : un step d’install reproductible et court, un job container: avec une image maîtrisée, ou le basculement self-hosted pour le réseau privé / licences. Documentez le choix dans le README du lab pour éviter que chaque contributeur réinvente une image différente.

Erreurs fréquentes

Symptôme	Cause	Correction
No agent found / queue longue	Parallel jobs épuisés / pool faux	Billing ; pool correct ; attendre
Outil absent (bicep / version Node)	Image ≠ votre laptop	Install step (bash curl) ou autre image ; lire software list
Script bash échoue sur Windows	Mauvaise image	ubuntu-latest ou réécrire en PowerShell
Minutes Free à 0	Trop de runs / macOS / parallélisme	Pause ; self-hosted #8 ; réduire triggers
Confusion name vs vmImage	YAML pool incomplet	Pour hosted : vmImage sous pool Azure Pipelines
Image deprecated / introuvable	Alias retiré par Microsoft	Lire doc hosted agents ; basculer vers l’alias supporté
Cold start très long	Nouvelle VM / image lourde	Normal ponctuellement ; éviter multi-job inutiles
Variables Agent.* vides	Mauvais scope / typo	Utiliser $(Agent.OS) dans un step script/pwsh

Quiz (5 questions)

1. Que signifie vmImage: ubuntu-latest ? – A. Une VM Azure que vous facturez 24×7 dans canadacentral
– B. Une image d’agent Microsoft-hosted Linux (alias « latest ») pour exécuter le job
– C. Un conteneur AKS obligatoire

2. Pourquoi surveiller le Free tier avec les agents hosted ? – A. Parce que chaque run consomme des minutes et des parallel jobs limités
– B. Parce qu’Azure Boards facture à la Story
– C. Parce que Git refuse les commits sans billing

3. Après #7, quelle suite logique P4 ? – A. Agents self-hosted : installer et sécuriser un agent
– B. Supprimer azure-pipelines.yml
– C. Coller un vrai PAT dans les variables YAML

4. Pourquoi une VM Microsoft-hosted est-elle considérée éphémère ? – A. Parce que le disque local n’est en général pas durable entre deux runs
– B. Parce qu’elle est facturée 24×7 dans canadacentral
– C. Parce qu’elle remplace Azure Repos

5. Quel levier réduit le plus souvent la consommation de minutes en lab ? – A. Triggers / paths ciblés et un seul job utile
– B. Ajouter macOS + Windows en parallèle sur chaque commit
– C. Echo des PAT dans les logs pour « debug »

Réponses : 1‑B · 2‑A · 3‑A · 4‑A · 5‑A

Pour aller plus loin

• Doc : Microsoft-hosted agents, Agent pools, listes logiciels par image
• Suite : self-hosted (#8), CI build (#9), OIDC (#12)

Maillage série Azure DevOps (P4)

← Précédent	Azure Pipelines YAML : introduction et premier pipeline
→ Suivant	Self-hosted agents
Aussi	CI build · Service connections OIDC · Hub démarrer Azure DevOps
URL menu live	https://devopelastichayway.com/azure-devops-microsoft-hosted-agents/

---

Retour parcours Azure DevOps — hub de la série et leçons sœurs.