Azure Project Processes

À la fin de ce tutoriel, vous saurez choisir le process Azure DevOps adapté à votre équipe (Basic, Agile, Scrum ou CMMI), lire les hiérarchies de work items, comparer les états de workflow, et vérifier le process d’un projet lab — sans supprimer l’existant, et sans secrets en clair.

Niveau : Débutant · Temps estimé : 35–50 min · Versions testées : Azure DevOps Services (portail 2026), process hérités (Inheritance) · Dernière vérification : 2026-09-12

Slug : azure-project-processes · Série : Azure DevOps (menu) · Lesson 6 / 31 · Région lab Azure : hors scope (0 € ADO Free tier)

Prérequis

• Organisation Azure DevOps + un projet lab (voir Azure Projects et organisation et composants)
• Bases vocabulaire agile : Agile terminology
• Droits Project Administrator (ou Owner org) pour inspecter Process / Team configuration
• Navigateur récent ; optionnel : Azure CLI + extension azure-devops

Coût estimé : gratuit (Boards / process templates sur Free tier). Aucune ressource Azure à facturer dans ce chapitre.

Ce que nous allons construire

Organisation ADO
  └── Process templates (hérités)
        ├── Basic   : Epic → Issue → Task
        ├── Agile   : Epic → Feature → User Story → Task (+ Bug, Issue, Test Case)
        ├── Scrum   : Epic → Feature → Product Backlog Item → Task (+ Bug, Impediment)
        └── CMMI    : Epic → Feature → Requirement → Task (+ Bug, Issue, Risk, Review)
Projet lab
  └── Project settings → Overview / Boards → Process visible
  └── Vérification hiérarchie backlog + états

(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « Quatre process Azure DevOps et leurs hiérarchies de work items ».)

Le contenu pédagogique d’origine (Basic, Agile, Scrum, CMMI et définitions des work items) est conservé et enrichi en français — jamais effacé. Les anciennes images hotlinkées Blogger ont été auditées (HTTP 200 au 2026-09-12) ; le corps enrichi privilégie tableaux et texte pour un rendu stable hors Elementor.

Étape 1 — Qu’est-ce qu’un process Azure DevOps ?

Un process (parfois appelé process template) définit le modèle de suivi du travail d’un projet Azure DevOps : types de work items, hiérarchie de backlog, états du workflow, et règles associées. Vous le choisissez surtout à la création du projet (Advanced → Work item process). Ensuite, Azure Boards (Azure Boards, labs Boards lab / Sprint lab) affiche Epic, Feature, stories, bugs, etc. selon ce modèle.

Sur Azure DevOps Services, le modèle courant est l’Inheritance : vous partez d’un process système (Basic / Agile / Scrum / CMMI) et pouvez le personnaliser (champs, états, règles) sans XML on-prem. Changer de process « pour voir » sur un backlog déjà rempli a un coût : types et états à mapper. Bon réflexe lab : un process par projet, cohérent avec le reste de la série.

Étape 2 — Basic process (conservé + enrichi)

Le process Basic offre la hiérarchie la plus courte. L’image classique du backlog Basic montre : les Issues et Tasks suivent le travail, tandis que les Epics regroupent le travail sous de plus grands scénarios.

• Epics — suivre des fonctionnalités ou exigences significatives (significant features or requirements).
• Issues — suivre des stories, bugs ou plus petits éléments de travail (stories, bugs, or smaller items of work).
• Tasks — suivre une plus petite quantité de travail pour laquelle vous voulez tracer le temps en heures ou en jours (hours or days).

Hiérarchie Basic : Epic → Issue → Task.

États typiques Basic : To Do → Doing → Done. C’est idéal pour un atelier d’une journée ou une équipe qui refuse la surcharge de types. Limite : pas de Feature distincte, pas de User Story / PBI nommés — tout le « besoin » vit dans Issue.

Epic: « Lab Boards en 1 journée »
  └── Issue: « Prioriser le backlog sprint »
        ├── Task: « Créer Sprint 1 » (Remaining = 2h)
        └── Task: « Déplacer 3 issues sur le board » (Remaining = 1h)

Étape 3 — Agile process (conservé + enrichi)

Le process Agile est le plus utilisé dans les parcours pédagogiques. L’image Agile montre : User Stories et Tasks pour le travail, Bugs pour les défauts de code, Epics et Features pour regrouper sous de plus grands scénarios.

• Epic — initiatives métier significatives (significant business initiatives).
• Feature — applications ou ensembles de travaux spécifiques (specific applications or sets of works).
• User Story — travail que vous assignerez à un membre d’équipe (work assigned to a specific team member), avec critères d’acceptation.
• Bug — défauts de code (code defects).
• Issues — obstacles à la progression (obstacles to progress).
• Test Cases — cas de test (suites d’étapes à valider côté serveur / application).

Hiérarchie Agile : Epic → Feature → User Story → Task (Bugs gérés au niveau backlog ou taskboard selon la config équipe).

États Agile courants : New → Active → Resolved → Closed (plus Removed). Tasks supportent Original Estimate, Remaining Work et Completed Work — utile pour capacité de sprint.

Étape 4 — Scrum process (conservé + enrichi)

Le process Scrum aligne le vocabulaire sur Scrum.org. L’image Scrum montre : Product Backlog Items et Tasks pour le travail, Bugs pour les défauts, Epics et Features pour le portfolio.

Hiérarchie Scrum : Epic → Feature → Product Backlog Item → Task.

