Partager via


Changer la visibilité du projet pour public ou privé

Azure DevOps Services

Découvrez comment modifier la visibilité de votre projet Azure DevOps entre public et privé, et comprendre les implications en matière de sécurité et d’accès de chaque paramètre de visibilité.

Important

Seules les organisations disposant de la stratégie Autoriser le projet public déjà activée peuvent créer des projets ou modifier la visibilité d’un projet en public. La stratégie n’est plus disponible pour les organisations qui ne l’utilisent pas déjà. Microsoft recommande d’utiliser GitHub pour tous les besoins de votre projet public.

Modifications apportées lors de la prise en compte d’un projet

Rendre un projet public affecte les autorisations, les niveaux d’accès et les fonctionnalités disponibles.

Important

Lorsque vous modifiez un projet privé en visibilité publique, tout le contenu du projet devient accessible publiquement. Vous ne pouvez pas conserver de manière sélective certains référentiels, chemins d’accès de zone ou générer des artefacts privés au sein d’un projet public.

Modifications de sécurité et d’autorisations

Lorsque vous passez de la visibilité du projet privé au public, les modifications suivantes se produisent :

  • Les autorisations de refus sont ignorées : toutes les autorisations définies explicitement sur « Refuser » ne sont pas appliquées pour les utilisateurs publics
  • Accès minimal accordé : les non-membres reçoivent automatiquement l’accès en lecture de référence au contenu public
  • Étendue du pipeline de génération : les pipelines définis sur l’étendue de regroupement de projets s’exécutent automatiquement avec l’étendue project pour améliorer la sécurité

Différences de niveau d’accès

Type d’utilisateur Accès au projet privé Accès au projet public
Utilisateurs anonymes Aucun accès Accès en lecture seule à la plupart du contenu
Parties prenantes Accès limité aux tableaux, pas d’accès repos Accès complet aux dépôts et aux tableaux
Utilisateurs de base Accès complet à l’exception des plans de test Accès complet à l’exception des plans de test
Plans de test de base Accès complet, y compris les plans de test Accès complet, y compris les plans de test

Disponibilité des fonctionnalités pour les membres non membres

Le tableau suivant montre quelles fonctionnalités sont disponibles pour les utilisateurs qui ne sont pas membres du projet :

Aire de services Accès non membre Remarques
Tableaux de bord Widgets en lecture seule et limités De nombreux widgets indisponibles
Wiki Read-only Contenu complet visible
Boards Lire les éléments de travail uniquement Backlogs, Boards, Sprints masqués
Repos Dépôts Git en lecture seule Référentiels TFVC masqués
Pipelines Lire les résultats de build/mise en production Éditeurs et bibliothèque masqués
Test Plans Aucun accès Tests manuels indisponibles
Recherche Fonctionnalité de recherche complète Contenu accessible
Paramètres Aucun accès Fonctionnalités d’administration masquées

Prerequisites

Avant de modifier la visibilité du projet, vérifiez que vous répondez à ces exigences :

Requirement Détails
Permissions Administrateur de regroupement de projets ou propriétaire de l’organisation
Configuration de l’organisation Doit activer la stratégie « Autoriser les projets publics »
Révision de sécurité Terminer la liste de contrôle de migration

Liste de contrôle de sécurité de la prémigration

Warning

Les projets publics exposent des données historiques, notamment les anciens commits, les éléments de travail et les journaux de génération. Passez en revue attentivement tout le contenu avant de rendre un projet public.

Exposition de l’organisation et de l’identité

  • [ ] Informations sur les membres : tous les noms et adresses e-mail des membres de l’organisation deviennent visibles
  • [ ] Paramètres de l’organisation : affichage en lecture seule de tous les paramètres d’organisation et de projet exposés
  • [ ] Traiter les métadonnées : toutes les valeurs de liste de sélection dans les projets d’organisation deviennent visibles
  • [ ] Historique des builds : noms et adresses e-mail à partir de déclencheurs de build et validations Git exposées

Considérations sur les projets croisés

  • [ ] Artefacts liés : rechercher des liens vers des projets privés susceptibles d’exposer des informations sensibles
  • [ ] Ressources partagées : passer en revue les ressources au niveau de l’organisation accessibles par le projet

Révision de sécurité du contenu

Éléments de travail et outils Agile

  • [ ] Éléments de travail historiques : passez en revue tous les éléments de travail, y compris les éléments fermés, pour obtenir des informations sensibles
  • [ ] Sécurité du chemin d’accès de zone : vérifiez qu’aucun chemin d’accès à une zone n’a de restrictions de sécurité spéciales (autorisations refusées ignorées dans les projets publics)
  • [ ] Discussions et commentaires : Vérifiez toutes les discussions sur l’élément de travail pour le contenu sensible ou inapproprié

Référentiels de code source

  • [ ] Historique des validations : passez en revue l’intégralité de l’historique Git pour les informations d’identification, les vulnérabilités de sécurité ou le code propriétaire
  • [ ] Messages de validation : vérifiez tous les messages de validation pour des informations sensibles ou du contenu inapproprié
  • [ ] Contenu du fichier : vérifiez qu’aucun fichier ne contient d’informations d’identification, de clés API ou de données confidentielles

