# ArgoCD et GitOps en 2026 : Deploiement Continu Kubernetes et Questions d'Entretien > Guide complet ArgoCD et GitOps pour le deploiement continu Kubernetes en 2026. Application CRDs, sync waves, gestion multi-cluster avec ApplicationSets et questions d'entretien techniques avec exemples YAML. - Published: 2026-06-05 - Updated: 2026-06-05 - Author: SharpSkill - Tags: argocd, gitops, kubernetes, continuous-deployment, devops, interview - Reading time: 10 min --- ArgoCD s'est impose comme l'outil GitOps de reference pour le deploiement continu sur Kubernetes. La [version 3.4](https://github.com/argoproj/argo-cd/releases), publiee en mai 2026, confirme cette position dominante alors que plus de 64 % des entreprises declarent desormais utiliser le GitOps comme mecanisme principal de livraison. Cet article explore les concepts fondamentaux d'ArgoCD, les patterns de configuration avances et les questions d'entretien les plus frequentes pour les postes DevOps et ingenierie de plateforme. > **Qu'est-ce que le GitOps ?** > > Le GitOps est une methodologie de deploiement dans laquelle Git constitue la source unique de verite pour le code applicatif et la configuration d'infrastructure. Un agent GitOps, execute a l'interieur du cluster, reconcilie en permanence l'etat reel du cluster avec l'etat desire declare dans un depot Git, corrigeant automatiquement toute deviation. ## Comment ArgoCD implemente le modele GitOps ArgoCD fonctionne sous la forme d'un ensemble de microservices deployes dans un cluster Kubernetes : un serveur API, un serveur de depots, un controleur d'applications et un cache Redis. Le controleur surveille les depots Git et compare l'etat desire (les manifestes dans Git) avec l'etat reel du cluster. Lorsqu'une difference apparait, ArgoCD alerte ou synchronise automatiquement selon la politique configuree. Ce modele base sur le pull (tirage) offre un avantage securitaire majeur par rapport aux deploiements traditionnels de type push pilotes par le CI. Le cluster tire les modifications depuis Git plutot que d'exposer un point d'entree pour qu'un outil CI pousse vers le cluster. Les credentials du cluster ne quittent jamais le perimetre du cluster. La premiere etape consiste a installer ArgoCD puis a definir une ressource Application : ```yaml # argocd-application.yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: my-web-app namespace: argocd spec: project: default source: repoURL: https://github.com/acme/my-web-app-config targetRevision: main path: overlays/production destination: server: https://kubernetes.default.svc namespace: production syncPolicy: automated: prune: true # Remove resources deleted from Git selfHeal: true # Revert manual changes in the cluster syncOptions: - CreateNamespace=true ``` Le bloc `source` pointe vers le depot Git contenant les manifestes Kubernetes. Le bloc `destination` specifie le cluster et le namespace cibles pour le deploiement. L'activation de `automated.selfHeal: true` garantit que toute modification manuelle effectuee via kubectl sera ecrasee par l'etat declare dans Git en quelques secondes. ## Sync Waves et Hooks : orchestrer l'ordre de deploiement Les deploiements en production ne se limitent rarement a un seul manifeste. Les migrations de base de donnees doivent s'executer avant le demarrage des pods applicatifs. Les ConfigMaps et Secrets doivent exister avant que les Deployments ne les referencent. ArgoCD resout cette problematique grace aux sync waves et aux resource hooks. Les sync waves attribuent un ordre numerique aux ressources. Les numeros les plus bas sont deployes en premier, et ArgoCD attend que chaque vague devienne saine avant de passer a la suivante : ```yaml # migration-job.yaml apiVersion: batch/v1 kind: Job metadata: name: db-migrate annotations: argocd.argoproj.io/sync-wave: "-1" # Runs before wave 0 argocd.argoproj.io/hook: PreSync # Executes before main sync argocd.argoproj.io/hook-delete-policy: HookSucceeded spec: template: spec: containers: - name: migrate image: acme/my-web-app:latest command: ["python", "manage.py", "migrate"] restartPolicy: Never ``` Le hook `PreSync` execute le job de migration avant qu'ArgoCD n'applique les manifestes principaux de l'application. La politique de suppression `HookSucceeded` nettoie le Job apres une execution reussie. ArgoCD 3.3 a egalement introduit les hooks `PreDelete`, resolvant le probleme recurrent des ressources orphelines lors de la suppression d'applications. ## Gestion multi-cluster avec les ApplicationSets Gerer des dizaines de clusters depuis une seule instance ArgoCD necessite davantage que la duplication de manifestes Application. Les [ApplicationSets](https://argo-cd.readthedocs.io/en/stable/user-guide/application-set/) generent des ressources Application de maniere dynamique a partir de templates et de generateurs : ```yaml # applicationset-clusters.yaml apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: my-web-app-all-clusters namespace: argocd spec: generators: - clusters: selector: matchLabels: env: production template: metadata: name: 'my-web-app-{{name}}' spec: project: default source: repoURL: https://github.com/acme/my-web-app-config targetRevision: main path: 'overlays/{{metadata.labels.region}}' destination: server: '{{server}}' namespace: production syncPolicy: automated: prune: true selfHeal: true ``` Le generateur `clusters` itere sur tous les clusters enregistres correspondant au label `env: production` et cree une Application par cluster. Les placeholders `{{name}}`, `{{server}}` et `{{metadata.labels.region}}` sont resolus a partir des donnees d'enregistrement du cluster. L'ajout d'un nouveau cluster de production a ArgoCD declenche automatiquement le deploiement de l'application sur ce cluster. ## ArgoCD vs Flux : choisir le bon outil GitOps La comparaison ArgoCD / Flux constitue l'un des sujets les plus recurrents en [entretien DevOps](/technologies/devops/interview-questions/kubernetes-basics). Les deux projets, tous deux diplomes CNCF Graduated, implementent le pattern GitOps, mais se distinguent par leur architecture et leurs compromis : | Fonctionnalite | ArgoCD 3.4 | Flux 2.8 | |---------|-----------|----------| | Architecture | Serveur centralise avec interface web | Controleurs distribues par cluster | | Interface web | Dashboard integre et abouti | Pas d'interface native (options tierces) | | Support Helm | Rendu des templates cote serveur | Integration native du SDK Helm | | Multi-cluster | Hub-and-spoke depuis une instance unique | Installation independante par cluster | | RBAC | Au niveau applicatif avec SSO | RBAC natif Kubernetes uniquement | | Automatisation d'images | Composant Image Updater separe | Reflecteur/automatisation d'images integre | | Deploiement progressif | Integration Argo Rollouts | Integration Flagger | | Empreinte ressources | Elevee (serveur API, serveur repo, Redis) | Reduite (uniquement les controleurs necessaires) | ArgoCD convient aux equipes qui privilegient la visibilite centralisee, un tableau de bord web et un RBAC granulaire au niveau applicatif. Flux s'adresse aux equipes operant en environnements edge ou a ressources limitees, ou a celles qui s'appuient fortement sur les fonctionnalites natives du cycle de vie Helm. Certaines organisations [utilisent les deux](https://codefresh.io/learn/argo-cd/argo-cd-vs-flux-6-key-differences-and-how-to-choose/) : ArgoCD pour les deploiements applicatifs ou l'interface apporte une valeur ajoutee, et Flux pour les composants d'infrastructure ou le fonctionnement distribue et la fidelite Helm importent davantage. ## Structure de depot pour un GitOps en production Une erreur frequente lors de l'adoption du GitOps consiste a stocker les manifestes Kubernetes dans le meme depot que le code source de l'application. Separer le depot de configuration du depot applicatif permet un historique Git plus propre, des cycles de revue independants et des declencheurs CI plus simples : ``` # Recommended repository structure my-web-app-config/ base/ deployment.yaml service.yaml kustomization.yaml overlays/ staging/ kustomization.yaml # Patches for staging replica-count.yaml production/ kustomization.yaml # Patches for production replica-count.yaml hpa.yaml ``` Le repertoire `base` contient les manifestes partages. Chaque overlay applique des patches specifiques a l'environnement via [Kustomize](https://kustomize.io/). Le pipeline CI construit et pousse l'image conteneur, puis met a jour le tag d'image dans le depot de configuration. ArgoCD detecte le commit et synchronise la nouvelle version vers le cluster. > **Reconciliation declenchee par webhook** > > La configuration de recepteurs webhook depuis GitHub, GitLab ou Bitbucket permet de declencher la reconciliation ArgoCD immediatement apres chaque push. Cette approche elimine l'intervalle de polling par defaut de 3 minutes et offre une detection de deploiement en moins de 10 secondes. L'intervalle de polling peut etre maintenu a 5-10 minutes comme mecanisme de secours. ## Nouveautes ArgoCD 3.4 a connaitre ArgoCD 3.4, publie en mai 2026, cible les operations Day 2 avec des fonctionnalites qui apparaissent frequemment en entretien pour les postes DevOps seniors. **La pause de reconciliation de cluster** permet aux operateurs de geler la synchronisation ArgoCD pendant un incident de production. Ce mecanisme empeche ArgoCD de reverter les correctifs d'urgence appliques directement sur le cluster pendant que l'equipe resout le probleme : ```yaml # Pause reconciliation on a specific cluster apiVersion: v1 kind: Secret metadata: name: prod-cluster namespace: argocd labels: argocd.argoproj.io/secret-type: cluster annotations: argocd.argoproj.io/pause-reconciliation: "true" stringData: server: https://prod-cluster.example.com config: | { "tlsClientConfig": { "insecure": false } } ``` **Les globs de valeurs Helm** remplacent les listes verbeuses de `valueFiles` par des patterns, reduisant les conflits de merge dans les equipes qui maintiennent de nombreux fichiers de valeurs specifiques a l'environnement : ```yaml # Before ArgoCD 3.4 source: helm: valueFiles: - values.yaml - values-production.yaml - values-production-eu.yaml - values-production-eu-secrets.yaml # With ArgoCD 3.4 value globs source: helm: valueFiles: - values.yaml - values-production*.yaml ``` ## Questions d'entretien courantes sur ArgoCD Ces questions apparaissent regulierement dans les entretiens DevOps et ingenierie de plateforme. Elles evaluent la comprehension des principes GitOps, pas uniquement la syntaxe ArgoCD. Pour une preparation plus large sur Kubernetes, le [module Kubernetes avance](/technologies/devops/interview-questions/kubernetes-advanced) couvre l'ordonnancement, les contextes de securite et les controleurs personnalises. > **Niveau de profondeur attendu en entretien** > > Les entretiens de niveau senior attendent des candidats qu'ils expliquent les compromis et les modes de defaillance, pas qu'ils se contentent d'enumerer des fonctionnalites. La preparation doit inclure des exemples concrets issus de l'experience en production : un incident ou le selfHeal a pose probleme, une migration ayant necessite des sync waves, ou un deploiement multi-cluster ayant requiert un deploiement progressif. **"Expliquez la difference entre la synchronisation automatique et manuelle dans ArgoCD."** La synchronisation automatique applique les modifications au cluster des qu'ArgoCD detecte une difference entre Git et l'etat reel. La synchronisation manuelle exige un declenchement explicite depuis l'interface, le CLI ou l'API. La synchronisation automatique avec `selfHeal: true` corrige en permanence la derive de configuration, ce qui constitue le standard pour les environnements de production ou la coherence de configuration est critique. La synchronisation manuelle convient aux environnements de staging ou les equipes souhaitent valider les changements avant de les appliquer. **"Que se passe-t-il lorsqu'ArgoCD detecte une derive entre Git et le cluster ?"** ArgoCD compare l'etat desire (les manifestes Git rendus via Helm, Kustomize ou YAML brut) avec l'etat reel du cluster. Si la synchronisation automatique est activee avec selfHeal, ArgoCD revert immediatement le cluster vers l'etat declare dans Git. Si selfHeal est desactive, ArgoCD marque l'application comme OutOfSync et attend une intervention manuelle. Le diff des ressources reste visible dans l'interface, indiquant precisement quels champs ont diverge. **"Comment gerer les migrations de base de donnees dans un workflow GitOps ?"** Les migrations de base de donnees s'executent sous forme de Jobs PreSync avec un numero de sync wave negatif. Le Job de migration s'execute avant qu'ArgoCD ne deploie la nouvelle version de l'application. En cas d'echec de la migration, la synchronisation est interrompue et la version precedente de l'application reste en cours d'execution. La politique de suppression `HookSucceeded` nettoie les Jobs de migration reussis. Pour les scenarios de rollback, les scripts de migration doivent etre concus comme des operations idempotentes. **"Comparez ArgoCD et Flux pour une infrastructure multi-cluster en production."** ArgoCD gere plusieurs clusters depuis un plan de controle unique, offrant une visibilite centralisee via son tableau de bord et un RBAC unifie sur l'ensemble des clusters. Flux fonctionne de maniere independante dans chaque cluster, reduisant le rayon d'impact puisqu'une defaillance du plan de controle n'affecte qu'un seul cluster. Au-dela de 100 clusters, le modele centralise d'ArgoCD necessite un cluster de gestion robuste, tandis que l'approche distribuee de Flux elimine ce point de defaillance unique. Le choix depend de la priorite de l'equipe : simplicite operationnelle (ArgoCD) ou isolation des defaillances (Flux). Le [module securite des pipelines CI/CD](/technologies/devops/interview-questions/cicd-pipeline-security) couvre les questions connexes sur la securisation des pipelines de deploiement. **"Qu'est-ce qu'un ApplicationSet et dans quels cas l'utiliser ?"** Un ApplicationSet est un controleur qui genere des ressources Application ArgoCD a partir de templates. Il utilise des generateurs (cluster, repertoire Git, liste, matrice, merge) pour produire plusieurs Applications a partir d'une seule definition. Les cas d'usage typiques incluent le deploiement d'une meme application sur tous les clusters de production, la generation d'applications par tenant dans une plateforme SaaS multi-tenant, ou la creation d'Applications pour chaque repertoire d'un monorepo. ## Conclusion - ArgoCD 3.4 (mai 2026) introduit la pause de reconciliation et les globs de valeurs Helm, repondant aux besoins operationnels Day 2 des clusters Kubernetes en production - Le modele GitOps base sur le pull elimine la necessite d'exposer les credentials du cluster aux outils CI, preservant les secrets a l'interieur du perimetre du cluster - Les sync waves et les hooks resolvent l'ordonnancement des deploiements : migrations avant les pods applicatifs, ConfigMaps avant les Deployments, nettoyage apres suppression - Les ApplicationSets automatisent le deploiement multi-cluster en generant des ressources Application a partir de labels de clusters, de repertoires Git ou de listes personnalisees - La separation du depot de configuration et du depot applicatif garantit un historique Git plus propre, des cycles de revue independants et des declencheurs CI simplifies - ArgoCD convient a la gestion multi-cluster centralisee grace a son dashboard et son RBAC ; Flux convient aux environnements distribues, a ressources limitees ou fortement dependants de Helm - La preparation aux entretiens GitOps doit couvrir la detection de derive, les strategies de synchronisation, les modes de defaillance et des scenarios concrets de production plutot que des definitions memorisees --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/fr/blog/devops/argocd-gitops-kubernetes-continuous-deployment-interview-questions