GitOps : de la théorie à la production en 90 jours

GitOps est devenu un buzzword. Mais entre la théorie (« Git comme unique source de vérité ») et une implémentation robuste en production, il y a un fossé. Nous avons guidé une vingtaine d'organisations suisses et françaises à franchir ce fossé. Voici la roadmap pragmatique que nous recommandons.

GitOps : définition opérationnelle

GitOps n'est pas juste « mettre le code infra dans Git ». C'est un modèle opérationnel complet :

1. Source de vérité unique : tous les états désirés (code app, configuration, infra) vivent dans Git
2. Réconciliation continue : un agent (ArgoCD, Flux) réconcilie l'état réel vs l'état désiré
3. Audit trail complet : chaque changement est tracé via Git history
4. Immutabilité : les changements passent par Git et pull requests, jamais via kubectl direct
5. Rollback automatique : revenir à un état connu prend un revert Git

Implémenté correctement, GitOps réduit lead time, augmente la sécurité, et rend les déploiements prédictibles et auditables.

Pourquoi GitOps maintenant ?

Trois raisons :

1. Compliance : auditeurs adorent Git history. Chaque déploiement a une trace.
2. Vitesse : merge une PR, c'est plus rapide que cliquer dans 10 UIs différentes.
3. Reliability : source unique de vérité = moins de drift, moins de "works on my laptop".

Pour les DSI/CTO, GitOps signifie aussi réduction du risque humain. Pas de "oups, j'ai supprimé la DB en prod".

Décision #1 : ArgoCD vs Flux

C'est LA question que nous posent nos clients. Honnêtement, les deux sont excellents. Voici les nuances :

Notre recommandation :

