J'ai installé Argo CD sur Kubernetes en local — Voici comment j'ai fait

Le pod tournait depuis onze jours. Stable. Sain. Faisant tranquillement son travail dans mon cluster Kubernetes local. Je l'ai supprimé exprès. Six secondes plus tard, un pod tout neuf est apparu à sa place. Même spécification, même configuration, zéro temps d'arrêt. Je n'ai pas touché à kubectl apply. Je n'ai déclenché aucun pipeline. Je n'ai absolument rien fait. Argo CD surveillait mon dépôt Git, a vu que l'état souhaité disait « ce pod doit exister » et l'a ramené à la vie avant que je puisse changer d'onglet dans le navigateur. Ce moment — voir un pod supprimé ressusciter de lui-même sur un cluster Docker Desktop local tournant sur mon MacBook — c'est le moment où GitOps a cessé d'être un concept abstrait que j'avais lu dans des articles de blog CNCF et est devenu quelque chose que je pouvais ressentir. Quelque chose de viscéral. Votre dépôt Git devient la seule source de vérité, et Kubernetes s'adapte pour correspondre. Pas éventuellement. Pas après l'exécution d'un pipeline. Maintenant. J'avais l'intention de configurer Argo CD depuis des mois. Je repoussais toujours au « week-end prochain ». L'hypothèse était que ce serait compliqué — les outils de niveau production le sont généralement. Je pensais avoir besoin d'un cluster cloud, d'un pipeline CI/CD déjà en place, peut-être d'un après-midi entier à me battre avec des Helm charts et des configurations RBAC. La configuration réelle a pris moins de dix minutes. Et le projet que j'ai utilisé pour le tester — infrawhisper, une plateforme de données et d'IA que je construis avec des composants comme un serveur API, un moteur IA, un processeur de flux et un tableau de bord en temps réel — m'a donné un test de résistance parfait pour savoir si Argo CD pouvait gérer un déploiement local véritablement complexe. Voici tout ce que j'ai fait, tout ce que j'ai appris, et le piège Docker Desktop qui a failli tout faire capoter.

Pourquoi j'ai enfin arrêté d'exécuter kubectl apply à la main

J'ai un aveu à faire. Pendant une durée embarrassante, mon flux de déploiement pour Kubernetes local ressemblait à ça :

1. Modifier le code
2. Construire l'image Docker
3. Exécuter kubectl apply -f deployment.yaml
4. Réaliser que j'ai oublié de mettre à jour le tag de l'image
5. Modifier le YAML, appliquer à nouveau
6. Me demander pourquoi les anciens pods tournent encore
7. Supprimer le deployment, appliquer à neuf
8. Répéter le lendemain avec la même frustration Si vous avez travaillé avec Kubernetes pendant un certain temps, vous connaissez cette douleur. Ce n'est pas que kubectl apply soit cassé — ça marche très bien. Le problème, c'est que ça vous place, vous l'humain, sur le chemin critique de chaque déploiement. Vous devenez le pipeline. Et les humains sont de terribles pipelines. Le problème plus profond, c'est le drift. Vous appliquez un manifeste. Un collègue (ou la version de vous-même à 2 heures du matin) fait un changement manuel rapide avec kubectl edit. Maintenant, l'état de votre cluster a silencieusement divergé de ce qui est dans votre dépôt Git. Personne ne le remarque jusqu'à ce que quelque chose casse. Et quand ça casse, bonne chance pour déterminer si l'état « correct » se trouve dans Git, dans le cluster, ou dans l'historique du terminal de quelqu'un. GitOps résout ce problème en rendant une règle non négociable : Git est la vérité. Le cluster correspond à Git. Toujours. S'ils divergent, c'est le cluster qui change — pas Git. Selon une enquête CNCF End User Survey de mi-2025, près de 60 % des clusters Kubernetes s'appuient désormais sur Argo CD pour la livraison d'applications. Ce chiffre augmente chaque trimestre. Et 97 % des répondants utilisant Argo CD l'exécutent en production — contre 93 % en 2023. Ce n'est plus un outil expérimental. C'est la méthode standard avec laquelle les équipes sérieuses déploient sur Kubernetes. Mais la plupart des guides que j'ai trouvés supposaient que vous exécutez EKS ou GKE. Un cluster de production avec un réseau correctement configuré, des load balancers et des contrôleurs ingress déjà en place. Je voulais savoir : est-ce que ça marche sur Docker Desktop ? Sur un cluster local où vous expérimentez, cassez des choses et apprenez ? La réponse est oui — avec un contournement important que je vous montrerai à l'étape deux.

