Aller au contenu principal
CTN Solutions

Navigation

Ressources

GitOps, c'est quoi ? Principes, différence avec le CI/CD, outils et quand l'adopter

GitOps, c'est quoi ? Les quatre principes OpenGitOps, ce qui change face à un pipeline CI/CD qui pousse, quand l'adopter et comment choisir l'outil.

L'équipe CTN Solutions · publié le · 16 min de lecture

Base d'expérience : Méthode et documentation officielle (principes et glossaire OpenGitOps v1.0.0, documentation d'Argo CD 3.5.5 et de Flux 2.9.6, annonces de la CNCF), sans référence client, sans retour de mission ni déploiement nommé.

Faits vérifiés sur les sources primaires le

Sur Kubernetes, un pipeline d'intégration et de livraison continues (CI/CD) qui applique lui-même les manifestes laisse une question sans réponse : ce qui tourne dans le cluster correspond-il encore à ce qui a été revu ? Une correction faite à la main pendant un incident ou un paramètre modifié hors du dépôt peuvent créer un écart que le pipeline ne voit pas, puisqu'il n'agit qu'à son déclenchement. Le jour où il faut revenir en arrière ou reconstruire un environnement, l'état de référence doit alors être reconstitué au lieu d'être relu.

GitOps répond à ce problème par une méthode d'exploitation : l'état désiré est déclaré, versionné dans un dépôt, puis tiré et réconcilié en continu par des agents logiciels. Cet article en donne la définition de référence, ce qu'elle change face à un pipeline qui pousse, les signes qu'il est temps de l'adopter ou encore trop tôt, et trois questions pour choisir l'outil ; l'exploitation au quotidien relève des guides présentés au chapitre 5.

Faits datés

Cette lecture s'appuie sur les principes et le glossaire OpenGitOps en version 1.0.0, sur la documentation d'Argo CD 3.5.5 (dernière version stable, publiée le 12 octobre 2026) et sur celle de Flux 2.9.6 (dernière version stable, publiée le 1er octobre 2026). Versions, dates et comportements par défaut ont été vérifiés le sur les sources officielles listées en fin d'article.

Vérifié le

GitOps, c'est quoi : une méthode d'exploitation en quatre principes

La définition de référence est publiée par OpenGitOps, projet Sandbox de la CNCF (Cloud Native Computing Foundation) depuis le 26 janvier 2021, qui publie les documents rédigés par le GitOps Working Group, fusionné avec le projet en mars 2024. Sa version 1.0.0, publiée en octobre 2021, est la première version complète des principes et du glossaire. Le document des principes donne cette définition :

« GitOps is a set of principles for operating and managing software systems. »

Autrement dit, un ensemble de principes pour exploiter et gérer des systèmes logiciels : une méthode, pas un outil. Les quatre principes portent sur l'état désiré du système.

Les quatre principes OpenGitOps v1.0.0 : nom officiel, texte anglais de la version 1.0.0 et traduction
Principe (nom officiel)Texte de la version 1.0.0Traduction
Declarative (déclaratif)A system managed by GitOps must have its desired state expressed declaratively.Un système géré par GitOps doit avoir son état désiré exprimé de manière déclarative.
Versioned and Immutable (versionné et immuable)Desired state is stored in a way that enforces immutability, versioning and retains a complete version history.L'état désiré est stocké d'une manière qui impose l'immuabilité et le versionnage, et qui conserve un historique complet des versions.
Pulled Automatically (tiré automatiquement)Software agents automatically pull the desired state declarations from the source.Des agents logiciels tirent automatiquement les déclarations d'état désiré depuis la source.
Continuously Reconciled (réconcilié en continu)Software agents continuously observe actual system state and attempt to apply the desired state.Des agents logiciels observent en continu l'état réel du système et tentent d'appliquer l'état désiré.

Le vocabulaire du glossaire

