Polyrepo (Multi-repository)

Le Polyrepo (Multi-repository) est la stratégie traditionnelle d'organisation de code consistant à héberger chaque projet, microservice ou library dans son propre dépôt Git séparé. Approche par défaut pour la plupart des entreprises modernes, dominante dans l'écosystème open source (chaque projet npm/PyPI/Cargo a son repo).

Avantages : (1) ownership claire par équipe/service — un repo, une équipe responsable, un on-call ; (2) access control fin via Git permissions (private repos, restricted teams) ; (3) versioning indépendant (semver par service) — service A v1.5 utilise lib X v2.3, service B v2.0 utilise lib X v3.0 simultanément ; (4) déploiement et release cycles indépendants ; (5) tooling/CI configuration adapté par projet (langages différents, build systems différents) ; (6) onboarding plus rapide (developer focus on 1 repo) ; (7) Git operations performantes (small repos, fast clone/log/status) ; (8) bonne fit pour open source (chacun fork son repo).

Inconvénients : (1) cross-repo refactoring difficile — changer API d'une library requiert PRs coordonnés sur N repos consumers, plus de risk de breakage ; (2) versioning hell — N services consomment lib commune, lockfile drift, dependency upgrade nightmare ; (3) duplication de boilerplate (CI configs, lint configs, Dockerfiles répétés N fois — peut être atténué via templates/scaffolds, GitHub template repos, internal cookiecutter) ; (4) discoverability faible (devs ne savent pas quels repos existent, where to find shared utility) ; (5) inconsistency code style/practices entre teams ; (6) integration testing cross-service complex (need test environments avec multiple services deployed) ; (7) shared library development friction (publish version, wait, update consumers).

Management strategies pour polyrepo : (1) shared internal package registry (npm Enterprise, Artifactory, GitHub Packages, AWS CodeArtifact) pour libs ; (2) GitHub Organizations pour grouper repos + Teams pour access control ; (3) GitHub topics et search pour discovery ; (4) Backstage (Spotify open source) — developer portal centralisé indexant tous les services, owners, docs, runbooks, dependencies ; (5) Repository templates / Scaffolds (Yeoman, Cookiecutter, GitHub template repos) for consistency ; (6) Renovate / Dependabot pour automated dependency updates cross-repo ; (7) shared CI/CD config via reusable workflows GitHub Actions / GitLab CI includes ; (8) inner-source culture (any developer can contribute to any repo via PR).

Quand préférer Polyrepo : (1) microservices avec strong autonomy per team (Spotify, Uber initialement, Amazon) ; (2) open source ecosystem ; (3) acquisition rolling-up — chaque acquired startup garde ses repos ; (4) regulatory isolation (PCI scope reduction) ; (5) very large org > 10k devs avec teams independent ; (6) polyglot extreme avec build systems trop disparates pour unifier.

Quand préférer Monorepo : (1) early-stage with small team needing speed of refactor ; (2) tightly coupled internal libs ; (3) want enforce consistency forcefully ; (4) have engineering bandwidth pour invest in advanced build systems (Bazel, Nx).

Hybrid patterns common : (1) macro-monorepos per domain (frontend monorepo, backend monorepo, data monorepo) plutôt qu'extremes ; (2) monorepo for shared libs + polyrepo for services ; (3) trunk-based dev + feature branches même en polyrepo. Compétences DOP-C02, AZ-400, GH-FOUND.