GitOps en 2026 : utile hors Kubernetes ?

GitOps a longtemps été présenté comme un synonyme de déploiement Kubernetes moderne. Dans les faits, le terme s’est surtout imposé avec des outils comme Argo CD et Flux, qui ont rendu très concrète l’idée d’un état déclaré dans Git puis réconcilié automatiquement sur un cluster. En 2026, le sujet revient pourtant au centre des discussions dans un périmètre plus large : infrastructure cloud, configuration système, politiques de sécurité, déploiements applicatifs, voire certains workflows data et plateforme.

Le problème, c’est que le mot GitOps est devenu flou. Pour certains, il suffit de stocker du Terraform dans un dépôt Git. Pour d’autres, GitOps implique forcément une boucle de réconciliation, des pull requests comme point de contrôle, un audit complet et une convergence automatique vers un état désiré. Entre ces deux extrêmes, beaucoup d’équipes adoptent une version partielle du modèle, parfois utile, parfois inutilement complexe.

La vraie question n’est donc pas “faut-il faire du GitOps ?”, mais plutôt : dans quels contextes GitOps apporte-t-il réellement de la valeur hors Kubernetes, et dans quels cas ajoute-t-il surtout une couche de process et d’outillage ?

Sur un site comme Pipeline Brut, la réponse ne peut pas être marketing. Elle doit partir du terrain : fréquence des changements, niveau de standardisation, besoin d’audit, risques de dérive, outillage déjà en place, et surtout capacité des équipes à maintenir le modèle dans le temps.

Pourquoi GitOps revient au centre des discussions en 2026

Si GitOps revient dans les conversations, ce n’est pas parce qu’un nouveau buzzword a remplacé le précédent. C’est surtout parce que plusieurs tendances se croisent.

La pression sur la traçabilité et l’audit

Les équipes infra et plateforme doivent démontrer plus facilement qui a changé quoi, quand, et via quel processus de validation. Sur ce point, Git reste un excellent socle : historique natif, revues de code, branches, signatures de commits selon les pratiques en place, intégration avec les pipelines CI/CD et rattachement clair aux tickets ou demandes de changement.

Quand une modification d’infrastructure passe par une pull request, elle devient plus facile à relire, discuter et rejouer. Ce n’est pas nouveau, mais c’est devenu plus important avec la montée des exigences autour de la sécurité de la chaîne logicielle, des contrôles internes et de la séparation des responsabilités.

La fatigue des accès manuels en production

Beaucoup d’organisations cherchent à réduire les modifications directes depuis une console cloud, un bastion ou un poste admin. Ce mouvement existait déjà, mais il s’est renforcé avec la généralisation des accès temporaires, des identités fédérées et des pipelines mieux sécurisés. Sur ce sujet, l’article sur l’usage d’OIDC en CI/CD pour éviter les secrets statiques s’inscrit dans la même logique : limiter les accès persistants et rendre les opérations plus pilotées.

GitOps séduit ici parce qu’il promet un modèle simple : le changement passe par Git, pas par une intervention manuelle. Cette promesse reste très forte, même hors Kubernetes.

La maturité des outils d’automatisation

En 2026, peu d’équipes partent de zéro. Elles ont déjà GitHub Actions, GitLab CI/CD, Jenkins, Terraform, OpenTofu, Ansible, Pulumi, Helm, des runners éphémères, des contrôles de policy, parfois une Internal Developer Platform. GitOps n’arrive donc pas comme une révolution isolée, mais comme une manière de structurer des briques existantes.

Le sujet revient justement parce que les équipes veulent relier ces briques sans retomber dans une usine à gaz. C’est le même enjeu que dans la structuration d’un pipeline CI/CD fiable sans complexité excessive : formaliser sans rigidifier.

Le besoin de convergence, pas seulement d’exécution

Beaucoup d’automatisations classiques restent orientées “push” : un pipeline exécute une action, puis termine. GitOps met en avant autre chose : une logique de réconciliation. Tant que l’état réel diffère de l’état attendu, le système continue à détecter ou corriger l’écart.