Le glossaire de la même version compte huit entrées ; cinq suffisent pour lire la suite.

  • État désiré (desired state) : les données de configuration suffisantes pour recréer le système. Il ne comprend généralement pas les données applicatives persistantes, comme le contenu d'une base, mais souvent les identifiants qui y donnent accès.
  • Magasin d'état (state store) : le système qui conserve des versions immuables de l'état désiré, avec contrôle d'accès et audit des changements. Git, dont GitOps tire son nom, en est l'exemple canonique ; tout système qui remplit ces critères peut servir.
  • Réconciliation : le processus qui fait correspondre l'état réel à l'état désiré. Contrairement au CI/CD traditionnel, généralement piloté par des déclencheurs prédéfinis, elle se déclenche à chaque divergence.
  • Dérive (drift) : l'état réel s'est écarté, ou est en train de s'écarter, de l'état désiré.
  • Continu : la réconciliation continue d'avoir lieu, sans devoir être instantanée.

Le blog OpenGitOps attribue le terme à Alexis Richardson, et le blog de Flux rattache son invention à un billet de Weaveworks sur les Operations by Pull Request.

Ce que GitOps change par rapport à un pipeline CI/CD qui pousse

Dans un pipeline qui pousse, l'intégration continue (CI) construit et teste l'image, puis applique les manifestes au cluster avec des droits d'écriture sur celui-ci. Le cluster ne change qu'au déclenchement, et le pipeline ne le regarde plus ensuite. Le billet d'annonce d'OpenGitOps 1.0 précise que le verbe « tirer » du principe 3 s'oppose justement aux pipelines qui poussent sur déclenchement.

En GitOps, la responsabilité se répartit autrement :

  1. Le pipeline s'arrête à une proposition. Il construit, teste et publie l'image, puis propose une nouvelle version de l'état désiré, par exemple une pull request qui change la référence d'image dans le dépôt de configuration. Selon la documentation d'Argo CD, avec la synchronisation automatique, le pipeline n'a plus besoin d'accéder au serveur d'API d'Argo CD : il commite et pousse dans le dépôt suivi. Le guide « Jenkins + Flux », que Flux signale comme non mis à jour depuis plus d'un an, indique aussi que le CI n'a pas besoin d'accès direct aux clusters de production.
  2. L'agent tire, puis compare. Argo CD interroge les dépôts toutes les 3 minutes par défaut, et des webhooks suppriment ce délai. Chez Flux, un webhook rend le modèle plus réactif sans le transformer en modèle « push » : l'événement ne contient aucune instruction et sert seulement de réveil anticipé. OpenGitOps admet ces déclencheurs, à condition de ne pas en dépendre exclusivement.
  3. La comparaison continue après le déploiement. Chez Argo CD, une application qui s'écarte de l'état cible apparaît OutOfSync ; elle n'est ramenée automatiquement à cet état qu'avec l'option selfHeal: true de la synchronisation automatique, faute de quoi l'écart reste affiché jusqu'à une nouvelle synchronisation. Chez Flux, chaque réconciliation d'une Kustomization réapplique l'état désiré : une modification faite par kubectl edit, patch ou delete est annulée à la réconciliation suivante.
  4. Le retour arrière passe par le dépôt. Avec la synchronisation automatique, Argo CD n'autorise pas sa propre fonction de rollback : on revient en arrière par un commit, qui rétablit des déclarations, pas des données persistantes.

« Continu » ne veut pas dire instantané : chez Flux, l'intervalle (.spec.interval) est un champ obligatoire de chaque Kustomization, GitRepository ou HelmRelease, et les réglages recommandés pour la production dans la spécification Kustomization prévoient de détecter la dérive et d'annuler les modifications faites avec kubectl toutes les heures. Le principe 3 ne dit pas non plus où l'agent s'exécute : une instance Argo CD peut déployer sur plusieurs clusters, un cluster Flux peut gérer des applications dans d'autres clusters. Le modèle tient à ce que l'agent tire l'état et le compare en continu, au lieu de recevoir des instructions d'un pipeline.

Pipeline qui pousse, agent qui tire et réconcilie

À gauche, le pipeline applique lui-même les manifestes à chaque déclenchement ; à droite, il propose une nouvelle version de l'état désiré, qu'un agent tire, compare en continu à l'état réel et applique.

Schéma défilable horizontalement ; sa version textuelle complète suit.

