Formation ArgoCD — GitOps sur Kubernetes

ArgoCD est l’outil qui manquait à votre pipeline CI/CD : pendant que votre CI pousse du code, ArgoCD surveille votre dépôt Git et synchronise automatiquement vos clusters Kubernetes. Résultat ? Moins de déploiements ratés, un historique de chaque changement, et la capacité de revenir en arrière en une commande.

Cette formation vous guide pas à pas, de la première installation jusqu’à la gestion de plusieurs environnements en production, en passant par la sécurisation et l’intégration avec vos pipelines CI existants.

Ce que vous allez apprendre

Cette formation couvre 7 modules progressifs :

Module	Sujet	Niveau
1	Concepts et architecture ArgoCD	Débutant
2	Installation (Helm + config initiale)	Débutant
3	Première application, sync, health	Débutant
4	App of Apps pattern	Intermédiaire
5	Intégration CI/CD — le bridge	Intermédiaire
6	Multi-environnements avec ApplicationSet	Intermédiaire
7	Sécuriser ArgoCD (RBAC, SSO, projets)	Avancé

Pourquoi ArgoCD et le GitOps

Avant ArgoCD, déployer sur Kubernetes signifiait souvent kubectl apply dans un script de CI, des credentials cluster exposés dans votre pipeline, et aucune trace fiable de qui a déployé quoi et quand.

ArgoCD renverse ce modèle : c’est le cluster qui tire les changements depuis Git, pas votre CI qui les pousse. Git devient la source de vérité unique. Ce que vous voyez dans le dépôt est exactement ce qui tourne en production — et si ce n’est pas le cas, ArgoCD le détecte et peut le corriger automatiquement (self-healing).

Le bénéfice concret : un historique complet d’audit (chaque commit = un état du cluster), la capacité de revenir en arrière sur n’importe quel déploiement, et la gestion de plusieurs environnements depuis un seul outil sans démultiplier les accès cluster dans votre CI.

À qui s’adresse cette formation

Cette formation est conçue pour :

Les développeurs et DevOps qui maîtrisent les bases Kubernetes (Pods, Deployments, Services) et veulent structurer leurs déploiements.
Les Platform Engineers qui déploient ArgoCD pour une équipe et ont besoin de comprendre le RBAC, les AppProjects et le multi-cluster.
Les équipes passant de Helm/kubectl en CI à une approche GitOps structurée, avec séparation des dépôts app et config.

Connaître Helm et/ou Kustomize est un plus pour les modules 3 à 6.

Ce que vous saurez faire à la fin

À l’issue des 7 modules, vous serez capable de :

Installer ArgoCD avec Helm et configurer l’accès initial au dashboard.
Déployer une application depuis un dépôt Git et comprendre les statuts de sync et de health.
Structurer un dépôt GitOps avec le pattern App of Apps et des overlays Kustomize par environnement.
Brancher votre CI (GitHub Actions, GitLab CI) sur ArgoCD sans donner d’accès cluster à la pipeline.
Sécuriser ArgoCD avec le RBAC, les AppProjects, le SSO via Dex et des Network Policies.

Les concepts clés d’ArgoCD

ArgoCD introduit trois objets Kubernetes custom (CRDs) qui structurent toute la configuration. Les comprendre avant d’installer est utile :

Objet	Rôle
`Application`	Lie une source Git (URL + path + révision) à une destination Kubernetes (cluster + namespace). C’est l’unité de déploiement d’ArgoCD.
`AppProject`	Définit un périmètre d’autorisation : quels dépôts Git une Application peut utiliser, dans quels namespaces elle peut déployer, quelles ressources K8s elle peut créer.
`ApplicationSet`	Génère automatiquement des objets `Application` depuis un template + une source de données (liste explicite, découverte de dossiers Git, liste de clusters…).

Chaque module de la formation approfondit l’un de ces objets. Pour le module 1 (Concepts), vous verrez aussi les composants internes : argocd-server, repo-server, application-controller, redis et dex.

Pièges courants avec ArgoCD

