Azure DevOps: Project Teams

À la fin de ce tutoriel, vous saurez définir une Project Team Azure DevOps, inviter des membres (utilisateurs AAD / Entra ou externes), créer une équipe via Project settings → Teams, comprendre l’équipe par défaut, les membres, les area paths / iterations en bref, et les permissions admin nécessaires — en enrichissant le parcours live Invite + acceptation d’invitation, sans secrets en clair.

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

Slug proposé : azure-devops-project-teams · Série : Azure DevOps (menu legacy + parcours P4) · Post WP : #1033

Prérequis

• Une Organization Azure DevOps déjà créée — hub Démarrer avec Azure DevOps ou organisation et composants / organisation et configuration
• Au moins un projet dans l’organisation (ex. ado-lab) — voir Azure projects et organisation, projets et permissions
• Des identités Entra / AAD (ou emails externes à inviter) — Azure Add AD Users, Azure Entra ID : bases, Azure Active Directory
• Droits admin-level sur le projet (Project Administrator) ou Owner org pour créer / modifier des teams et inviter
• Navigateur récent ; MFA activé sur les comptes admin (rappel Entra)

Coût estimé : gratuit sur le Free tier ADO pour un petit lab. Pas de ressource Azure canadacentral requise ici (mentionnée seulement pour la cohérence de la série).

Différenciation : Add users and set permissions couvre access levels et groupes Readers / Contributors / Project Administrators. Ce tuto se concentre sur les Project Teams : Invite, création d’équipe, membres, et lien Boards (area paths / iterations).

Ce que nous allons construire

Organisation Azure DevOps
  └── Projet ado-lab (déjà créé)
        ├── Invite (coin haut droit) → AAD / external user + acceptation
        ├── Project settings → Teams
        │     ├── Équipe par défaut (ex. ado-lab Team)
        │     ├── Nouvelle équipe (optionnelle) : Dev / QA / SM / Deploy
        │     ├── Members (ajout / retrait)
        │     └── Area paths & Iterations (aperçu Boards)
        └── Permissions admin (Project Administrators) pour gérer les teams

(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « Azure DevOps Project Teams : Invite, membres, équipe par défaut et area paths ».)

Une team est un groupe de membres qui travaillent sur un projet : typiquement le développeur, le QA, le Scrum Master et la personne responsable du déploiement. Les teams structurent les backlogs et sprints dans Azure Boards / work items.

Étape 1 — Qu’est-ce qu’une Project Team ?

Contenu live conservé et enrichi. Dans Azure DevOps, une team n’est pas un simple chat : c’est une unité de travail qui possède :

Chaque projet a au moins une équipe par défaut (souvent nommée <ProjectName> Team). Vous pouvez en créer d’autres (ex. Frontend, Platform, QA) pour isoler des backlogs — utile dès que deux flux de travail coexistent.

Rôles métier fréquents dans une team lab :

• Developer — code, PRs, work items techniques
• QA — tests, bugs, validation
• Scrum Master — facilitation, impediments, cadence
• Deploy / Release owner — environnements, releases, gates

Ces rôles ne sont pas des groupes de sécurité ADO automatiques : ce sont des responsabilités. Les droits effectifs passent par Permissions (Contributors, etc.) + membership de la team pour Boards.

Étape 2 — Droits admin : qui peut modifier une team ?

Contenu live conservé. Un utilisateur doit disposer d’un accès admin-level pour créer une équipe, inviter largement ou changer les settings sensibles :

1. Idéalement appartenir au groupe Project Administrators du projet.
2. Ou être Project Collection Administrator / Owner au niveau organisation (trop large pour le quotidien — réservez-le au lab ou à l’admin org).
3. Vérifier aussi l’access level : un Stakeholder a des capacités limitées ; pour gérer settings et invitations utiles en lab, préférez Basic + Project Administrators.

Sans ces droits, les boutons Invite, New team ou Add (membres) seront absents ou grisés. En cas de doute : Add users and set permissions.

Étape 3 — Invite depuis le coin haut droit du projet (parcours live)

Contenu live conservé et développé — ne pas ignorer.

Step 1 — Bouton Invite

1. Connectez-vous à https://dev.azure.com/<votre-org>/<votre-projet> (ex. projet ado-lab).
2. En haut à droite de la page projet, cliquez le bouton Invite (parfois regroupé près de Project settings / avatar selon la densité du bandeau 2026).
3. Un panneau d’invitation s’ouvre : recherche d’identités, choix de projets / groupes, option d’envoi d’email.

Ce raccourci Invite est le chemin le plus visible pour un admin qui veut rapidement ajouter quelqu’un au projet — complémentaire (pas exclusif) de Organization Settings → Users et de Project settings → Teams.

Step 2 — Utilisateur AAD / Entra ou utilisateur externe

