Introduction : pourquoi l’Infrastructure as Code est devenue incontournable

En 2024, 83 % des entreprises utilisant le cloud public déclarent avoir adopté au moins un outil d’Infrastructure as Code (IaC), selon le rapport State of DevOps de Puppet. La raison est simple : gérer manuellement des dizaines, voire des centaines de ressources cloud via une console web est une recette garantie pour les erreurs humaines, les drifts de configuration et les nuits blanches.

L’IaC consiste à décrire l’intégralité de votre infrastructure (serveurs, réseaux, bases de données, load balancers…) sous forme de fichiers de code versionnés. Deux outils dominent le marché lorsque l’on travaille sur AWS : Terraform (de HashiCorp) et CloudFormation (natif Amazon Web Services).

Mais lequel choisir ? La réponse n’est pas aussi évidente qu’il n’y paraît. Chez Lueur Externe, agence certifiée AWS Solutions Architect depuis plus de 20 ans, nous déployons quotidiennement ces deux outils pour nos clients. Voici notre comparatif détaillé, fondé sur l’expérience terrain.

Terraform : présentation et philosophie

Un outil open source et multi-cloud

Terraform a été lancé en 2014 par HashiCorp. C’est un outil open source écrit en Go qui utilise un langage déclaratif propriétaire : le HCL (HashiCorp Configuration Language). Sa grande force réside dans son approche multi-cloud : un seul et même outil permet de piloter des ressources sur AWS, Google Cloud, Azure, mais aussi Cloudflare, Datadog, GitHub, Kubernetes et plus de 4 000 providers référencés dans le Terraform Registry.

Le concept de state file

Terraform maintient un fichier d’état (state file) qui cartographie les ressources réelles par rapport à votre configuration déclarée. Ce fichier est la colonne vertébrale de Terraform : il permet de calculer les plans d’exécution (ce qui va être créé, modifié ou détruit) avant toute modification.

Ce state file peut être stocké localement ou — c’est fortement recommandé — dans un backend distant comme un bucket S3 avec verrouillage DynamoDB :

