Terraform vs CloudFormation vs CDK : quel IaC choisir en 2026 ?

C’est là que le trio Terraform / CloudFormation / AWS CDK revient systématiquement. Mais il faut lever une ambiguïté dès le départ : le CDK ne remplace pas CloudFormation. Le CDK synthétise vos stacks en templates CloudFormation, puis utilise le service CloudFormation pour exécuter les déploiements.

Dans cet article, on ne cherchera pas un véritable vainqueur. On va plutôt répondre à la seule question qui compte : pour votre organisation (AWS‑only ou multi‑cloud), vos équipes (dev‑first ou platform), et votre niveau d’exigence (drift, multi‑comptes, gouvernance), quel choix est le plus robuste en 2026 — et pourquoi ?

Terraform vs CloudFormation vs AWS CDK : quel IaC choisir en 2026 ?

En 2026, choisir un outil d’Infrastructure as Code (IaC) ne se résume plus à “quel langage je préfère”.

Le vrai sujet, c’est : AWS CDK est souvent présenté comme l’outil IaC moderne face à CloudFormation. En réalité, il faut le voir comme une surcouche de développement.

Concrètement :

• cdk synth produit une CloudAssembly, incluant un template AWS CloudFormation et des artefacts de déploiement
• cdk deploy utilise le service AWS CloudFormation pour exécuter les déploiements
• AWS résume la même idée dans ses guides : après cdk synth, ton code est converti en templates CloudFormation, et à partir de là le processus est CloudFormation

Donc, le duel réel ressemble plutôt à :

• CloudFormation : l’outil natif AWS (templates YAML/JSON + stacks)
• AWS CDK : l’expérience développeur pour générer du CloudFormation
• Terraform : un workflow IaC multi‑providers basé sur un state, souvent adopté comme standard plateforme

Outil	Philosophie	Point fort	Point d’attention
Terraform	IaC multi‑providers basé sur state + workflow plan/apply	Très bon pour standardiser une plateforme au‑delà d’AWS, modules réutilisables	La gestion du state (backend, locking, process d’équipe) est une discipline
CloudFormation	IaC natif AWS en templates YAML/JSON	Intégration AWS, change sets, drift detection, StackSets	Verbosité, DX parfois moins fluide à grande échelle
AWS CDK	IaC as software : écrire en langage dev, générer CloudFormation	DX développeur, abstractions (constructs), patterns	Débogage / lisibilité parfois à travers le template généré

Les 4 critères qui départagent vraiment en 2026

Avant de rentrer dans les outils, pose ces quatre questions (ce sont elles qui te donneront une conclusion crédible dans un article 2026) :

• Prévisualisation : comment vois‑tu précisément ce qui va changer avant d’impacter la prod ?
• Drift : que se passe‑t‑il quand quelqu’un change quelque chose hors IaC (console, CLI, incident response) ?
• Échelle : comment tu déploies sur plusieurs comptes/régions, et comment tu standardises ?
• Gouvernance : comment tu empêches les mauvaises pratiques (ports ouverts, absence de tags, régions interdites…) avant que ça parte en prod ?

Prévisualisation : comment voir précisément ce qui va changer avant d’impacter la prod ?

Le vrai sujet n’est pas : est‑ce qu’on a un aperçu ?

La vrai question qui se pose est : à quel moment et avec quel niveau de confiance on peut relire les changements ?

Avec Terraform, l’étape de référence est terraform plan : la commande génère un execution plan qui permet de prévisualiser les changements que Terraform compte appliquer.

Et point important pour les process d’équipe : plan ne modifie rien tant apply n’est pas fait
En pratique, ça donne un rituel simple : plan sur PR, review, puis apply sur merge (ou promotion contrôlée).

Avec CloudFormation, l’équivalent opérationnel est le Change Set. Tu proposes un template modifié (ou des paramètres) et CloudFormation compare ce que tu soumets avec l’état de la stack pour générer une liste de changements à venir. Ensuite, tu exécutes (ou non) le change set.
Là aussi, le bon usage “prod‑safe” est clair : change set obligatoire avant toute mise à jour.

Avec AWS CDK, tu as cdk diff : la commande est faite pour voir les changements entre ce que ton app CDK décrit localement et ce qui est déployé. Elle peut même comparer une stack déployée avec un template CloudFormation local.
Mais il faut garder en tête la mécanique : CDK synthétise des templates CloudFormation, puis déploie via CloudFormation.