Différences clés vs Agile : le besoin s’appelle Product Backlog Item (PBI) plutôt que User Story ; les obstacles sont souvent des Impediments plutôt que des Issues Agile ; les Tasks Scrum suivent surtout Remaining Work (pas toujours le trio Original/Completed). États typiques : New → Approved → Committed → Done (+ Removed).

Epic → Feature « Livraison incrément sprint »
  └── PBI « Afficher le board équipe »
        ├── Task « Configurer Iteration Path »
        └── Task « Démo Definition of Done »

Étape 5 — CMMI process (conservé + enrichi)

Le process CMMI (Capability Maturity Model Integration) cible des contextes où la traçabilité et le change management formel comptent. L’image CMMI montre : Requirements et Tasks pour le travail, Bugs pour les défauts, Epics et Features pour regrouper.

Hiérarchie CMMI : Epic → Feature → Requirement → Task.

En plus, CMMI expose souvent Change Request, Risk et Review pour un enregistrement auditable des décisions. États typiques : Proposed → Active → Resolved → Closed. Tasks supportent Original Estimate, Remaining Work et Completed Work. En lab pédagogique « discovery », CMMI est souvent overkill : gardez-le pour une démo gouvernance, pas pour un premier sprint Boards.

Étape 6 — Tableau comparatif des distinctions

Les bugs peuvent apparaître au même niveau que le backlog produit ou au niveau Task selon Team configuration → Working with bugs. Vérifiez ce réglage avant de conclure qu’un Bug « a disparu » du backlog.

Étape 7 — Lab : voir le process de votre projet

1. Ouvrez https://dev.azure.com/<org>/<project>/.
2. Project settings (engrenage) → Overview : notez le process affiché (ex. Agile).
3. Organization settings → Boards → Process : ouvrez le process pour lister types et états (lecture seule si process système).
4. Boards → Backlogs : basculez Epic / Feature / Stories (ou PBI / Issues selon process). Si Epic manque, cochez-le dans Team configuration (comme dans le tuto Boards).
5. Créez un item de chaque niveau portfolio → produit → Task pour valider la hiérarchie (titres lab clairs, pas de données perso).

az devops configure --defaults organization=https://dev.azure.com/<org> project=<project>
az boards work-item create --title "Lab Issue or Story" --type "User Story" -o table
# Adaptez --type au process (Issue | User Story | Product Backlog Item | Requirement)

Ne placez jamais de PAT en clair dans un tutoriel public : utilisez az login / variables d’environnement locales hors dépôt.

Étape 8 — Comment choisir (décision rapide)

• Équipe < 5, Kanban minimal → Basic.
• Cours DevOps / stories + tests → Agile (recommandé série).
• Scrum strict (PBI, Impediment, Remaining only) → Scrum.
• Audit, exigences formelles, risques → CMMI.

Une fois le projet créé, préférez personnaliser le process hérité (ajouter un état, un champ) plutôt que migrer massivement les work items. Documentez tout changement de process dans le README du lab.

Étape 9 — Personnaliser sans casser le lab

Sur le modèle Inheritance, vous pouvez dériver un process (ex. Agile-Lab-DEH) depuis Agile pour ajouter un état « Ready for demo » ou un champ « Lab module ». Gardez la personnalisation minimale en formation : chaque champ custom devient une dette pour les prochains labs et pour l’export. Ne renommez pas les types système (User Story, Bug) sauf besoin métier clair — le maillage avec les tutos Boards et le vocabulaire Microsoft s’en ressent.

Checklist avant personnalisation : (1) projet lab isolé, (2) export CSV des work items existants, (3) communication à l’équipe, (4) test sur un item jetable, (5) documenter dans le README du repo lab. Si vous enseignez plusieurs process, créez plusieurs projets plutôt qu’un seul projet « fourre-tout ».

Le process n’est pas qu’un libellé : il structure les requêtes, les boards, les notifications et parfois les extensions Marketplace. Un changement tardif coûte plus cher qu’un choix prudent à la création du projet — d’où ce chapitre placé tôt dans la série Azure DevOps.

Quiz rapide

1. Quelle hiérarchie Basic est correcte ? (a) Feature → Story → Task (b) Epic → Issue → Task (c) Epic → PBI → Bug
2. Dans Agile, quel type suit surtout les défauts de code ? → Bug
3. Scrum nomme le besoin backlog : Product Backlog Item
4. CMMI ajoute typiquement : Risk / Change Request / Review
5. Où voir le process du projet ? → Project settings → Overview

Erreurs courantes

• « Je ne vois pas Epic » — Team configuration → Backlogs → cocher Epic (et Feature si besoin).
• « Mon Bug n’est pas sur le backlog » — Working with bugs (backlog vs tasks).
• « On a changé de process et tout est cassé » — migration de types/états : planifier, backup export, communication équipe.
• « Basic me manque les Features » — normal ; passez Agile/Scrum sur un nouveau projet lab plutôt que forcer Basic.
• Images Elementor / hotlinks morts — préférer contenu texte/tableaux ; retirer uniquement les balises img en 404 (consigne Maître).

Aller plus loin

• Azure Boards — créer work items et backlogs
• Azure Boards lab et Sprint lab
• Azure Projects — création projet + process à la naissance
• Agile terminology
• Documentation Microsoft : Choose a process (learn.microsoft.com — Azure DevOps Boards)

En résumé : le process Azure DevOps fixe le langage du travail. Basic va à l’essentiel (Epic / Issue / Task) ; Agile et Scrum ajoutent Feature + besoin nommé (User Story ou PBI) ; CMMI pousse exigences et risques. Choisissez tôt, enrichissez votre backlog ensuite — et gardez Boards aligné avec le process réel du projet.

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