Terraform vs Pulumi vs Crossplane : duel IaC 2026

Présentation des Outils IaC

Terraform

Terraform (site officiel : terraform.io) est un moteur déclaratif destiné à provisionner et versionner l'infrastructure. Il s'appuie sur HCL (HashiCorp Configuration Language) et un vaste écosystème de providers pour AWS, Azure, GCP et bien d'autres.

• Approche déclarative (HCL)
• Écosystème mature de modules (Registry)
• Bon pour l'infrastructure « infrastructure-first » et les environnements multi-cloud

Commandes usuelles :

terraform init
terraform validate
terraform plan
terraform apply

Exemple HCL basique (VPC + tag) :

provider "aws" {
  region = "us-west-2"
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags = {
    Name = "example-vpc"
  }
}

Pulumi

Pulumi (pulumi.com) permet d'écrire l'infrastructure en tant que code en utilisant des langages généralistes (TypeScript/JavaScript, Python, Go, .NET). Idéal pour les équipes développeurs qui veulent réutiliser des bibliothèques, des patterns de test et des outils de CI/CD familiers.

• Langages natifs : TypeScript/JS, Python, Go, .NET
• Possibilité d'utiliser code, tests unitaires et packages NPM/PyPI
• Bon pour la logique d'infrastructure dynamique

Exemple TypeScript simple (S3 bucket) :

const pulumi = require("@pulumi/pulumi");
const aws = require("@pulumi/aws");

const bucket = new aws.s3.Bucket("my-bucket", {
  acl: "private",
  tags: {
    environment: "dev"
  }
});

module.exports = { bucketName: bucket.id };

Crossplane

Crossplane (crossplane.io) s'intègre à Kubernetes et expose les ressources cloud via des API Kubernetes. Il est conçu pour des workflows GitOps et pour déléguer la gestion d'infrastructure aux équipes plateformes via des Compositions et des Claims.

• Modèle Kubernetes (CRDs, Composition)
• Adapté aux clusters Kubernetes et GitOps (ArgoCD, Flux)
• Permet de définir des abstractions (Compositions) réutilisables

Exemple simple de claim Postgres :

apiVersion: database.crossplane.io/v1alpha1
kind: PostgresInstance
metadata:
  name: my-postgres
spec:
  classRef:
    name: my-postgres-class

Intégration et Écosystème

Tous les outils s'intègrent dans des pipelines CI/CD classiques (GitHub Actions, GitLab CI, Jenkins, etc.). Quelques points pratiques :

• Terraform : modules partagés via Terraform Registry, bonnes intégrations avec Terraform Cloud/Enterprise (policies, state management).
• Pulumi : s'intègre naturellement aux tests unitaires (Jest/Mocha pour TypeScript), aux packages NPM et aux workflows d'intégration continue (ex. : npm ci, pulumi up --yes).
• Crossplane : se pilote via kubectl / GitOps ; s'intègre avec ArgoCD/Flux pour synchronisation et observabilité.

Exemple d'intégration CI (pipeline minimal pour Terraform) :

#!/bin/bash
set -euo pipefail

# Install Terraform (CI image)
terraform init
terraform validate
terraform plan -out=tfplan
# Optionnel : terraform show -json tfplan > tfplan.json
# Approval step then : terraform apply tfplan

Coûts & Licences

Le coût total d'utilisation d'un outil IaC dépend de plusieurs facteurs : licence, offres SaaS, consommation CI, stockage d'état et coûts opérationnels.

• Terraform : le cœur open-source est utilisable gratuitement ; HashiCorp propose Terraform Cloud / Enterprise (offres freemium et payantes) pour le state management, le policy-as-code et la collaboration. Considérez les coûts associés au stockage d'état chiffré (S3 + KMS) et aux workspaces partagés.
• Pulumi : projet open-source (licence Apache 2.0) avec une offre cloud commerciale. Les coûts à prévoir : exécution du runtime dans vos runners CI, stockage de stack state (si vous utilisez le service Pulumi), licences d'entreprise si vous optez pour Pulumi Cloud Pro.
• Crossplane : distribué sous licence Apache 2.0, Crossplane s'exécute dans Kubernetes. Les coûts opérationnels proviennent des ressources Kubernetes (CPU/mémoire pour controllers), du stockage et des opérateurs nécessaires pour les providers cloud.

Dans notre pratique, nous avons vu des projets où le passage à Pulumi augmentait légèrement l'empreinte CI (builds TypeScript + tests), mais réduisait le temps d'onboarding des développeurs grâce au code réutilisable. Pesez coût d'exécution vs productivité des équipes.

