GitOps avec ArgoCD : migrer vers le modèle App of Apps

Au sein de la Console DSO du Ministère de l'Intérieur, l'un des chantiers structurants de 2025 a été la migration des déploiements Kubernetes depuis un mode Push (appels directs à l'API Server depuis uen base de code Ansible) vers un mode Pull piloté par ArgoCD selon le pattern App of Apps.

Pourquoi changer d'approche ?

Le modèle Push classique — où l'équipe utilise directement l'équivalent d'un kubectl apply — présente plusieurs limites dans un contexte de plateforme multi-équipes :

• Surface d'attaque élargie : disposer de credentials Kubernetes avec des droits larges
• Dérive de configuration : rien ne garantit que l'état du cluster correspond à ce qui est dans Git
• Auditabilité limitée : difficile de savoir qui a déployé quoi et quand

ArgoCD résout ces trois problèmes en inversant le flux : c'est le cluster qui tire sa configuration depuis Git, et non l'inverse.

Le pattern App of Apps

Le pattern App of Apps (ou Application of Applications) consiste à créer une Application ArgoCD racine, dont le seul rôle est de pointer vers un répertoire Git contenant d'autres manifests Application. ArgoCD réconcilie alors l'arbre complet automatiquement.

# app-of-apps.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: platform-root
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://gitlab.example.com/platform/gitops.git
    targetRevision: main
    path: apps/
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Le répertoire apps/ contient alors un manifest Application par composant de la plateforme (Vault, SonarQube, Nexus, etc.).

Mise en œuvre sur la Console DSO

La migration s'est déroulée en plusieurs étapes :

1. Inventaire des ressources existantes : cartographie de tout ce qui était déployé manuellement ou via CI
2. Création du dépôt GitOps : structure apps/, manifests/, charts/ avec conventions claires
3. Bootstrap ArgoCD : installation via Helm, configuration du projet et des policies RBAC
4. Migration progressive : un composant à la fois, en commençant par les outils non critiques
5. Suppression des sources Ansible : une fois la migration complète, suppression des sources de code Push et révocation des credentials Kubernetes

Retour d'expérience

Ce qui a bien fonctionné

• La réconciliation automatique (selfHeal) a immédiatement détecté des dérives de configuration que nous ignorions
• L'interface ArgoCD offre une visibilité incomparable sur l'état réel du cluster vs. l'état désiré
• Les PR sur le dépôt GitOps sont devenues la seule porte d'entrée pour tout changement en production

Les points d'attention

• Secrets : ArgoCD ne gère pas les secrets nativement — nous avons intégré Vault avec le plugin argocd-vault-plugin puis migré vers ExternalSecrets Operator
• Temps de réconciliation : sur un grand nombre d'applications, ajuster les paramètres timeout.reconciliation et timeout.hard.reconciliation
• RBAC ArgoCD : concevoir les projets et les policies en amont est crucial pour un environnement multi-équipes

Conclusion

La migration vers ArgoCD App of Apps a profondément amélioré notre posture de sécurité et notre capacité à auditer les déploiements. La courbe d'apprentissage existe, mais l'investissement est largement rentabilisé dès les premières semaines de fonctionnement en production.

Si vous envisagez une migration similaire, je vous recommande de commencer par un environnement de staging complet avant de toucher la production, et de former l'ensemble de l'équipe aux concepts GitOps avant le démarrage.