Dans nos formations Azure DevOps chez Artza Technologies, une confusion revient systématiquement : faire la distinction entre niveaux d'accès et permissions.

Cette ambiguïté n'est pas anodine, car elle impacte directement la gestion des licences, l'organisation des équipes et la maîtrise des coûts.

Comprendre ces deux concepts distincts est essentiel pour optimiser votre investissement dans Azure DevOps et garantir une attribution correcte des rôles au sein de vos projets.

Niveaux d'accès vs Permissions : deux concepts complémentaires

La première source de confusion réside dans la superposition apparente de ces deux notions. Pourtant, elles opèrent sur des plans différents et répondent à des logiques distinctes.

Les niveaux d'accès : une question de licence

Les niveaux d'accès définissent l'étendue des fonctionnalités Azure DevOps auxquelles un utilisateur peut accéder au niveau de l'organisation ou de la collection. Ils sont directement liés au modèle de licence et déterminent quelles fonctionnalités sont disponibles.

Un niveau d'accès répond à la question : "À quelles fonctionnalités de la plateforme cet utilisateur peut-il accéder ?"

Principaux niveaux disponibles :

• Stakeholder : accès limité aux fonctionnalités de suivi et visualisation
• Basic : accès aux fonctionnalités essentielles de développement
• Basic + Test Plans : fonctionnalités Basic avec ajout des outils de test
• Visual Studio Professional (VS Pro) : inclut dans l'abonnement Visual Studio
• Visual Studio Enterprise (VS Enterprise) : niveau le plus complet

Les permissions : une question de sécurité

Les permissions, quant à elles, contrôlent ce qu'un utilisateur peut faire dans un contexte spécifique : organisation, projet, dépôt, pipeline ou élément de travail. Elles constituent le système de sécurité granulaire d'Azure DevOps.

Une permission répond à la question : "Que peut faire cet utilisateur dans cette ressource particulière ?"

Le piège classique

« Je suis Administrateur de la collection de projets, pourquoi je ne peux pas voir le code source ? »

Vous pouvez avoir le rôle de sécurité le plus élevé (Project Collection Administrator) qui vous donne théoriquement le droit de tout faire. Mais si votre niveau d'accès est réglé sur Stakeholder (gratuit, sans accès au code), le menu "Repos" (Code) disparaîtra purement et simplement de votre interface.

La preuve en images :

La politique de licence derrière les niveaux d'accès

Microsoft utilise les niveaux d'accès pour gérer la monétisation d'Azure DevOps. C'est le mécanisme technique qui valide que vous respectez les règles commerciales.

Azure DevOps applique un modèle de tarification directement lié aux niveaux d'accès attribués. Cette politique influence significativement le budget et nécessite une planification rigoureuse.

Modèle de tarification Azure DevOps Services

Azure DevOps Services propose une tarification flexible avec une offre gratuite limitée et des paliers payants.

Tarification standard :

• Stakeholder : gratuit (utilisateurs illimités)
• Basic : 5 premiers utilisateurs gratuits, puis environ 6€/utilisateur/mois
• Basic + Test Plans : environ 52€/utilisateur/mois
• VS Professional : inclus dans l'abonnement Visual Studio (environ 45€/mois)
• VS Enterprise : inclus dans l'abonnement Visual Studio (environ 250€/mois)

Les détenteurs d'abonnements Visual Studio actifs bénéficient automatiquement du niveau d'accès correspondant sans coût supplémentaire dans Azure DevOps Services. C'est un avantage souvent sous-exploité lors de l'évaluation des coûts.

Spécificités Azure DevOps Server

Pour les installations on-premise, le modèle diffère sensiblement. Azure DevOps Server nécessite l'achat de licences serveur et de CAL par utilisateur.

Types de licences :

• Stakeholder : gratuit (nombre illimité)
• Basic CAL : licence standard requise
• Test Plans CAL : pour les fonctionnalités de test avancées
• Licences Visual Studio : incluent automatiquement les droits d'accès équivalents

Pour la version Cloud, Azure DevOps Services, la vérification de la licence est automatique et le niveau d’accès est positionné en fonction de la licence rattachée au compte Microsoft de l’utilisateur.