Communauté & Ressources

La maturité de la communauté influence la disponibilité des modules, la vitesse de résolution des bugs et la richesse des tutoriels :

• Terraform : communauté la plus large et Registry riche en modules réutilisables, abondance d'exemples et de formations.
• Pulumi : communauté en croissance rapide, bon support pour les langages modernes et exemples axés développeurs (SDK, tests). Outils comme tf2pulumi facilitent certaines migrations depuis Terraform.
• Crossplane : communauté plus spécialisée autour du modèle Kubernetes/GitOps ; excellente documentation sur Compositions et patterns plateforme pour équipes SRE/Platform Eng.

Ressources conseillées : pages officielles des projets (liens fournis dans l'introduction) et les dépôts GitHub root des projets pour les issues et PR (consulter les racines de projet publique).

Cas d'Usage Avancés

Terraform — conformité et politique (ex : policy-as-code)

Cas d'usage : automatiser la conformité et faire respecter des règles (naming, chiffrement, tags obligatoires). Dans un contexte CI, combinez terraform validate, des scanners IaC (tfsec, Checkov) et les politiques de la plateforme (ex. HashiCorp Sentinel ou Open Policy Agent) pour bloquer les déploiements non conformes.

• Outils recommandés : tfsec, Checkov, OPA
• Pratique : tests d'intégration du module dans un environnement isolé avec des comptes AWS/GCP de pré-prod

Dans notre pratique, nous avons souvent constaté que l'ajout d'un run de tfsec dans la pipeline réduit nettement les régressions de sécurité avant déploiement.

Pulumi — tests unitaires et intégration continue

Cas d'usage : intégrer des tests unitaires et mocks dans la même base de code. Avec Pulumi vous pouvez :

• Écrire des tests unitaires (Jest/Mocha pour TypeScript, pytest pour Python) qui valident la programmation de ressources.
• Mocker les providers Pulumi pour exécuter des tests rapides sans toucher l'API cloud.

Exemple de test TypeScript complet (Jest + Pulumi mocks). Placez pulumi.runtime.setMocks avant d'importer le programme Pulumi afin d'éviter des appels réseau pendant les tests :

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

// Provide lightweight mocks for unit tests
pulumi.runtime.setMocks({
  newResource: (args: any) => {
    return {
      id: args.name + "-id",
      state: args.inputs,
    };
  },
  call: (args: any) => args.inputs,
});

// Import the Pulumi program after mocks are set
let bucket: aws.s3.Bucket;
beforeAll(async () => {
  const program = await import("../index"); // adapt path to your Pulumi program
  bucket = program.bucket as aws.s3.Bucket;
});

describe("S3 bucket unit tests", () => {
  test("bucket has private ACL", async () => {
    const acl = await bucket.acl;
    expect(acl).toBe("private");
  });
});

Ce test est autonome : les mocks retournent des IDs et états simulés, ce qui permet des assertions rapides dans CI sans frais cloud. Adaptez les imports selon votre structure de projet (ESM/ CommonJS).

Crossplane — hybrid clusters et abstractions plateforme

Cas d'usage : gérer des clusters hybrides et exposer des abstractions plateforme (ex. PostgresInstance, RedisCluster) que les équipes applicatives réclament via des Claims. Avec Crossplane, les équipes plateformes conçoivent des Compositions contenant plusieurs ressources cloud et contrôlent les classes (classRef) disponibles pour les développeurs.

Exemple Composition (schéma simplifié) :

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: composite-postgres-standard
spec:
  compositeTypeRef:
    apiVersion: database.example.org/v1alpha1
    kind: CompositePostgres
  resources:
    - name: storage
      base:
        apiVersion: database.aws.crossplane.io/v1alpha1
        kind: RDSInstance
      patches: []

Stratégies de migration

La migration d'un outil IaC vers un autre doit être planifiée en étapes reproductibles. Voici une stratégie pragmatique appliquée dans plusieurs projets :

1. Inventaire : exportez l'état actuel et dressez la liste des ressources critiques (RDS, VPC, IAM, S3).
2. Priorisation : identifiez un périmètre réduit pour un prototype (1 VPC + 1 DB + 1 app) afin de mesurer le temps d'effort.
3. Méthode de migration : choisir entre « rewrite » (ré-écrire les définitions dans le langage cible) ou « import & adapt » (utiliser outils de conversion pour accélérer la migration).
4. Automatisation des tests : créez des tests unitaires/mocks (Pulumi) ou des tests d'intégration (Terraform) pour valider le comportement post-migration.
5. Cutover progressif : importer/dual-run sur un scope non critique, vérifier la parité, puis basculer progressivement.

Exemples pratiques :

Migration Terraform → Pulumi : utiliser tf2pulumi pour générer un squelette TypeScript/Go à partir d'un HCL existant, puis nettoyer et intégrer au CI. Exemple de mapping manuel :

resource "aws_s3_bucket" "b" {
  bucket = "my-bucket"
  acl    = "private"
}

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

const bucket = new aws.s3.Bucket("b", {
  bucket: "my-bucket",
  acl: "private",
});

Migration Terraform → Crossplane : plus conceptuelle — on passe d'une gestion centralisée à un modèle Kubernetes-driven. Stratégie : identifier les abstractions (ex. DatabaseClaim) puis créer des Compositions Crossplane qui provisionnent les ressources équivalentes. Testez via des environnements Kubernetes de staging et vérifiez les ConnectionSecrets et RBAC.

Dans notre pratique, le facteur clé de succès est la répétabilité : script d'import, tests automatisés et plan de rollback clair dans la première semaine de migration.

Bonnes Pratiques & Sécurité

• Gestion des secrets : ne stockez jamais secrets en clair dans le code. Utilisez des secrets managers (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) ou les mécanismes de secret de Kubernetes pour Crossplane.
• Validation & Scanning : intégrez tfsec, Checkov, Terrascan pour Terraform ; pour Pulumi, exécutez des scanners sur le code produit (SAST) et des tests unitaires; pour Crossplane, validez les Compositions et utilisez admission controllers pour vérifier les objects avant acceptation.
• Least privilege : appliquez des rôles IAM minimaux pour les comptes utilisés par vos runners CI/CD et pour les controllers Crossplane.
• State management : chiffrez les backends d'état (S3 + KMS, Terraform Cloud) et contrôlez l'accès en lecture/écriture.

Dépannage courant :

• Terraform plan montre des changements inattendus → exécutez terraform refresh et vérifiez les fournisseurs et versions.
• Pulumi échoue avec erreurs de type → vérifiez la version du SDK (@pulumi/pulumi) et que les dépendances NPM/PyPI sont verrouillées dans le pipeline.
• Crossplane ne provisionne pas → inspectez les events du controller et les secrets (credentials) : kubectl -n crossplane-system logs et vérifiez les ConnectionSecrets.

Benchmarks & Sources

Les performances et économies dépendent fortement du contexte (taille de l'infrastructure, fréquence de déploiement, workflows CI). Pour des retours d'expérience et études de cas, consultez les pages officielles et études éditeurs :

• Terraform (HashiCorp) — documentation, cas d'usage et Terraform Cloud.
• Pulumi — tutoriels, études de cas et guides de tests.
• Crossplane — guides sur Compositions et GitOps.

Remarque : évitez d'appliquer des chiffres génériques sans reproduire les tests dans votre contexte. Pour obtenir des métriques fiables, reproduisez des scénarios (provisionnement, scale-out, modifications fréquentes) avec vos comptes cloud, vos modules et vos runners CI.

Cas d'Utilisation et Scénarios

Exemples concrets

Quelques scénarios pragmatiques pour orienter votre choix :

• Infrastructures classiques (réseaux, VMs, DB) avec modules partagés → Terraform (HCL) est souvent le choix le plus pragmatique.
• Équipes développeurs souhaitant utiliser un langage familier, intégrer des tests unitaires et des packages → Pulumi est adapté.
• Organisation centrée sur Kubernetes et GitOps, souhaitant exposer des abstractions plateforme aux développeurs → Crossplane est pertinent.

Commandes exemples pour Crossplane (déployer claim + application) :

kubectl apply -f example-postgres-claim.yaml
kubectl apply -f app_deployment.yaml

Architecture & Choix (diagramme)

Conclusion

Le choix entre Terraform, Pulumi et Crossplane dépend de vos priorités : maturité et modules réutilisables (Terraform), intégration développeur et tests (Pulumi), ou modèle Kubernetes/GitOps et abstractions plateforme (Crossplane). Ma recommandation pratique : prototyper rapidement un cas d'usage critique avec chaque outil (petit projet) et mesurer l'effort d'intégration, la couverture sécurité et le coût d'exploitation pour votre contexte.

Ressources officielles pour approfondir : Terraform, Pulumi, Crossplane. Commencez par des prototypes, automatisez les scans et verrouillez les secrets avant de passer à la production.