Lire le schéma sous forme textuelle
  1. Pipeline qui pousse : un commit déclenche l'intégration continue, qui construit et teste l'image puis applique elle-même les manifestes, avec des droits d'écriture sur le cluster.
  2. Le cluster n'est modifié qu'à ce déclenchement : un écart introduit après coup échappe au pipeline.
  3. Modèle GitOps : le commit déclenche aussi la construction et les tests de l'image, puis l'intégration continue propose une nouvelle version de l'état désiré par une pull request.
  4. Une fois fusionnée, cette version est conservée dans un dépôt versionné, Git ou registre OCI.
  5. L'agent, Argo CD ou Flux, tire l'état désiré depuis ce dépôt et le compare à l'état réel du cluster.
  6. En cas d'écart, nouvelle version ou dérive, l'agent applique l'état désiré si sa politique de correction le prévoit, puis la comparaison reprend.
Modèle explicatif, sans donnée client, d'après les principes OpenGitOps v1.0.0 et les documentations d'Argo CD 3.5.5 et de Flux 2.9.6 citées en fin d'article.

Ce que le modèle change pour les droits et les secrets

Le gain tient à un déplacement des droits, pas à leur disparition : le CI n'a plus besoin de droits d'écriture sur les clusters, mais l'agent les reçoit. Flux lie kustomize-controller et helm-controller au rôle cluster-admin et applique par défaut une Kustomization avec le compte d'administration du cluster, sauf si .spec.serviceAccountName en restreint la portée ; une instance Argo CD conserve les identifiants des clusters qu'elle gère dans des Secrets Kubernetes. Flux range d'ailleurs « Pull vs. Push » et le moindre privilège parmi ses principes de sécurité : protéger l'agent et le dépôt conditionne le gain.

Le dépôt devenant la source de vérité, il ne doit pas contenir de secrets en clair. La documentation de Flux juge dangereux de stocker des Secrets en clair ou en base64 dans Git, quelle que soit la visibilité du dépôt, et le déchiffrement intégré aux Kustomization ne prend en charge que SOPS ; l'historique du dépôt conserve aussi les anciennes versions chiffrées, ce qui aggrave la fuite d'une ancienne clé. La documentation d'Argo CD recommande fortement de peupler les secrets dans le cluster de destination (Sealed Secrets, External Secrets Operator, Secrets Store CSI Driver) plutôt que de les injecter à la génération des manifestes, qu'Argo CD conserve en clair dans son cache Redis.

Quand adopter GitOps, et quand c'est prématuré

Aucune source officielle ne fixe de seuil d'adoption, ni en taille d'équipe, ni en nombre de clusters, ni en fréquence de déploiement. Les signes qui suivent sont une grille de lecture éditoriale, appuyée sur les définitions et documentations citées.

Les signes qu'il est temps

  • Plusieurs environnements ou clusters doivent rester identiques, ou pouvoir être reconstruits. L'état désiré suffit par définition à recréer le système : un cluster peut se reconstruire à partir du dépôt, données persistantes et secrets gérés hors du dépôt mis à part.
  • Chaque changement doit laisser une trace revue. L'historique complet et le contrôle d'accès du magasin d'état font de la revue de fusion le point de contrôle.
  • Des modifications manuelles créent des écarts. La comparaison continue rend la dérive visible, et la corrige si la politique de l'outil le prévoit.
  • Le pipeline détient des droits d'écriture sur les clusters. Le modèle permet de les lui retirer, à condition de protéger l'agent qui les reçoit.

Les signes que c'est prématuré

  • Les déploiements reposent sur des scripts impératifs. Le glossaire définit une description déclarative comme celle qui décrit l'état voulu sans spécifier de procédure : il faut d'abord traduire les commandes en manifestes.
  • Les images sont référencées par une étiquette mutable comme « latest ». Selon le billet d'annonce d'OpenGitOps 1.0, un tel état désiré n'est plus versionné, faute de retour arrière possible.
  • Aucune stratégie de secrets n'est choisie. Le dépôt ne doit contenir aucun secret en clair : le chiffrement ou la synchronisation des secrets se décide avant le premier commit.
  • Personne ne peut absorber la cadence des mises à jour. L'agent devient un composant de production : la documentation d'Argo CD ne recommande pas son installation sans haute disponibilité en production, et chaque outil ne maintient que ses trois dernières versions mineures.
  • On attend de GitOps qu'il restaure les données. L'état désiré exclut généralement les données applicatives persistantes (chapitre 1) : sauvegarder et restaurer une base ou un volume reste un dispositif distinct, à prévoir hors du dépôt.