terraform {
  backend "s3" {
    bucket         = "mon-projet-terraform-state"
    key            = "prod/infrastructure.tfstate"
    region         = "eu-west-3"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Modules et réutilisabilité

L’un des atouts majeurs de Terraform est son système de modules. Vous pouvez encapsuler des composants d’infrastructure complets (un cluster ECS, un VPC avec subnets, un bucket S3 avec politique de cycle de vie) dans des modules réutilisables, versionnés et partagés au sein de votre organisation.

Le Terraform Registry propose déjà des milliers de modules communautaires prêts à l’emploi. Par exemple, le module officiel terraform-aws-modules/vpc/aws a été téléchargé plus de 50 millions de fois.

CloudFormation : présentation et philosophie

Le service natif d’AWS

CloudFormation existe depuis 2011. C’est un service managé d’AWS, gratuit (vous ne payez que les ressources provisionnées), qui permet de décrire votre infrastructure AWS au format JSON ou YAML. Chaque déploiement crée une stack qui gère le cycle de vie complet des ressources.

Intégration profonde avec l’écosystème AWS

CloudFormation bénéficie d’un avantage structurel : il est développé par AWS, pour AWS. Cela signifie que les nouveaux services ou fonctionnalités AWS sont souvent supportés dans CloudFormation le jour même de leur lancement, parfois avant tout autre outil tiers.

De plus, CloudFormation s’intègre nativement avec :

  • AWS CDK (Cloud Development Kit) pour écrire l’infrastructure en TypeScript, Python, Java ou C#
  • AWS Service Catalog pour gouverner les déploiements
  • AWS Config pour la conformité
  • AWS Organizations pour les déploiements multi-comptes via les StackSets

Exemple de template CloudFormation

Voici un exemple de template YAML créant un bucket S3 avec chiffrement :

AWSTemplateFormatVersion: '2010-09-09'
Description: Bucket S3 chiffré pour les assets statiques

Resources:
  AssetsBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: mon-projet-assets-prod
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256
      VersioningConfiguration:
        Status: Enabled
      Tags:
        - Key: Environment
          Value: production
        - Key: ManagedBy
          Value: CloudFormation

Outputs:
  BucketArn:
    Description: ARN du bucket S3
    Value: !GetAtt AssetsBucket.Arn

Comparatif détaillé : Terraform vs CloudFormation

Voici un tableau synthétique des principales différences entre les deux outils :

CritèreTerraformCloudFormation
ÉditeurHashiCorp (open source)AWS (service managé)
LangageHCL (HashiCorp Configuration Language)YAML / JSON
Multi-cloud✅ Oui (4 000+ providers)❌ AWS uniquement
Gestion d’étatState file externe (S3, Terraform Cloud…)Géré automatiquement par AWS
Coût de l’outilGratuit (CLI) / Payant (Cloud/Enterprise)Gratuit
Support nouveaux services AWSQuelques jours/semaines de décalageSouvent jour J
ModularitéModules puissants et versionnésNested stacks (moins flexibles)
Gestion du driftterraform plan (détection à la demande)Drift detection intégrée
Rollback automatique❌ Non natif✅ Oui (rollback automatique en cas d’échec)
Import de ressources existantesterraform importresource import (depuis 2023)
Écosystème étenduProviders Kubernetes, GitHub, Datadog…Limité à AWS + Custom Resources
Courbe d’apprentissageMoyenne (HCL à maîtriser)Faible à moyenne (YAML/JSON familiers)

Les forces de Terraform face à CloudFormation

La portabilité multi-cloud

Si votre stratégie implique plusieurs fournisseurs cloud — ou si vous envisagez une migration future — Terraform est le choix logique. Avec un seul workflow et un seul langage, vous pouvez gérer simultanément :

  • Vos instances EC2 et bases RDS sur AWS
  • Votre CDN et vos Workers sur Cloudflare
  • Vos repos et pipelines CI/CD sur GitHub
  • Vos dashboards de monitoring sur Datadog

Cette capacité à orchestrer des ressources au-delà d’AWS est un avantage considérable pour les architectures modernes.

La puissance du plan d’exécution

La commande terraform plan génère un aperçu détaillé de tous les changements qui seront appliqués avant toute modification réelle. C’est un filet de sécurité indispensable :

terraform plan

# Terraform will perform the following actions:
#
#   ~ aws_instance.web_server
#       instance_type: "t3.medium" -> "t3.large"
#
#   + aws_security_group_rule.allow_https
#
# Plan: 1 to add, 1 to change, 0 to destroy.

CloudFormation propose les Change Sets, qui remplissent un rôle similaire, mais l’expérience développeur est généralement jugée moins fluide.

La communauté et l’écosystème

Terraform bénéficie d’une communauté open source massive. Sur GitHub, le dépôt principal cumule plus de 43 000 étoiles. Les outils complémentaires sont nombreux :

  • Terragrunt pour gérer les configurations DRY à grande échelle
  • tflint pour le linting statique
  • Checkov et tfsec pour l’analyse de sécurité
  • Atlantis pour les workflows de PR automatisés

Les forces de CloudFormation face à Terraform

Zéro gestion d’état

C’est sans doute l’avantage le plus sous-estimé de CloudFormation. L’état de votre infrastructure est géré automatiquement par AWS. Vous n’avez pas à :

  • Configurer un bucket S3 et une table DynamoDB pour le state
  • Gérer les conflits de verrouillage en équipe
  • Vous inquiéter de la corruption du fichier d’état
  • Planifier des sauvegardes du state file

Pour les petites équipes ou les projets à croissance rapide, cet aspect opérationnel simplifié est un gain de temps réel.

Le rollback automatique

Quand un déploiement CloudFormation échoue, la stack revient automatiquement à son état précédent. C’est un comportement par défaut extrêmement rassurant en production. Terraform, en revanche, peut laisser votre infrastructure dans un état intermédiaire en cas d’échec partiel, ce qui nécessite une intervention manuelle.

AWS CDK : l’infrastructure en code réel

Le Cloud Development Kit (CDK) a transformé l’expérience CloudFormation. Au lieu d’écrire des centaines de lignes de YAML, vous utilisez un vrai langage de programmation :

import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';

export class MyStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string) {
    super(scope, id);

    new s3.Bucket(this, 'AssetsBucket', {
      bucketName: 'mon-projet-assets-prod',
      encryption: s3.BucketEncryption.S3_MANAGED,
      versioned: true,
      removalPolicy: cdk.RemovalPolicy.RETAIN,
    });
  }
}

Le CDK synthétise ensuite un template CloudFormation standard. C’est le meilleur des deux mondes : la puissance d’un langage de programmation avec la fiabilité du moteur CloudFormation.

Les StackSets pour le multi-comptes

Pour les organisations utilisant AWS Organizations avec des dizaines de comptes AWS, les StackSets permettent de déployer une même stack CloudFormation sur plusieurs comptes et régions simultanément. C’est un scénario courant dans les grandes entreprises que Terraform gère de manière moins élégante.

Quel outil choisir ? Critères de décision

Le choix entre Terraform et CloudFormation n’est pas binaire. Voici les questions clés à vous poser :

