Monorepo vs Polyrepo : Quelle stratégie GitOps pour vos Microservices Kubernetes ?

Gérer une poignée de microservices est un jeu d'enfant. Mais passer à l'échelle avec plus de 50 services plonge souvent les équipes dans le "Repository Hell". Le choix entre un dépôt unique (Monorepo) et des dépôts multiples (Polyrepo) n'est pas qu'une question de préférence : c'est une décision structurante qui impacte directement la performance de votre CI/CD, la vélocité des développeurs et la sécurité de votre cluster Kubernetes.

Dans cet article, nous analysons les impacts concrets sur le RBAC, le temps de build et le "Blast Radius" pour vous aider à trancher.

🛠 Prérequis Techniques

Avant d'implémenter ces stratégies, assurez-vous de disposer de la stack suivante :

Orchestrateur : Cluster Kubernetes (v1.24+).
GitOps Controller : Argo CD (recommandé pour les ApplicationSets) ou Flux.
CI Tool : GitLab CI, GitHub Actions ou Jenkins (avec support des triggers conditionnels).
VCS : Git avec accès administrateur pour configurer les règles de protection (Branch Protection).

🔍 Analyse des modèles et structures

Scénario A : Le modèle Polyrepo (Isolation forte)

C'est l'approche "native" des microservices : un dépôt Git par service. Elle favorise le découplage fort et l'autonomie des équipes.

Structure typique :

# Dépôt: service-payment
├── charts/             # Helm chart dédié au service
├── src/                # Code source applicatif
├── Dockerfile
└── .github/workflows/  # Pipeline CI isolé

# Dépôt: service-auth
├── ... (structure identique totalement indépendante)

L'Arme secrète : Argo CD ApplicationSet

Gérer 50 dépôts manuellement est impossible. L'utilisation d'un ApplicationSet avec un générateur SCM est obligatoire pour détecter automatiquement les nouveaux repos.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: polyrepo-apps
spec:
  generators:
  - scmProvider:
      github:
        organization: YOUR_ORG_NAME
        tokenRef:
          secretName: github-token
          key: token
        # Filtre intelligent pour ne cibler que les repos de services
        filters:
        - repositoryMatch: "service-*"
  template:
    metadata:
      name: '{{ repository }}'
    spec:
      source:
        repoURL: '{{ url }}'
        targetRevision: HEAD
        path: charts/app
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{ repository }}'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Scénario B : Le modèle Monorepo (Cohérence forte)

Tout le code, l'IaC et les configurations vivent dans un seul dépôt géant. C'est le modèle favorisé par les géants (Google, Meta) pour maximiser la réutilisation du code.

Structure typique :

# Dépôt: monorepo-platform
├── apps/
│   ├── payment/        # Code + Chart + Tests
│   └── auth/
├── libs/               # Bibliothèques partagées (le grand atout du Monorepo)
├── infra/
│   └── k8s-manifests/  # Définitions GitOps globales
└── .github/workflows/  # CI unifié

L'enjeu critique : L'optimisation de la CI

Dans un Monorepo, interdiction de tout rebuilder à chaque commit. Vous devez utiliser la détection de changements (Path filtering) ou des outils de build intelligents (Nx, Bazel).

# Exemple GitHub Actions optimisé
name: Build Monorepo Services
on:
  push:
    branches: [ "main" ]
    paths:
      - 'apps/**'
      - 'libs/**'

jobs:
  detect-changes:
    runs-on: ubuntu-latest
    outputs:
      matrix: ${{ steps.set-matrix.outputs.matrix }}
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0 # Nécessaire pour comparer les diffs
      - id: set-matrix
        run: |
          # Script ou action (ex: dorny/paths-filter) pour générer 
          # une matrice JSON des services modifiés
          
  build-service:
    needs: detect-changes
    if: ${{ needs.detect-changes.outputs.matrix != '[]' }}
    strategy:
      matrix: ${{fromJson(needs.detect-changes.outputs.matrix)}}
    runs-on: ubuntu-latest
    steps:
      - run: make build-service SERVICE=${{ matrix.service }}

🌳 Arbre de décision stratégique

Pour faire le bon choix, suivez cette logique binaire :