Ce que fait réellement Argo CD (Le modèle mental qui compte)

Avant de parcourir l'installation, je veux vous donner le modèle mental qui a fait que tout s'est mis en place pour moi. Parce que les commandes sont simples. Comprendre pourquoi elles fonctionnent est ce qui distingue quelqu'un qui installe Argo CD de quelqu'un qui l'utilise réellement bien. Argo CD est un controller Kubernetes. Il s'exécute dans votre cluster sous forme d'un ensemble de pods — un serveur, un serveur de dépôts, un controller d'applications et quelques services de support. Une fois installé, vous le dirigez vers un dépôt Git et lui dites : « Ce répertoire contient l'état souhaité de mon application. Surveille-le. » À partir de ce moment, Argo CD fonctionne en boucle de réconciliation continue :

1. Observer — Interroger le dépôt Git pour détecter les changements (ou recevoir des notifications webhook)
2. Comparer — Calculer la différence entre l'état souhaité dans Git et l'état réel dans le cluster
3. Agir — S'ils diffèrent, vous alerter (sync manuel) ou appliquer automatiquement les changements (auto sync) La troisième étape est là où réside la magie. Avec l'auto-sync activé, le flux de travail devient :

Push vers Git → Argo CD détecte le changement → Déploie automatiquement → S'auto-répare en cas de drift

Pas de pipeline CI/CD déclenchant une étape de déploiement. Pas d'humain exécutant des commandes. Vous poussez du code, et le cluster converge pour correspondre. La boucle de rétroaction est si serrée qu'elle a changé ma façon de penser aux déploiements. Voici ce qui l'a rendu concret pour moi : j'ai poussé une mise à jour de Helm chart vers mon dépôt infrawhisper à 23h15. À 23h15 et environ huit secondes, Argo CD avait déjà synchronisé le changement et les nouveaux pods étaient en cours de déploiement. Je n'ai même pas quitté mon éditeur de code. Le message de commit est apparu dans le tableau de bord Argo CD — feat(deploy): add Argo CD application manifest for GitOps deployment — et le statut de synchronisation affichait « Sync OK ». Ce niveau d'immédiateté rend les déploiements manuels aussi dépassés que d'envoyer des instructions de déploiement par pigeon voyageur. Encore une chose sur le modèle mental. Argo CD ne fait pas que déployer. Il surveille activement le drift. Si quelqu'un (ou quelque chose) modifie l'état du cluster en dehors de Git — un kubectl edit manuel, un script non autorisé, une suppression accidentelle — Argo CD détecte la différence et la corrige. Le cluster se répare lui-même. Je le prouverai avec un test en direct plus loin dans cet article. Mais d'abord, mettons-le en marche.

La configuration complète : Argo CD sur Docker Desktop Kubernetes

Prérequis — Ce dont vous avez besoin avant de commencer

Vous avez besoin de exactement deux choses :

• Docker Desktop avec Kubernetes activé (Paramètres → Kubernetes → Enable Kubernetes → Apply & Restart). J'utilise Docker Desktop sur macOS, mais les étapes sont identiques sur Windows et Linux.
• kubectl configuré et pointant vers votre cluster Docker Desktop. Vérifiez avec :

kubectl config current-context
# Devrait afficher : docker-desktop

Si vous voyez un contexte différent, changez avec kubectl config use-context docker-desktop. Vous ne voulez pas installer Argo CD accidentellement sur un cluster de production. Demandez-moi comment je sais que ça vaut le coup de vérifier. C'est tout. Pas de Helm requis pour l'installation de base. Pas de compte fournisseur cloud. Pas de load balancer. Le Kubernetes intégré de Docker Desktop suffit.

Étape 1 — Installer Argo CD dans votre cluster

Deux commandes. La première crée un namespace dédié. La seconde télécharge les manifestes officiels d'Argo CD et installe tout.

