Azure DevOps: Add Users and Set Permissions

À la fin de ce tutoriel, vous saurez connecter l’organisation Azure DevOps à Microsoft Entra ID, ajouter des users via Organization Settings → Users, choisir l’access level (Basic / Stakeholder), puis assigner des permissions au niveau organisation et projet (Readers, Contributors, Project Administrators) — avec tests de connexion, moindre privilège et rappels MFA, sans secrets en clair.

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

Prérequis

• Une Organization Azure DevOps déjà créée (hub Démarrer avec Azure DevOps ou organisation et composants)
• Des utilisateurs Entra / AAD déjà existants — création détaillée dans Azure Add AD Users et Azure Entra ID : bases
• Droits Project Collection Administrator / Owner (ou équivalent) sur l’org lab
• Navigateur + (optionnel) Azure CLI avec az extension add --name azure-devops
• MFA activé sur les comptes admin (rappel Entra)

Coût estimé : gratuit sur le Free tier ADO pour un petit lab (quotas Basic inclus). Pas de ressource Azure canadacentral requise ici.

Différenciation : la page sœur azure-add-ad-users crée / invite les identités côté Entra. Ce tuto se concentre sur l’ajout dans l’organisation ADO et l’assignation des permissions org + projet.

Ce que nous allons construire

Microsoft Entra ID (users / groupes déjà créés)
        │ liaison directory
        ▼
Organisation Azure DevOps
  ├── Organization Settings → Microsoft Entra (directory lié)
  ├── Users → ADD Users (access level Basic / Stakeholder)
  ├── Security → Permissions (groupes org)
  └── Projet ado-lab
        └── Project settings → Permissions
              ├── Readers
              ├── Contributors  ← usage lab quotidien
              └── Project Administrators

(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « Ajout users Azure DevOps et permissions org vs projet ».)

Étape 1 — Connecter l’Organization à Active Directory / Microsoft Entra

Contenu live conservé et enrichi. Avant d’inviter qui que ce soit, liez l’org au bon tenant.

1. Connectez-vous à https://dev.azure.com/<votre-org> avec un compte Owner / PCA.
2. Ouvrez Organization Settings (engrenage en bas à gauche, niveau org).
3. Sous General, cliquez Microsoft Entra (libellé historique : Azure Active Directory).
4. Sélectionnez le directory (tenant) auquel vous voulez connecter l’organisation, puis confirmez.

Effets : users/groupes Entra résolvables dans ADO ; MFA / Conditional Access du tenant s’appliquent. Changer de directory est sensible — en lab, liez une seule fois.

Vérification : Microsoft Entra affiche le tenant lié (pas « Not connected »). Voir aussi Azure Active Directory et Entra ID bases.

Étape 2 — Ouvrir Organization Settings → Users

Une fois le directory connecté :

1. Organization Settings → Users.
2. Observez la liste : membres existants, Access level, date d’ajout, éventuels guests.
3. Repérez aussi le résumé des licences (Basic vs Stakeholder) — utile avant d’ajouter une équipe entière.

Modèle mental à ancrer dès maintenant :

Sans access level adapté, même un Contributor « parfait » restera bloqué (ex. Stakeholder qui tente un git push).

Astuce lab : notez dans un tableau personnel user → access level → groupe projet avant d’inviter une équipe réelle. Cela évite les allers-retours Users ↔ Permissions et documente le moindre privilège pour un audit rapide.

Étape 3 — Add users via le bouton ADD Users

1. Cliquez Add users (ADD Users).
2. Recherchez l’UPN / nom d’un user déjà dans Entra (ou un Security group).
3. Choisissez l’Access level : Basic (Repos/Pipelines/Boards lab), Stakeholder (lecture Boards, pas de push), Basic + Test Plans hors scope.
4. Assignez au projet ado-lab et au groupe Contributors si proposé.
5. Validez / envoyez l’invitation.

Bonnes pratiques : préférer un groupe Entra ado-lab-contributors ; moindre privilège Basic + Contributors (pas PCA) ; aucun PAT réel — placeholder <PAT_SCOPES_MINIMAUX> seulement.

Option CLI (après az login ou PAT en variable d’environnement) :

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

# Lister les users (lecture)
az devops user list -o table

# Ajouter un user (adapter email + access level)
az devops user add 
  --email lab-dev@<tenant>.onmicrosoft.com 
  --license-type express 
  --send-email-invite false

express correspond en pratique au niveau Basic côté CLI ; vérifiez toujours le résultat dans l’UI Users.

