Pulumi vs Terraform en 2026 : Infrastructure as Code avec TypeScript et Questions d'Entretien

Pulumi vs Terraform constitue le choix central d'infrastructure as code pour les équipes DevOps en 2026. Ces deux outils provisionnent des ressources cloud de manière déclarative, mais diffèrent en termes de support linguistique, de gestion d'état et de maturité de l'écosystème. Cette comparaison couvre les compromis techniques, des exemples de code en TypeScript et HCL, ainsi que les questions d'entretien qui émergent lors des discussions sur les choix IaC.

Architecture Fondamentale : Moteur Pulumi vs Cycle Plan-Apply de Terraform

Terraform utilise un langage spécifique au domaine (HCL) et un workflow en deux phases : terraform plan génère un plan d'exécution, terraform apply l'exécute. Le fichier d'état suit les métadonnées des ressources et est stocké localement ou dans des backends distants comme S3 ou Terraform Cloud.

Pulumi intègre son moteur dans des runtimes à usage général. Les programmes écrits en TypeScript, Python, Go ou C# s'exécutent directement contre les APIs cloud via les providers Pulumi. L'état est stocké dans Pulumi Cloud par défaut, avec des options pour des backends auto-gérés incluant S3, Azure Blob Storage et les fichiers locaux.

La différence architecturale apparaît immédiatement dans la façon dont chaque outil gère les boucles, les conditionnels et les abstractions. Le for_each et count de Terraform fonctionnent dans les contraintes de HCL. Les programmes Pulumi utilisent les constructions natives du langage : for...of en TypeScript, les compréhensions de liste en Python, range en Go.

import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";

// Native TypeScript array methods work directly
const environments = ["dev", "staging", "prod"];

const buckets = environments.map(env => 
  new aws.s3.BucketV2(`data-${env}`, {
    bucket: `myapp-data-${env}-${pulumi.getStack()}`,
    tags: {
      Environment: env,
      ManagedBy: "pulumi",
    },
  })
);

// Export bucket ARNs as stack outputs
export const bucketArns = buckets.map(b => b.arn);

La configuration Terraform équivalente nécessite la syntaxe HCL pour l'itération :

# main.tf - Terraform HCL example
variable "environments" {
  type    = list(string)
  default = ["dev", "staging", "prod"]
}

resource "aws_s3_bucket" "data" {
  for_each = toset(var.environments)

  bucket = "myapp-data-${each.key}-${terraform.workspace}"

  tags = {
    Environment = each.key
    ManagedBy   = "terraform"
  }
}

output "bucket_arns" {
  value = [for b in aws_s3_bucket.data : b.arn]
}

Les deux snippets créent trois buckets S3. La version Terraform est concise et lisible pour quiconque connaît HCL. La version Pulumi utilise du TypeScript standard, ce qui signifie l'autocomplétion IDE, la vérification de types et l'intégration avec les bases de code existantes sans apprendre un nouveau langage.

Support TypeScript : Langage Natif vs CDKTF (Déprécié)

Pulumi a supporté TypeScript dès sa première version publique. Le SDK expose des classes de ressources typées, et pulumi.Output<T> encapsule les valeurs asynchrones qui se résolvent pendant le déploiement. Les outils de refactoring, les linters et les frameworks de test de l'écosystème TypeScript s'appliquent directement.

La réponse de Terraform au support de langage à usage général était CDKTF (Cloud Development Kit for Terraform). CDKTF permettait aux équipes d'écrire du TypeScript ou Python qui se compilait en JSON Terraform. HashiCorp a déprécié CDKTF en décembre 2025 et a archivé le dépôt. Les projets CDKTF existants fonctionnent toujours, mais aucune mise à jour n'est publiée pour les nouvelles versions Terraform ou les changements de providers.

Pour les équipes qui veulent du TypeScript IaC en 2026, Pulumi est l'option activement maintenue. Les équipes déjà investies dans CDKTF peuvent continuer à exécuter leurs stacks, mais la migration vers HCL ou Pulumi est la voie à suivre pour les nouveaux développements.

import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";

// Custom component encapsulating VPC, subnets, and routing
export class StandardVpc extends pulumi.ComponentResource {
  public readonly vpcId: pulumi.Output<string>;
  public readonly publicSubnetIds: pulumi.Output<string>[];