kubectl create namespace argocd
kubectl apply -n argocd -f \
  https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Cela installe Argo CD v3.3.4 (la version stable de mars 2026), qui inclut les hooks PreDelete, le rafraîchissement de jetons OIDC en arrière-plan, des contrôles RBAC améliorés et l'intégration KEDA. Le manifeste déploie plusieurs composants dans le namespace argocd :

• argocd-server — Le serveur API et l'interface web
• argocd-repo-server — Clone et traite vos dépôts Git
• argocd-application-controller — Le moteur de réconciliation qui surveille le drift
• argocd-redis — Couche de cache
• argocd-dex-server — Authentification SSO (optionnel pour les configurations locales) Attendez environ 60-90 secondes que tous les pods atteignent l'état Running. Vous pouvez les observer démarrer :

kubectl get pods -n argocd -w

Quand vous voyez cinq ou six pods affichant tous 1/1 Running, vous êtes prêt pour l'étape suivante. Et l'étape suivante est celle qui m'a bloqué pendant une bonne vingtaine de minutes.

Étape 2 — Supprimer les NetworkPolicies (Le piège Docker Desktop)

C'est l'étape qu'aucun guide de « démarrage rapide » ne mentionnait. J'ai installé Argo CD, j'ai essayé d'accéder à l'interface, et j'ai obtenu rien. Connection refused. Timeout. Les pods tournaient, le service existait, mais le port-forwarding ne... fonctionnait tout simplement pas. Après vingt minutes à vérifier les sélecteurs de service et les logs des pods, j'ai trouvé le problème : Argo CD est livré avec des ressources NetworkPolicy qui restreignent le trafic entre ses composants. Sur un vrai cluster avec un plugin CNI qui supporte les NetworkPolicies (Calico, Cilium, etc.), elles fonctionnent parfaitement. Sur le réseau Kubernetes intégré de Docker Desktop ? Elles cassent silencieusement tout. Le CNI par défaut de Docker Desktop n'applique pas les NetworkPolicies, mais les policies sont quand même créées et peuvent interférer avec la découverte de services de manières subtiles. La solution est simple :

kubectl delete networkpolicies --all -n argocd

C'est tout. Une commande. Vingt minutes de ma vie que je ne récupérerai pas. J'écris ceci pour que vous ne perdiez pas les mêmes vingt minutes.

Après avoir exécuté cela, le port-forwarding fonctionne immédiatement. Si vous utilisez un vrai cluster avec Calico ou Cilium, sautez cette étape — vous voulez garder ces policies.

Étape 3 — Accéder au tableau de bord Argo CD

Exposez maintenant le serveur Argo CD à votre machine locale :

kubectl port-forward svc/argocd-server -n argocd 8443:443

Ouvrez votre navigateur et allez à https://localhost:8443. Vous recevrez un avertissement de certificat — c'est normal pour un certificat auto-signé sur localhost. Cliquez pour continuer. Vous devriez voir l'écran de connexion d'Argo CD. Épuré. Minimaliste. Cette interface sombre qui signale « c'est un outil sérieux ».

Étape 4 — Obtenir vos identifiants de connexion

Le nom d'utilisateur par défaut est admin. Le mot de passe initial est généré automatiquement et stocké comme un secret Kubernetes. Extrayez-le avec :

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d

Copiez cette sortie — c'est votre mot de passe temporaire. Connectez-vous avec admin et le mot de passe décodé. Astuce de pro : Changez ce mot de passe immédiatement après la première connexion, surtout si quelqu'un d'autre a accès à votre réseau. Dans un environnement de développement local, c'est moins critique, mais prendre de bonnes habitudes compte. Vous pouvez le changer via la CLI d'Argo CD ou dans l'interface sous User Info → Update Password. À ce stade, vous avez une installation Argo CD entièrement fonctionnelle qui tourne sur votre cluster Kubernetes local. Le tableau de bord est vide — pas encore d'applications. Ça change maintenant.

Étape 5 — Créer votre manifeste Application