Choisissez CloudFormation si :

  • Votre infrastructure est 100 % AWS et le restera
  • Vous souhaitez minimiser la complexité opérationnelle (pas de state à gérer)
  • Vous utilisez déjà AWS CDK ou envisagez de l’adopter
  • Vous avez besoin de rollback automatique en production
  • Votre organisation exploite AWS Organizations avec des déploiements multi-comptes

Choisissez Terraform si :

  • Vous avez une stratégie multi-cloud ou hybride
  • Vous gérez des ressources hors AWS (DNS Cloudflare, repos GitHub, monitoring Datadog…)
  • Vous avez besoin d’une modularité avancée et de modules réutilisables
  • Votre équipe DevOps est expérimentée et apprécie l’écosystème open source
  • Vous souhaitez une portabilité de vos compétences IaC entre différents clouds

L’approche hybride

De nombreuses organisations adoptent une approche hybride qui combine les forces des deux outils. Par exemple :

  • CloudFormation (via CDK) pour le socle réseau, les comptes AWS et les politiques de sécurité
  • Terraform pour les couches applicatives, les intégrations tierces et les environnements de développement

Cette approche pragmatique est celle que nous recommandons fréquemment chez Lueur Externe à nos clients disposant d’architectures AWS complexes.

Bonnes pratiques communes aux deux outils

Quel que soit votre choix, certaines bonnes pratiques s’appliquent universellement :

  • Versionner tout dans Git : chaque modification d’infrastructure doit passer par une Pull Request avec review
  • Séparer les environnements : des stacks ou workspaces distincts pour dev, staging et production
  • Utiliser des variables et des paramètres : jamais de valeurs en dur dans les templates
  • Scanner la sécurité : intégrer des outils comme Checkov, cfn-nag ou tfsec dans votre pipeline CI/CD
  • Documenter les décisions : expliquer pourquoi telle architecture a été choisie, pas seulement comment
  • Tester avant de déployer : terraform plan ou Change Sets systématiques avant chaque apply
  • Limiter le blast radius : découper l’infrastructure en stacks ou modules de taille raisonnable

Performances et limites à connaître

Il est important de mentionner quelques limites pratiques que l’on découvre souvent en production :

Limites de CloudFormation :

  • Maximum 500 ressources par stack (contournable avec les nested stacks)
  • Les templates peuvent devenir très verbeux en YAML/JSON (un VPC complet peut dépasser 800 lignes)
  • Le temps de rollback peut être long sur des stacks volumineuses (parfois 30-45 minutes)

Limites de Terraform :

  • Le state file est un point de défaillance critique : sa corruption peut bloquer tout déploiement
  • Les mises à jour de providers peuvent introduire des breaking changes
  • La licence BSL adoptée en 2023 par HashiCorp a suscité des inquiétudes (ce qui a donné naissance au fork OpenTofu)

OpenTofu : le fork à surveiller

Suite au changement de licence de Terraform en août 2023 (passage de MPL à BSL), la Linux Foundation a lancé OpenTofu, un fork open source sous licence MPL 2.0. En 2024, OpenTofu a atteint la version 1.7 et propose déjà des fonctionnalités exclusives comme le chiffrement natif du state file.

Si la question de la licence est importante pour votre organisation, OpenTofu est une alternative crédible et compatible avec l’écosystème Terraform existant.

Conclusion : choisir l’outil qui sert votre stratégie

Le débat Terraform vs CloudFormation n’a pas de vainqueur absolu. Le meilleur outil est celui qui s’aligne avec votre stratégie cloud, la maturité de votre équipe et vos contraintes opérationnelles.

CloudFormation excelle dans les environnements 100 % AWS grâce à son intégration native, sa gestion d’état transparente et ses rollbacks automatiques. Terraform brille par sa polyvalence multi-cloud, sa modularité et son écosystème communautaire riche.

Dans tous les cas, l’adoption de l’Infrastructure as Code n’est plus optionnelle en 2024 : c’est un prérequis pour la fiabilité, la reproductibilité et la scalabilité de vos déploiements cloud.

Chez Lueur Externe, certifiée AWS Solutions Architect et spécialiste de l’infrastructure cloud depuis 2003, nous accompagnons nos clients dans le choix, la mise en place et l’optimisation de leur stratégie IaC sur AWS. Que vous partiez de zéro ou que vous souhaitiez migrer d’un outil à l’autre, nos experts sont là pour vous guider.

👉 Contactez l’équipe Lueur Externe pour auditer votre infrastructure et déployer une stratégie Infrastructure as Code adaptée à vos besoins.