Pour la version on-premise, Azure DevOps Server, le positionnement de l’utilisateur sur un niveau d’accès est purement déclaratif. Techniquement, rien n’empêche de positionner un utilisateur sur un niveau d’accès plus élevé que celui correspondant strictement à sa licence.

Détail des licences et niveaux d'accès associés

Pour illustrer concrètement l'utilisation de chaque niveau d'accès, examinons des cas d'usage typiques rencontrés dans les organisations.

Stakeholder (Partie Prenante)

Pour qui ? Les Product Owners, les managers, les directeurs, et les utilisateurs métiers qui doivent créer des tickets ou suivre l'avancement sans toucher au code.

Coût Gratuit et illimité (Services & Server).

Ce qu'il permet :

• Accès complet aux Boards (Kanban, Backlogs) pour créer et modifier des User Stories et Bugs.
• Approuver des déploiements dans les Pipelines.
• Voir les Tableaux de bord (Dashboards).

Limitations majeures : Aucun accès aux Repos (Code) ni à Test Plans.

Basic

Pour qui ? Les développeurs, les DevOps, et la majorité des membres techniques de l'équipe.

Coût 5 premiers gratuits (sur Services), puis payant par utilisateur/mois (env. 5€). Sur Server, nécessite une CAL.

Ce qu'il permet :

• Tout ce que fait le Stakeholder.
• Accès complet à Azure Repos (Git et TFVC) pour lire et écrire du code.
• Accès à Azure Pipelines pour configurer les builds et releases.

Limitations majeures : Accès à Test Plans mais uniquement en mode consultation et exécution. Un utilisateur "Basic" peut voir les tests, mais ne peut pas les créer ni les gérer formellement.

Visual Studio Professional

Pour qui ? Les développeurs confirmés ou ceux travaillant sur l'IDE Visual Studio complet (pas VS Code).

Coût Les développeurs confirmés ou ceux travaillant sur l'IDE Visual Studio complet (pas VS Code).

Ce qu'il permet :

• Exactement les mêmes fonctionnalités que le niveau Basic dans Azure DevOps.
• L'avantage est administratif : pas besoin de payer une licence "Basic" supplémentaire, l'utilisateur est "reconnu" par le système.

Limitations majeures : accès à Test Plans mais uniquement en mode consultation et exécution. Un utilisateur "VS Pro" peut voir les tests, mais ne peut pas les créer ni les gérer formellement.

Basic + Test Plans

Pour qui ? Les testeurs QA, les valideurs fonctionnels avancés.

Coût Payant (nettement plus cher que Basic, env. 44€/mois sur Services).

Ce qu'il permet :

• Toutes les fonctionnalités du niveau Basic.
• Accès complet au module Test Plans : création de plans de tests, suites de tests, cas de tests manuels et exécution via le "Web Runner".

Visual Studio Enterprise

Pour qui ? Les architectes, les lead devs, les testeurs avancés possédant cette souscription haut de gamme.

Coût Inclus dans l'abonnement Visual Studio Enterprise.

Ce qu'il permet :

• Le niveau "Roi". Il donne accès à tout.
• Inclut automatiquement les fonctionnalités de Basic + Test Plans.
• Donne souvent droit à des crédits Azure mensuels pour l'expérimentation et à des fonctionnalités d'extensions avancées (comme la gestion de paquets Artefacts illimitée ou des outils de scan de code spécifiques).

Conclusion : optimiser vos coûts Azure DevOps

La prochaine fois qu'un utilisateur vous dit "Je ne peux pas accéder à cette fonctionnalité", ne foncez pas tout de suite dans les groupes de sécurité !

1. Vérifiez son Niveau d'accès (Organization Settings > Users). A-t-il la bonne licence ?
2. Si le niveau est bon, alors vérifiez ses Permissions (Project Settings > Permissions). Est-il dans le bon groupe ?

En maîtrisant ces deux leviers, vous optimiserez non seulement la sécurité de vos projets, mais aussi votre facture Azure DevOps.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Le champ est obligatoire

Votre commentaire a bien été envoyé !

L'adresse électronique n'est pas valide

Envoyer