GitHub Organizations & Collaboration d'Équipe

Niveau : Intermediate

Durée : 1h15

Prérequis

Maîtriser les bases de Git (commits, branches, fusions)
Savoir collaborer sur GitHub (Issues, Pull Requests, Code Reviews)

Objectifs d'apprentissage

Comprendre le but et l'architecture d'une GitHub Organization
Distinguer les rôles de membres (Owners vs Members)
Savoir créer et gérer des équipes (Teams) et structurer les permissions
Maîtriser les différents niveaux de permissions de dépôts (Read, Triage, Write, Maintain, Admin)
Configurer et appliquer des Branch Protection Rules sur la branche principale

Progression dans cet atelier 0%

Slides PDF PPTX

1. Pourquoi les GitHub Organizations existent-elles ?

Les logiciels modernes ne sont presque jamais construits seuls. Ils sont construits par des équipes. Si Git permet de gérer l’historique du code sur votre machine, GitHub permet de gérer la collaboration. Cependant, lorsque le nombre de collaborateurs augmente, gérer les accès utilisateur par utilisateur devient impossible.

Sans organisation (Comptes individuels)

Imaginez une communauté ou une entreprise de 50 développeurs. Sans structure centralisée, chaque développeur possède ses propres dépôts sur son compte personnel.

Permissions compliquées : Il faut inviter manuellement chaque collaborateur sur chaque dépôt individuel.
Accès dispersés : Le code est éparpillé sur des dizaines de comptes personnels différents.
Aucune gouvernance : Pas de possibilité de définir des standards de sécurité ou de qualité globaux.
Sécurité limitée : Risque élevé de fuites de code si un compte personnel est compromis.

Avec une GitHub Organization

Une GitHub Organization est un espace partagé qui centralise tous les projets et rassemble tous les collaborateurs sous une entité unique.

flowchart TD
    Org[HashCode Community - Organization]
    Org --> Repos[Repositories]
    Org --> Members[Collaborateurs]
    Org --> Teams[Équipes]
    
    Repos --> W[workshops]
    Repos --> OS[operation-sentinel]
    Repos --> L[labs]
    
    Teams --> Eng[Engineering]
    Teams --> Sec[Security]
    Teams --> Doc[Documentation]

Tout est centralisé au même endroit. Cela permet de simplifier la facturation, d’harmoniser les politiques de sécurité (comme la double authentification obligatoire) et de structurer le travail.

2. Membres et Rôles au sein de l’Organisation

Une GitHub Organization contient principalement deux grands types de comptes utilisateurs :

Les Owners (Propriétaires)

Ils ont un contrôle administratif total sur l’ensemble de l’organisation.

Créer et supprimer des dépôts (repositories).
Ajouter, inviter ou retirer des membres de l’organisation.
Créer et structurer des équipes (Teams).
Gérer les paramètres de facturation et de sécurité globale.

Les Members (Membres)

Ce sont les collaborateurs réguliers de l’organisation.

Ils collaborent sur les dépôts auxquels ils ont accès.
Ils peuvent faire partie d’équipes internes.
Ils ne peuvent pas modifier les paramètres de l’organisation ni supprimer les dépôts stratégiques.

3. La gestion des Équipes (Teams)

Il est extrêmement fastidieux de lier 50 développeurs à 20 dépôts différents un par un. C’est pourquoi GitHub propose les Teams.

Une Team représente un groupe de personnes au sein de l’organisation. Les permissions ne sont plus attribuées à des individus, mais directement à des équipes.

Exemple de structure d’équipes pour HashCode Community :

HashCode Community
│
├── Core Team
├── Engineering
├── DevOps
├── Security
├── Documentation
├── Workshop Mentors
└── Contributors

Mécanisme de cascade de permissions :

Si vous attribuez à la Team Documentation la permission Write sur les dépôts workshops, academy-assets et website, chaque nouveau membre ajouté à cette équipe héritera automatiquement et instantanément de ces droits.

4. Les Niveaux de Permissions sur les Dépôts

GitHub propose 5 niveaux de permissions gradués pour contrôler ce que chaque équipe peut faire sur un dépôt spécifique :