Pipelines de génération et de mise en production

  • [ ] Définitions de pipeline : Vérifier les informations d’identification exposées, les URL internes ou les détails de l’environnement
  • [ ] Journaux de génération : vérifier les journaux de build historiques pour obtenir des informations sensibles
  • [ ] Connexions de service : vérifiez qu’aucune dépendance de flux privé ne peut pas accéder aux personnes non membres

Artefacts et packages

  • [ ] Contenu du package : passez en revue tous les packages dans les flux dans l’étendue du projet pour connaître les préoccupations relatives à la confidentialité
  • [ ] Paramètres de flux : comprendre que les paramètres en amont sont désactivés pour les flux de projet publics

Extensions et personnalisations

  • [ ] Extensions personnalisées : Vérifier que les extensions fonctionnent correctement pour les non-membres
  • [ ] Personnalisations des formulaires d’élément de travail : tester des contrôles et des champs personnalisés avec un accès non membre

Étape 1 : Activer les projets publics pour votre organisation

  1. Connectez-vous à votre organisation (https://dev.azure.com/{yourorganization}).

  2. Sélectionnez Paramètres de l’organisation.

    Capture d’écran montrant le bouton Paramètres de l’organisation

  3. Sélectionnez Stratégies.

  4. Sous Stratégies de sécurité, activez Autoriser les projets publics.

    Capture d’écran montrant les paramètres de l’organisation, la page Stratégie, les stratégies de sécurité

Étape 2 : Modifier la visibilité du projet

  1. Accédez à votre projet (https://dev.azure.com/{yourorganization}/{yourproject}).

  2. Sélectionnez Paramètres du projet.

  3. Sélectionnez Vue d’ensemble.

  4. Dans le menu déroulant Visibilité , choisissez Public ou Privé.

  5. Cliquez sur Enregistrer.

    Capture d’écran montrant les paramètres du projet, vue d’ensemble, options de visibilité.

Gérer les contributeurs dans les projets publics

Ajouter des membres de projet

Ajoutez des contributeurs aux projets publics de la même façon que les projets privés :

  1. Accédez auxautorisations des> du projet.
  2. Sélectionnez Ajouter pour inviter des utilisateurs.
  3. Affectez les niveaux d’accès appropriés (Parties prenantes, De base ou De base + Plans de test).

Pour plus d’informations, consultez Ajouter des utilisateurs à votre organisation.

Considérations relatives à l’utilisateur externe

Lorsque vous invitez des utilisateurs externes à des projets publics :

  • Ils accèdent à tout le contenu public de votre organisation
  • Envisagez de créer des organisations distinctes pour des projets publics si vous avez du contenu sensible ailleurs

Autres approches pour le contenu sensible

Option 1 : Organisation distincte pour les projets publics

Si votre organisation actuelle contient des éléments sensibles :

  1. Créer une organisation spécifiquement pour les projets publics
  2. Migrer uniquement du contenu non sensible vers la nouvelle organisation
  3. Conserver les projets sensibles dans l’organisation privée d’origine

Option 2 : Migration sélective du contenu

Déplacer des éléments de travail sensibles

Migration d’info-bulles de référentiel Git

Pour les référentiels présentant un historique problématique, migrez uniquement l’état actuel :

Warning

Cette action crée un dépôt sans connexion à l’original. L’historique des demandes de tirage et le suivi des modifications sont perdus.

# Clone the existing repository
git clone <original_clone_URL>
cd <repository_name>

# Ensure you're on the desired branch
git checkout main

# Remove Git history
rm -rf .git  # On Windows: rmdir /s .git

# Initialize new repository
git init

# Connect to new repository in public project
git remote add origin <new_public_repo_URL>

# Push current state as initial commit
git add .
git commit -m "Initial public release"
git push --set-upstream origin main

Limitations pour les membres non membres

Les non-membres de projets publics ne peuvent pas effectuer les actions suivantes :

  • Modifier ou créer du contenu (fichiers, éléments de travail, pipelines)
  • Afficher les adresses e-mail ou les informations de contact des membres du projet
  • Accéder aux paramètres d’administration ou aux pages de configuration
  • Utiliser des fonctionnalités de recherche avancées au sein de l’organisation
  • Naviguer entre plusieurs projets publics dans la même organisation
  • Favoris ou suivis d’artefacts

Résoudre les problèmes d’accès au projet public

Problèmes courants

Problème : Les non-membres ne peuvent pas accéder au projet après l’avoir rendu public

  • Solution : vérifiez que la stratégie « Autoriser les projets publics » de l’organisation est activée

Problème : certains contenus apparaissent toujours restreints

  • Solution : rechercher les autorisations de refus susceptibles d’affecter des zones spécifiques

Problème : les utilisateurs externes ne peuvent pas contribuer

  • Solution : vérifiez qu’ils sont ajoutés en tant que membres du projet avec des niveaux d’accès appropriés

Étape suivante