Entre les deux, un périmètre restreint peut servir de premier pas : une couche de composants ou un environnement hors production, avec une politique de correction de la dérive décidée par écrit.

Choisir l'outil : trois questions avant de trancher

Argo CD se présente comme un outil de livraison continue déclaratif et GitOps pour Kubernetes, qui prend des dépôts Git comme source de vérité ; Flux, comme un outil qui garde les clusters Kubernetes synchronisés avec des sources de configuration et automatise les mises à jour de configuration quand du nouveau code est à déployer. Flux est diplômé de la CNCF depuis le 30 novembre 2022 ; Argo, le projet qui regroupe Argo CD, Argo Workflows, Argo Events et Argo Rollouts, l'est depuis le 6 décembre 2022, un statut qui porte sur le projet Argo dans son ensemble et non sur Argo CD seul. Aucun des deux projets ne publie de comparatif ; trois questions, tirées de leurs documentations, orientent le choix sans valoir recommandation.

Une interface et des droits propres, ou le RBAC de Kubernetes ?

Argo CD fournit une interface web, une API et une interface en ligne de commande (CLI), avec son propre contrôle d'accès fondé sur les rôles (RBAC) : la ConfigMap argocd-rbac-cm et les rôles d'AppProject. Il n'a pas de gestion d'utilisateurs hormis le compte admin et s'appuie sur une authentification unique (SSO) ou des comptes locaux ; son installation « Core », dont le paquet ne comprend ni serveur d'API ni interface, renonce à ce RBAC et s'appuie sur le seul RBAC de Kubernetes. Flux ne fournit pas d'interface propre : il s'appuie sur le RBAC de Kubernetes et l'impersonation, et les interfaces viennent de l'écosystème, comme la Flux Web UI du projet Flux Operator, extérieur au projet CNCF Flux. Ce que ce choix engage pour les équipes produit est détaillé dans le chapitre « Argo CD ou Flux : critères de choix » de l'article sur GitOps en production.

Combien de clusters, et depuis où ?

Une instance Argo CD peut déployer sur plusieurs clusters, dont elle stocke les identifiants comme Secrets Kubernetes ; argocd cluster add exige un accès privilégié au cluster ajouté. Son contrôleur ApplicationSet, intégré depuis la version 2.3, génère des Applications pour de nombreux clusters à partir d'un seul manifeste, et seuls des administrateurs doivent pouvoir créer, modifier ou supprimer un ApplicationSet. Chez Flux, une Kustomization cible un cluster distant par .spec.kubeConfig : un Secret contenant un kubeconfig, ou une ConfigMap fondée sur l'identité de charge de travail, sans Secret, mode que la documentation recommande. Dans les deux cas, l'endroit où vivent les identifiants des clusters se décide avant le premier déploiement.

Quelle cadence de mise à jour l'équipe peut-elle tenir ?

Argo CD publie une version mineure tous les trois mois et ne corrige que les trois dernières ; au , la dernière stable est la 3.5.5 et la 3.6 est prévue le 3 novembre 2026, date indicative. Flux maintient ses trois dernières versions mineures, au rythme d'au moins trois par an ; sa dernière stable est la 2.9.6. Argo CD 3.5 est testé avec Kubernetes 1.33 à 1.36, Flux 2.9 prend en charge Kubernetes 1.34, 1.35 et 1.36 : un cluster dont les montées de version prennent du retard peut sortir de la fenêtre de l'outil.

Les comportements par défaut à connaître

  • Sans prune: true, la synchronisation automatique d'Argo CD laisse en place les ressources retirées de Git, et elle refuse par défaut une synchronisation qui viderait l'application (allowEmpty).
  • Le projet default d'Argo CD, créé automatiquement, autorise toute source, toute destination et tout type d'objet.
  • Chez Flux, .spec.prune est un champ obligatoire de chaque Kustomization, sans valeur par défaut.

Le comparatif détaillé, critère par critère, dérive comprise, se trouve dans « GitOps en production : Argo CD ou Flux, santé des applications et nettoyage des orphelins ».

Passer à la production : ce que traitent les guides détaillés

Une fois l'outil choisi, les questions changent de nature : que signifie une application « Degraded », comment amorcer un cluster, que devient un champ retiré du dépôt. Trois guides publiés les traitent :

