Quelles sont les stratégies monorepo vs polyrepo ?

Question

Accepted Answer

**Monorepo** (un référentiel pour de nombreux projets/services) et **polyrepo** (un référentiel distinct par projet) sont deux stratégies pour organiser le code sur plusieurs projets. Chacune présente des compromis importants affectant la collaboration, l'outillage et la scalabilité — les comprendre éclaire les décisions architecturales importantes.

## Monorepo — un référentiel pour tout

```text
Many projects/services/libraries in a SINGLE repository:
  ✓ SHARED code/libraries easy to use and refactor (one place, atomic changes)
  ✓ ATOMIC commits across projects (change an API and all its consumers together)
  ✓ Unified tooling, versioning, CI; consistent standards; easy cross-project visibility
  ✓ Simplified dependency management (one version of shared code)
  ✗ Repo can get HUGE (needs scaling tooling — sparse checkout, build caching)
  ✗ Needs sophisticated build/CI tooling (Nx, Turborepo, Bazel) to be efficient
  ✗ Broad access; CI must be smart (only build what changed)
→ Used by Google, Meta, etc. (with heavy tooling investment).
```

## Polyrepo — un référentiel par projet

```text
Each project/service/library in its OWN repository:
  ✓ Clear OWNERSHIP and boundaries; independent versioning/releases/CI
  ✓ Smaller, focused repos; granular access control; independent teams
  ✗ SHARED code is harder (publish/consume packages; version coordination)
  ✗ Cross-cutting changes span MANY repos (coordinate multiple PRs — painful)
  ✗ Potential inconsistency across repos (tooling, standards drift)
→ Common default; fits independent services/teams.
```

## Choix

```text
MONOREPO → tightly-coupled projects, heavy code sharing, want atomic cross-project
  changes and unified tooling, willing to invest in scaling tooling
POLYREPO → independent projects/teams, clear boundaries, independent release cycles,
  simpler per-repo needs
→ No universal answer; depends on the org, coupling, scale, and tooling investment.
```

## Pourquoi c'est important

Comprendre les stratégies monorepo vs polyrepo est une connaissance de niveau senior précieuse pour **prendre des décisions architecturales judicieuses concernant l'organisation du code**, un choix significatif aux implications larges, donc utile pour les rôles senior/architecturaux.

Les deux approches — **monorepo** (de nombreux projets dans un référentiel) et **polyrepo** (un référentiel distinct par projet) — représentent des philosophies organisationnelles fondamentalement différentes avec des compromis réels. Les avantages du **monorepo** (facilité du code partagé et du refactoring, **commits atomiques multi-projets** — modification d'une API et de tous ses consommateurs ensemble, outillage et normes unifiés, gestion simplifiée des dépendances) le rendent puissant pour les projets fortement couplés avec partage de code important, mais cela nécessite un investissement significatif dans **l'outillage de scalabilité** (Nx, Turborepo, Bazel, checkout partiel, CI intelligent) pour gérer efficacement le grand référentiel. Les avantages du **polyrepo** (propriété et limites claires, cycles de versioning et de release indépendants, petits référentiels focalisés, accès granulaire) conviennent aux projets et équipes indépendants, mais rendent **le code partagé plus difficile** (publication/consommation de packages, coordination des versions) et **les changements transversaux douloureux** (coordination des PRs sur plusieurs référentiels).

Comprendre ces compromis et comment **choisir** (monorepo pour les projets fortement couplés avec partage de code disposés à investir dans l'outillage ; polyrepo pour les projets et équipes indépendants avec limites claires) reflète le jugement architectural attendu aux niveaux senior — reconnaître qu'il n'y a pas de réponse universelle et que le bon choix dépend du couplage, de l'échelle, de la structure de l'équipe et de l'investissement en outillage.

Puisque l'organisation du code sur plusieurs projets est une décision architecturale significative affectant la collaboration, l'outillage, la scalabilité et l'autonomie de l'équipe, et puisque la compréhension des compromis monorepo/polyrepo éclaire ce choix conséquent, comprendre les stratégies monorepo vs polyrepo est une connaissance senior précieuse pour la prise de décisions architecturales, un sujet fréquemment débattu où comprendre les compromis (plutôt que de favoriser dogmatiquement l'une des deux) reflète le jugement mature attendu pour les rôles senior façonnant la façon dont une organisation structure son code.