• Startups / petites équipes : ArgoCD (dashboard aide, plus d'exemples)
• Organisations matures en Kubernetes : Flux (plus léger, meilleur control)

Pour une implémentation en 90 jours, nous recommandons ArgoCD. L'adoption sera plus rapide.

Roadmap de mise en œuvre : 90 jours

Phase 1 : Fondations (Semaines 1-3)

Semaine 1 : Préparation & design

• Former le team aux concepts GitOps
• Décider : ArgoCD ou Flux
• Planifier la structure Git (monorepo vs polyrepo)
• Identifier les secrets à migrer

Semaine 2 : Cluster préparation

• Installer ArgoCD (ou Flux) sur un cluster de staging
• Configurer RBAC, ingress, TLS
• Tester les webhooks GitHub/GitLab
• Documentation initiale

Semaine 3 : Premier app

• Convertir une application simple en manifestes K8s
• Créer le repo Git (structure claire)
• Configurer la sync ArgoCD
• Effectuer les premiers deployments via Git

Phase 2 : Scaling (Semaines 4-7)

Semaine 4 : Secrets & sécurité

• Implémenter secrets management (Sealed Secrets ou External Secrets)
• Jamais committer de secrets en clair
• Auditer les repos existants
• Former sur les bonnes pratiques

Semaine 5 : Multi-environnements

• Structure : dev/staging/prod dans Git
• Kustomize ou Helm pour variabiliser configs
• Gestion des dépendances entre envs
• Drift detection activée

Semaine 6-7 : Onboarding applications

• Migrer 5-10 apps prioritaires
• Mettre en place des templates réutilisables
• Valider les pipelines CI → CD
• Documenter les patterns

Phase 3 : Maturation (Semaines 8-12)

Semaine 8-9 : Rollback & DR

• Tester les rollbacks (reverts Git)
• Évaluer RTO/RPO par app
• Configurer les alertes de drift
• Disaster recovery flows

Semaine 10-11 : Observabilité & audit

• Logs des sync ArgoCD centralisés
• Alertes sur les drifts ou échecs
• Audit trail : qui a changé quoi, quand
• Dashboard de visibilité

Semaine 12 : Stabilisation & support

• Tous les tests en prod
• Documentation finale
• Support plan & runbooks
• Rétrospective et ajustements

Décision #2 : Monorepo vs Polyrepo

Deux architectures Git possibles :

Monorepo (tout dans un repo) :

• Avantages : atomicité, contrôle centralisé, rollback facile
• Inconvénients : permissions fines difficiles, historique volumineux
• Bon pour : organisations < 100 devs, contrôle fort requis

Polyrepo (un repo par app/service) :

• Avantages : autonomie équipes, ownership clair, repos légers
• Inconvénients : déploiements cross-repo complexes, audit dispersé
• Bon pour : organisations > 100 devs, équipes autonomes

Notre recommandation pour 90j : Commencer monorepo si < 50 apps/services. Permet contrôle et auditabilité. Refactoriser vers polyrepo si nécessaire plus tard.

Comparaison approfondie : ArgoCD vs Flux en production

La table ci-dessus donne une vue d'ensemble, mais en production les différences deviennent plus tangibles. Voici ce que nous observons chez nos clients :

ArgoCD en production : ArgoCD brille par son dashboard web. Pour les équipes qui découvrent GitOps, pouvoir visualiser l'état de chaque application, voir les diffs entre l'état désiré et l'état réel, et déclencher un sync manuellement depuis l'UI est un accélérateur d'adoption. Le support multi-cluster est natif et bien intégré : un seul ArgoCD peut gérer dev, staging et prod. En revanche, à partir de 200+ applications, le controller ArgoCD consomme significativement plus de ressources (2-4 GB RAM, latence de réconciliation de 30-60 secondes). Il faut alors shardder par Application Set ou déployer plusieurs instances.

Flux en production : Flux adopte une approche plus modulaire : chaque composant (source-controller, kustomize-controller, helm-controller, notification-controller) est indépendant. C'est plus complexe à configurer initialement, mais plus flexible à scale. Flux gère nativement les Helm releases comme des objets Kubernetes, ce qui simplifie la gestion des charts complexes. Son empreinte mémoire reste stable même avec 500+ ressources. Le principal inconvénient : sans UI native, le debugging nécessite de maîtriser kubectl et les CRDs Flux, ce qui ralentit l'onboarding des développeurs moins ops-oriented.

Notre retour d'expérience sur 20+ implémentations :

• Organisations < 50 devs, < 100 apps : ArgoCD dans 85% des cas
• Organisations > 100 devs, 200+ apps : Flux dans 60% des cas
• Migration ArgoCD vers Flux : rare et coûteuse (3-4 semaines). Choisissez bien dès le départ.

Gestion des secrets : le point critique

C'est l'erreur #1 : des secrets commités en clair. Voici le bon pattern :

Option 1 : Sealed Secrets (simple, K8s natif)

# Dans le repo Git (sécurisé, chiffré)
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: db-credentials
  namespace: production
spec:
  encryptedData:
    password: AgBvK3x4K... # chiffré avec clé publique cluster

ArgoCD le décrypte automatiquement au deploy. Avantage : pas de stockage externe, tout dans Git.

Option 2 : External Secrets (flexible)

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: vault-backend
spec:
  provider:
    vault:
      server: "https://vault.example.com"
      path: "secret"
      auth:
        kubernetes: {}
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-secret
spec:
  secretStoreRef:
    name: vault-backend
  target:
    name: db-secret
  data:
    - secretKey: password
      remoteRef:
        key: db-password

Avantage : secrets centralisés (Vault, HashiCorp, 1Password), rotation plus facile.

Recommandation : Sealed Secrets pour démarrer (90j), migrer vers External Secrets + Vault quand maturité augmente.

Stratégies de déploiement avec GitOps

Pattern 1 : Sync automatique (recommandé pour 80% des cas)

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-api
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/my-api.git
    targetRevision: HEAD
    path: k8s/
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true        # supprimer ressources supprimées dans Git
      selfHeal: true     # reconcilier si drift détecté
    syncOptions:
      - CreateNamespace=true

La sync se fait automatiquement dès un merge. Aucune intervention humaine.

Pattern 2 : Sync manuelle (plus sûr pour prod critique)

  syncPolicy:
    # Pas de 'automated'
    # Require manual sync approval

Chaque déploiement doit être approuvé via argocd app sync. Bon pour les changements sensibles.

Rollback : simple mais puissant

Le grand avantage de GitOps : rollback = revert Git.

# Prod bug ?
git revert <commit-id>
git push origin main

# ArgoCD détecte le changement, redéploie la version précédente
# RTO : 2-5 minutes

Comparé à kubectl set image (qui n'est pas tracé, pas auditable), c'est du jour à la nuit.

Erreurs courantes et comment les éviter

Erreur 1 : Chaos de fichiers YAML

Comment éviter : Kustomize ou Helm dès le départ. Pas de YAML dupliqué.

Erreur 2 : Pas de gestion des secrets

Conséquence : secrets en clair → breach → RGPD violations.

Comment éviter : Sealed Secrets ou External Secrets. Auditer tous les repos.

Erreur 3 : Drift silencieux

Quelqu'un fait kubectl apply -f directement = état réel ≠ état Git.

Comment éviter : Jamais de kubectl write en prod. Que des reads. Appliquer le principe : "Git est le point unique de vérité."

Erreur 4 : Pas de tests avant sync

Un manifeste K8s valide ≠ déploiement réussi.

Comment éviter :

• Tester dans dev/staging d'abord
• Valider YAML : kube-score, kubeval
• Tests fonctionnels en CI avant de merger

Erreur 5 : Performance : trop de flux réconciliant

100 apps × ArgoCD controller = charge cluster.

Comment éviter : Shard ArgoCD par namespace. Un ArgoCD par équipe. Hidora aide souvent à structurer cette architecture pour les grandes organisations.

Observabilité & monitoring GitOps

Une fois en place, comment savoir que tout fonctionne ?

Métriques clés

argocd_app_reconcile_count              # nombre de syncs
argocd_app_reconcile_duration_seconds   # durée des syncs
argocd_app_sync_total                   # syncs réussies vs échouées
argocd_app_health_status                # santé apps

Alertes essentielles

- alert: AppSyncFailed
  expr: argocd_app_sync_total{phase="Failed"} > 0
  annotations:
    summary: "App {{ $labels.name }} sync échoué"

- alert: DriftDetected
  expr: argocd_app_info{sync_status="OutOfSync"} == 1
  annotations:
    summary: "Drift détecté : {{ $labels.name }}"

Couplées avec Slack notifications, vous êtes alerté en temps réel.

Conclusion : réussite en 90 jours

GitOps transforme vos déploiements. Mais c'est un changement opérationnel et culturel. La roadmap ci-dessus a marché pour une vingtaine d'organisations suisses/françaises.

Points clés pour réussir :

1. Choisir ArgoCD (plus rapide à adopt) ou Flux (plus puissant)
2. Implémenter secrets management dès le départ
3. Commencer avec quelques apps low-risk
4. Former vs commander : le buy-in des devs est critique
5. Mesurer : lead time, deployment frequency, drifts

En 90 jours, vous serez en production. En 6 mois, c'est une culture.

À lire aussi :

• Platform Engineering : pourquoi vos équipes dev en ont besoin
• Infrastructure as Code : Terraform en production, sans regrets

Cet article vous a été utile ? Découvrez comment Hidora peut vous accompagner : Professional Services · Managed Services · SLA Expert