Changements datés à vérifier avant d'installer

  • Argo CD 3.5 passe à Helm 4, avec une rupture pour les registres OCI servis en HTTP simple, et remplace la vérification de signature GnuPG par Source Integrity.
  • Flux 2.8 a retiré les API v1beta2 des sources et des Kustomization, Flux 2.9 celles des images et des notifications (migration par flux migrate) ; Flux 2.9 ajoute aussi .spec.ignore aux Kustomization, pour exclure des champs précis de la correction de dérive, comme /spec/replicas géré par un autoscaler horizontal (HPA).
  • Flux v1 est en fin de vie et archivé : un tutoriel écrit pour lui ne décrit pas les contrôleurs spécialisés de Flux v2.

Sur une plateforme que nous construisons, nous fixons d'abord les règles de gouvernance, puis l'outil qui doit les appliquer : qui déploie, avec quels droits, où vivent les secrets. C'est la démarche de la page Plateforme Kubernetes : livrer sans perdre le contrôle.

Sources officielles et limites de lecture

Les principes et le glossaire OpenGitOps sont cités au tag v1.0.0 de leur dépôt ; Argo CD, d'après sa documentation stable (version 3.5.5 au ) ; Flux, d'après les spécifications de kustomize-controller 1.9.6, source-controller 1.9.6 et helm-controller 1.6.5, livrés avec Flux 2.9.6, et les pages du projet. L'ensemble a été vérifié le . Les traductions sont libres ; seul le texte anglais d'OpenGitOps fait foi.

  • Les signes d'adoption et de prématurité relèvent d'un jugement éditorial : aucune source officielle ne fixe de seuil.
  • Argo CD et Flux ne publient pas de comparatif officiel, et aucune donnée de part de marché ou de performance n'est citée ici : les trois questions ne classent pas les outils.
  • Les versions évoluent vite et la date d'Argo CD 3.6 n'est qu'un plan : toute procédure tirée de cet article se vérifie sur la version réellement déployée.
  • L'origine du terme est rapportée sans date, faute d'avoir pu vérifier celle du billet de Weaveworks sur une source primaire.
  • Cet article ne traite ni l'organisation des dépôts, ni le choix d'un outil de secrets, ni le déploiement progressif, et ne décrit aucun déploiement client.