Étape 4 — Permissions organisation : Security → Permissions + test

Contenu live conservé. Après l’ajout, les droits fins se règlent ici :

1. Organization Settings → Permissions (chemin live historique : Security → Permissions ; le portail 2026 regroupe souvent sous Permissions).
2. Sélectionnez un groupe org (ex. Project Collection Valid Users, groupes custom, ou un groupe Entra mappé).
3. Examinez les bits Allow / Deny / Not set (gestion d’agents, création de projets, politiques, etc.).
4. Testez avec l’utilisateur ajouté : session privée (ou autre navigateur), compte lab, puis observez projets visibles, settings accessibles et boutons grisés. Sans ce test, une permission « Allow » sur papier peut masquer un Deny hérité d’un autre groupe.

Réflexes : Deny > Allow ; pas de Create/Delete project pour Contributors ; MFA d’abord côté Entra ; documenter toute élévation temporaire. Vue élargie : organisation-projets · Azure projects.

Étape 5 — Permissions projet : Project settings → Permissions

Contenu live conservé et étendu. Le quotidien se joue au niveau projet :

1. Ouvrez le projet (ex. ado-lab) → Project settings (engrenage bas gauche).
2. Sous General, ouvrez Permissions (chemin live : Project settings → General → Permissions).
3. Sélectionnez un groupe projet standard :

4. Ajoutez le user ou le groupe Entra au groupe voulu (Members → Add).
5. Sur le groupe, parcourez les security bits (Edit project-level information, Create repository, Manage pipelines, Delete team project…). Laissez les défauts Contributors sauf besoin pédagogique précis.
6. Option Teams : Project settings → Teams → membres de la team par défaut — utile pour Boards, complémentaire aux Permissions.

Vérification croisée : Basic + Contributors doit pouvoir cloner le repo et créer un work item ; Stakeholder + Readers ne doit pas pousser sur main. Si le comportement diverge, revérifiez l’access level (étape 3) avant de toucher aux Deny — la licence produit bloque souvent avant l’ACL.

Étape 6 — Check-list moindre privilège

1. Identité Entra → directory lié → Users + access level → permissions projet d’abord, org seulement si transversal.
2. Groupe Entra → Contributors ; MFA OK ; projet Private ; pas de PCA par défaut.
3. PAT : scopes minimaux, expiration courte, jamais dans un channel. Suite : sécurité et gouvernance.

Vérification de fin de parcours

1. Microsoft Entra lié ; user visible dans Users avec le bon access level.
2. Session privée : accès à ado-lab ; membership Contributors/Readers confirmée.
3. Basic+Contributors : clone / WI OK ; Stakeholder seul : pas de push.
4. Aucun PAT/secret réel dans Git ; vous distinguez Users (org) vs Permissions (projet).

Nettoyage

Retirez users de test (Users → Remove) et memberships projet/Entra ; révoquez PAT de démo ; gardez org + ado-lab pour la série ; ne changez pas de directory sur une org partagée.

Erreurs fréquentes

Quiz (3 questions)

1. Quelle couche contrôle surtout la capacité à utiliser Repos / Pipelines (licence produit) ? – A. Uniquement Project settings → Teams
– B. L’access level (Basic / Stakeholder) dans Organization Settings → Users
– C. La région Azure canadacentral

2. Pour un développeur lab au quotidien, quelle combinaison respecte le mieux le moindre privilège ? – A. Stakeholder + Project Collection Administrator
– B. Basic + Contributors (idéalement via groupe Entra)
– C. Basic + Owner org pour toute l’équipe

3. Où assigne-t-on en priorité Readers / Contributors / Project Administrators pour un projet ado-lab ? – A. Project settings → Permissions (General)
– B. Uniquement Billing → Payment method
– C. Le resource group canadacentral

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

Pour aller plus loin

• Learn : Add users · Permissions · Access levels · az devops user
• Suite : organisation/projets, Boards, Repos · Legacy : organisation et composants, Azure projects

Maillage série Azure DevOps

• rank_math_title : Azure DevOps : Add Users and Set Permissions (org + projet)
• rank_math_description : Ajoutez des users à votre organisation Azure DevOps : Basic ou Stakeholder, puis Readers, Contributors ou Project Administrators. Tutoriel pratique FR 2026.
• rank_math_focus_keyword : azure devops add users permissions
• Slug : azure-devops-add-users-and-set-permissions
• URL live (référence) : https://devopelastichayway.com/azure-devops-add-users-and-set-permissions/
• Statut : HOLD — draft only, ne pas publier sans feu vert Maître