Azure DevOps : organisation et configuration

À la fin de ce tutoriel, vous saurez situer une Organization Azure DevOps, lier un compte MSA / GitHub / work-school (et le rattachement Microsoft Entra ID), parcourir Organization Settings → Boards → Process, fixer le process par défaut, inspecter Fields / Work item types / Layout / States, créer le process hérité AgileSubprocess, ajouter le work item UnitTesting, créer un projet dessus, puis changer le process d’un projet existant en lisant les avertissements — sans secrets en clair, sans balises img 404.

Niveau : Débutant → Intermédiaire · Temps estimé : 50–70 min · Versions testées : Azure DevOps Services (portail 2026), Inheritance · Dernière vérification : 2026-09-12

Slug : azure-devops-organization-and-its-configuration · Série : Azure DevOps (menu legacy Lesson 7) · WP #1028 · Région lab Azure : hors scope (0 € ADO Free tier)

Prérequis

• Compte Microsoft (MSA), GitHub, ou work / school account pour une org lab
• Droits Project Collection Administrator / Owner (Process et Change process)
• Notions Boards : Azure Boards, terminologie Agile, Project Processes
• Users : Add users and set permissions, Azure Active Directory, Azure Add AD Users
• Navigateur + MFA ; aucun PAT en clair dans Git

Coût estimé : gratuit (Free tier). Aucune ressource Azure facturable dans ce chapitre.

Différenciation : la sœur azure-project-processes compare Basic / Agile / Scrum / CMMI. Cette page configure l’Organisation (défaut, héritage, WIT custom, change process). Hub : Azure DevOps.

Ce que nous allons construire

Compte (MSA | GitHub | work/school → Entra ID)
        │
        ▼
Organisation Azure DevOps
  ├── Projects liés (échelle entreprise)
  ├── Organization Settings → Boards → Process
  │     ├── Basic / Agile / Scrum / CMMI (+ Set as default)
  │     ├── Fields · Work item types · Backlog levels · Projects
  │     ├── Epic → Layout (lecture seule système) · States To Do/Doing/Done
  │     └── Inherited : AgileSubprocess
  │           ├── New Work Item UnitTesting (+ layout, group, page, rule, state)
  │           └── New project → UnitTesting visible sur Boards
  └── Change Process of Existing Project (warnings mapping)