Code Partagé : Avez-vous plus de 20% de code commun (libs, utils) entre les services ?
- 🟢 OUI → Monorepo (évite l'enfer du versionning des librairies internes via npm/maven privés).
- 🔴 NON → Passez au point 2.
Maturité CI/CD : Avez-vous une équipe Platform capable de gérer du Caché distribué ou des outils comme Nx/Turborepo ?
- 🔴 NON → Polyrepo (Un Monorepo sans outillage avancé devient une usine à gaz lente).
- 🟢 OUI → Monorepo.
Audit & Sécurité : La ségrégation stricte des accès git est-elle une exigence légale/audit ?
- 🟢 OUI → Polyrepo (L'isolation est native).
- 🔴 NON → Monorepo avec CODEOWNERS.

🔐 Sécurité : RBAC et Blast Radius

Gestion des accès (RBAC Git)

Polyrepo : "Zero Trust" par défaut. L'équipe Payment ne peut physiquement pas voir ni toucher le code de l'équipe Auth si vous ne leur donnez pas les droits sur le repo.
Monorepo : Tout le monde voit tout. La sécurité repose sur la configuration du fichier CODEOWNERS.

Exemple CODEOWNERS strict :

# Personne ne touche à l'infra sans validation des SRE
/infra/        @org/sre-team

# Isolation logique des services
/apps/payment/ @org/team-payment
/apps/auth/    @org/team-security

Limitation du "Blast Radius" (Rayon d'impact)

C'est le talon d'Achille du Monorepo. Une erreur de syntaxe dans un workflow GitHub Actions global peut bloquer le déploiement de l'intégralité des 50 services.

✅ Contre-mesures obligatoires :

Valider les changements de pipeline sur un environnement de staging.
Utiliser des politiques OPA/Kyverno pour empêcher un commit invalide d'atteindre la branche principale.

💸 Performance & Coûts

Critère	Polyrepo	Monorepo
Temps de Clone	⚡️ Rapide. On ne clone que le nécessaire.	🐢 Lent. Un repo de 5Go ralentit la CI. Solution : `sparse-checkout` et `fetch-depth: 1`.
Runners CI	Parallélisation massive de petits jobs.	Nécessite des runners puissants (CPU/RAM) et un cache agressif.
Déploiement K8s	Indépendant. Argo CD gère X applications séparées.	Groupé. Risque de surcharge du contrôleur si tout change en même temps.

✅ Tests et Validation (Quality Gates)

Que vous soyez en Mono ou Poly, la validation des manifestes YAML avant le merge est non-négociable pour éviter de casser le cluster.

Snippet de validation universel (Kubeconform) :

#!/bin/bash
# Script CI de pré-validation
# Requis: kubeconform v0.6.1+

echo "🔍 Audit des manifestes Kubernetes..."
find ./apps -name '*.yaml' -print0 | xargs -0 kubeconform \
  -summary \
  -verbose \
  -schema-location default \
  -schema-location 'https://raw.githubusercontent.com/datreeio/CRDs-catalog/main/{{.Group}}/{{.ResourceKind}}_{{.ResourceAPIVersion}}.json' \
  -kubernetes-version 1.28.0

if [ $? -eq 0 ]; then
  echo "✅ Manifestes valides."
else
  echo "❌ Erreur de conformité détectée."
  exit 1
fi

↩️ Rollback et Gestion de crise

En cas de déploiement défectueux, la stratégie diffère :

Polyrepo : Simple git revert sur le dépôt concerné. L'impact est contenu au seul service.
Monorepo : Le git revert est risqué si d'autres commits (d'autres équipes) ont été empilés entre temps.
- Best Practice : Privilégiez toujours le Fix-Forward (nouveau commit correctif).
- Urgence : Utilisez l'interface Argo CD pour désactiver l'Auto-Sync et forcer manuellement une ancienne révision (Git Hash).

📝 Checklist de mise en production

Avant de migrer, validez ces points :

Architecture : La structure des dossiers est documentée et figée (ADR).
Sécurité : CODEOWNERS (Monorepo) ou équipes GitHub (Polyrepo) configurés.
Protection : Les Branch Protection Rules exigent des statuts CI verts avant merge.
GitOps : Argo CD est configuré avec prune: false au début (sécurité anti-suppression).
Secrets : Scan actif (Trivy/Gitleaks) dans les hooks de pre-commit.
Versioning : Stratégie de tag homogène (ex: v1.2.0 ou sha-7b3f1).

FAQ Rapide

Q: Peut-on mélanger les deux ? R: Oui, l'approche "Hybride" est très courante. Un Monorepo pour le cœur applicatif métier (Back/Front), et des Polyrepos pour les outils d'infrastructure (Terraform) ou les services tiers isolés.

Q: Argo CD préfère-t-il une méthode ? R: Argo CD est agnostique. Cependant, le Polyrepo peut stresser l'API Kubernetes si vous générez des centaines d'objets Application sans tuning. Le Monorepo simplifie la source de vérité.

Conclusion

Il n'y a pas de vainqueur par K.O.

Choisissez le Polyrepo pour la sécurité, l'isolation et si vos équipes sont très hétérogènes.
Choisissez le Monorepo si vous visez une cohérence technique forte et une réutilisation maximale du code, mais soyez prêt à investir dans une équipe de Platform Engineering pour maintenir l'outillage.

💡 Le conseil de Tecapic : Si vous démarrez avec 50 microservices sans expert CI/CD dédié, commencez par le Polyrepo standardisé par des templates (cookiecutter/scaffolding). La dette technique du Monorepo est souvent plus lourde à porter au début.

Monorepo vs Polyrepo - Stratégie GitOps pour 50 microservices