Azure Projects — créer et configurer un projet Azure DevOps
À la fin de ce tutoriel, vous saurez créer un projet Azure DevOps sous une organisation, choisir la Visibility (Private / Public), comprendre le conteneur fondamental (code, planification, collaboration), vérifier qu’une team du même nom est créée automatiquement, et parcourir Project settings (Overview, Services, Teams, Repos, Pipelines, Boards) — 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) · Dernière vérification : 2026-09-12
Slug :
azure-projects· Série : Azure DevOps (menu) · Lesson 8 / 31 · Focus SEO :azure devops projects
Prérequis
- Organisation Azure DevOps déjà créée : organisation et composants et Démarrer avec Azure DevOps
- Process à choisir à la création : Azure Project Processes (Basic, Agile, Scrum, CMMI)
- Notions d’équipe : Azure DevOps Project Teams
- Backlog et vocabulaire : Azure Boards, Agile terminology
- Repo Git du projet : Azure Repo
- Droits Project Collection Administrator (ou Owner org) pour New project ; optionnel Azure CLI +
azure-devops
Coût estimé : gratuit (Free tier). Aucune ressource Azure à facturer. Région lab éventuelle : canadacentral (hors scope).
Ce que nous allons construire
Organisation Azure DevOps
└── New project (Visibility Private | Public)
├── Conteneur : Repos + Boards + Pipelines + Artifacts
├── Team du même nom (auto)
└── Project settings
├── Overview (nom, description, process, visibilité)
├── Services (Boards, Repos, Pipelines, Test Plans, Artifacts)
├── Teams / Permissions
└── Repos · Pipelines · Boards
Lab : ado-lab-projects (Private, Git, Agile)
(Schéma local Excalidraw / draw.io, alt : « New project, team auto et Project settings ». Aucune balise img — le post d’origine n’en avait aucune.)
Le contenu d’origine (Azure DevOps – Project Settings : org / projets, conteneur, team auto, Public vs Private) est conservé et enrichi en français — jamais effacé.
Étape 1 — Qu’est-ce qu’un projet Azure DevOps ?
Un projet Azure DevOps (Azure DevOps project) fournit un dépôt pour le code source et un lieu où les utilisateurs planifient, suivent la progression et collaborent pour construire des solutions logicielles. Un projet représente un conteneur fondamental : les données y sont stockées dès qu’elles sont ajoutées à Azure DevOps. Lorsque vous créez votre projet, une team du même nom est automatiquement créée.
En pratique, le projet est la frontière de la série : Boards, Repos, Pipelines, Artifacts. Sans projet : pas de backlog, pas de repo, pas de pipeline. Cette leçon (Lesson 8 / 31) arrive tôt : process, teams et boards s’accrochent à ce conteneur.
Le nom apparaît dans l’URL https://dev.azure.com/<org>/<project>/. Choisissez-le avec soin (étape 8) : le renommer casse favoris, service connections et scripts az devops.
Étape 2 — Organisation vs projets multiples
Les projets sont créés sous une organisation. Dans une seule organisation, vous pouvez créer plusieurs projets.
L’organization porte billing, users, Access levels, policies et agent pools. Le projet porte Boards, Repos, Pipelines, Artifacts et les Project settings. Org lab typique : ado-lab pour le parcours, plus un projet jetable ici.
| Niveau | Contient | Settings typiques |
|---|---|---|
| Organization | Projets, users, billing, policies | Microsoft Entra, Access levels, Overview |
| Project | Boards, Repos, Pipelines, Artifacts | Process, Visibility, Teams, Services |
URL utiles :
https://dev.azure.com/<org>/_settings/ # Organization settings
https://dev.azure.com/<org>/<project>/_settings/ # Project settings
Évitez les projets vides « pour voir » : chaque projet a permissions, teams et process. Un second projet sert à isoler un process (Agile vs Basic) ou une démo Public — pas chaque micro-exercice.
Étape 3 — Visibility : Public vs Private (conservé + enrichi)
Les utilisateurs non connectés au service ont un accès lecture seule aux projets public sur Azure DevOps. Les projets private exigent que les utilisateurs reçoivent un accès au projet et soient connectés pour utiliser les services.
C’est le réglage Visibility du dialogue New project (et plus tard Project settings → Overview).
| Visibility | Qui lit ? | Qui écrit ? | Usage lab |
|---|---|---|---|
| Private (défaut) | Membres accordés + connectés | Selon groupes (Contributors, etc.) | Recommandé pour ado-lab |
| Public | Lecture anonyme (non signés) | Membres accordés + connectés | Démo open-source, jamais un lab avec secrets |
Règle lab : Private partout. Un Public expose repo, work items et souvent pipelines en lecture. Aucun secret en clair (PAT, .env) — même en Private.
Changer la Visibility (Overview) Private → Public est une publication, pas un « test ». Documentez-la.
Étape 4 — Création : New project
- Ouvrez
https://dev.azure.com/<org>/. - Cliquez New project (bouton en haut à droite, ou liste des projets).
- Project name :
ado-lab-projects(voir naming, étape 8). - Description (optionnelle) : « Lab Lesson 8 — Azure Projects ».
- Visibility : Private.
- Dépliez Advanced si besoin : Version control = Git (TFVC hors scope série) ; Work item process = Agile (voir Azure Project Processes).
- Create. Attendez la page d’accueil du projet.
Le process se choisit à la naissance. Pour comparer Basic et Agile, créez un second projet lab plutôt que de migrer.
Étape 5 — Team du même nom (automatique)
Lorsque vous créez votre projet, une team du même nom est automatiquement créée. Pour ado-lab-projects, Azure DevOps crée la team ado-lab-projects. Cette team par défaut possède déjà un backlog, un board et des Area / Iteration Path de base.
Point d’entrée de Azure DevOps Project Teams : rien à créer pour commencer. Ajoutez une 2ᵉ team seulement pour deux backlogs (ex. frontend / plateforme). Lab débutant : une team suffit.
Vérification : Project settings → Teams — team homonyme visible. Invitez les membres via Permissions / Teams selon votre modèle d’org.
Étape 6 — Project settings : carte des zones
Ouvrez Project settings (engrenage en bas à gauche). C’est le titre d’origine de cette leçon : Azure DevOps – Project Settings.
| Zone | À faire maintenant | Plus tard |
|---|---|---|
| Overview | Nom, description, Visibility Private, process affiché | Delete project (danger) |
| Teams | Team homonyme ; membres lab | 2ᵉ team (Project Teams) |
| Permissions | Readers / Contributors / Project Administrators | Mapping Entra |
| Services | Laisser Boards, Repos, Pipelines actifs | Désactiver Test Plans si inutiles |
| Notifications | Échecs pipeline, PR (sans flood) | Journal de la série |
| Repos | Repo Git par défaut (même nom que le projet) | Policies de branche (Azure Repo) |
| Pipelines | Agent pools, settings | YAML CI/CD |
| Boards | Team configuration, Working with bugs | Azure Boards |
| Artifacts | Feeds (souvent vide au jour 1) | Packages lab |
Services éteint un hub (ex. Test Plans). En lab, gardez Boards + Repos + Pipelines : la série s’y appuie.
Overview affiche le Process (Agile, etc.) — confirmez l’étape 4. Une description évite qu’un collègue supprime un lab « vide ».
Étape 7 — Lab pratique : créer ado-lab-projects
Objectif : un projet Private, Git, process Agile, team auto visible, Overview renseigné.
- New project → Name
ado-lab-projects→ Visibility Private → Advanced : Git + Agile → Create. - Accueil projet : notez les tuiles Boards, Repos, Pipelines.
- Repos : un repo Git du même nom existe (souvent avec README initial selon l’option).
- Project settings → Overview : vérifiez Name, Visibility Private, Process Agile. Ajoutez la description du lab.
- Project settings → Teams : team
ado-lab-projectsprésente. - Project settings → Services : Boards, Repos, Pipelines = On.
- Boards → Work items → New : créez une User Story
US-lab-projet(titre lab, pas de données perso). - Option : Project settings → Overview → Delete uniquement sur un projet jetable — jamais sur
ado-labde la série.
Si New project est grisé : droits org insuffisants (Create project). Demandez à l’Owner, ou une org lab Free personnelle.
Étape 8 — Naming : conventions lab
Un bon nom de projet est court, ASCII, stable :
- Préfixe série :
ado-lab-…(ex.ado-lab-projects,ado-lab-process-agile). - Pas d’espaces si possible (l’UI les accepte, les scripts moins).
- Pas de secrets, pas de nom d’entreprise client, pas de PII.
- Évitez de réutiliser trop tôt un nom soft-deleted (verrou temporaire après Delete).
Le nom alimente l’URL, le repo et la team. Renommer (Overview → Name) coûte cher : mettez à jour favoris, pipelines et az devops configure.
Étape 9 — Un projet ou plusieurs ?
| Stratégie | Quand | Risque |
|---|---|---|
Un projet (ado-lab) | Parcours pédagogique, petite équipe | Backlog unique, simple |
| Plusieurs projets | Isoler process, démo Public, frontières d’équipe | Permissions et duplication |
Pour la série : un projet principal + projets jetables de leçon. Pas un projet par chapitre. Groups, service connections et agent pools se multiplient à chaque projet.
Les azure devops projects sont des frontières de données, pas des dossiers. Un repo de plus se crée dans le projet (Repos → New repository).
Étape 10 — CLI : az devops project
az devops configure --defaults organization=https://dev.azure.com/<org>
# Lister les projets
az devops project list -o table
# Créer (Private, Agile) — jamais de PAT en clair
az devops project create \
--name ado-lab-projects \
--description "Lab Lesson 8 Azure Projects" \
--visibility private \
--source-control git \
--process Agile \
-o table
# Inspecter
az devops project show --project ado-lab-projects -o jsonc
Auth : az login (ou variable locale hors dépôt). Jamais de PAT dans un tuto, un README ou un screenshot.
Quiz rapide
- Où crée-t-on un projet ? (a) Azure Portal seul (b) Sous une organization Azure DevOps (c) Resource group
canadacentral - Que fournit un projet ? → dépôt + planification / suivi / collaboration (conteneur fondamental)
- Visibility Public : les non-connectés ont… → un accès lecture seule
- Visibility Private : il faut… → être accordé + signé
- À la création, les teams ? → une team du même nom est créée automatiquement
- Où changer la description et la Visibility ? → Project settings → Overview
- Commande CLI pour créer ? →
az devops project create
Erreurs courantes
- « New project est grisé » — pas les droits org (Create project). Owner / Collection Admin.
- « Je ne vois pas le projet » — mauvaise org, ou Private sans grant.
- « La team n’existe pas » — elle a le même nom que le projet ; ouvrez Project settings → Teams.
- « J’ai mis Public par erreur » — Overview → Visibility Private ; auditez le repo (pas de secrets).
- « J’ai choisi TFVC » — la série est Git ; recréez un projet Git plutôt que migrer.
- « Trop de projets vides » — Delete les jetables ; un projet = une frontière.
- PAT dans le chat / le YAML — interdit.
az loginou secret store local. - Images 404 — ce post n’avait aucune balise
img; n’en ajoutez pas.
Aller plus loin
- Azure Project Processes — Basic / Agile / Scrum / CMMI à la création
- Azure DevOps Project Teams — teams, Area Path
- Azure Boards et Agile terminology
- Azure Repo — Git dans le projet
- Organisation et composants
- Démarrer avec Azure DevOps
- Doc Microsoft : Create a project (learn.microsoft.com)
En résumé : un projet Azure DevOps est le conteneur fondamental sous une organization (dépôt, planification, collaboration). Une org peut en avoir plusieurs. Public = lecture anonyme ; Private = accès accordé et session. Une team du même nom naît à la création. Parcourez Project settings, nommez proprement, restez Private en lab, et industrialisez avec az devops project sans secret.
Retour parcours Azure DevOps — hub de la série et leçons sœurs.