(Schéma local Excalidraw / draw.io, alt : « Organisation Azure DevOps, process défaut, héritage AgileSubprocess et UnitTesting ». L’image Blogger SetDefaultProcess.jpg était HTTP 200 ; corps text-first comme #1027 — aucune balise img.)

Le contenu pédagogique d’origine (Organization, process défaut, Fields, Layout/States lecture seule, héritage AgileSubprocess, UnitTesting, change process) est conservé et enrichi en français — jamais effacé.

Étape 1 — Qu’est-ce qu’une Azure Organization ?

Une Organization Azure DevOps sert à connecter des groupes de projets liés et à faire passer à l’échelle votre entreprise (intent d’origine). Ce n’est pas un Resource Group du portail Azure : c’est le conteneur Boards, Repos, Pipelines, Artifacts et Test Plans pour plusieurs projets.

Type de compte	Effet typique
Personal Microsoft account (MSA)	Org perso / lab rapide
GitHub account	Connexion via identité GitHub
Work or school account	Connexion automatique à Azure AD (désormais Microsoft Entra ID)

Le compte work / school est le chemin entreprise : MFA / Conditional Access du tenant s’appliquent. Voir Azure Active Directory et Add users.

Azure DevOps est un outil personnalisé qui aide l’équipe de développement logiciel à gérer et suivre les activités du projet (SDLC — contenu d’origine). L’Organization est le toit commun. URL lab : https://dev.azure.com/<votre-org>.

Étape 2 — Process courants : Agile, Scrum (+ Basic, CMMI)

Process très couramment utilisés : Agile et Scrum. Azure DevOps propose aussi Basic et CMMI.

Process	Usage pédagogique
Basic	Kanban simple Epic → Issue → Task ; souvent défaut org neuve
Agile	Stories + Bugs + Test Case — défaut fréquent des labs
Scrum	Product Backlog Item, Impediment
CMMI	Requirements, Risk, Review — contexte formel

Détail des hiérarchies : azure-project-processes. Ici on configure le catalogue org et l’héritage.

Étape 3 — Organization Settings → Boards → Process

1. Connectez-vous à https://dev.azure.com/<votre-org>.
2. Ouvrez Organization Settings (engrenage bas gauche, niveau org — pas Project settings).
3. Sous Boards, cliquez Process.

Vous voyez la liste des process (système + hérités), le process par défaut, et les Projects associés. C’est le hub de gouvernance du modèle Inheritance.

Prenez deux minutes pour noter dans un tableau personnel process → projets associés → défaut oui/non avant toute personnalisation. Cette photo d’état évite de désactiver un process encore utilisé par un projet lab oublié, et documente la gouvernance pour un audit rapide en formation.

Étape 4 — Basic par défaut et « Set as default process »

Le process Basic est souvent le process par défaut, mais vous pouvez le changer : menu … (ou clic droit) sur un process → Set as default process (contenu d’origine).

Effet : les nouveaux projets proposent ce process. Les projets déjà créés ne changent pas automatiquement — voir étape 11. Astuce lab : mettez Agile en défaut si la série Boards utilise User Story.

Étape 5 — Onglet Fields et inspection d’un process

Sélectionnez un process (ex. Basic). Zones utiles (contenu d’origine enrichi) :

Onglet / zone	Ce que vous voyez
Fields	Tous les champs liés aux process / types
Work item types	Epic, Issue, Task… (selon process)
Backlog levels	Niveaux portfolio / product / iteration
Projects	Projets déjà associés à ce process

Ouvrez Fields pour comprendre Area Path, Iteration Path, Effort, etc. Ne modifiez pas un process système : verrouillé — d’où l’héritage (étape 8).

Étape 6 — Work Item → Epic → Layout et States (lecture seule système)

1. Process Basic (ou Agile) → onglet Work item types.
2. Cliquez Epic → Layout : formulaires, groupes, pages — lecture seule sur un process système.
3. Onglet States : pour Basic Epic typiquement To Do, Doing, Done — encore non modifiable sur le process système.

Message pédagogique : personnaliser = process hérité, jamais le process système Microsoft. Sur Agile/Scrum/CMMI les noms d’états diffèrent (New / Active / …).

Étape 7 — Pourquoi héritage plutôt que XML ?

Sur Azure DevOps Services, le modèle Inheritance remplace le XML on-prem pour la majorité des labs. Avantages : UI, mises à jour Microsoft du parent, isolation par process nommé (AgileSubprocess). Règle série : un process hérité par besoin métier clair (ex. WIT UnitTesting), pas dix forks « pour essayer ».

Étape 8 — Créer le process hérité AgileSubprocess

Create a custom process (Inherited process) — contenu d’origine :

1. Organization Settings → Boards → Process.
2. Sur le process Agile, menu … → Create inherited process.
3. Nom : AgileSubprocess · Description courte (ex. « Lab DEH — WIT UnitTesting ») · Create Process.

Sur AgileSubprocess vous pouvez ensuite : Set as default process, Disable process, ouvrir Work item types. Le parent Agile reste intact. Vérification : indicateur Inherited from Agile dans la liste Process.

Étape 9 — New Work Item UnitTesting + layout, group, page, rule, state

Toujours sur AgileSubprocess :

1. New work item type → Name UnitTesting · description · choisir icon et color · créer.
2. Ouvrez UnitTesting → Layout : Add a field (existants) ou nouveau champ ; ajoutez New group, New page, New rule (contenu d’origine).
3. Onglet States : ajoutez un nouvel état lab (ex. Ready for review) — possible parce que le process est hérité.

Action	Conseil lab
Nom WIT	PascalCase clair (UnitTesting)
Champs	Réutiliser Title, Description, Area/Iteration d’abord
Rules	Une règle simple — documenter dans le README
Color/icon	Distincts des Bugs / User Stories sur le board

Un seul WIT pédagogique suffit à démontrer Layout / States / Rules.

Étape 10 — Créer un projet depuis AgileSubprocess

1. New project → Name ado-lab-agilesub · Private · Git.
2. Advanced → Work item process : sélectionnez AgileSubprocess.
3. Create → Boards → New Work Item : vous devez voir UnitTesting parmi les types hérités.
4. Créez un item UT-smoke-layout et vérifiez le layout custom.

az devops configure --defaults 
  organization=https://dev.azure.com/<votre-org> 
  project=ado-lab-agilesub

az boards work-item create 
  --title "UT-smoke-layout" 
  --type "UnitTesting" 
  --output table

Auth navigateur ou PAT en variable d’environnement — jamais en clair dans Git. Si --type UnitTesting échoue, confirmez le process dans Project settings → Overview.

Étape 11 — Change Process of Existing Project

Vous pouvez changer le process d’un projet existant, mais le changement peut retirer ou mapper certains work items — lisez l’avertissement attentivement (contenu d’origine).

1. Organization Settings → Boards → Process.
2. Vue Projects associée au process → sélectionnez le projet.
3. Menu … → Change process → target process → validez / Close.

Depuis → Vers	Risque relatif
Agile → AgileSubprocess	Plus bas (même famille)
Basic → Agile / Scrum	Mapping Issue ↔ Story/PBI
Agile → CMMI	Plus élevé (Requirement vs Story)

Checklist : export CSV, projet lab isolé, lire chaque écran de mapping, smoke Boards après. Ne faites jamais ça en prod sans backup.

En lab pédagogique, préférez un second projet jetable pour tester Change process plutôt que de recycler le projet où vous avez déjà créé UnitTesting et des User Stories liées. Ainsi vous conservez une référence stable sur AgileSubprocess pendant que vous explorez le mapping.

Étape 12 — Checklist de gouvernance org

Contrôle	Où
Compte work/school + Entra (si entreprise)	Connexion org
Process défaut = Agile (série Boards)	Set as default process
AgileSubprocess créé	Inherited from Agile
UnitTesting + 1 état custom	WIT layout / states
Projet ado-lab-agilesub	Project settings → Overview
Change process testé sur jetable	Warnings lus
Users Basic + Contributors	Add users

Quiz rapide

1. Quel compte auto-connecte l’org à Azure AD / Entra ? → Work or school account
2. Où gérer les process org ? → Organization Settings → Boards → Process
3. Peut-on modifier Layout d’Epic sur Basic système ? → Non — il faut un inherited process
4. Nom du process hérité du lab d’origine ? → AgileSubprocess
5. WIT custom du lab ? → UnitTesting
6. Change process peut… ? → retirer / mapper des work items — lire le warning

Erreurs courantes

• Pas de menu Process — vous êtes en Project settings ; ouvrez Organization Settings.
• « Cannot edit layout » — process système ; créez un inherited process.
• UnitTesting absent — projet encore sur Agile système ; nouveau projet sur AgileSubprocess ou Change process.
• Set as default « ne change rien » — normal pour les projets existants.
• Mapping perdu après change — types incompatibles ; export CSV avant.
• Images Elementor / hotlinks morts — corps text-first ; retirer uniquement les balises img en 404.

FAQ

Organization vs Project ? L’Organization regroupe projets, users, billing et catalogue process. Le Project porte Repos/Boards d’une équipe — Azure Projects.

Toujours hériter d’Agile ? Pour la série pédagogique oui. Basic pour un atelier Kanban d’une journée ; Scrum si le vocabulaire PBI est déjà ancré.

Différence avec azure-project-processes ? Project Processes = choisir Basic/Agile/Scrum/CMMI. Ici = configurer l’org (défaut, héritage, WIT, change process).

Entra ID obligatoire ? Lab MSA : non. Entreprise / MFA / groupes : work account + Entra — Azure Active Directory.

Aller plus loin

• Azure Projects — création projet + process à la naissance
• Azure Project Processes — hiérarchies Basic / Agile / Scrum / CMMI
• Azure Boards · Boards lab · Sprint lab
• Add users and permissions · Agile terminology
• Hub : Azure DevOps
• Documentation Microsoft : Create an organization, Inherit a process, Change the process used by a project (learn.microsoft.com)

En résumé : l’Organization Azure DevOps relie projets et identités ; Organization Settings → Boards → Process gouverne Basic/Agile/Scrum/CMMI, le défaut, et les process hérités comme AgileSubprocess. Personnalisez Layout/States via l’héritage (WIT UnitTesting), créez un projet dessus, et ne changez le process d’un projet existant qu’après avoir lu les avertissements de mapping.

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