CloudFormation vs Terraform : check pratique multi-cloud 2026

AWS CloudFormation et Terraform ne sont plus des alternatives en avril 2026, mais plutôt une décision d’ordre. Celui qui prend au sérieux le multi-cloud utilise Terraform pour la plateforme et CloudFormation pour les profondeurs d’AWS. Celui qui inverse cela se créé exactement les dettes de migration qu’il voulait éviter.

LiésAWS Savings Plans vs. Reserved Instances 2026  /  Cloud Brokerage Services et le rapport FinOps avril 2026

Ce qui différencie réellement Terraform et CloudFormation en 2026

Les deux outils font la même promesse : infrastructure en tant que code, déclaratif, idempotent, versionnable. Avant de comparer, voyons rapidement les bases.

Qu’est-ce que l’infrastructure en tant que code ? Un modèle dans lequel les serveurs, les réseaux, les bases de données et les rôles IAM ne sont plus créés par clic dans une console Web, mais décrits dans des fichiers texte. Ces fichiers passent par le même processus de révision que le code d’application, traversent les pipelines CI et produisent des environnements reproductibles. Sans IaC, personne ne peut dire avec certitude pourquoi un environnement de préproduction a une apparence différente de la production.

Dans le Mittelstand allemand, j’entends depuis deux ans la même question : « Lequel devrions-nous choisir ? » La question est mal posée. La bonne question est : quelle stratégie cloud avons-nous réellement ? Quel outil convient à quelle couche ? Celui qui clarifie cela avant de choisir l’outil économise la discussion pour les deux prochaines années.

CloudFormation est une partie intégrante native d’AWS. Les nouveaux services AWS apparaissent dans le catalogue de ressources CloudFormation le jour de leur publication. Le fournisseur AWS Terraform suit généralement six à dix jours plus tard, parfois des semaines. Celui qui doit avoir des ressources d’agent Bedrock ou des instances EC2-C8in GA en avril 2026 dans son code le jour du lancement a un avantage de vitesse mesurable avec CloudFormation. Dans la vie quotidienne d’un groupe DAX, cela est pertinent. Dans le Mittelstand, c’est rare.

Terraform joue sa force dans la largeur. Un catalogue de fournisseurs de plus de 4 500 couvre non seulement Azure et GCP, mais également Cloudflare, Datadog, GitHub, Okta, Snowflake. Celui qui veut coder l’identité, la surveillance ou les configurations Edge sans apprendre une langue propre à chaque pile n’a pas d’alternative réelle. Le changement de licence vers BSL en août 2023 a conduit à la bifurcation OpenTofu. Les deux forks sont prêts pour la production et compatibles API en avril 2026. OpenTofu est hébergé par la Linux Foundation, tandis que Terraform reste sous l’égide de HashiCorp et désormais d’IBM.

Le tableau explique pourquoi il y a des partisants, mais pas pourquoi la discussion tourne souvent mal. Il omet deux points qui sont décisifs dans les revues d’architecture. Qui supporte le risque de gestion de l’état ? Qui prend en charge l’intégration de nouveaux membres d’équipe ? Les deux sont plus avantageux avec CloudFormation, car il y a moins de choses à savoir. Avec Terraform, c’est plus coûteux, car il y a plus de choses qui peuvent aller mal.

Où CloudFormation gagne, où Terraform excelle

Dans le test pratique avec trois équipes cloud DACH du dernier trimestre, les mêmes arguments sont revenus régulièrement. Ils étaient moins idéologiques que ce que l’internet laisse croire. Un conglomérat de construction mécanique avec 4 500 employés, un assureur en Allemagne du Sud et un fournisseur de SaaS avec 80 ingénieurs. Trois niveaux de maturité très différents, trois points de douleur très similaires.

Une observation issue des revues : les équipes CloudFormation sous-estiment régulièrement à quel point un « peut-être plus tard Azure » peut devenir une exigence stricte. Dès que les ventes incluent une clause multi-cloud dans un contrat avec un grand client, la stratégie IaC est le dernier domino qui tombe. Celui qui est alors toujours sur CloudFormation-only écrit des scripts parallèles pour Azure sans abstraction propre. C’est exactement le type de fonctionnement hybride que personne ne veut.

À l’inverse, les équipes Terraform sous-estiment la charge de maintenance du backend d’état. Un bucket S3 avec une table de verrouillage DynamoDB, répliqué régionalement, avec versionnage et cryptage KMS, semble simple. Jusqu’à ce qu’un fichier d’état entre deux exécutions CI parallèles produise une condition de course et que personne ne sache plus quel plan de sortie a réellement été appliqué. J’ai laissé cela par défaut une fois de trop. Aujourd’hui, la recommandation est claire : un verrou par espace de travail, un espace de travail par travail CI, snapshot automatique du fichier d’état avant chaque application.

C’est exactement ce qui s’est passé chez le conglomérat de construction mécanique. Un exécution de pipeline avec deux branches parallèles, les deux sur le même fichier d’état. La deuxième exécution a écrasé l’état de la première, une instance RDS était ensuite inconnue de Terraform, mais existante sur AWS. Trois jours de correction de dérive, deux tickets, un rapport de statut embarrassant au comité de pilotage. Si la deuxième exécution avait eu son propre espace de travail, cela aurait été une affaire de dix minutes.

Les fournisseurs de SaaS de l’échantillon ont vécu le cas inverse. Ils ont commencé avec CloudFormation et ont poussé la pile pendant trois ans. Puis est venue la demande de provisionner des comptes Snowflake de manière programmatique. Sans fournisseur Terraform, il n’y avait pas de solution propre. Le pont a été une fonction Lambda qui effectue des appels d’API Snowflake et est déclenchée par la pile CloudFormation. Cela fonctionne, mais ce n’est plus de l’IaC. C’est du code de collage avec un autocollant de pile. Celui qui se trouve dans cette situation a fait le choix de l’outil trop tard.

