Comment une agence doit-elle versionner ses projets clients sur GitHub ?
Une agence doit versionner chaque projet client dans un dépôt privé distinct, rattaché à une organisation GitHub plutôt qu'à un compte personnel, avec des accès nommés par collaborateur, une branche principale protégée, et un transfert de propriété planifié dès la signature du contrat.
Une agence versionne chaque projet client dans un dépôt privé séparé au sein d'une organisation GitHub, avec des accès individuels par rôle, une branche principale protégée, et un transfert de propriété planifié dès la fin du contrat.
Pourquoi le versionning change la donne pour une agence ?
Une agence qui gère plusieurs projets clients en parallèle, avec une équipe qui change au fil des missions, ne peut pas se permettre de perdre du code ou de laisser un projet sur l'ordinateur d'un seul développeur. Notre article c'est quoi GitHub présente la plateforme ; celui-ci se concentre sur son organisation concrète à l'échelle d'une agence avec plusieurs clients.
Un compte collectif qui appartient à l'agence, jamais à une seule personne qui peut partir.
Chaque projet client vit dans son propre dépôt, isolé des autres clients.
L'historique de commits documente qui a livré quoi, et quand, en cas de litige ou de transfert.
Comment organiser ses dépôts, projet par projet ?
La règle de base : un dépôt par projet client, jamais un dépôt fourre-tout qui mélange plusieurs clients ou plusieurs sites. Un nom de dépôt explicite (par exemple dupont-site-vitrine ou client-refonte-2026) permet de retrouver immédiatement le bon projet sans ouvrir chaque dépôt pour vérifier.
Cette organisation suppose un compte d'organisation GitHub (gratuit pour les petites équipes, puis facturé par utilisateur sur l'offre Team), distinct des comptes personnels des collaborateurs. L'agence reste ainsi propriétaire légale de tous les dépôts, même quand un développeur quitte l'équipe. Notre tutoriel comment créer son premier dépôt GitHub détaille la mécanique de base si ce n'est pas encore en place.
Visibilité par défaut : privé, sans exception, pour tout code appartenant à un client. Le passage en public ne se discute qu'avec l'accord explicite du client, et seulement pour un projet qui n'expose aucune information sensible.
Comment gérer les accès par client et par collaborateur ?
GitHub permet d'attribuer un rôle précis à chaque personne sur chaque dépôt, plutôt qu'un accès global identique pour tout le monde.
| Rôle | Pour qui | Droits |
|---|---|---|
| Admin | Dirigeant ou lead technique | Gère les accès, supprime ou transfère le dépôt |
| Maintain | Développeur référent du projet | Gère les branches et les paramètres, sans accès aux droits d'administration |
| Write | Développeur sur le projet | Pousse du code, ouvre des pull requests |
| Triage | Chef de projet | Gère les tickets (issues) sans modifier le code |
| Read | Client, en option | Consulte l'avancement sans pouvoir modifier quoi que ce soit |
Ajouter le contact technique du client en lecture seule rassure sur la transparence du travail sans ouvrir la porte à une modification involontaire. À l'inverse, retirer l'accès d'un collaborateur qui quitte l'agence doit être systématique et immédiat : un ancien salarié ou freelance qui garde un accès actif à des dépôts clients est un risque de sécurité, pas un oubli anodin.
Quelles conventions de branches et de commits adopter ?
- Branche
mainprotégée : aucune modification poussée directement, tout passe par une pull request relue par un second développeur avant fusion. - Une branche par fonctionnalité, nommée de façon descriptive (
feature/formulaire-contact,fix/bug-paiement), supprimée une fois fusionnée. - Messages de commit explicites, idéalement reliés au ticket ou à la demande du client, pour reconstituer l'historique sans deviner.
- Pull requests même en solo : elles gardent une trace des changements majeurs et facilitent la relecture a posteriori.
Ce socle de discipline évite qu'un projet client ne devienne illisible dès qu'un deuxième développeur doit y intervenir, parfois plusieurs mois après la livraison initiale.
Comment protéger les secrets et les identifiants clients ?
Un dépôt de projet client contient rarement que du code : il côtoie souvent des identifiants de base de données, des clés d'API ou des mots de passe d'accès à des services tiers.
Un identifiant client poussé par erreur dans un commit reste consultable dans l'historique du dépôt, même après suppression du fichier : la seule réponse fiable est de révoquer immédiatement l'identifiant concerné, puis d'utiliser systématiquement un fichier .env exclu par .gitignore.
Pour les automatisations qui tournent directement dans GitHub (GitHub Actions), les identifiants doivent être stockés dans les Secrets du dépôt ou de l'organisation, jamais écrits en clair dans un fichier de configuration. Les mots de passe applicatifs partagés avec un client (comme un Application Password WordPress) doivent en outre être changés à chaque fin de mission.
Comment transférer un dépôt au client en fin de mission ?
- 1. Prévoir le transfert au contratLa propriété du code livré revient contractuellement au client : le transfert de dépôt n'est pas une faveur, c'est une obligation à anticiper.
- 2. Ouvrir Settings → Danger ZoneSur le dépôt concerné, l'option « Transfer ownership » déclenche le changement de propriétaire.
- 3. Renseigner le compte ou l'organisation du clientLe client doit disposer d'un compte GitHub (personnel ou organisation) pour recevoir le dépôt.
- 4. Garder un accès de maintenance si besoinSi un contrat de maintenance continue, l'agence redevient simple collaboratrice du dépôt transféré, avec un rôle Write plutôt que Admin.
Ce transfert ferme proprement la mission : le client détient désormais l'historique complet, sans dépendre d'un compte d'agence qui pourrait disparaître.
Ce que nous appliquons sur les projets que nous accompagnons
Voici un exemple représentatif de notre pratique, sans donnée client ni chiffre inventé.
Une organisation GitHub, jamais un compte personnel de développeur
Chez Amari Agency, chaque projet client vit dans un dépôt privé dédié au sein de notre organisation GitHub, nommé selon le format client-projet, avec un .gitignore complet dès la création. Le contact technique du client est ajouté en lecture seule dès le démarrage pour suivre l'avancement sans pouvoir modifier le code, et la propriété du dépôt est officiellement transférée à la fin du contrat quand le projet le prévoit.
Quelles erreurs fréquentes éviter ?
Bonnes pratiques
- Dépôt privé par défaut, visibilité publique uniquement sur accord explicite du client.
- Propriétaire identifiable : l'organisation de l'agence, jamais un compte personnel.
- Pull request relue avant toute fusion sur la branche principale.
Erreurs qui coûtent cher
- Dépôt créé sous le compte GitHub personnel d'un développeur qui peut quitter l'agence du jour au lendemain.
- Client qui découvre en fin de contrat qu'il ne peut pas récupérer son code faute de transfert prévu.
- Accès laissé actif à un ancien collaborateur ou freelance.
Quels contenus lire ensuite ?
Ces ressources complètent ce guide sans cibler la même requête :
Questions fréquentes sur le versionning des projets clients
Faut-il un compte GitHub par client ?
Non, l'agence garde un seul compte d'organisation et crée un dépôt distinct pour chaque projet client, avec des accès gérés individuellement par dépôt.
Combien coûte un plan GitHub Team pour une agence ?
L'offre Team est facturée par utilisateur et par mois ; une petite agence avec quelques collaborateurs reste sur un budget modeste, largement compensé par la sécurité apportée sur les projets clients.
Comment retirer l'accès d'un collaborateur qui quitte l'agence ?
Depuis les paramètres de l'organisation, il suffit de retirer la personne de l'organisation : elle perd instantanément l'accès à tous les dépôts, sans avoir à le faire dépôt par dépôt.
Le client peut-il réclamer le code en cours de contrat ?
Cela dépend des termes contractuels, mais ajouter le client en lecture seule dès le démarrage évite ce type de tension : il voit l'avancement sans avoir besoin de réclamer un accès complet.
Faut-il rendre le dépôt public pour rassurer le client ?
Non, un accès en lecture seule au dépôt privé suffit largement : la visibilité publique n'apporte rien à la relation client et expose inutilement le code.