Pulumi et l'Infrastructure As Actual Code

J’ai fait du Terraform pendant 5 ans. J’ai écrit des milliers de lignes de HCL. J’ai debuggué des for_each qui font n’importe quoi, des count qui réordonnent des ressources en prod, et des modules tellement abstraits que personne savait plus ce qu’ils faisaient.

Puis j’ai essayé Pulumi.

Et là, je me suis rendu compte d’un truc : on a remplacé le YAML par un DSL, et on a appelé ça “du code”.

C’est pas du code. C’est une config avec des {}.

Pulumi fait le pari inverse : utilisez vos vrais langages. TypeScript. Python. Go. C#. Java. Pas un nouveau langage à apprendre. Pas une syntaxe propriétaire. Les mêmes langages que vous utilisez pour vos applications.

Et ça change tout.

Lexique et bibliographie

• IaC (Infrastructure as Code): définir son infra dans des fichiers versionnés.
• IaS (Infrastructure as Software): utiliser des vrais langages de programmation, pas des DSLs.
• HCL: HashiCorp Configuration Language, le DSL de Terraform. Déclaratif, non Turing-complet.
• CDK: Cloud Development Kit, AWS. Écrit en TypeScript/Python, compile en CloudFormation.
• Automation API: API Pulumi qui permet d’appeler pulumi up depuis un programme.
• ESC (Environments, Secrets, Configuration): solution de gestion centralisée des secrets Pulumi.
• Provider: plugin qui traduit les appels Pulumi en API cloud (AWS, Azure, GCP, etc.).
• Stack: instance isolée et configurable d’un programme Pulumi (dev, staging, prod).
• Pulumi Neo: agent AI spécialisé infrastructure sorti en 2026.

Sources

1. Pulumi Docs — Infrastructure as Code Concepts
   https://www.pulumi.com/docs/iac/concepts/

2. Pulumi — Infrastructure as Software
   https://www.pulumi.com/what-is/what-is-infrastructure-as-software/

3. Pulumi GitHub — Apache 2.0, 25.4k stars
   https://github.com/pulumi/pulumi

Le grand mensonge de l’IaC

L’infrastructure as code a résolu un vrai problème : plus de clics dans la console AWS à 3h du matin. Tout dans Git. Tout reviewable. Tout reproductible.

Sauf qu’on a confondu “mettre de la config dans des fichiers” avec “écrire du code”.

Regarde Terraform. T’as HCL. Un langage déclaratif, non Turing-complet, avec des boucles limitées (for_each, count), des conditions bancales, et des modules qui sont juste des templates glorifiés.

C’est pas du code. C’est du YAML avec du rouge à lèvres.

Et le pire ? Tout le monde a accepté que “l’IaC c’est comme ça”. On a naturalisé la médiocrité.

Pourquoi les DSLs d’infrastructure sont un cul-de-sac

Les boucles

Tu veux créer 20 buckets S3 avec des noms qui varient légèrement ?

En HCL :

1resource "aws_s3_bucket" "buckets" {
2  for_each = toset(["logs", "backups", "data", "archive", "cache", "static", "media", "temp", "config", "export"])
3  bucket   = "myapp-${each.key}-${var.environment}"
4}

En TypeScript avec Pulumi :

1const names = ["logs", "backups", "data", "archive", "cache", "static", "media", "temp", "config", "export"];
2for (const name of names) {
3  new aws.s3.Bucket(`myapp-${name}-${environment}`, {
4    bucket: `myapp-${name}-${environment}`,
5  });
6}

La différence ? C’est une boucle. Une vraie. Pas une construction magique du langage. Tu peux mettre des conditions, des breaks, des appels API, des imports npm. T’as pas à apprendre les subtilités de for_each vs count et les edge cases où ils se comportent différemment.

Les types

Le jour où t’as passé 30 minutes à chercher pourquoi Terraform refuse ton list(string) alors que la doc dit qu’il attend un set(string), tu sais de quoi je parle.

Les types en Pulumi sont des vrais types. Compilés. Checkés à l’écriture, pas à l’exécution.

1const vpc = new aws.ec2.Vpc("main", {
2  cidrBlock: "10.0.0.0/16",
3  enableDnsHostnames: true,
4  // Si je mets un string à la place d'un boolean,
5  // le compilateur me gueule dessus avant même d'exécuter
6});

Les tests

Tu testes ton infrastructure Terraform ? Non. Personne ne le fait. Parce que c’est trop pénible.

