8 Min. Lecture<\/p>\n
AWS CloudFormation et Terraform ne sont plus des alternatives en avril 2026, mais plut\u00f4t une d\u00e9cision d’ordre. Celui qui prend au s\u00e9rieux le multi-cloud utilise Terraform pour la plateforme et CloudFormation pour les profondeurs d’AWS. Celui qui inverse cela se cr\u00e9\u00e9 exactement les dettes de migration qu’il voulait \u00e9viter.<\/strong><\/p>\n Les points cl\u00e9s en bref<\/p>\n Li\u00e9s<\/span>AWS Savings Plans vs. Reserved Instances 2026<\/a> \/<\/span> Cloud Brokerage Services et le rapport FinOps avril 2026<\/a><\/p>\n Les deux outils font la m\u00eame promesse : infrastructure en tant que code, d\u00e9claratif, idempotent, versionnable. Avant de comparer, voyons rapidement les bases.<\/p>\n Qu’est-ce que l’infrastructure en tant que code ?<\/strong> Un mod\u00e8le dans lequel les serveurs, les r\u00e9seaux, les bases de donn\u00e9es et les r\u00f4les IAM ne sont plus cr\u00e9\u00e9s par clic dans une console Web, mais d\u00e9crits dans des fichiers texte. Ces fichiers passent par le m\u00eame processus de r\u00e9vision 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\u00e9production a une apparence diff\u00e9rente de la production.<\/p>\n Dans le Mittelstand allemand, j’entends depuis deux ans la m\u00eame question : \u00ab Lequel devrions-nous choisir ? \u00bb La question est mal pos\u00e9e. La bonne question est : quelle strat\u00e9gie cloud avons-nous r\u00e9ellement ? Quel outil convient \u00e0 quelle couche ? Celui qui clarifie cela avant de choisir l’outil \u00e9conomise la discussion pour les deux prochaines ann\u00e9es.<\/p>\n CloudFormation est une partie int\u00e9grante 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\u00e9n\u00e9ralement six \u00e0 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.<\/p>\n Terraform joue sa force dans la largeur. Un catalogue de fournisseurs de plus de 4 500 couvre non seulement Azure et GCP, mais \u00e9galement Cloudflare, Datadog, GitHub, Okta, Snowflake. Celui qui veut coder l’identit\u00e9, la surveillance ou les configurations Edge sans apprendre une langue propre \u00e0 chaque pile n’a pas d’alternative r\u00e9elle. Le changement de licence vers BSL en ao\u00fbt 2023 a conduit \u00e0 la bifurcation OpenTofu. Les deux forks sont pr\u00eats pour la production et compatibles API en avril 2026. OpenTofu est h\u00e9berg\u00e9 par la Linux Foundation, tandis que Terraform reste sous l’\u00e9gide de HashiCorp et d\u00e9sormais d’IBM.<\/p>\n Source : Guide de l’utilisateur AWS CloudFormation avril 2026, instantan\u00e9 du registre de fournisseurs HashiCorp du 24 avril 2026<\/p>\n<\/div>\n Le tableau explique pourquoi il y a des partisants, mais pas pourquoi la discussion tourne souvent mal. Il omet deux points qui sont d\u00e9cisifs dans les revues d’architecture. Qui supporte le risque de gestion de l’\u00e9tat ? Qui prend en charge l’int\u00e9gration de nouveaux membres d’\u00e9quipe ? Les deux sont plus avantageux avec CloudFormation, car il y a moins de choses \u00e0 savoir. Avec Terraform, c’est plus co\u00fbteux, car il y a plus de choses qui peuvent aller mal.<\/p>\n Dans le test pratique avec trois \u00e9quipes cloud DACH du dernier trimestre, les m\u00eames arguments sont revenus r\u00e9guli\u00e8rement. Ils \u00e9taient moins id\u00e9ologiques que ce que l’internet laisse croire. Un conglom\u00e9rat de construction m\u00e9canique avec 4 500 employ\u00e9s, un assureur en Allemagne du Sud et un fournisseur de SaaS avec 80 ing\u00e9nieurs. Trois niveaux de maturit\u00e9 tr\u00e8s diff\u00e9rents, trois points de douleur tr\u00e8s similaires.<\/p>\n CloudFormation gagne<\/p>\n Terraform \/ OpenTofu excelle<\/p>\n Une observation issue des revues : les \u00e9quipes CloudFormation sous-estiment r\u00e9guli\u00e8rement \u00e0 quel point un \u00ab peut-\u00eatre plus tard Azure \u00bb peut devenir une exigence stricte. D\u00e8s que les ventes incluent une clause multi-cloud dans un contrat avec un grand client, la strat\u00e9gie IaC est le dernier domino qui tombe. Celui qui est alors toujours sur CloudFormation-only \u00e9crit des scripts parall\u00e8les pour Azure sans abstraction propre. C’est exactement le type de fonctionnement hybride que personne ne veut.<\/p>\n \u00c0 l’inverse, les \u00e9quipes Terraform sous-estiment la charge de maintenance du backend d’\u00e9tat. Un bucket S3 avec une table de verrouillage DynamoDB, r\u00e9pliqu\u00e9 r\u00e9gionalement, avec versionnage et cryptage KMS, semble simple. Jusqu’\u00e0 ce qu’un fichier d’\u00e9tat entre deux ex\u00e9cutions CI parall\u00e8les produise une condition de course et que personne ne sache plus quel plan de sortie a r\u00e9ellement \u00e9t\u00e9 appliqu\u00e9. J’ai laiss\u00e9 cela par d\u00e9faut 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’\u00e9tat avant chaque application.<\/p>\n C’est exactement ce qui s’est pass\u00e9 chez le conglom\u00e9rat de construction m\u00e9canique. Un ex\u00e9cution de pipeline avec deux branches parall\u00e8les, les deux sur le m\u00eame fichier d’\u00e9tat. La deuxi\u00e8me ex\u00e9cution a \u00e9cras\u00e9 l’\u00e9tat de la premi\u00e8re, une instance RDS \u00e9tait ensuite inconnue de Terraform, mais existante sur AWS. Trois jours de correction de d\u00e9rive, deux tickets, un rapport de statut embarrassant au comit\u00e9 de pilotage. Si la deuxi\u00e8me ex\u00e9cution avait eu son propre espace de travail, cela aurait \u00e9t\u00e9 une affaire de dix minutes.<\/p>\n Les fournisseurs de SaaS de l’\u00e9chantillon ont v\u00e9cu le cas inverse. Ils ont commenc\u00e9 avec CloudFormation et ont pouss\u00e9 la pile pendant trois ans. Puis est venue la demande de provisionner des comptes Snowflake de mani\u00e8re programmatique. Sans fournisseur Terraform, il n’y avait pas de solution propre. Le pont a \u00e9t\u00e9 une fonction Lambda qui effectue des appels d’API Snowflake et est d\u00e9clench\u00e9e 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.<\/p>\n Dans les trois configurations pratiques que j’ai examin\u00e9es de plus pr\u00e8s 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\u00e9cifiques \u00e0 AWS. La d\u00e9finition de la couche est le secret. Celui qui l’a \u00e9crite peut dormir mieux.<\/p>\n Concr\u00e8tement, cela ressemble \u00e0 ceci : Terraform d\u00e9finit les VPC, les sous-r\u00e9seaux, les r\u00f4les 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\u00e9cifiques \u00e0 AWS ont besoin : provisionnement du catalogue de services, plans de sauvegarde AWS avec des r\u00e8gles de cycle de vie complexes, strat\u00e9gies de d\u00e9ploiement AppConfig. La passerelle se fait via les sorties Terraform, qui sont aliment\u00e9es dans un pile CloudFormation en tant que param\u00e8tres SSM. Le mod\u00e8le s’est impos\u00e9 dans la pratique en 2026, car il relie les deux mondes sans frottement.<\/p>\n Le d\u00e9nominateur commun : la gestion de l’\u00e9tat reste clairement s\u00e9par\u00e9e par couche. L’\u00e9tat Terraform se trouve dans le bucket S3 par compte et r\u00e9gion. Les piles CloudFormation ont leur propre gestion d’\u00e9tat c\u00f4t\u00e9 service. Les deux mondes sont orchestr\u00e9s 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\u00e9f\u00e9rence \u00e0 des ressources non existantes.<\/p>\n Une deuxi\u00e8me le\u00e7on pratique : la gestion du d\u00e9calage est le poste de d\u00e9pense invisible. La d\u00e9tection de d\u00e9calage CloudFormation est int\u00e9gr\u00e9e et signale les \u00e9carts de configuration par ressource. Avec Terraform, c’est g\u00e9n\u00e9ralement un travail de planification r\u00e9current dans la CI qui prend en charge la cr\u00e9ation de tickets en cas de d\u00e9calage. Les deux m\u00e9thodes fonctionnent. Mais seule l’une est document\u00e9e de mani\u00e8re coh\u00e9rente. Celui qui a d\u00e9j\u00e0 cherch\u00e9 une modification de console qui invalide un fichier d’\u00e9tat conna\u00eet la valeur d’un rapport de d\u00e9calage.<\/p>\n Chez l’assureur du test pratique, la gestion du d\u00e9calage a \u00e9t\u00e9 le levier qui a rendu possible l’acceptation de la conformit\u00e9. L’auditeur externe voulait voir une r\u00e9f\u00e9rence de pile v\u00e9rifi\u00e9e pour chaque ressource productive. Avec le rapport de d\u00e9calage CloudFormation natif, cela a \u00e9t\u00e9 livr\u00e9 en deux heures. Du c\u00f4t\u00e9 Terraform, il a fallu une semaine pour que driftctl cat\u00e9gorise correctement les ressources non g\u00e9r\u00e9es. Les deux mondes ont fonctionn\u00e9, mais l’effort a \u00e9t\u00e9 in\u00e9gal.<\/p>\n Une troisi\u00e8me observation pratique concerne le th\u00e8me de la r\u00e9utilisation des modules. Chez le conglom\u00e9rat de construction de machines, sept unit\u00e9s commerciales travaillaient en parall\u00e8le sur des clusters EKS. Sans module Terraform commun, chaque unit\u00e9 avait son propre code de cluster avec des \u00e9carts minimes. L’\u00e9quipe de plate-forme a investi un mois pour construire un module EKS central, avec des variables d’entr\u00e9e claires et des valeurs par d\u00e9faut sens\u00e9es. Apr\u00e8s trois mois, toutes les unit\u00e9s avaient migr\u00e9, les efforts de maintenance ont diminu\u00e9 d’un tiers. Avec CloudFormation, le m\u00eame mod\u00e8le aurait fonctionn\u00e9, mais l’\u00e9cosyst\u00e8me de modules est plus \u00e9troit et le pool commun de blocs r\u00e9utilisables plus petit.<\/p>\n \n”<\/span><\/p>\n AWS CloudFormation et Terraform ne sont plus une alternative en avril 2026, mais une d\u00e9cision d’ordre.<\/p>\n<\/blockquote>\n<\/figure>\n Trois mouvements du march\u00e9 rendent la question des couches plus urgente en 2026, et non moins importante. HashiCorp a \u00e9t\u00e9 acquis par IBM en f\u00e9vrier 2024. La transition se poursuit jusqu’en 2027 et concerne la feuille de route des prix de HCP. OpenTofu s’est \u00e9tabli comme un projet de la Linux Foundation et est consid\u00e9r\u00e9 en 2026 comme un remplacement int\u00e9gr\u00e9 avec son propre registre de modules. AWS a publi\u00e9 en avril 2026 les hooks CloudFormation GA, qui int\u00e8grent les v\u00e9rifications de d\u00e9rive et de conformit\u00e9 dans chaque cycle de vie de pile. Trois mouvements qui appara\u00eetront dans chaque examen d’architecture des deux prochains trimestres.<\/p>\n Celui qui n’a pas encore de d\u00e9finition \u00e9crite des couches en 2026 devrait la r\u00e9diger maintenant. Non pas comme une r\u00e9glementation d’architecture, mais comme un outil d’aide \u00e0 la d\u00e9cision pour chaque nouveau module : quelle couche, quel outil, quelle gestion d’\u00e9tat. Cela \u00e9vite les discussions r\u00e9p\u00e9titives sur le fait de savoir si un nouveau service atterrit dans CloudFormation ou Terraform. Cela rend possible l’int\u00e9gration de nouveaux ing\u00e9nieurs de plateforme en quelques jours au lieu de semaines.<\/p>\n Trois \u00e9tapes concr\u00e8tes qui se sont av\u00e9r\u00e9es efficaces dans les configurations pratiques. Premi\u00e8rement : r\u00e9diger une carte des couches unilat\u00e9rale qui clarifie quel outil est responsable pour chaque type de ressource. Deuxi\u00e8mement : unifier le backend d’\u00e9tat par compte et r\u00e9gion, avec une convention d’espace de travail claire. Troisi\u00e8mement : int\u00e9grer un travail de rapport de d\u00e9rive dans la CI qui g\u00e9n\u00e8re automatiquement des tickets en cas de d\u00e9viations. Ces trois \u00e9tapes peuvent \u00eatre mises en \u0153uvre en deux semaines et \u00e9pargnent compl\u00e8tement la prochaine r\u00e9union d’examen d’architecture.<\/p>\n Ce qui ne fait pas partie de cette s\u00e9quence : une migration d’outil sans d\u00e9clencheur. Celui qui souhaite passer de CloudFormation \u00e0 Terraform pour des raisons de propret\u00e9 de code, sans exigence de multi-nuage en arri\u00e8re-plan, br\u00fble trois trimestres de temps d’ing\u00e9nierie pour un refactoring qui n’est pas mesur\u00e9. La discussion la plus honn\u00eate dans chaque examen d’architecture des deux prochains trimestres est donc la question de l’occasion concr\u00e8te, et non la question de l’outil concret.<\/p>\n Seulement avec un d\u00e9clencheur d’ing\u00e9nierie de plateforme ou de cloud multi-cloud clair. Les piles AWS pures sans connexion SaaS b\u00e9n\u00e9ficient peu du changement et supportent la nouvelle courbe d’apprentissage et la charge de gestion d’\u00e9tat. Ceux qui ont un contrat multi-cloud avec de grands clients dans le pipeline devraient commencer en parall\u00e8le.<\/p>\n<\/details>\n OpenTofu est pr\u00eat pour la production en 2026, compatible API et h\u00e9berg\u00e9 par la Linux Foundation. Ceux qui ont besoin de clart\u00e9 de licence pour la conformit\u00e9 ou qui veulent partager des modules sans risque de fournisseur sont mieux \u00e9quip\u00e9s avec OpenTofu. La licence BSL de HashiCorp est toujours sans critique pour une utilisation interne.<\/p>\n<\/details>\n Le verrouillage d’\u00e9tat Terraform via DynamoDB est la norme, OpenTofu utilise le m\u00eame sch\u00e9ma de backend. Un verrou par espace de travail, un espace de travail par travail CI. Ceux qui ex\u00e9cutent des pipelines parall\u00e8les sans strat\u00e9gie de verrouillage construisent une corruption d’\u00e9tat.<\/p>\n<\/details>\n Pour les piles CloudFormation pures, le rapport natif suffit. D\u00e8s que Terraform et CloudFormation fonctionnent en parall\u00e8le, driftctl en tant que deuxi\u00e8me regard est utile : il voit \u00e9galement les ressources non g\u00e9r\u00e9es que aucun pile ne conna\u00eet. Les deux se compl\u00e8tent, ne se remplacent pas.<\/p>\n<\/details>\n Jusqu’en 2027, le plan d’int\u00e9gration est en cours, apr\u00e8s quoi les mod\u00e8les de tarification et de support seront probablement r\u00e9organis\u00e9s. Terraform open source et HCP resteront disponibles jusqu’alors. Ceux qui conduisent une ind\u00e9pendance de fournisseur pure comme principe d’architecture devraient \u00e9valuer OpenTofu.<\/p>\n<\/details>\n Conseils de lecture de la r\u00e9daction<\/p>\n Plus de contenu du r\u00e9seau MBF Media<\/p>\n\n
Ce qui diff\u00e9rencie r\u00e9ellement Terraform et CloudFormation en 2026<\/h2>\n
\n\n
\n \nCrit\u00e8re<\/th>\n CloudFormation<\/th>\n Terraform \/ OpenTofu<\/th>\n<\/tr>\n<\/thead>\n \n Couverture cloud<\/strong><\/td>\n Seulement AWS (y compris AWS Outposts, Local Zones)<\/td>\n 4 500+ fournisseurs, tous les hyperscalers<\/td>\n<\/tr>\n \n Support Day-One<\/strong><\/td>\n Jour 0 (natif)<\/td>\n Retard typique de 6 \u00e0 21 jours<\/td>\n<\/tr>\n \n Gestion de l’\u00e9tat<\/strong><\/td>\n Service-side chez AWS, pas de gestion de verrouillage<\/td>\n \u00c0 h\u00e9berger soi-m\u00eame (S3+DynamoDB), HCP ou OpenTofu Cloud<\/td>\n<\/tr>\n \n Langage<\/strong><\/td>\n YAML\/JSON d\u00e9claratif<\/td>\n HCL avec modules, variables, blocs dynamiques<\/td>\n<\/tr>\n \n D\u00e9tection de d\u00e9rive<\/strong><\/td>\n Rapports de d\u00e9rive de pile natifs<\/td>\n terraform plan ou outils de d\u00e9rive (driftctl)<\/td>\n<\/tr>\n \n \u00c9cosyst\u00e8me de modules<\/strong><\/td>\n Registre public CloudFormation, catalogue \u00e9troit<\/td>\n Registre Terraform, large et impuls\u00e9 par la communaut\u00e9<\/td>\n<\/tr>\n \n Licence<\/strong><\/td>\n Service AWS, gratuit<\/td>\n BSL (Terraform) ou MPL 2.0 (OpenTofu)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n O\u00f9 CloudFormation gagne, o\u00f9 Terraform excelle<\/h2>\n
\n
\n
La r\u00e9alit\u00e9 multi-cloud dans la pratique DACH<\/h2>\n
Les d\u00e9cisions que les architectes doivent prendre jusqu’au T3 2026<\/h2>\n
Foire aux questions<\/h2>\n
En vaut-il la peine de passer de CloudFormation \u00e0 Terraform en 2026 ?<\/strong><\/summary>\n
OpenTofu ou Terraform avec licence BSL ?<\/strong><\/summary>\n
Comment r\u00e9soudre la condition de course d’\u00e9tat entre les ex\u00e9cutions CI parall\u00e8les ?<\/strong><\/summary>\n
Le rapport de d\u00e9rive CloudFormation suffit-il ou a-t-on besoin de driftctl ?<\/strong><\/summary>\n
Que signifie l’acquisition d’HashiCorp par IBM pour le choix de l’outil ?<\/strong><\/summary>\n
\n