Terraform a perdu la communauté — OpenTofu et Pulumi se partagent le marché
Le fork OpenTofu a trois ans et tourne en production chez Boeing, Capital One et AMD. Pulumi, de son côté, croît de 45 % par an et lance un agent IA qui provisionne l’infrastructure en langage naturel.
Août 2023 : HashiCorp change la licence de Terraform de la MPL à la BSL. Février 2025 : IBM rachète HashiCorp pour 6,4 milliards de dollars. Juillet 2026 : le fork OpenTofu, hébergé par la Linux Foundation, tourne en production chez Boeing, Capital One et AMD, tandis que Pulumi croît de 45 % par an et vient de lancer un agent IA qui génère l’infrastructure en langage naturel. Le marché de l’Infrastructure as Code pèse aujourd’hui 2,1 milliards de dollars avec 28 % de croissance annuelle. Terraform détient encore 76 % des parts de marché, mais ce chiffre masque une réalité bien plus brutale : la confiance n’y est plus, et les alternatives ne se contentent plus de suivre — elles dessinent les standards de demain.
La licence qui a tout changé
Le 10 août 2023, HashiCorp remplace la licence des produits cœur — dont Terraform, Vault et Consul — de la MPL 2.0 (open source, permissive) à la BSL 1.1 (Business Source License). La BSL interdit l’utilisation « concurrentielle » du logiciel : quiconque construit un produit qui encapsule ou orchestre Terraform pour des tiers est en infraction. Les utilisateurs finaux — ceux qui tapent terraform apply dans leur CI — ne sont pas touchés. Mais tous les éditeurs de plateformes qui intégraient Terraform dans leurs offres (Spacelift, env0, Scalr, Harness, Gruntwork) voient leur modèle économique menacé du jour au lendemain.
La réaction est immédiate. En septembre 2023, un consortium d’entreprises fork Terraform 1.5 — la dernière version MPL — et lance OpenTofu sous l’égide de la Linux Foundation. Le fork bénéficie d’un soutien massif : Spacelift, env0, Gruntwork, Harness, Scalr, Cloud Posse et plusieurs dizaines d’autres sociétés signent la déclaration commune. Les contributeurs individuels affluent — plus de 800 contributeurs sur le dépôt GitHub en moins de six mois.
Fast-forward à juillet 2026. OpenTofu est en version 1.9, a rejoint la CNCF (Cloud Native Computing Foundation) au même titre que Kubernetes, et des entreprises du calibre de Boeing, Capital One et AMD l’utilisent en production. Le fork n’est plus une protestation : c’est une plateforme IaC de premier plan.
OpenTofu 1.9 : plus qu’un clone
OpenTofu conserve une compatibilité syntaxique quasi totale avec Terraform. Même HCL, même format de state file, mêmes commandes (init, plan, apply, destroy). Pour la majorité des configurations existantes, la migration tient en une commande : tofu init à la place de terraform init.
Mais le fork ne s’est pas contenté de rattraper Terraform. Depuis le fork, OpenTofu a livré des fonctionnalités que Terraform n’a toujours pas :
- Chiffrement natif du state. OpenTofu 1.7 introduit un chiffrement configurable des fichiers de state et de plan — une demande de longue date de la communauté, satisfaite sans KMS externe. Support natif de PBKDF2, AWS KMS, GCP KMS et OpenBao (le fork open source de Vault). Indispensable pour toute organisation soumise à des exigences de conformité.
- Blocs
removed. Une manière déclarative de retirer des ressources du state sans passer parterraform state rm, qui est fragile et sujet à l’erreur humaine en production. - Évaluation précoce des variables et
locals. Les backends peuvent enfin être paramétrés proprement, un irritant majeur de Terraform depuis des années. - Framework de test enrichi.
tofu testest plus mature queterraform test, avec des mock providers qui permettent de tester sans credentials cloud réels — un vrai test unitaire d’infrastructure. - Fonctions dans les configurations de providers. La syntaxe étendue de la 1.9 permet d’appeler des fonctions de provider directement dans la configuration du provider lui-même.
Du côté de Terraform, les fonctionnalités exclusives sont essentiellement Stacks (abstraction multi-environnement), Sentinel (policy-as-code propriétaire) et l’intégration avec HCP Terraform (anciennement Terraform Cloud). Ce sont des briques intéressantes pour les grandes organisations, mais elles verrouillent l’utilisateur dans l’écosystème HashiCorp/IBM avec un ticket d’entrée significatif — Sentinel n’est disponible que sur les paid plans.
Pulumi : des langages généralistes et un agent IA
Pulumi attaque le problème sous un angle radicalement différent. Au lieu d’un DSL comme HCL, Pulumi permet d’écrire l’infrastructure en TypeScript, Python, Go, C#, Java ou YAML. Le développeur utilise son langage quotidien, son IDE avec autocomplétion et type-checking, ses bibliothèques standard — et Pulumi traduit le tout en appels d’API cloud.
L’argument n’est pas cosmétique. Quand une équipe doit provisionner 200 groupes de sécurité à partir d’un fichier CSV, elle écrit une boucle for en TypeScript — pas un bloc dynamic imbriqué en HCL dont la lisibilité s’effondre au-delà de trois niveaux. Quand elle doit appeler une API métier externe pendant le déploiement, elle le fait dans le même fichier, avec la même stack.
Pulumi revendique aujourd’hui environ 1 800 providers natifs (contre plus de 4 800 pour Terraform), mais ce chiffre sous-estime sa couverture réelle : le pulumi-terraform-bridge permet de consommer n’importe quel provider Terraform depuis Pulumi. Les trois hyperscalers — AWS, Azure, GCP — sont couverts de première classe. L’écart se ressent surtout sur les SaaS de niche (registrar DNS, plateformes d’observabilité spécifiques), où Terraform conserve un avantage de couverture.
Le véritable différenciateur de Pulumi en 2026, c’est Pulumi Neo : un agent IA capable de générer du code d’infrastructure à partir d’une phrase en langage naturel. « Déploie un cluster EKS avec trois node groups GPU sur AWS » — Neo produit la configuration Pulumi complète, applique les politiques de sécurité de l’organisation, et ouvre une pull request pour revue humaine. L’agent opère dans les limites RBAC existantes et chaque modification passe par les pipelines CI/CD standards. Ce n’est pas un gadget : Neo repositionne la concurrence autour de l’orchestration assistée par IA, pas de la syntaxe du langage.
Les benchmarks disponibles montrent que Pulumi traite les déploiements incrémentaux jusqu’à 60 % plus vite que Terraform sur les infrastructures dépassant les 1 000 ressources. Sur les déploiements initiaux massifs, Terraform conserve un avantage grâce à sa parallélisation mature.
Le facteur IBM
Le rachat de HashiCorp par IBM en février 2025 pour 6,4 milliards de dollars ajoute une couche d’incertitude stratégique. IBM promet la continuité — mais la question n’est pas de savoir si Terraform sera maintenu (il le sera), mais pour qui il sera optimisé. Les décisions de roadmap d’un éditeur sous bannière IBM seront-elles alignées sur les besoins de la communauté open source ou sur les marges de la division cloud IBM ?
OpenTofu, hébergé par la Linux Foundation et gouverné par la CNCF, offre une réponse claire à cette question : la gouvernance est communautaire, le financement est diversifié (Spacelift, env0, Gruntwork et d’autres financent le développement), et la licence MPL 2.0 est irréversible. Pour les DSI qui doivent présenter un plan de continuité à leur comité d’audit, cette garantie pèse lourd.
Pulumi, sous licence Apache 2.0, joue une partition différente : celle de l’innovation produit. L’entreprise mise sur Neo et sur un modèle de cloud managé (Pulumi Cloud) dont le free tier est généreux — resources illimitées pour l’usage individuel, contre 500 resources maximum pour le free tier de Terraform Cloud.
Que choisir en juillet 2026 ? Le verdict
Le paysage IaC de 2026 ne se résume pas à un podium, mais à trois trajectoires qui s’adressent à des organisations différentes.
Restez sur Terraform si vous êtes déjà déployé sur HCP Terraform avec des politiques Sentinel, que vous avez un contrat de support HashiCorp/IBM actif et que vos besoins ne tombent pas sous le coup de la BSL. Le coût de migration n’est pas justifié si la plateforme actuelle couvre vos cas d’usage.
Migrez vers OpenTofu si vous construisez une plateforme interne qui exécute de l’IaC pour le compte d’équipes applicatives (la BSL vous expose), si le chiffrement natif du state est une exigence de conformité, ou si vous voulez sortir de la dépendance IBM sans changer d’écosystème. La migration est un tofu init pour 90 % des configurations — le principal effort porte sur le remplacement de Sentinel par OPA/Conftest.
Adoptez Pulumi si votre équipe est composée majoritairement de développeurs qui veulent rester en TypeScript, Python ou Go, si vous gérez plus de 1 000 ressources cloud avec des cycles de mise à jour fréquents (l’avantage de vitesse incrémentale se matérialise ici), ou si vous voulez expérimenter le provisionnement par IA avec Neo. Pulumi est aussi le meilleur choix pour les greenfield projects qui n’ont pas d’héritage Terraform.
La seule erreur stratégique en 2026 serait de traiter Terraform comme un standard immuable. La communauté a bifurqué, les alternatives sont en production, et l’IA commence à écrire l’infrastructure. Le statu quo n’est plus une option neutre — c’est un pari sur IBM.