  constructor(name: string, args: { cidr: string; azCount: number }, opts?: pulumi.ComponentResourceOptions) {
    super("mycompany:network:StandardVpc", name, {}, opts);

    const vpc = new aws.ec2.Vpc(`${name}-vpc`, {
      cidrBlock: args.cidr,
      enableDnsHostnames: true,
      tags: { Name: name },
    }, { parent: this });

    this.vpcId = vpc.id;

    // Create public subnets across availability zones
    const azs = aws.getAvailabilityZones({ state: "available" });
    this.publicSubnetIds = [];

    for (let i = 0; i < args.azCount; i++) {
      const subnet = new aws.ec2.Subnet(`${name}-public-${i}`, {
        vpcId: vpc.id,
        cidrBlock: `10.0.${i}.0/24`,
        availabilityZone: azs.then(az => az.names[i]),
        mapPublicIpOnLaunch: true,
        tags: { Name: `${name}-public-${i}` },
      }, { parent: this });
      this.publicSubnetIds.push(subnet.id);
    }

    this.registerOutputs({ vpcId: this.vpcId });
  }
}

Ce composant Pulumi crée une abstraction VPC réutilisable. Les consommateurs l'instancient avec new StandardVpc("prod", { cidr: "10.0.0.0/16", azCount: 3 }). L'équivalent en Terraform est un répertoire de module avec des variables, des outputs et des fichiers HCL. Les deux approches permettent la réutilisation ; la version Pulumi hérite de l'outillage TypeScript pour la documentation, les tests et le versionnage.

Gestion d'État et Options de Backend

La gestion d'état est l'endroit où les différences opérationnelles apparaissent. L'état Terraform contient les IDs de ressources, les métadonnées des providers et les valeurs sensibles. Les équipes doivent configurer des backends distants pour permettre la collaboration et implémenter le verrouillage pour empêcher les modifications concurrentes.

La configuration du backend Terraform supporte S3, Azure Blob, Google Cloud Storage, Terraform Cloud et d'autres. Chaque backend nécessite sa propre configuration d'authentification. Le verrouillage d'état utilise DynamoDB pour les backends S3, les baux de blob pour Azure, ou le verrouillage natif dans Terraform Cloud.

Pulumi Cloud gère le stockage d'état, le verrouillage et l'historique par défaut. Les équipes créent un compte gratuit, exécutent pulumi login, et la gestion d'état est configurée. Pour les équipes qui nécessitent un état auto-géré, Pulumi supporte S3, Azure Blob, GCS et les backends de fichiers locaux avec la commande pulumi login.

# Pulumi: login to self-managed S3 backend
pulumi login s3://my-pulumi-state-bucket

# Terraform: configure S3 backend in HCL
# backend.tf
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Pulumi Cloud fournit une interface web pour l'historique des stacks, la visualisation des ressources et les permissions d'équipe. Terraform Cloud offre des fonctionnalités similaires avec l'application de politiques via Sentinel. Des options auto-hébergées existent pour les deux : le backend auto-hébergé de Pulumi et Terraform Enterprise.

Écosystème de Providers et Support Multi-Cloud

L'écosystème de providers de Terraform est le plus large en IaC. Le Terraform Registry liste plus de 4 000 providers couvrant AWS, Azure, GCP, Kubernetes et des centaines de plateformes SaaS. La qualité des providers varie : les providers officiels HashiCorp et des fournisseurs cloud reçoivent des mises à jour régulières, tandis que les providers communautaires peuvent être en retard sur les changements d'API.

Les providers Pulumi encapsulent les providers Terraform en utilisant un pont qui génère des SDKs typés. Le Pulumi Registry expose des providers pour les principaux clouds, Kubernetes, les bases de données et les services de monitoring. Parce que Pulumi fait le pont avec les providers Terraform, la couverture de l'écosystème est comparable, bien que les nouvelles versions de providers Terraform nécessitent des mises à jour du pont avant que les SDKs Pulumi ne reflètent les changements.