Piège	Impact	Correctif
Tout dans le `default` AppProject	Aucune isolation — une Application peut déployer partout	Créer un AppProject par équipe dès le départ
`syncPolicy: automated` sans `prune: true`	Les ressources supprimées de Git restent dans le cluster	Activer `prune: true` en même temps que `automated`
Sync auto activée en production	Un commit en prod → déploiement sans validation humaine	Garder le sync manuel en production, auto seulement en dev/staging
Secrets dans les `values` Helm	Credentials en clair dans le config-repo	Utiliser External Secrets, Sealed Secrets ou SOPS
Compte `admin` conservé en production	Accès global non auditable	Changer le mot de passe dès l’installation, désactiver `admin` ensuite
App of Apps sans AppProject restrictif	L’application racine peut déployer n’importe où	Définir `sourceRepos` et `clusterResourceWhitelist` dans AppProject

Critères de réussite

Votre déploiement ArgoCD est prêt pour la production quand :

Aucune Application n’est dans le default AppProject en production
Le compte admin local est désactivé — la connexion passe par SSO (Dex)
Les Applications de production sont en sync manuel, pas automated sans revue
Tous les secrets passent par External Secrets, Sealed Secrets ou SOPS
Chaque équipe a son propre AppProject avec sourceRepos limités
Les tokens CI sont des comptes de service ArgoCD avec droits minimaux
Les alertes de drift sont configurées (Slack, Teams ou autre)
Un rollback git a été testé (git revert + sync) au moins une fois

L’architecture globale : CI + GitOps ensemble

Beaucoup de guides présentent ArgoCD de façon isolée. Voici la vision d’ensemble qui donne tout son sens à la formation :

Workflow CI/GitOps : code source → pipeline CI → config repo → ArgoCD → cluster Kubernetes

Dans un modèle GitOps propre, la CI ne modifie pas directement les ressources du cluster en production. Elle publie des artefacts (images, charts) et met à jour Git — le tag d’image dans le config-repo. ArgoCD détecte le changement dans Git et applique l’état désiré sur le cluster.

Modules de la formation

1 — Concepts et architecture Architecture interne, modèle de réconciliation, Application, AppProject, ApplicationSet

2 — Installation Helm chart, accès initial au dashboard, configuration de base, CLI argocd

3 — Première application Sync manuel/auto, health statuses, self-heal, prune

4 — App of Apps Pattern App of Apps, ApplicationSet, List generator, gestion multi-apps

5 — Intégration CI/CD Bridge CI/GitOps, mise à jour de tag, Image Updater, argocd app wait

6 — Multi-environnements Overlays Kustomize, Cluster generator, promotion via PR, rollback

7 — Sécuriser ArgoCD RBAC, AppProjects, SSO avec Dex, External Secrets, Network Policies

Dépôts de référence pour la formation

Pour suivre les modules pratiques, vous avez besoin de deux dépôts :

app-repo/          ← Code source (votre application)
  src/
  Dockerfile
  .github/ ou .gitlab-ci.yml

config-repo/       ← Manifestes Kubernetes (Helm ou Kustomize)
  apps/            ← (Module 4) App of Apps
  app-repo/
    Chart.yaml
    values.yaml
    values-dev.yaml
    values-staging.yaml
    values-prod.yaml

À retenir

ArgoCD est un opérateur Kubernetes qui synchronise votre cluster depuis Git.
Le modèle GitOps sépare CI (publie artefacts) et CD (applique depuis Git) — ArgoCD fait le CD.
Dans un modèle GitOps propre, la CI met à jour Git, pas le cluster directement.
ArgoCD introduit trois objets K8s : Application, AppProject, ApplicationSet.
Le self-healing détecte et corrige toute dérive entre l’état Git et l’état du cluster.
La formation suit une progression débutant → avancé, chaque module étant autonome.

Prochaines étapes

Concepts et architecture Comprendre ArgoCD avant de l'installer

Comprendre le GitOps Le modèle pull vs push expliqué en détail

Sécuriser une pipeline CI/CD Les bases de sécurité avant d'aller en production