C’est précisément ce point qui rend GitOps intéressant hors Kubernetes dans certains cas. Pas parce que Git devient magique, mais parce que la réconciliation répond à un vrai problème : la dérive opérationnelle.

Ce que GitOps veut dire concrètement hors Kubernetes

Avant de juger l’intérêt de GitOps, il faut clarifier le terme. Hors Kubernetes, beaucoup d’équipes utilisent “GitOps” pour désigner des pratiques très différentes.

Le niveau minimal : Git comme source de vérité

Premier niveau : les définitions d’infrastructure, de configuration ou de déploiement vivent dans Git. Les changements passent par pull request, revue, merge, puis pipeline. C’est déjà utile, mais ce n’est pas toujours suffisant pour parler de GitOps au sens fort.

Exemple typique : un dépôt Terraform ou OpenTofu, avec plan en pull request puis apply après validation. On obtient de la traçabilité, de la revue, de la reproductibilité. En revanche, on n’a pas forcément de boucle de réconciliation continue.

Le niveau intermédiaire : Git + automatisation pilotée

Deuxième niveau : Git déclenche automatiquement l’application des changements, avec contrôles, approbations et éventuellement détection de dérive. C’est souvent le modèle adopté avec Atlantis pour Terraform, ou avec des workflows GitHub Actions / GitLab CI/CD qui orchestrent plan, policy checks et apply.

On se rapproche de GitOps, mais la convergence dépend encore beaucoup du pipeline et de la discipline des équipes.

Le niveau fort : Git + réconciliation continue

Troisième niveau : un agent ou un contrôleur compare régulièrement l’état réel à l’état déclaré et agit pour réduire l’écart, ou au minimum le signale de façon fiable. C’est le modèle historique popularisé dans Kubernetes, mais il peut exister ailleurs, à condition que l’outillage et le domaine s’y prêtent.

Cette distinction est importante, car beaucoup de débats sur GitOps mélangent ces trois niveaux. Or la réponse à “est-ce utile ?” change complètement selon qu’on parle simplement de versionner des manifestes, ou de mettre en place une convergence continue sur des systèmes hétérogènes.

Les cas où GitOps fonctionne vraiment hors Kubernetes

GitOps hors Kubernetes n’est pas une fiction. Il existe des cas où le modèle apporte une vraie valeur opérationnelle. Le point commun : un état déclaratif relativement stable, des changements fréquents mais contrôlables, et un besoin fort de traçabilité.

Infrastructure cloud relativement standardisée

Pour des environnements AWS, Azure ou Google Cloud gérés avec Terraform ou OpenTofu, GitOps peut très bien fonctionner si l’organisation accepte une règle simple : pas de changement manuel durable dans la console.

Dans ce cadre, Git joue le rôle de source de vérité, les pull requests servent de point de validation, et les pipelines appliquent les changements. Des outils comme Atlantis, Terraform Cloud, HCP Terraform ou des pipelines maison peuvent encadrer le cycle. On peut y ajouter des contrôles de policy avec OPA, Checkov ou Sentinel selon l’écosystème choisi.

Ce modèle est particulièrement utile quand :

• les environnements sont nombreux mais similaires ;
• les changements sont planifiables ;
• les équipes veulent limiter les opérations manuelles ;
• la conformité ou l’audit comptent réellement.

À l’inverse, si l’environnement est rempli d’exceptions, de ressources créées à la main ou d’intégrations peu déclaratives, GitOps devient vite fragile.

Configuration système et base image

Sur la configuration de serveurs, de VM ou d’images système, GitOps peut aussi être pertinent. Des outils comme Ansible, Packer ou leurs équivalents dans des chaînes d’image permettent de décrire l’état attendu, de versionner les changements et d’automatiser leur application.

Le modèle fonctionne bien quand on privilégie des artefacts immuables : images de VM, templates de machine, configurations standardisées. Il fonctionne moins bien quand on essaie de réconcilier en continu des serveurs historiques, modifiés au fil des ans, avec des écarts non documentés.