Outil	avant prod	prévisualisation	Bénéefice en pratique
Terraform	Un plan d’exécution qui décrit les changements prévus (créations, modifications, suppressions)	Côté Terraform (local ou CI/CD), basé sur config + state	Relecture claire avant exécution, très CI/CD‑friendly
CloudFormation	Un Change Set qui prévisualise l’impact d’un changement sur une stack (incluant l’impact sur ressources existantes)	Dans CloudFormation (console / API), au niveau stack	Tu sais ce que CloudFormation va tenter de faire avant d’exécuter
AWS CDK	Un diff d’infrastructure entre ce que ton app CDK décrit et ce qui est déjà déployé (comparaison orientée templates)	Côté CDK CLI (dev/CI), avec comparaison contre la stack déployée	Très pratique pour relire rapidement l’impact de changements de code

Drift : que se passe‑t‑il quand quelqu’un change quelque chose hors IaC ?

Le drift, c’est le moment où ton IaC cesse d’être une photographie fiable, parce que quelqu’un a modifié la réalité hors du workflow (console, CLI, incident response). La question n’est pas “est‑ce que ça arrive ?” mais “comment on s’en rend compte, et comment on évite d’écraser des changements importants ?”.

Côté CloudFormation, AWS est explicite : des changements faits en dehors de CloudFormation peuvent compliquer les mises à jour ou suppressions, et la drift detection sert à identifier ces écarts et à prendre des actions correctives pour réaligner les ressources avec le template.

Dans Terraform, la logique drift est intimement liée au state. HashiCorp documente une approche safe avec le mode refresh-only : tu peux détecter un drift (introduit volontairement hors Terraform), examiner ce que ça implique, puis décider soit de garder le changement (et mettre à jour le code), soit de revenir à l’intention du code (et corriger l’infra).

chez AWS CDK, le point clé est : comme CDK déploie via CloudFormation, tu hérites des mêmes enjeux et des mêmes outils côté exécution (drift detection, drift-aware change sets).

Outil	Comment le drift est détecté	gestion / correction	Point fort
Terraform	Drift vu comme un écart entre state et réalité, avec des approches “refresh/refresh‑only” pour constater l’écart	Tu choisis : soit tu acceptes le changement (et réalignes le code), soit tu reviens à l’intention du code	Approche très explicite : tu peux constater le drift sans “forcer” un changement immédiat
CloudFormation	Identifie les ressources modifiées en dehors de CloudFormation	Drift-aware change sets : permettent de gérer le drift de façon plus sûre et de ramener les ressources driftées en ligne avec le template	AWS outille bien le drift (détection + remédiation guidée)
AWS CDK	Peut déclencher une détection de drift via CloudFormation (CDK “drift”)	En remédiation, tu retombes sur les mécanismes CloudFormation (dont drift-aware change sets)	Très clair : CDK distingue drift (réalité vs attendu) et diff (template local vs template déployé)

Échelle : comment tu déploies sur plusieurs comptes/régions, et comment tu standardises ?

À l’échelle, les outils se différencient moins sur comment créer une ressource que sur comment industrialiser.

Côté CloudFormation, StackSets est un avantage structurel : StackSets étend CloudFormation en permettant de créer, mettre à jour ou supprimer des stacks à travers plusieurs comptes et régions avec une seule opération.

Avec AWS CDK, l’échelle se pense en unités de déploiement : une stack CDK est l’unité minimale, et quand tu déploies, ses ressources sont déployées ensemble en tant que CloudFormation stack.

Donc CDK t’aide surtout à standardiser par le code (constructs, patterns internes), mais l’échelle organisationnelle (multi‑comptes / multi‑régions) reste souvent un sujet d’orchestration CloudFormation (ou de pipelines).

Côté Terraform, l’échelle se gère principalement via la structuration du state (séparation par périmètre/environnement) et via des backends distants : le backend définit où Terraform stocke son state, ce qui permet à plusieurs personnes (ou jobs CI) de travailler sur le même périmètre de manière cohérente.

Outil	Organisation	Standardisation / réutilisation	Point fort
Terraform	Approche flexible : dépend surtout de ton design (périmètres de state, orchestration, pipelines)	Modules (briques réutilisables) + conventions de repo + backends	Très bon pour standardiser une plateforme, y compris au‑delà d’AWS
CloudFormation	StackSets : déploiement de stacks sur plusieurs comptes et régions “en une opération”	Nested stacks / templates factorisés	Natif AWS, très efficace pour les “baselines” orga (guardrails, comptes, régions)
AWS CDK	Peut viser l’échelle via multiples stacks/environnements, mais l’exécution reste CloudFormation	Constructs/patterns internes (réutilisation “code”)	Excellent pour standardiser des patterns de déploiement côté dev