Terratest existe. Il déploie de la vraie infra pour chaque test. Il coûte de l’argent. Il prend 5 à 30 minutes. Et il faut écrire en Go, même si ton infra est en HCL.

Avec Pulumi :

 1import { describe, it, assert } from "vitest";
 2import * as pulumi from "@pulumi/pulumi";
 3
 4// Mock complet — zéro appel cloud
 5pulumi.runtime.setMocks({
 6  newResource: (type: string, name: string, inputs: any) => ({
 7    id: `${name}_id`,
 8    state: inputs,
 9  }),
10  call: (token: string, args: any) => args,
11});
12
13describe("VPC", () => {
14  it("devrait avoir un CIDR privé", async () => {
15    const vpc = new aws.ec2.Vpc("main", { cidrBlock: "10.0.0.0/16" });
16    const cidr = await vpc.cidrBlock;
17    assert(cidr.startsWith("10."));
18  });
19});

Ce test s’exécute en millisecondes. Sans credentials cloud. Dans le même runner que tes tests applicatifs.

Tu peux enfin faire du TDD sur ton infrastructure. Pas un luxe — une nécessité, quand t’as 500 ressources à déployer.

Comment Pulumi marche vraiment

Sous le capot

Le modèle est simple :

1. Tu écris un programme dans un langage supporté (TypeScript, Python, Go, C#, Java, YAML)
2. pulumi up exécute le programme en local
3. Le moteur construit un graphe de dépendances entre les ressources
4. Il compare l’état désiré vs l’état actuel (stocké dans un backend : Pulumi Cloud, S3, etc.)
5. Il calcule un plan et te le montre
6. Tu valides, il exécute en appelant directement les APIs des providers

Pas de CloudFormation au milieu. Pas de couche de synthèse. Direct API calls, comme Terraform.

La limite des 500 ressources

CDK hérite de la limite CloudFormation : 500 ressources par stack. Pulumi n’a pas cette limite. Son moteur appelle les APIs directement.

Tu veux déployer 2000 ressources dans un seul stack ? Go for it. Y a pas de plafond.

Le multi-cloud natif

Le même programme peut faire ça :

1import * as aws from "@pulumi/aws";
2import * as azure from "@pulumi/azure-native";
3import * as cloudflare from "@pulumi/cloudflare";
4
5const vpc = new aws.ec2.Vpc("main", { cidrBlock: "10.0.0.0/16" });
6const db = new azure.sql.Database("analytics", { /* ... */ });
7const dns = new cloudflare.Record("app", { name: "app", type: "A" });

AWS, Azure, Cloudflare. En TypeScript. Dans le même fichier. Avec les types, l’autocomplete, et la vérification à la compilation.

Essaie de faire ça en HCL sans devenir fou.

Le vrai game changer : l’Automation API

C’est le truc que Terraform peut pas faire, structurellement.

L’Automation API expose le moteur Pulumi comme une bibliothèque. Tu peux appeler pulumi up depuis n’importe quel programme. Pas en shelling out un CLI. Pas en parsant du stdout.

import { LocalWorkspace } from "@pulumi/pulumi/automation";

const stack = await LocalWorkspace.createOrSelectStack({
  stackName: "dev",
  projectName: "my-infra",
  program: async () => {
    const bucket = new aws.s3.Bucket("data");
    return { bucketName: bucket.bucket };
  },
});

const result = await stack.up();
console.log(result.outputs.bucketName.value);

Tu peux builder :

• Un portail self-service où les devs cliquent “créer un environnement” et Pulumi provisionne
• Un CI/CD où les PRs génèrent des previews en temps réel
• Un produit SaaS qui provisionne de l’infra pour ses clients, par API

Les outils DSL-based peuvent pas faire ça. C’est pas une question de fonctionnalité manquante. C’est une impossibilité architecturale.

Le malus : quand Pulumi devient un problème

Je vais pas te vendre du rêve. Pulumi a des vrais problèmes.

L’écosystème

Terraform a 3000+ providers. Pulumi en a 100+. Moins de modules. Moins de réponses Stack Overflow. Moins d’exemples.

Si tu bosses sur un provider obscur (un CRM random, un SaaS niche), t’as de bonnes chances que le provider Pulumi soit inexistant ou mal maintenu.

La discipline

Le pire ennemi de Pulumi, c’est le développeur qui abuse.

Avec Terraform, t’es limité par le langage. Tu peux pas faire n’importe quoi. Avec Pulumi, tu peux. Appels API dans la définition d’infra. Side effects. Async bugs. Génériques TypeScript obscurs. Helpers qui cachent des comportements.

Si ton équipe a pas de discipline de code review, Pulumi devient un enfer.

Le vendor lock

Pulumi Cloud est excellent. Mais c’est le chemin naturel. Le self-hosted (backend S3) existe, mais tu perds : le run history, le policy as code intégré, la gestion de secrets, les webhooks.

Tu commences gratos. Tu finis à $85/user/mois.

C’est pas cher pour ce que c’est. Mais c’est un lock-in à connaître.

Le tableau de bord 2026

Le benchmark de déploiement (DevToolReviews, Sanj 2026) :

• Terraform : plans les plus prévisibles, meilleur pour review multi-cloud
• Pulumi : itération la plus rapide pour les équipes dev (mêmes langages, mêmes outils)
• CDK : plus rapide à écrire pour AWS pur (L2/L3 constructs), mais CloudFormation ralentit le déploiement réel

La question des agents IA

En 2026, les coding agents écrivent de plus en plus d’infrastructure.

Pulumi Neo est un agent spécialisé infra qui comprend ton contexte d’organisation, respecte tes policies, et exécute des tâches de provisionnement de bout en bout. Aiden for Infrastructure fait la même chose pour Terraform.

Mais y a un avantage décisif pour Pulumi : les agents IA sont meilleurs en TypeScript qu’en HCL. C’est une question de volume d’entraînement. Y a 500 fois plus de code TypeScript que de code HCL dans les datasets d’entraînement.

Si l’avenir de l’IaC c’est “l’agent écrit, l’humain review”, avoir un langage standard plutôt qu’un DSL est un avantage structurel.

Les questions qui restent

1. HCL c’est vraiment si pire ? L’argument de Terraform — “HCL est lisible et prévisible, même par des ops qui codent pas” — tient toujours. La lisibilité d’un main.tf est supérieure à celle d’un programme TS avec des génériques. Faut choisir son public.

2. L’A/B testing est-il un vrai besoin ou un luxe ? Avec Pulumi, le test unitaire d’infra coûte zéro. Avec Terraform, c’est tellement chiant que personne ne le fait. Tu veux tester ton infra ou pas ?

3. Pulumi Cloud est-il un lock-in acceptable ? Oui, si la valeur est là. Non, si t’es dans un environnement air-gapped ou que tu veux tout self-hosté.

4. Les agents IA changent-ils la donne ? Oui. Pulumi Neo + TypeScript, c’est probablement le futur. Mais on est en 2026, les agents hallucinent encore.

5. Quand fuir Pulumi ? Équipe ops-heavy sans background dev. Besoin de 3000+ providers. Environnement régulé où l’audit préfère des fichiers HCL qu’un humain peut lire sans exécuter.

Mot de la fin

Pulumi a raison sur le principe : l’infrastructure devrait être du vrai code, pas un DSL.

Les tests, les types, l’A/B testing, les abstractions, le partage via package managers, l’Automation API — tout ça, c’est pas du luxe. C’est ce qui arrive quand on traite l’infrastructure comme du logiciel, pas comme de la config.

Mais le prix à payer, c’est la discipline. Un code d’infrastructure trop clever, c’est pire que du HCL moche.

La question, c’est pas “Pulumi ou Terraform ?”. C’est “est-ce que ton équipe est prête à traiter l’infrastructure comme du logiciel ?”

Si oui, Pulumi est un bond en avant. Si non, Terraform te protégera de toi-même.

See ya space-cowboy.

Prompt pour générer l’image de l’article

Create a split-comparison banner image for a tech article titled "Infrastructure As Actual Code" vs "Infrastructure As Config".
Left side (Terraform/HCL): a tangled, gray, bureaucratic mess of paperwork, YAML files, and configuration documents
stacked in messy piles. Text "HCL / DSL" in faded bureaucratic font. Muted grays and browns.
Right side (Pulumi): clean, modern IDE with TypeScript code, glowing syntax highlighting in blue and green,
showing clean loops, classes, and test assertions. A Terminal at the bottom shows "pulumi up" running.
Text "Pulumi / Actual Code" in vibrant tech font. Bright modern colors (blue #0066ff, green #00cc88).
In the center: a gate/portal transition where the gray mess transforms into clean code.
Background: dark mode (#0d1117). No logos. 16:9 ratio, blog header style.