Autrement dit, GitOps est plus efficace sur du standard reconstruit que sur du patrimoine bricolé.

Politiques de sécurité et garde-fous plateforme

Un autre domaine où GitOps a du sens hors Kubernetes est la gestion de politiques : règles IAM, policies réseau, contrôles de conformité, règles de scanning, approbations de déploiement, templates de pipelines, catalogues de services internes.

Quand ces éléments sont définis comme du code et propagés depuis Git, on gagne en cohérence. Le dépôt devient un point central pour faire évoluer les standards plateforme. C’est particulièrement pertinent dans des approches de type golden paths, à condition de ne pas les transformer en carcan. Le sujet est proche de l’usage pragmatique des golden paths DevOps.

Déploiements applicatifs simples et répétables

Hors Kubernetes, certaines applications se prêtent aussi à un mode GitOps : déploiements sur VM, services packagés, stacks Docker Compose dans des environnements maîtrisés, configurations de reverse proxy, jobs programmés, workers internes.

Le modèle est utile quand le déploiement peut être entièrement décrit et rejoué. Si publier une version revient à modifier un tag d’image, une configuration ou une référence d’artefact dans Git, puis laisser l’automatisation converger, GitOps reste lisible.

En revanche, si le déploiement dépend d’une série d’actions contextuelles, de validations humaines non formalisées ou d’opérations ponctuelles sur des systèmes tiers, le bénéfice diminue fortement.

Là où GitOps ajoute surtout de la complexité

Le discours marketing oublie souvent de dire que GitOps a un coût. Hors Kubernetes, ce coût peut devenir supérieur au bénéfice si le terrain n’est pas adapté.

Les systèmes peu déclaratifs

GitOps suppose qu’on puisse exprimer un état cible de manière relativement claire. Or beaucoup de systèmes d’entreprise sont mal adaptés à cela : applications legacy, appliances, outils SaaS avec API incomplètes, configurations dispersées, workflows métiers dépendants d’actions manuelles.

Dans ces cas-là, Git devient un tableau de bord imparfait de ce qu’on aimerait avoir, pas une source de vérité fiable. On finit avec des dépôts qui décrivent un monde théorique, alors que la réalité vit ailleurs.

Les changements rares ou très contextuels

Si une équipe modifie une ressource tous les trois mois, avec un fort besoin d’analyse contextuelle à chaque fois, la mise en place d’un modèle GitOps complet n’est pas forcément rentable. Une procédure simple, bien documentée, avec revue et journalisation peut suffire.

GitOps est plus convaincant quand il absorbe un flux régulier de changements. Sinon, il risque de n’être qu’un cérémonial supplémentaire.

Les organisations qui n’acceptent pas la discipline associée

Le vrai prérequis de GitOps n’est pas technique. Il est organisationnel : accepter que Git soit le point de passage normal. Si les équipes continuent à corriger directement dans la console “pour aller vite”, puis repoussent la remise en conformité, le modèle se dégrade rapidement.

On retrouve ici le même problème que dans beaucoup d’automatisations fragiles : l’outil n’échoue pas seul, c’est la discipline de fonctionnement qui s’érode. Quand les écarts manuels deviennent la norme, GitOps perd sa crédibilité.

Les workflows hybrides mal pensés

Un piège fréquent consiste à mélanger GitOps, tickets ITSM, approbations manuelles, scripts hors pipeline, interventions d’astreinte et exceptions non codifiées, sans clarifier qui fait autorité. Résultat : personne ne sait si l’état réel doit suivre Git, si Git doit refléter le réel, ou si un autre système tranche.

Dans ce scénario, GitOps n’apporte pas de simplification. Il ajoute une couche de plus à un flux déjà confus.

Les limites concrètes : drift, secrets, état et exceptions

Même quand l’intention est bonne, GitOps hors Kubernetes se heurte à des limites très concrètes. Ce sont elles qui font la différence entre un modèle utile et une promesse décevante.

