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.

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