C'est ici qu'Argo CD se connecte à votre dépôt Git et commence à gérer vos déploiements. Vous avez besoin d'un manifeste Application — une ressource personnalisée Kubernetes qui indique à Argo CD quoi surveiller et où déployer. Voici le manifeste que j'ai utilisé pour mon projet infrawhisper :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-repo.git
    targetRevision: main
    path: deploy/helm/my-app
    helm:
      valueFiles:
        - values.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: my-app
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Laissez-moi expliquer ce que fait chaque section, car comprendre ces champs vous fait gagner des heures de débogage plus tard : source — Où Argo CD doit chercher vos manifestes :

• repoURL : Votre dépôt Git (les dépôts publics fonctionnent directement ; les dépôts privés nécessitent des identifiants configurés dans les paramètres d'Argo CD)
• targetRevision : Quelle branche suivre. J'utilise main, mais vous pouvez pointer vers n'importe quelle branche, tag ou SHA de commit
• path : Le répertoire dans le dépôt qui contient vos manifestes Kubernetes ou votre chart Helm
• helm.valueFiles : Si vous utilisez Helm (c'était mon cas), cela spécifie quel fichier de valeurs appliquer destination — Où Argo CD doit déployer :
• server : L'URL du serveur API Kubernetes. https://kubernetes.default.svc signifie « déployer dans le même cluster où Argo CD s'exécute ». Pour les configurations locales, c'est toujours ce que vous voulez.
• namespace : Le namespace cible pour les ressources de votre application syncPolicy — Comment Argo CD doit se comporter :
• automated : Active l'auto-sync. Sans cela, vous devriez cliquer manuellement sur « Sync » dans l'interface à chaque fois
• prune: true : Si vous supprimez une ressource de Git, Argo CD la supprime du cluster. Sans cela, les manifestes supprimés laissent des ressources orphelines
• selfHeal: true : C'est le point crucial. Si quelqu'un ou quelque chose modifie l'état du cluster en dehors de Git, Argo CD le rétablit. Votre cluster correspond toujours à Git.
• CreateNamespace=true : Argo CD créera le namespace cible s'il n'existe pas Sauvegardez cela sous application.yaml dans le répertoire de votre projet. Ajustez repoURL, path et namespace pour correspondre à votre configuration réelle.

Étape 6 — Déployer et observer la magie

Appliquez le manifeste :

kubectl apply -f application.yaml

Basculez maintenant vers votre tableau de bord Argo CD à https://localhost:8443. En quelques secondes, vous devriez voir votre application apparaître. Argo CD commence immédiatement la synchronisation — clonant votre dépôt, rendant le chart Helm (ou les manifestes simples), et appliquant les ressources à votre cluster. Pour mon projet infrawhisper, le tableau de bord s'est illuminé avec toute la topologie de l'application : api-server avec 3 pods, dashboard avec 2 pods, ai-engine avec 2 pods, stream-processor avec 2 pods, collector avec 2 pods, plus l'infrawhisper-agent et le contrôleur ingress. Le tout visible dans une vue réseau. Le hash du commit 776a48f de mon dernier push était directement visible dans l'interface, avec le message de commit que j'avais écrit quelques minutes plus tôt.

La liste des conteneurs Docker Desktop racontait la même histoire sous un angle différent — 38 conteneurs en cours d'exécution, avec les composants argocd aux côtés de mes pods applicatifs : ai-engine, api-server, clickhouse, collector, dashboard, kafka, postgres, redis, stream-processor. Une plateforme de données complète tournant en local, gérée entièrement via Git.

Voilà pour la configuration. Six étapes, moins de dix minutes. Mais la configuration n'est que la fondation. La vraie question est : est-ce que ça marche vraiment comme la documentation le promet ? J'ai effectué trois tests pour le découvrir.

Le test d'auto-réparation : Supprimer un pod exprès

Voici le test que j'ai effectué pour prouver que l'auto-réparation fonctionne sur un cluster local. Mon composant dashboard infrawhisper tournait avec 2 pods réplica. Un pod spécifique — dashboard-75fd8b8ddb-55x9h — tournait de manière saine depuis 11 jours. Stable, servant du trafic, faisant son travail. Je l'ai tué.

kubectl delete pod dashboard-75fd8b8ddb-55x9h -n my-app

Puis j'ai observé. Pas le tableau de bord d'Argo CD — j'ai observé le terminal. En six secondes :

• AVANT : dashboard-75fd8b8ddb-55x9h — Running, Âge : 11 jours
• SUPPRIMÉ : Pod terminé
• APRÈS : dashboard-75fd8b8ddb-lt5bn — Running, Âge : 6 secondes Un pod tout neuf, nom différent, même spécification. Le controller ReplicaSet de Kubernetes a géré le remplacement immédiat (c'est le comportement standard de Kubernetes). Mais voici la partie qui compte : la boucle de réconciliation d'Argo CD a confirmé que l'état du cluster correspondait toujours à l'état souhaité dans Git. Si la suppression du pod avait causé un drift du déploiement global par rapport à la définition de Git — par exemple, si quelqu'un avait réduit manuellement le nombre de réplicas — Argo CD l'aurait également détecté et corrigé. Ce n'est pas de la résilience hypothétique. C'est mesurable. Je l'ai vu se produire sur mon laptop, sur un cluster local, avec des outils que vous pouvez installer en dix minutes. L'implication plus profonde a mis une journée à être assimilée. Avec l'auto-réparation activée, vos manifestes de déploiement dans Git ne sont pas de simples fichiers de configuration. Ce sont un contrat. Une promesse sur ce à quoi le cluster doit ressembler à tout moment. Brisez le contrat manuellement, et le système l'applique automatiquement. Ce changement de mentalité — de « je déploie des choses » à « je déclare des choses et le système les maintient » — est au cœur du GitOps. Et ça se ressent complètement différemment une fois que vous l'avez expérimenté de première main.

Détection de drift : Le gardien silencieux

Le test d'auto-réparation couvre les suppressions accidentelles. Mais qu'en est-il des modifications manuelles intentionnelles ? Le genre qui se produit quand quelqu'un exécute kubectl edit deployment pour « corriger rapidement » quelque chose en production à 3 heures du matin ? J'ai testé cela en réduisant manuellement mon déploiement api-server de 3 réplicas à 1 :

kubectl scale deployment api-server --replicas=1 -n my-app

Pendant environ quinze secondes, le cluster avait 1 pod api-server au lieu des 3 définis dans mon dépôt Git. Puis la boucle de réconciliation d'Argo CD a détecté le drift, comparé l'état réel à Git, et remis à l'échelle à 3. Pas d'alarme. Pas d'intervention manuelle. Le tableau de bord Argo CD a brièvement affiché la santé de l'application comme « Degraded » (ce qui est exact — exécuter moins de réplicas que souhaité est dégradé), puis est repassé à « Healthy » une fois la réconciliation terminée. C'est le comportement qui rend GitOps transformateur pour les équipes. Il ne fait pas que prévenir les problèmes — il les corrige activement. Et il crée une piste d'audit. Chaque opération de synchronisation apparaît dans l'historique d'Argo CD. Vous pouvez voir exactement quand le drift s'est produit et quand il a été corrigé. Essayez d'obtenir ça avec kubectl apply.

Auto-Sync : Push vers Git, regardez le déploiement

Le troisième test était le plus simple et le plus satisfaisant. J'ai modifié une valeur dans le values.yaml de mon Helm chart — augmenté le nombre de réplicas du dashboard de 2 à 3 — commité et poussé vers main. J'avais le tableau de bord Argo CD ouvert dans un navigateur et mon terminal exécutant kubectl get pods -n my-app -w côte à côte. En environ quinze secondes après le push, Argo CD a détecté le nouveau commit, téléchargé le chart mis à jour, rendu les manifestes et appliqué le changement. Un troisième pod dashboard a commencé à démarrer sous mes yeux. Le statut de synchronisation dans le tableau de bord s'est mis à jour pour afficher le nouveau hash de commit. Le message de commit que je venais d'écrire était là dans l'interface. Pas de pipeline. Pas de configuration webhook. Pas de script de déploiement. J'ai poussé du code et le cluster a changé. C'est la promesse de GitOps, et sur un cluster Docker Desktop local exécutant Argo CD v3.3.4, elle a été tenue exactement comme annoncé.

Ce qu'Argo CD réussit — Et où il est honnête

Après avoir fait tourner cette configuration pendant plusieurs jours sur mon projet infrawhisper, voici mon évaluation honnête. Ce qui est véritablement impressionnant :

• Le tableau de bord seul justifie l'installation. Voir toute la topologie de votre application — chaque deployment, service, pod et ingress — dans une carte visuelle est quelque chose que kubectl ne pourra jamais vous donner. Pour mon projet infrawhisper avec ses plus de douze composants, c'est passé de « ce serait bien » à « comment je faisais sans ça » en environ trois heures.
• La vitesse de synchronisation est réelle. Je m'attendais à des minutes. J'ai eu des secondes. Le délai entre le push vers Git et le changement visible en direct dans le cluster était systématiquement inférieur à 20 secondes sur ma configuration locale.
• Le rollback se fait en un clic. Argo CD conserve un historique de chaque synchronisation. Si un déploiement tourne mal, vous cliquez sur « Rollback » et sélectionnez un commit précédent. Le cluster revient en arrière. Essayez de faire ça avec kubectl apply et une prière.
• Le rendu des Helm charts est fait pour vous. Je n'ai pas eu besoin d'exécuter helm template ou helm install localement. Le repo-server d'Argo CD rend le chart et applique la sortie. Cela signifie que votre dépôt Git n'a besoin que du code source du chart — Argo CD gère le reste. Ce que j'aurais aimé que quelqu'un me dise :
• La surcharge de ressources n'est pas négligeable. Sur Docker Desktop, les composants d'Argo CD ont ajouté environ 500 à 700 Mo d'utilisation RAM et plusieurs cœurs CPU d'activité en arrière-plan. Sur une machine moderne, c'est acceptable. Sur un laptop plus ancien, vous le sentirez. Mon Docker Desktop exécutait déjà 38 conteneurs pour le stack infrawhisper — ajouter les pods d'Argo CD par-dessus a poussé l'utilisation mémoire totale au-delà de 8 Go.
• Les dépôts privés nécessitent une configuration supplémentaire. Si votre dépôt Git est privé (la plupart le sont), vous devez configurer les identifiants de dépôt dans les paramètres d'Argo CD. Cela implique soit une clé SSH, un jeton d'accès personnel, soit une GitHub App. La documentation officielle couvre bien ce sujet, mais c'est une étape supplémentaire que les guides « installation en deux commandes » omettent opportunément.
• Le processus du mot de passe admin initial est maladroit. Décoder en Base64 un secret Kubernetes pour obtenir son premier mot de passe fonctionne, mais ce n'est pas une expérience développeur formidable. J'aimerais voir un assistant de configuration interactif pour les installations locales.
• Les NetworkPolicies sur Docker Desktop sont une vraie perte de temps. J'ai déjà couvert cela dans les étapes de configuration, mais ça vaut la peine de le répéter : si vous êtes sur Docker Desktop et que les connexions ne fonctionnent pas, supprimez d'abord les NetworkPolicies. Ce seul problème cause probablement plus d'installations locales d'Argo CD abandonnées que n'importe quel vrai bug. Si vous préférez confier à quelqu'un la construction de ce type d'infrastructure de zéro — clusters Kubernetes, pipelines GitOps, tout le stack d'ingénierie de plateforme — j'accepte des projets DevOps et d'ingénierie cloud. Vous pouvez voir ce que j'ai construit sur fiverr.com/s/EgxYmWD.

Où cela s'intègre dans un vrai workflow

Exécuter Argo CD en local n'est pas qu'un exercice d'apprentissage. C'est la première étape d'un workflow qui évolue directement vers la production. Voici la progression que je prévois pour mon projet infrawhisper : Étape 1 (où j'en suis) : Cluster Docker Desktop local avec Argo CD gérant les déploiements Helm. Parfait pour le développement, tester les comportements de synchronisation et valider les manifestes avant qu'ils ne touchent un vrai cluster. Étape 2 : Déplacer les mêmes manifestes — sans modification — vers un cluster de staging sur AWS EKS ou un cluster auto-géré. Le manifeste Application d'Argo CD reste identique. Seul le destination.server change. Étape 3 : Déploiement en production avec Argo CD gérant plusieurs environnements via ApplicationSets. Même dépôt Git, différents fichiers de valeurs par environnement, Argo CD orchestrant le déploiement vers chacun. L'insight clé : le manifeste Application que j'ai écrit à l'étape 5 de ce guide ne change pas entre les étapes. Le Helm chart ne change pas. La politique de synchronisation ne change pas. Je construis le workflow de production maintenant, sur mon laptop, avec les mêmes outils que j'utiliserai quand infrawhisper sera en production. Ce n'est pas un avantage secondaire d'Argo CD local — c'est l'avantage principal. Les ingénieurs de plateforme représentent désormais 37 % des utilisateurs d'Argo CD selon l'enquête CNCF, et c'est exactement pourquoi. Les patterns que vous établissez localement se transfèrent directement en production. Il n'y a pas d'étape « réécrire le pipeline de déploiement » quand vous êtes prêt à livrer.

Les cinq choses qu'Argo CD vous donne que kubectl apply ne donnera jamais

Après avoir vécu avec cette configuration, je peux articuler exactement ce qui a changé. Pas en termes abstraits — en termes concrets de workflow quotidien : 1. L'Auto Sync élimine complètement l'étape de déploiement. Push vers Git. Partez. Le cluster se met à jour. Ça semble anodin jusqu'à ce que vous réalisiez combien de fois par jour vous exécutez kubectl apply. Pour moi, c'était 15 à 20 fois pendant le développement actif. Chaque fois, c'est un changement de contexte, une fenêtre de terminal, une chance d'appliquer le mauvais manifeste au mauvais namespace. Tout disparu. 2. L'auto-réparation attrape des erreurs que vous ne remarqueriez jamais. Suppressions accidentelles de pods. Scripts non autorisés. Autoscalers mal configurés. Argo CD détecte le drift et le corrige. Sur mon stack infrawhisper avec plus de 10 microservices, ce n'est pas un luxe — c'est la différence entre un environnement local stable et un qui se dégrade lentement. 3. La détection de drift crée la responsabilité. Chaque modification manuelle est annulée et journalisée. C'est la sécurité et l'hygiène opérationnelle combinées. Vous pouvez voir qui (ou quoi) a modifié le cluster, quand, et comment Argo CD l'a corrigé. 4. Le tableau de bord visuel remplace une douzaine de commandes kubectl. Statut des pods, nombre de réplicas, health checks, historique de synchronisation, topologie de l'application — le tout dans un onglet de navigateur. Avant, j'exécutais kubectl get pods, kubectl get svc, kubectl describe deployment et kubectl logs en succession rapide juste pour comprendre l'état de mon cluster. Maintenant, je jette un coup d'œil au tableau de bord Argo CD. 5. Le rollback devient un simple clic. Pas « trouver le dernier commit fonctionnel, extraire le manifeste, l'appliquer, vérifier que ça a marché ». Un clic. Sélectionner le commit. Terminé. Pour un projet comme infrawhisper avec des services interdépendants, cela seul justifie la configuration.

Ce que je ferais différemment la prochaine fois

Si je devais tout reconfigurer de zéro, trois choses changeraient : J'installerais la CLI Argo CD dès le départ. L'interface web est excellente pour la visualisation, mais la CLI (argocd) est plus rapide pour gérer les applications, synchroniser et vérifier le statut depuis le terminal. Je ne l'ai pas installée au début parce que je voulais garder la configuration minimale, et je l'ai regretté en moins d'un jour. Installez-la avec :

brew install argocd

J'utiliserais les ApplicationSets dès le premier jour. Mon projet infrawhisper a un seul manifeste Application, mais au fur et à mesure que j'ajoute des environnements (staging, production), j'aurai besoin d'une Application par environnement. Les ApplicationSets vous permettent de créer des templates de ressources Application — une définition qui génère plusieurs Applications basées sur des paramètres. Commencer avec ce pattern tôt évite une migration ultérieure. Je configurerais les identifiants du dépôt immédiatement. J'ai commencé avec un fork de dépôt public pour les tests, puis je suis passé à mon vrai dépôt privé. L'étape de configuration des identifiants a interrompu mon flux. Configurez-le d'abord, même si votre dépôt est actuellement public. Votre futur vous vous remerciera.

Pour démarrer : La checklist de dix minutes

Voici la version condensée. Si vous avez tout lu ci-dessus et voulez juste les étapes sur un seul écran :

# 1. Vérifiez votre contexte Kubernetes
kubectl config current-context  # Devrait être : docker-desktop
# 2. Installez Argo CD
kubectl create namespace argocd
kubectl apply -n argocd -f \
  https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
# 3. Attendez les pods (environ 60-90 secondes)
kubectl get pods -n argocd -w
# 4. Supprimez les NetworkPolicies (Docker Desktop uniquement !)
kubectl delete networkpolicies --all -n argocd
# 5. Port-forward l'interface
kubectl port-forward svc/argocd-server -n argocd 8443:443
# 6. Récupérez le mot de passe admin
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d
# 7. Connectez-vous sur https://localhost:8443 (admin + mot de passe décodé)
# 8. Appliquez votre manifeste Application
kubectl apply -f application.yaml

Huit commandes. Moins de dix minutes. Un pipeline GitOps entièrement fonctionnel tournant sur votre laptop. Argo CD prend en charge les Helm charts, Kustomize, Jsonnet et les manifestes YAML simples — quel que soit votre format de déploiement actuel, il s'intègre sans rien réécrire. Pour mon projet infrawhisper, j'ai utilisé Helm parce que le chart était déjà structuré pour des déploiements paramétrés. Mais si vous avez un répertoire de manifestes YAML bruts, pointez simplement le source.path de l'Application vers ce répertoire et supprimez la section helm. Argo CD se charge du reste.

Questions fréquemment posées

Est-ce qu'Argo CD fonctionne avec Docker Desktop Kubernetes ?

Oui. Argo CD tourne sur le Kubernetes intégré de Docker Desktop avec un contournement nécessaire : supprimez les NetworkPolicies par défaut dans le namespace argocd, car le CNI de Docker Desktop ne les gère pas correctement. Après cela, toutes les fonctionnalités — auto-sync, auto-réparation, détection de drift et le tableau de bord web — fonctionnent de manière identique aux clusters hébergés dans le cloud.

Combien de RAM utilise Argo CD sur un cluster local ?

Comptez 500 à 700 Mo de RAM supplémentaire pour les composants du plan de contrôle d'Argo CD (server, repo-server, application-controller, redis, dex). Sur une machine avec 16 Go+ de RAM, c'est négligeable. Sur des machines à 8 Go exécutant d'autres charges de travail lourdes, vous devrez peut-être ajuster les limites de ressources dans les manifestes d'Argo CD.

Est-ce qu'Argo CD peut déployer depuis un dépôt Git privé ?

Oui, mais vous devez d'abord configurer les identifiants du dépôt dans les paramètres d'Argo CD. Les options incluent les clés SSH, les jetons d'accès personnels ou les GitHub Apps. Configurez cela via l'interface Argo CD (Settings → Repositories) ou via la CLI argocd avant de créer votre manifeste Application.

Que se passe-t-il si je modifie manuellement quelque chose dans le cluster ?

Avec selfHeal: true dans la politique de synchronisation de votre Application, Argo CD détecte le drift et rétablit automatiquement le cluster pour correspondre à Git. Le tableau de bord affiche brièvement l'application comme « OutOfSync » ou « Degraded », puis la corrige lors du prochain cycle de réconciliation (typiquement moins de 30 secondes). L'événement de drift est journalisé dans l'historique de synchronisation pour l'audit.

Est-ce que la configuration locale d'Argo CD est la même qu'en production ?

Pratiquement identique. Le manifeste Application, les politiques de synchronisation et la configuration du Helm chart se transfèrent directement à un cluster de production. Les seules modifications sont l'URL destination.server (pointant vers votre cluster de production au lieu de kubernetes.default.svc) et les fichiers de valeurs spécifiques à l'environnement. C'est l'un des arguments les plus forts pour commencer en local — vous construisez des patterns de production dès le premier jour.

Travaillons ensemble

Vous cherchez à construire des systèmes d'IA, automatiser des workflows ou faire évoluer votre infrastructure technologique ? Je serais ravi de vous aider.

• Fiverr (builds sur mesure et intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design et branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io