Gouvernance : empêcher les mauvaises pratiques avant le passage en prod

En 2026, la gouvernance IaC efficace combine presque toujours deux niveaux :

• shift-left : bloquer tôt (dev/CI)
• guardrails “autoritatifs” : bloquer au moment de l’exécution côté plateforme/cloud

Avec Terraform, une réponse enterprise classique est Sentinel : HashiCorp documente que Sentinel sert à faire appliquer des politiques sur configurations, states et plans, et que l’exécution des policies intervient après terraform plan et avant terraform apply (pile au bon moment pour bloquer un changement non conforme).

Côté CloudFormation, l’outil de policy-as-code phare est CloudFormation Guard : tu écris des règles dans le DSL Guard pour valider des données JSON/YAML (donc des templates CloudFormation).
Et pour passer du lint à l’enforcement, AWS propose les Guard Hooks : des hooks activables qui évaluent les ressources avant d’autoriser des opérations de stack.

Avec AWS CDK, tu peux faire du shift-left de manière très naturelle : AWS documente la policy validation à la synthèse, notamment via le plugin CfnGuardValidator qui permet d’appliquer des règles CloudFormation Guard sur les templates générés par CDK.

Outil	Bocage des mauvaises pratiques	Mécanisme principal	Point fort
Terraform	Dans le workflow d’exécution (avant application), surtout en plateforme Terraform gérée	Sentinel (policies évaluées après la prévisualisation et avant application)	Très adapté aux organisations qui veulent des règles centralisées sur plans/states/configs
CloudFormation	Au niveau CloudFormation, avant d’autoriser des opérations de stack	CloudFormation Guard (règles) + Guard Hooks / Hooks (enforcement “à l’exécution”)	Approche “autoritative” : empêche réellement une opération non conforme au moment critique
AWS CDK	Très tôt (au moment de la synthèse) + à l’exécution via CloudFormation	Policy validation à la synthèse (via Guard) + (recommandé) hooks CloudFormation pour validation autoritative	Shift‑left efficace : feedback rapide aux devs; et la validation finale peut être imposée côté CloudFormation

Conclusion

Au fond, comparer Terraform, CloudFormation et AWS CDK en 2026 n’est pas un concours de syntaxe. C’est une question de fiabilité opérationnelle : est‑ce que votre organisation sait changer l’infrastructure souvent, sans surprise, sans dérive, et avec des garde‑fous clairs ?

Si vous ne deviez retenir qu’une idée, ce serait celle‑ci : il n’y a pas un vainqueur universel, il y a un meilleur outil pour votre contexte — et votre contexte se lit très bien à travers les quatre points d’attention.

• Sur la prévisualisation, la maturité ne vient pas du bouton que vous cliquez (plan, change set, diff) mais du fait de rendre la lecture des changements obligatoire avant toute mise en production, avec un vrai rituel de review et des règles d’approbation.
• Sur le drift, le sujet n’est pas d’“éviter la console” (ça arrivera), mais de définir un contrat : comment on détecte, comment on documente, et comment on réconcilie — vite, et sans improvisation.
• Sur l’échelle, ce qui compte n’est pas la capacité à créer une ressource, mais la capacité à standardiser : conventions, briques réutilisables, séparation des périmètres, et un modèle clair pour multi‑comptes / multi‑régions.
• Sur la gouvernance, le bon système est celui qui bloque les mauvaises pratiques avant qu’elles ne deviennent un incident : validation en CI (shift‑left) + garde‑fous “autoritatifs” au moment du déploiement.

Dans ce cadre, les choix deviennent assez naturels :

• CloudFormation est souvent la réponse la plus robuste quand vous êtes AWS‑only et que vous cherchez du natif, du multi‑comptes et un modèle de stack clairement gouverné.
• AWS CDK est un excellent compromis quand vos équipes sont dev‑first et veulent coder l’infra comme un logiciel, sans perdre la compatibilité CloudFormation — tout en gardant en tête que le CDK n’exécute pas : il génère et s’appuie sur CloudFormation.
• Terraform brille quand vous pensez plateforme ou multi‑providers : c’est une colonne vertébrale efficace, à condition d’assumer la discipline autour du state (stockage, verrouillage, séparation des périmètres et process d’exécution