Sources

  1. GitOps Principles v1.0.0, OpenGitOps (CNCF), https://github.com/open-gitops/documents/blob/v1.0.0/PRINCIPLES.md, consulté le 18/10/2026.
  2. GitOps Glossary v1.0.0, OpenGitOps (CNCF), https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md, consulté le 18/10/2026.
  3. Release v1.0.0, open-gitops/documents, OpenGitOps, https://github.com/open-gitops/documents/releases/tag/v1.0.0, consulté le 18/10/2026.
  4. README du dépôt open-gitops/documents, tag v1.0.0, OpenGitOps, https://github.com/open-gitops/documents/blob/v1.0.0/README.md, consulté le 18/10/2026.
  5. History, open-gitops/project, https://github.com/open-gitops/project/blob/main/history.md, consulté le 18/10/2026.
  6. OpenGitOps 1.0 is finally here and why you should care, OpenGitOps, https://opengitops.dev/blog/1.0-announcement/, consulté le 18/10/2026.
  7. CNCF Landscape (landscape.yml), Cloud Native Computing Foundation, https://github.com/cncf/landscape/blob/master/landscape.yml, consulté le 18/10/2026.
  8. The Cloud Native Computing Foundation Announces Argo has Graduated, CNCF, https://www.cncf.io/announcements/2022/12/06/the-cloud-native-computing-foundation-announces-argo-has-graduated/, consulté le 18/10/2026.
  9. Flux Graduates from the Cloud Native Computing Foundation Incubator, CNCF, https://www.cncf.io/announcements/2022/11/30/flux-graduates-from-cncf-incubator/, consulté le 18/10/2026.
  10. Flux turns 10!, Flux, https://fluxcd.io/blog/2026/07/flux-turns-10/, consulté le 18/10/2026.
  11. Release v3.5.5, Argo CD, https://github.com/argoproj/argo-cd/releases/tag/v3.5.5, consulté le 18/10/2026.
  12. Release Process And Cadence, Argo CD, https://argo-cd.readthedocs.io/en/latest/developer-guide/release-process-and-cadence/, consulté le 18/10/2026.
  13. Overview, Argo CD, https://argo-cd.readthedocs.io/en/stable/, consulté le 18/10/2026.
  14. Automated Sync Policy, Argo CD, https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/, consulté le 18/10/2026.
  15. Architectural Overview, Argo CD, https://argo-cd.readthedocs.io/en/stable/operator-manual/architecture/, consulté le 18/10/2026.
  16. FAQ, Argo CD, https://argo-cd.readthedocs.io/en/stable/faq/, consulté le 18/10/2026.
  17. Webhook Configuration, Argo CD, https://argo-cd.readthedocs.io/en/stable/operator-manual/webhook/, consulté le 18/10/2026.
  18. Introduction to ApplicationSet controller, Argo CD, https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/, consulté le 18/10/2026.
  19. ApplicationSet Security, Argo CD, https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Security/, consulté le 18/10/2026.
  20. RBAC Configuration, Argo CD, https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/, consulté le 18/10/2026.
  21. Projects, Argo CD, https://argo-cd.readthedocs.io/en/stable/user-guide/projects/, consulté le 18/10/2026.
  22. Declarative Setup, Argo CD, https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/, consulté le 18/10/2026.
  23. Cluster Management, Argo CD, https://argo-cd.readthedocs.io/en/stable/operator-manual/cluster-management/, consulté le 18/10/2026.
  24. Installation, Argo CD, https://argo-cd.readthedocs.io/en/stable/operator-manual/installation/, consulté le 18/10/2026.
  25. Argo CD Core, Argo CD, https://argo-cd.readthedocs.io/en/stable/operator-manual/core/, consulté le 18/10/2026.
  26. Secret Management, Argo CD, https://argo-cd.readthedocs.io/en/stable/operator-manual/secret-management/, consulté le 18/10/2026.
  27. v3.4 to 3.5 (Upgrading), Argo CD, https://argo-cd.readthedocs.io/en/stable/operator-manual/upgrading/3.4-3.5/, consulté le 18/10/2026.
  28. Release v2.9.6, Flux, https://github.com/fluxcd/flux2/releases/tag/v2.9.6, consulté le 18/10/2026.
  29. Flux releases, Flux, https://fluxcd.io/flux/releases/, consulté le 18/10/2026.
  30. Announcing Flux 2.9 GA, Flux, https://fluxcd.io/blog/2026/06/flux-v2.9.0/, consulté le 18/10/2026.
  31. Announcing Flux 2.8 GA, Flux, https://fluxcd.io/blog/2026/02/flux-v2.8.0/, consulté le 18/10/2026.
  32. Flux Documentation, Flux, https://fluxcd.io/flux/, consulté le 18/10/2026.
  33. Core Concepts, Flux, https://fluxcd.io/flux/concepts/, consulté le 18/10/2026.
  34. Frequently asked questions, Flux, https://fluxcd.io/flux/faq/, consulté le 18/10/2026.
  35. Kustomization (spec), Flux, https://fluxcd.io/flux/components/kustomize/kustomizations/, consulté le 18/10/2026.
  36. Git Repositories (spec), Flux, https://fluxcd.io/flux/components/source/gitrepositories/, consulté le 18/10/2026.
  37. Helm Releases (spec), Flux, https://fluxcd.io/flux/components/helm/helmreleases/, consulté le 18/10/2026.
  38. Security Documentation, Flux, https://fluxcd.io/flux/security/, consulté le 18/10/2026.
  39. Flux from End to End, Flux, https://fluxcd.io/flux/flux-e2e/, consulté le 18/10/2026.
  40. Jenkins + Flux, Flux, https://fluxcd.io/flux/use-cases/jenkins/, consulté le 18/10/2026.
  41. Manage Kubernetes secrets with SOPS, Flux, https://fluxcd.io/flux/guides/mozilla-sops/, consulté le 18/10/2026.
  42. Secrets Management, Flux, https://fluxcd.io/flux/security/secrets-management/, consulté le 18/10/2026.
  43. Selective drift correction with ignore rules, Flux, https://fluxcd.io/blog/2026/08/ignore-rules-drift-detection/, consulté le 18/10/2026.

Parlons de votre contexte.

Cet article expose une pratique générale ; votre situation a ses propres contraintes. Décrivez-la, nous répondons avec un périmètre.

Ouvrir le formulaire