Le drift reste un problème central

La dérive entre l’état déclaré et l’état réel ne disparaît pas parce qu’on versionne du code. Elle change simplement de forme.

Sur de l’infrastructure cloud, le drift peut venir :

• d’un changement manuel dans la console ;
• d’un service managé qui enrichit ou modifie certains attributs ;
• d’une ressource partiellement gérée par plusieurs outils ;
• d’un import incomplet ou d’un état mal consolidé ;
• d’une dépendance externe qui évolue.

Terraform et OpenTofu savent détecter une partie de ces écarts au moment du plan, mais cela ne suffit pas toujours à parler de réconciliation continue. Et surtout, tous les drifts ne doivent pas être corrigés automatiquement. Certains nécessitent une décision humaine.

Hors Kubernetes, le vrai sujet n’est pas “peut-on détecter un drift ?”, mais “que fait-on de façon fiable quand on le détecte ?”

Les secrets compliquent vite la promesse “tout dans Git”

GitOps ne veut pas dire stocker des secrets en clair dans un dépôt. En pratique, la gestion des secrets impose presque toujours une architecture complémentaire : HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, External Secrets dans certains environnements, ou des mécanismes de chiffrement comme SOPS.

Plus l’environnement est hétérogène, plus la promesse “Git comme source unique de vérité” devient incomplète. Git peut piloter les références, les politiques d’accès, les mappings, mais rarement le secret brut lui-même. Ce n’est pas un défaut en soi, mais il faut le reconnaître clairement.

L’état et les verrous restent sensibles

Dans l’infrastructure as code, la question de l’état n’est jamais anodine. Avec Terraform ou OpenTofu, le state est un composant critique. GitOps n’efface ni les problèmes de verrouillage, ni les risques de concurrence, ni la nécessité de découper correctement les périmètres d’application.

Une équipe peut avoir des dépôts Git impeccables et malgré tout rencontrer des blocages opérationnels si plusieurs pipelines se disputent le même état, si le découpage des workspaces est mauvais, ou si les dépendances entre stacks sont mal gérées.

Les exceptions finissent toujours par arriver

Rotation d’urgence, incident de sécurité, ressource cassée, import d’existant, migration partielle, changement imposé par un éditeur SaaS : aucun environnement réel n’échappe aux exceptions. La question n’est pas de les éliminer, mais de savoir comment les absorber sans casser le modèle.

Un GitOps robuste prévoit :

• un chemin d’exception explicite ;
• une remise en conformité documentée ;
• des délais clairs pour refléter les changements dans Git ;
• une supervision qui signale les écarts persistants.

Sans cela, les exceptions deviennent des contournements permanents.

Les outils réels à regarder, sans les confondre avec la méthode

Parler de GitOps hors Kubernetes sans citer les outils serait abstrait. Mais il faut éviter une confusion fréquente : aucun outil ne “fait” GitOps à lui seul. Il fournit au mieux une partie du modèle.

Pour l’infrastructure

• Terraform et OpenTofu pour la description déclarative ;
• Atlantis pour intégrer plan/apply dans les pull requests ;
• HCP Terraform ou d’autres orchestrateurs pour le pilotage centralisé ;
• GitHub Actions, GitLab CI/CD ou Jenkins pour l’exécution des workflows.

Pour les contrôles et policies

• OPA et son langage Rego ;
• Conftest pour tester des configurations ;
• Checkov pour l’analyse de code d’infrastructure ;
• Sentinel dans certains environnements HashiCorp.

Pour les secrets

• Vault ;
• AWS Secrets Manager ;
• Azure Key Vault ;
• Google Secret Manager ;
• SOPS pour le chiffrement de fichiers quand c’est pertinent.

Pour la détection et la visibilité

Selon les cas, il faut compléter avec de la supervision, des audits de drift, des logs de pipeline, des alertes et des tableaux de bord. Un modèle GitOps sans visibilité sur la convergence réelle est incomplet. Sur ce point, la logique rejoint la supervision bout en bout des flux de déploiement : il ne suffit pas d’automatiser, il faut voir ce qui se passe réellement.