Pulumi offre également des providers natifs écrits directement contre les APIs cloud. Les providers natifs pour AWS, Azure et Kubernetes livrent un support le jour même pour les nouvelles fonctionnalités API. Le compromis est que les providers natifs n'existent que pour les principaux clouds ; les services moins courants utilisent des providers bridgés.

// Using Pulumi's native AWS provider for Lambda
import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";

const role = new aws.iam.Role("lambda-role", {
  assumeRolePolicy: aws.iam.assumeRolePolicyForPrincipal({
    Service: "lambda.amazonaws.com",
  }),
});

const lambdaFunction = new aws.lambda.Function("api-handler", {
  runtime: aws.lambda.Runtime.NodeJS20dX,
  handler: "index.handler",
  role: role.arn,
  code: new pulumi.asset.AssetArchive({
    "index.js": new pulumi.asset.StringAsset(
      `exports.handler = async () => ({ statusCode: 200, body: "OK" });`
    ),
  }),
});

export const functionArn = lambdaFunction.arn;

Tester le Code d'Infrastructure

Les tests sont l'endroit où le choix du langage crée une divergence. Les programmes Pulumi sont du code standard, donc les tests unitaires utilisent des frameworks familiers. Le module @pulumi/pulumi/runtime fournit le mocking pour la création de ressources, permettant aux tests de vérifier la configuration sans déployer de ressources.

import { describe, it, expect, beforeAll } from "vitest";
import * as pulumi from "@pulumi/pulumi";

// Mock Pulumi runtime
pulumi.runtime.setMocks({
  newResource: (args: pulumi.runtime.MockResourceArgs) => {
    return { id: `${args.name}-id`, state: args.inputs };
  },
  call: (args: pulumi.runtime.MockCallArgs) => {
    return args.inputs;
  },
});

describe("S3 Bucket Configuration", () => {
  let bucketTags: Record<string, string>;

  beforeAll(async () => {
    // Import the Pulumi program after mocks are set
    const infra = await import("../infra/index");
    // Extract outputs for testing
    bucketTags = await new Promise(resolve => {
      infra.buckets[0].tags.apply(tags => resolve(tags as Record<string, string>));
    });
  });

  it("should tag buckets with Environment", () => {
    expect(bucketTags).toHaveProperty("Environment");
  });

  it("should tag buckets with ManagedBy", () => {
    expect(bucketTags.ManagedBy).toBe("pulumi");
  });
});

Les tests Terraform utilisent terraform test (introduit dans Terraform 1.6) ou des outils externes comme Terratest. terraform test exécute des fichiers de test HCL qui créent de vraies ressources dans des configurations isolées. Terratest est une bibliothèque Go qui encapsule les commandes Terraform et fournit des assertions.

# tests/bucket.tftest.hcl - Terraform native test
run "bucket_tags" {
  command = plan

  assert {
    condition     = aws_s3_bucket.data["dev"].tags["Environment"] == "dev"
    error_message = "Bucket must be tagged with Environment"
  }

  assert {
    condition     = aws_s3_bucket.data["dev"].tags["ManagedBy"] == "terraform"
    error_message = "Bucket must be tagged with ManagedBy"
  }
}

Les deux approches valident la configuration d'infrastructure. L'avantage de Pulumi est l'intégration avec les runners de test TypeScript et les outils de couverture. Les tests natifs de Terraform s'exécutent sans dépendances externes mais nécessitent la syntaxe HCL.

Questions d'Entretien : Pulumi vs Terraform

Les entretiens DevOps en 2026 incluent fréquemment des comparaisons d'outils IaC. Voici des questions qui distinguent les candidats ayant utilisé les deux outils en production.

« Que se passe-t-il lorsque l'état Terraform diverge de l'infrastructure réelle ? »

Réponse attendue : terraform plan détecte la dérive en comparant l'état avec l'infrastructure réelle. Le plan montre les ressources à mettre à jour, créer ou détruire. La dérive se produit lorsque des modifications sont effectuées en dehors de Terraform (console, CLI, autres outils). Les options incluent terraform refresh pour mettre à jour l'état, terraform import pour placer les ressources sous gestion, ou accepter le plan pour restaurer l'état souhaité.

« Comment Pulumi gère-t-il les secrets différemment de Terraform ? »