1. Saisissez l’email d’un utilisateur AAD / Microsoft Entra déjà dans le tenant lié, ou d’un utilisateur externe (guest / Microsoft account selon la politique de votre org).
2. Pour un utilisateur externe, Azure DevOps envoie une invitation à son email : la personne doit accepter l’invitation pour rejoindre le projet et devenir membre effectif.
3. Pour un user Entra déjà résolu, l’ajout peut être quasi immédiat une fois validé (selon directory lié et access level).
4. Attribuez un groupe projet adapté si proposé (Contributors pour le lab quotidien, Readers pour lecture seule).
5. Confirmez / envoyez.

Points d’attention :

• L’invitation non acceptée = le user n’apparaît pas encore comme membre opérationnel (vérifiez spam / filtre corporate).
• Directory Entra non lié → users AAD introuvables ; liez d’abord via Organization Settings → Microsoft Entra (voir Azure Active Directory).
• Après Invite, ajoutez aussi la personne dans Project settings → Teams → Members pour le board / capacity.

Étape 4 — Project settings → Teams : créer et gérer une équipe

En parallèle du bouton Invite, le chemin « officiel » pour les Project Teams est :

1. Ouvrez le projet → Project settings (engrenage en bas à gauche).
2. Sous General, cliquez Teams.
3. Vous voyez la liste : au minimum l’équipe par défaut.

Créer une nouvelle équipe

1. Cliquez New team (ou Create new team).
2. Donnez un nom clair (ex. ado-lab-platform, QA-Team) et une description courte.
3. Option : cocher Create an area path with the name of the team — pratique pour isoler le backlog (voir étape 5).
4. Validez. L’équipe apparaît dans la liste.

Équipe par défaut

• Chaque projet a une team default : c’est celle utilisée si vous ne choisissez pas d’autre contexte dans Boards.
• Vous pouvez renommer l’équipe par défaut (ex. ado-lab Team → Core Product) sans casser le projet — documentez le changement pour l’équipe.
• Ne multipliez pas les teams « pour voir » : une team supplémentaire = un backlog / capacity à maintenir.

Ajouter / retirer des membres

1. Cliquez le nom de la team → onglet Members (ou Add selon UI).
2. Add → recherchez users ou groupes Entra déjà dans l’org / projet.
3. Ajoutez Developer, QA, Scrum Master, Deploy owner selon votre scénario lab.
4. Retirez les comptes de test une fois l’exercice fini (hygiène moindre privilège).

Astuce : préférer un Security group Entra (ex. ado-lab-contributors) ajouté comme membre de la team — moins de gestion individuelle. Voir Entra ID bases.

Étape 5 — Area paths et iterations (aperçu Boards)

Les teams brillent surtout avec Azure Boards :

En bref (détails dans Azure Boards et work items) :

1. Project settings → Teams → votre team → Iterations and areas (libellés proches selon portail).
2. Sélectionnez les area paths inclus (souvent l’area homonyme créé à la création de la team).
3. Sélectionnez les iterations actives pour le sprint en cours.
4. Dans Boards, basculez le team context (sélecteur en haut) pour voir le bon backlog.

Sans area path cohérent, deux teams verront le même monolithe de work items — source classique de confusion.

Étape 6 — Vérification de fin de parcours

1. Invite : un user AAD ou externe a été invité ; l’externe a accepté l’email.
2. Project settings → Teams : équipe par défaut visible ; éventuelle 2ᵉ team créée ; Members listés (Dev / QA / SM / Deploy selon le lab).
3. Session privée avec un membre : accès au projet, board de la team visible (selon permissions + access level).
4. Area paths / iterations : au moins une area associée à la team ; une iteration sélectionnée pour le sprint lab.
5. Aucun PAT / secret réel dans les notes ; droits admin limités au cercle nécessaire.

Erreurs fréquentes

Quiz / FAQ courte

1. Qu’est-ce qu’une Project Team dans Azure DevOps ? – A. Uniquement un canal Teams Microsoft 365
– B. Un groupe de membres d’un projet (Dev, QA, SM, Deploy…) avec backlog / areas / iterations
– C. Un resource group Azure en canadacentral

2. Pour inviter un utilisateur externe au projet (parcours live), que doit-il faire ? – A. Rien — l’accès est immédiat sans email
– B. Accepter l’invitation reçue par email pour rejoindre le projet
– C. Créer un nouveau tenant Entra

3. Où crée-t-on une équipe dédiée et gère-t-on ses membres côté settings ? – A. Billing → Payment method
– B. Project settings → Teams
– C. Uniquement Azure Portal → Resource groups

4. Pourquoi séparer les area paths entre deux teams ? – A. Pour facturer Azure Différemment
– B. Pour que chaque team ait un backlog filtré (évite le monolithe partagé)
– C. Parce que Git l’exige

5. Quel prérequis de droits pour modifier une team / inviter largement ? – A. Stakeholder sans groupe admin
– B. Accès admin-level (ex. Project Administrators)
– C. Uniquement un compte GitHub sans MFA

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

Pour aller plus loin

• Learn : Add teams · Add users to a project or team · About area and iteration paths
• Suite Boards : Azure Boards · work items
• Identité & permissions : Add users and set permissions · Azure Add AD Users

Maillage série Azure DevOps

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