Faire intervenir un prestataire externe sur un projet logiciel pose toujours les mêmes questions : faut-il donner accès au dépôt ? quels sont les risques ? comment garder le contrôle ?
Il existe une approche simple et robuste, largement utilisée avec GitHub : travailler via forks et Pull Requests, sans accès direct en écriture.
Travailler sans accès au dépôt principal
Un prestataire n’a pas besoin de droits en écriture pour contribuer à votre projet.
Le fonctionnement est simple :
- il crée une copie du dépôt (fork)
- il développe les modifications sur cette copie
- il propose une Pull Request
- vous validez (ou non) l’intégration
Votre dépôt principal reste inchangé tant que vous n’avez rien validé.
Étape 1 : donner un accès en lecture
Sur un dépôt privé, le prestataire doit pouvoir cloner le code.
Repository → Settings → Collaborators and teams → Add people
- Ajouter l’utilisateur GitHub du prestataire
- Lui attribuer le rôle : Read
👉 Ce rôle permet :
- de cloner le dépôt
- de créer un fork (si autorisé)
- de proposer des Pull Requests
👉 Il ne permet pas :
- de pousser du code
- de modifier le dépôt
C’est le niveau d’accès minimal recommandé pour démarrer.
Étape 2 : autoriser le fork (si nécessaire)
C’est le seul point technique à vérifier, et celui qui bloque le plus souvent.
Sur un dépôt privé, le fork dépend de la configuration de l’organisation.
1. Activer le fork au niveau de l’organisation
Sur votre GitHub, aller dans : Organization Settings → Member privileges → Repository forking
Vérifier que l’option Allow forking of private repositories est activée
2. Vérifier le fork au niveau du dépôt
Dans : Repository → Settings → General → Forking
Vérifier que Allow forking est activé
👉 Si l’option est grisée, cela signifie que l’organisation ne l’autorise pas
👉 Documentation officielle :
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-the-forking-policy-for-your-repository
Étape 3 : fonctionnement de la collaboration
Une fois ces deux éléments en place :
- Le prestataire clone ou fork le dépôt
- Il travaille sur sa copie
- Il propose une Pull Request
- Vous relisez et validez
Pourquoi ce modèle est efficace
Ce fonctionnement repose sur une séparation claire :
- Lecture autorisée → le prestataire peut travailler
- Écriture interdite → vous gardez le contrôle
- Validation obligatoire → rien n’est intégré sans accord
Chaque modification est visible, discutée et tracée.
Cas où le fork n’est pas possible
Certaines organisations désactivent volontairement le fork.
Dans ce cas, deux options :
Option 1 — Accès direct
Repository → Settings → Collaborators → Add people → Role: Write
Plus simple, mais moins cloisonné.
Option 2 — Dépôt intermédiaire
Vous créez un dépôt miroir sur lequel le prestataire a accès, puis vous intégrez les changements manuellement.
En pratique
Pour démarrer rapidement, vérifiez ces trois points :
- Accès lecture donné
→ Repository → Settings → Collaborators → Role: Read - Fork autorisé au niveau organisation
→ Organization Settings → Member privileges - Fork activé sur le dépôt
→ Repository → Settings → General
Si ces trois éléments sont en place, la collaboration peut démarrer immédiatement, sans accès en écriture.