Réponse attendue : Pulumi chiffre les secrets dans l'état par défaut en utilisant une passphrase ou un KMS cloud. La fonction pulumi.secret() marque les valeurs comme sensibles, et elles restent chiffrées au repos. Terraform stocke les secrets en texte clair dans les fichiers d'état ; les équipes comptent sur le chiffrement du backend (chiffrement côté serveur S3) et les contrôles d'accès. Terraform 1.4 a ajouté le marquage de variable sensitive, mais les valeurs apparaissent toujours non chiffrées dans l'état.

« Pourquoi HashiCorp a-t-il déprécié CDKTF, et quelles sont les options de migration ? »

Réponse attendue : CDKTF ajoutait une surcharge de maintenance sans correspondre à la cadence de mise à jour de Terraform. Les nouvelles versions de providers et les fonctionnalités Terraform nécessitaient des mises à jour manuelles des bindings CDK. HashiCorp a choisi de se concentrer sur HCL et Terraform Cloud. Les options de migration sont : convertir en HCL en utilisant cdktf convert, réécrire en Pulumi si TypeScript est requis, ou continuer à exécuter les stacks CDKTF existants sans mises à jour.

« Quand choisiriez-vous Pulumi plutôt que Terraform pour un nouveau projet ? »

Réponse attendue : Choisir Pulumi quand l'équipe utilise déjà TypeScript/Python/Go et veut l'IaC dans le même langage que le code applicatif, quand des abstractions complexes nécessitent de vraies constructions de programmation (génériques, interfaces, frameworks de test), ou quand le chiffrement intégré des secrets est une exigence. Choisir Terraform quand l'équipe connaît HCL, quand l'écosystème de providers doit inclure des providers de niche ou communautaires, ou quand l'outillage organisationnel (Atlantis, Spacelift) s'intègre avec Terraform.

Pour plus de préparation aux entretiens sur l'infrastructure as code, consultez Questions d'Entretien Terraform : Guide Complet Infrastructure as Code et le module Terraform Avancé.

Stratégies de Migration : Terraform vers Pulumi

Pulumi fournit pulumi import pour placer les ressources cloud existantes sous gestion sans les recréer. Pour les équipes avec un état Terraform, pulumi convert traduit le HCL en programmes Pulumi. La conversion n'est pas parfaite : les modules complexes et les blocs dynamiques nécessitent un ajustement manuel.

# Convert Terraform HCL to Pulumi TypeScript
pulumi convert --from terraform --language typescript

# Import existing AWS resources into Pulumi state
pulumi import aws:s3/bucketV2:BucketV2 my-bucket my-existing-bucket-name

Une migration par phases permet aux équipes d'exécuter les deux outils pendant la transition. Terraform gère les stacks existants tandis que Pulumi provisionne la nouvelle infrastructure. Une fois que les équipes acquièrent de l'expérience Pulumi, elles convertissent les stacks Terraform de manière incrémentale. L'état n'est pas partagé entre les outils, donc la gestion des ressources doit être clairement divisée pour éviter les conflits.

Cadre de Décision pour 2026

Points Clés pour l'Infrastructure as Code en 2026

• Terraform 1.16 est le choix stable pour l'IaC basé sur HCL avec le plus grand écosystème de providers et un outillage mature (Atlantis, Spacelift, env0).
• Pulumi v3.263 offre TypeScript, Python, Go et C# avec des tests natifs du langage, l'intégration IDE et le chiffrement intégré des secrets.
• CDKTF est déprécié depuis décembre 2025. Les équipes voulant du TypeScript IaC devraient évaluer Pulumi plutôt que de démarrer de nouveaux projets CDKTF.
• Les deux outils supportent les déploiements multi-cloud, les backends d'état distants et la collaboration d'équipe. Le choix dépend de la préférence de langage et de l'expertise existante de l'équipe.
• Les discussions d'entretien devraient démontrer la compréhension de la gestion d'état, la détection de dérive, les écosystèmes de providers et les compromis entre la simplicité du DSL et la puissance des langages à usage général.
• La migration de Terraform vers Pulumi est possible en utilisant pulumi convert et pulumi import, mais nécessite une planification soigneuse et un déploiement progressif.