Une grille simple pour décider sans effet de mode

Plutôt que de demander “est-ce qu’on fait du GitOps ?”, il vaut mieux passer votre contexte dans une grille de décision simple. Si plusieurs réponses sont négatives, mieux vaut souvent rester sur une automatisation plus classique et plus lisible.

1. L’état cible est-il vraiment déclaratif ?

Si vous ne pouvez pas décrire clairement ce que doit être le système, GitOps sera bancal. C’est le premier filtre.

2. Les changements sont-ils fréquents ou suffisamment standardisés ?

Plus le flux de changement est régulier, plus GitOps a de chances d’être rentable. Pour des opérations rares et très contextuelles, le gain est souvent faible.

3. Peut-on limiter sérieusement les modifications manuelles ?

Si la réponse est non, il faut au minimum un mécanisme crédible de détection et de rattrapage du drift. Sinon, Git cesse vite d’être fiable comme source de vérité.

4. Le besoin d’audit et de revue est-il fort ?

Quand l’audit, la séparation des rôles et la traçabilité sont importants, GitOps prend immédiatement plus de valeur.

5. Les secrets et dépendances externes sont-ils maîtrisables ?

Si votre workflow dépend d’éléments impossibles à intégrer proprement au modèle, attendez-vous à une architecture hybride. Ce n’est pas forcément bloquant, mais il faut l’assumer.

6. Les équipes ont-elles la maturité de fonctionnement nécessaire ?

GitOps n’est pas qu’une question d’outils. Il faut des revues propres, des conventions de dépôt, des pipelines fiables, des chemins d’exception, et une culture qui évite les correctifs invisibles.

7. La boucle de réconciliation est-elle réellement utile ?

C’est souvent la meilleure question. Si un simple pipeline déclenché au merge suffit, alors une approche “Git-driven automation” peut être plus adaptée qu’un GitOps revendiqué partout. Il n’est pas obligatoire d’aller jusqu’à la convergence continue pour obtenir 80 % du bénéfice.

Le bon contrepied : viser Git comme point de contrôle, pas comme religion

Le meilleur usage de GitOps hors Kubernetes n’est pas dogmatique. Il consiste souvent à prendre ce que le modèle a de plus utile :

• Git comme point de passage normal ;
• pull requests comme mécanisme de revue ;
• automatisation fiable de l’application ;
• détection des écarts ;
• standardisation progressive des changements.

En revanche, vouloir forcer une vision “tout doit être GitOps” sur des systèmes peu déclaratifs, très hybrides ou pleins d’exceptions produit rarement de bons résultats. On obtient alors un vernis de modernité, mais pas une meilleure maîtrise opérationnelle.

Le contrepied utile en 2026 est donc simple : ne pas confondre versionnage, infrastructure as code, automatisation CI/CD et GitOps complet. Ces briques se complètent, mais elles ne se recouvrent pas totalement.

Conclusion

Oui, GitOps peut être utile hors Kubernetes en 2026. Pas partout, pas automatiquement, et certainement pas parce que le terme est à la mode. Il fonctionne bien quand vous avez un état déclaratif crédible, un besoin fort de traçabilité, des changements suffisamment standardisés et une vraie discipline pour éviter les écarts manuels durables.

Il fonctionne mal quand le système réel échappe au déclaratif, quand les exceptions dominent, ou quand l’organisation n’est pas prête à traiter Git comme point de contrôle opérationnel.

Si vous devez trancher, commencez petit : un périmètre standard, une chaîne de revue propre, une automatisation lisible, une détection de drift utile. Ensuite seulement, voyez si la réconciliation continue apporte un gain réel. Sur Pipeline Brut, c’est souvent là que se fait la différence entre une pratique robuste et un slogan de plus. Si vous voulez structurer ce type de décision sur vos pipelines et automatisations, parcourez aussi les autres retours terrain du site pour comparer les compromis avant d’ajouter une nouvelle couche d’outillage.