La réalité multi-cloud dans la pratique DACH

Dans les trois configurations pratiques que j’ai examinées de plus près pour ce test, une constante est apparue : personne n’utilise uniquement l’un ou l’autre. Les architectures multi-cloud en production combinent Terraform pour la couche de plate-forme et CloudFormation pour les profondeurs spécifiques à AWS. La définition de la couche est le secret. Celui qui l’a écrite peut dormir mieux.

Concrètement, cela ressemble à ceci : Terraform définit les VPC, les sous-réseaux, les rôles IAM, la confiance entre comptes, les clusters EKS, le DNS Cloudflare, les configurations de surveillance Datadog. CloudFormation prend en charge ce dont les macros de service spécifiques à AWS ont besoin : provisionnement du catalogue de services, plans de sauvegarde AWS avec des règles de cycle de vie complexes, stratégies de déploiement AppConfig. La passerelle se fait via les sorties Terraform, qui sont alimentées dans un pile CloudFormation en tant que paramètres SSM. Le modèle s’est imposé dans la pratique en 2026, car il relie les deux mondes sans frottement.

Le dénominateur commun : la gestion de l’état reste clairement séparée par couche. L’état Terraform se trouve dans le bucket S3 par compte et région. Les piles CloudFormation ont leur propre gestion d’état côté service. Les deux mondes sont orchestrés via des pipelines CI, qui connaissent l’ordre : d’abord la plate-forme, puis la charge de travail, puis les macros. Celui qui inverse cela construit des piles qui font référence à des ressources non existantes.

Une deuxième leçon pratique : la gestion du décalage est le poste de dépense invisible. La détection de décalage CloudFormation est intégrée et signale les écarts de configuration par ressource. Avec Terraform, c’est généralement un travail de planification récurrent dans la CI qui prend en charge la création de tickets en cas de décalage. Les deux méthodes fonctionnent. Mais seule l’une est documentée de manière cohérente. Celui qui a déjà cherché une modification de console qui invalide un fichier d’état connaît la valeur d’un rapport de décalage.

Chez l’assureur du test pratique, la gestion du décalage a été le levier qui a rendu possible l’acceptation de la conformité. L’auditeur externe voulait voir une référence de pile vérifiée pour chaque ressource productive. Avec le rapport de décalage CloudFormation natif, cela a été livré en deux heures. Du côté Terraform, il a fallu une semaine pour que driftctl catégorise correctement les ressources non gérées. Les deux mondes ont fonctionné, mais l’effort a été inégal.

Une troisième observation pratique concerne le thème de la réutilisation des modules. Chez le conglomérat de construction de machines, sept unités commerciales travaillaient en parallèle sur des clusters EKS. Sans module Terraform commun, chaque unité avait son propre code de cluster avec des écarts minimes. L’équipe de plate-forme a investi un mois pour construire un module EKS central, avec des variables d’entrée claires et des valeurs par défaut sensées. Après trois mois, toutes les unités avaient migré, les efforts de maintenance ont diminué d’un tiers. Avec CloudFormation, le même modèle aurait fonctionné, mais l’écosystème de modules est plus étroit et le pool commun de blocs réutilisables plus petit.

Les décisions que les architectes doivent prendre jusqu’au T3 2026

Trois mouvements du marché rendent la question des couches plus urgente en 2026, et non moins importante. HashiCorp a été acquis par IBM en février 2024. La transition se poursuit jusqu’en 2027 et concerne la feuille de route des prix de HCP. OpenTofu s’est établi comme un projet de la Linux Foundation et est considéré en 2026 comme un remplacement intégré avec son propre registre de modules. AWS a publié en avril 2026 les hooks CloudFormation GA, qui intègrent les vérifications de dérive et de conformité dans chaque cycle de vie de pile. Trois mouvements qui apparaîtront dans chaque examen d’architecture des deux prochains trimestres.

Celui qui n’a pas encore de définition écrite des couches en 2026 devrait la rédiger maintenant. Non pas comme une réglementation d’architecture, mais comme un outil d’aide à la décision pour chaque nouveau module : quelle couche, quel outil, quelle gestion d’état. Cela évite les discussions répétitives sur le fait de savoir si un nouveau service atterrit dans CloudFormation ou Terraform. Cela rend possible l’intégration de nouveaux ingénieurs de plateforme en quelques jours au lieu de semaines.

Trois étapes concrètes qui se sont avérées efficaces dans les configurations pratiques. Premièrement : rédiger une carte des couches unilatérale qui clarifie quel outil est responsable pour chaque type de ressource. Deuxièmement : unifier le backend d’état par compte et région, avec une convention d’espace de travail claire. Troisièmement : intégrer un travail de rapport de dérive dans la CI qui génère automatiquement des tickets en cas de déviations. Ces trois étapes peuvent être mises en œuvre en deux semaines et épargnent complètement la prochaine réunion d’examen d’architecture.

Ce qui ne fait pas partie de cette séquence : une migration d’outil sans déclencheur. Celui qui souhaite passer de CloudFormation à Terraform pour des raisons de propreté de code, sans exigence de multi-nuage en arrière-plan, brûle trois trimestres de temps d’ingénierie pour un refactoring qui n’est pas mesuré. La discussion la plus honnête dans chaque examen d’architecture des deux prochains trimestres est donc la question de l’occasion concrète, et non la question de l’outil concret.

Foire aux questions

Source de l’image de titre : Pexels / Kampus Production (px:8353774)

Traduit de l’original allemand par intelligence artificielle. La version allemande fait foi.