Gérer un produit réparti sur plusieurs dépôts GitHub

Un produit moderne vit rarement dans un seul dépôt. Le front, l’API, l’application mobile et l’infrastructure ont chacun leur rythme, leurs relectures et souvent leurs équipes. Le code y gagne en clarté ; la gestion de projet, elle, se complique.

Le piège du « un dépôt, un tableau »

Le réflexe courant consiste à suivre chaque dépôt séparément, avec ses propres issues. Très vite, une même évolution se retrouve découpée en trois tickets dans trois endroits différents, et plus personne n’a de vue d’ensemble.

Le problème n’est pas technique : le découpage du code ne correspond pas au découpage du travail. Un client ne demande pas « une modification de l’API », il demande une fonctionnalité.

Partir du produit, pas du code

L’approche inverse consiste à créer un projet par produit, puis à y rattacher les dépôts qui le composent. Les tickets décrivent ce que l’on livre ; les dépôts indiquent où le travail aura lieu.

• Un ticket peut concerner plusieurs dépôts à la fois.
• Le tableau se filtre par dépôt quand une équipe veut se concentrer sur sa partie.
• Les specs et les maquettes vivent au niveau du projet, pas dispersées dans chaque dépôt.

Trois habitudes qui aident

Nommez les tickets du point de vue de l’utilisateur plutôt que du composant. Gardez une seule source de vérité pour les statuts : si un ticket est « En revue », il l’est pour tout le monde. Enfin, passez régulièrement en revue les tickets sans dépôt : ce sont souvent des décisions à prendre plutôt que du code à écrire.

C’est l’organisation que Grepo propose par défaut : un projet, plusieurs dépôts, un seul tableau.