À partir de quelle taille de dépôt une équipe a-t-elle besoin d'outillage de build monorepo au-delà de Git seul ?

Question ouverte

Un dépôt unique pour plusieurs services et bibliothèques peut fonctionner longtemps avec les seules fonctionnalités de Git et des règles de CI simples : sparse checkout en mode cône, clones partiels sans blobs, filtres de chemin décidant quelles tâches du pipeline s'exécutent, et un fichier CODEOWNERS. À un certain point, les équipes adoptent un outil de graphe de build dédié (un exécuteur de tâches conscient des dépendances et doté d'un cache distant, ou un système de build hermétique) et restructurent souvent le dépôt autour de lui.

Où se situe ce point ? Parmi les seuils candidats évoqués dans des retours d'expérience publics figurent le nombre de projets, le nombre de contributeurs qui poussent des commits par jour, le temps réel d'exécution d'une CI complète, la taille du clone, et la part des builds qui sont de purs répétitions de code inchangé. On ne sait pas clairement lequel de ces facteurs impose réellement le changement, ni si l'outillage a été adopté à cause d'une douleur mesurée ou à cause de ce que publient les organisations plus grandes.

Une incertitude connexe porte sur le coût : la durée de la migration, la proportion de définitions de build qu'il a fallu réécrire, si le nouvel outil a ensuite été retiré, et quelles mesures au niveau de Git (sparse checkout, clone partiel, worktrees) ont été conservées par la suite.

Ce qu'une réponse utile contient

• Les faits relatifs au dépôt au moment de la décision : nombre de projets et de langages, nombre de contributeurs, commits par jour, taille du clone, durée de CI avant et après.
• L'élément déclencheur concret, et si une mesure moins coûteuse (CI filtrée par chemin, mise en cache dans le pipeline existant) a été essayée d'abord, et pourquoi elle n'a pas suffi.
• L'outil choisi, l'effort de migration en semaines-personnes, et les problèmes rencontrés durant les premiers mois.
• Si le résultat a été mesuré (taux de succès du cache, temps médian de CI, délai jusqu'au premier build pour un nouveau contributeur) et quels étaient ces chiffres.
• Des cas où des équipes en sont restées à Git seul à des tailles que d'autres ont jugées ingérables, et les pratiques qui l'ont permis.
• Les réponses devraient distinguer les témoignages directs des résumés de rapports d'autrui.