Comprendre les Permissions Utilisateurs sur GitLab
Pourquoi des niveaux d'accès différents ?
Dans un projet professionnel, tout le monde n'a pas besoin de pouvoir tout modifier. Donner les droits de suppression à un stagiaire qui vient d'arriver ou un accès en écriture à un client qui veut juste suivre l'avancement est un risque inutile. C'est pour cela que GitLab propose des niveaux de permissions granulaires.
Le but est de protéger la branche principale (souvent le code qui tourne en production) tout en permettant à chacun de contribuer efficacement selon son rôle. Bien configurer ces droits, c'est s'assurer que le projet avance sans accrocs techniques ou sécuritaires.
Les rôles principaux sur GitLab
Pour simplifier la gestion, GitLab regroupe les droits dans des rôles prédéfinis. Voici ce qu'il faut retenir pour chaque profil :
-
Guest (Invité) : Le rôle le plus restrictif. Il est idéal pour les personnes qui doivent suivre le projet sans toucher au code (clients, managers). Ils peuvent voir les tickets et laisser des commentaires, mais ne voient pas le code source dans un cadre privé.
-
Reporter (Rapporteur) : Le rôle parfait pour les testeurs ou observateurs techniques. Ils peuvent lire et télécharger le code, mais ils n'ont pas le droit de le modifier ou de créer des branches.
-
Developer (Développeur) : Le rôle standard pour l'équipe technique. Un développeur peut créer des branches, pousser du code sur les branches non protégées et créer des demandes de fusion (Merge Requests).
-
Maintainer (Mainteneur) : C'est l'administrateur du projet. Il a tous les droits : configurer les accès, gérer les runners de CI/CD et surtout, il peut modifier les branches protégées comme le main.
Voici un résumé des actions autorisées selon le rôle attribué à l'utilisateur :
| Action | Guest | Reporter | Developer | Maintainer |
|---|---|---|---|---|
| Créer des tickets et commenter | ✅ | ✅ | ✅ | ✅ |
| Lire et télécharger le code | ❌ | ✅ | ✅ | ✅ |
| Créer des branches / MR | ❌ | ❌ | ✅ | ✅ |
| Gérer les Jalons (Milestones) | ❌ | ❌ | ✅ | ✅ |
| Ajouter de nouveaux membres | ❌ | ❌ | ❌ | ✅ |
| Gérer les variables CI/CD et Runners | ❌ | ❌ | ❌ | ✅ |
Information importante
Le rôle Guest ne peut pas lire ni télécharger le code sur un projet Privé ou Interne. Cependant, sur un projet Public, tout utilisateur (y compris Guest) peut accéder au code source.
Comment modifier les permissions ?
Si vous avez déjà ajouté un membre et que vous souhaitez changer son rôle, la procédure pour modifier les accès est très rapide.
Accéder à la liste des membres
Allez dans le menu Settings puis sélectionnez Members.
Changer le rôle d'un collaborateur
En face du nom de l'utilisateur, cliquez sur le menu déroulant de sa permission actuelle et sélectionnez le nouveau rôle souhaité. La mise à jour est instantanée.
"Le changement de rôle s'applique sans avoir besoin de rafraîchir la page"
Conclusion
Une bonne gestion des permissions est le socle d'un projet sécurisé. En tant que Mainteneur, votre rôle est de veiller à ce que chacun ait assez de liberté pour travailler, sans pour autant mettre en péril la stabilité du code final.
Maintenant que votre équipe est configurée avec les bons accès, vous allez pouvoir commencer à organiser les tâches à accomplir. Pour cela, GitLab propose un outil indispensable : le Système de Tickets (Work items). C'est ce que nous allons découvrir dès maintenant.
Espace commentaire
Écrire un commentaire
Rejoignez la discussion
Vous devez être connecté pour poster un message.
28 commentaires
Comment je fais pour qu'un client puisse juste voir le code sans pouvoir merger ?
C'est tout à fait normal. Le rôle Developer ne permet pas de modifier les branches protégées. À ne jamais faire en prod : donner le rôle Maintainer à tout le monde.
Vérifie les réglages des protected branches dans ton interface.
J'ai un souci, mes dev n'arrivent pas à push sur
mainalors qu'ils ont le rôle Developer. C'est normal ?