Niveau	Description des Droits	Usage Type
`Read`	Peut voir le code, cloner le dépôt et ouvrir des Issues/Discussions. Ne peut pas pousser de code directement.	Contributors (nouveaux venus, externes)
`Triage`	Peut faire tout ce que fait `Read`, plus gérer les Issues, les labels, assigner des tâches et fermer des tickets. Ne peut pas modifier le code.	Workshop Mentors / Project Managers
`Write`	Peut faire tout ce que fait `Triage`, plus pousser du code sur des branches hors-main et ouvrir/valider des Pull Requests.	Engineering Team (Développeurs actifs)
`Maintain`	Peut gérer les paramètres du dépôt (sans les droits d’administration destructeurs comme supprimer le dépôt) et gérer les règles de protection de branches.	Maintainers / Tech Leads
`Admin`	Contrôle total du dépôt : accès aux secrets de CI/CD, gestion des collaborateurs et possibilité de supprimer le dépôt.	Founders / Core Team

5. Workflow de Collaboration Moderne en Équipe

Dans une équipe d’ingénierie professionnelle, les développeurs ne poussent jamais directement leur code sur la branche principale (main). Ils suivent un cycle de développement strict et balisé.

Le Cycle de Vie d’une Fonctionnalité :

flowchart LR
    Issue[1. Issue] --> Assign[2. Assignation]
    Assign --> Branch[3. Branche]
    Branch --> Commit[4. Commits & Push]
    Commit --> PR[5. Pull Request]
    PR --> Review[6. Review & Approval]
    Review --> Merge[7. Merge & Tag]

Assignation Claire des Rôles

Pour éviter toute ambiguïté, chaque étape possède un responsable précis :

Une Issue = un responsable unique (Assignee) qui s’engage à la résoudre.
Une Pull Request = un auteur qui a écrit le code.
Une Review = un ou plusieurs relecteurs désignés qui apportent un œil critique et constructif.

6. Règles de Protection de Branches (Branch Protection Rules)

Puisque la branche main représente la version stable de votre application en production, elle doit être protégée contre les erreurs humaines et le code instable.

Sur GitHub, un administrateur ou un mainteneur peut configurer des Branch Protection Rules sur main.

Configuration Standard Recommandée (HashCode Standards) :

Interdire les Pushs directs sur la branche main : Tout changement doit obligatoirement transiter par une Pull Request.
Exiger au moins une validation (Approval) : La PR ne peut pas être fusionnée si elle n’a pas été formellement validée par au moins un autre développeur qualifié.
Exiger que les tests passent (Status Checks) : Le pipeline de CI/CD (ex: GitHub Actions) doit obligatoirement être au vert (tests unitaires réussis, pas de vulnérabilité détectée) avant de pouvoir fusionner.
Exiger des branches à jour : Le code de la branche de fonctionnalité doit être synchronisé avec les derniers commits de main avant la fusion pour éviter les régressions silencieuses.

Fiches de révision

Question

Quelle est la différence majeure entre un Owner et un Member dans GitHub ?

Cliquer pour révéler la réponse

Réponse

L'Owner dispose d'un accès administratif total à l'organisation (facturation, sécurité, suppression), tandis que le Member collabore sur les dépôts affectés.

Cliquer pour voir la question

Question

Quel niveau de permission est idéal pour un développeur de l'équipe engineering ?

Cliquer pour révéler la réponse

Réponse

Le niveau Write (pour créer des branches, pousser son code et ouvrir des Pull Requests).

Cliquer pour voir la question

Question

Pourquoi crée-t-on des Teams sur GitHub ?

Cliquer pour révéler la réponse

Réponse

Pour gérer les permissions de manière centralisée et les affecter en cascade à un groupe d'utilisateurs sur plusieurs dépôts.

Cliquer pour voir la question

Question

À quoi sert le principe du Moindre Privilège (Least Privilege) ?

Cliquer pour révéler la réponse

Réponse

À accorder uniquement les accès et permissions strictement nécessaires pour accomplir une tâche, afin de limiter la surface d'attaque et les erreurs.

Cliquer pour voir la question

Quiz de validation

1. Un collaborateur externe doit pouvoir lire le code et ouvrir des tickets de bug, mais ne doit pas pouvoir toucher au code. Quelle permission lui attribuez-vous ?

2. Quelle règle de protection de branche empêche un développeur de pousser directement un correctif rapide sur la branche main sans passer par une PR ?

3. Qui est responsable de la décision finale de fusionner une Pull Request dans un cadre d'équipe standardisé ?

Prochaine étape

Félicitations ! Vous avez acquis une vision complète de l’ingénierie collaborative à l’échelle d’une organisation d’ingénieurs. Clôturons ce parcours par une rétrospective complète de ce que vous avez appris, et préparons votre certification finale !

Prochain atelier

15. Rétrospective & Certification

Labs associés

Lab Niveau 16 — GitHub Organizations