Terraform vs Pulumi : lisibilité, tests et adéquation à l'équipe

Ce que les gens entendent vraiment par « Terraform vs Pulumi »

Quand on parle de Terraform vs Pulumi, il ne s'agit généralement pas de débattre qui a le plus de providers ou les fonctionnalités les plus cool. La vraie question pratique est : qu'est‑ce qui sera plus facile à vivre chaque semaine quand on crée, modifie et dépanne l'infrastructure ?

Au quotidien, l'infrastructure en tant que code signifie que votre configuration cloud est écrite de façon répétable. Un changement est un changement de code. Une revue a lieu avant toute exécution. Ensuite, un outil montre un plan de ce qui va changer, et vous appliquez avec un historique clair de qui a fait quoi et pourquoi.

C'est pour ça que la lisibilité et la prévisibilité comptent plus qu'une longue liste de fonctionnalités. La plupart des équipes ne plantent pas parce qu'un outil ne peut pas créer une ressource. Elles ont du mal parce que les gens ne comprennent pas rapidement ce qu'un changement fera, ou elles ne font pas assez confiance à la sortie pour agir vite.

La douleur se manifeste souvent par des revues lentes et stressantes, un onboarding inégal, des environnements qui dérivent, et la peur constante qu'un changement casse la production.

Cette comparaison se concentre sur la façon dont chaque outil se lit dans de vraies revues, comment les équipes l'adoptent, comment les tests fonctionnent en pratique, et comment gérer les environnements sans créer lentement de la dérive de configuration.

Lisibilité et expérience de revue de code

La plupart des discussions Terraform vs Pulumi commencent par une question simple : votre équipe peut‑elle lire le changement et prédire ce qu'il fera ?

Terraform utilise HCL, conçu pour l'infrastructure. Pour du travail courant comme une VPC, des rôles IAM ou un service applicatif, les fichiers se lisent souvent comme un formulaire déclaratif : type de ressource, nom et paramètres clés. Les revues paraissent généralement cohérentes entre projets, même si des personnes différentes ont écrit le code.

Pulumi ressemble à du code applicatif normal parce que c'en est. Vous créez des ressources avec des fonctions et des objets, et vous pouvez utiliser librement des boucles, conditions et fonctions d'aide. Cela peut être très lisible pour des ingénieurs, surtout quand la logique d'infrastructure est complexe. Mais cela peut aussi masquer ce qui va se passer quand des valeurs sont construites dynamiquement.

Les variables et la réutilisation se ressentent différemment. Terraform vous pousse vers des inputs, des locals et des modules, donc les réviseurs se concentrent souvent sur quels inputs ont changé et quelle version de module a été utilisée. Pulumi favorise la réutilisation via les outils du langage : fonctions, classes, packages et bibliothèques partagées. Ça réduit la duplication, mais cela implique plus de lecture de code lors des revues.

Pour les non‑experts, les revues vont mieux quand l'équipe s'accorde sur quelques habitudes : garder les noms et tags prévisibles, préférer des expressions simples aux boucles astucieuses, mettre le « pourquoi » en courts commentaires près des réglages risqués (IAM, réseau, protections de suppression), garder des diffs petits, et toujours lire le plan/preview en même temps que le code.

Si vos réviseurs sont surtout ops et plateforme, la forme uniforme de Terraform aide. Si vos réviseurs sont majoritairement des ingénieurs logiciels, Pulumi peut sembler plus naturel, tant que le code reste lisible.

Adoption par l'équipe et courbe d'apprentissage

La vraie différence d'adoption entre Terraform et Pulumi n'est pas que syntaxique. C'est qui doit devenir suffisamment confiant pour relire les changements, les approuver et les supporter en cas de panne.

Terraform demande à la plupart d'apprendre un langage conçu pour un usage précis (HCL) et un petit ensemble de concepts IaC. C'est souvent plus simple pour les équipes ops, sécurité et plateforme parce que le code ressemble à de la configuration et paraît similaire d'un projet à l'autre.

Pulumi demande d'apprendre les concepts IaC plus un langage général (souvent TypeScript ou Python). Si votre équipe développe déjà dans ce langage, l'onboarding peut paraître plus rapide parce que boucles, fonctions et packages sont familiers. Sinon, la courbe d'apprentissage est réelle, surtout pour les collègues qui ne font que relire occasionnellement.

L'onboarding est plus simple quand les responsabilités sont claires. En pratique, les équipes se répartissent souvent en quelques rôles : auteurs (changements quotidiens), réviseurs (vérifient l'intention et le risque), approbateurs (sécurité et coût), et on‑call (débogage et notions d'état). Tout le monde n'a pas besoin du même niveau de profondeur, mais tous doivent partager un modèle mental commun de comment les changements sont proposés, prévisualisés et appliqués.

La cohérence empêche l'adoption de s'effondrer sur plusieurs repos. Choisissez un petit ensemble de conventions et imposez‑les tôt : structure des dossiers, nommage, tags, comment passer les inputs, séparation des environnements, et ce que « fini » signifie (formatage, linting et vérification du plan à chaque changement).

Pour des équipes mixtes, le choix le plus sûr est généralement celui qui maximise le confort des réviseurs. Si la moitié de l'équipe maîtrise TypeScript, Pulumi peut très bien fonctionner, mais seulement si vous standardisez les patterns et évitez le code « malin ». Si les réviseurs sont principalement non‑développeurs, la forme plus simple de Terraform l'emportera souvent.

Si les développeurs veulent Pulumi pour des composants réutilisables mais que les réviseurs sécurité ont du mal à le lire, commencez par un repo de templates partagé et des règles de revue strictes. Ça réduit les surprises pendant que l'équipe prend confiance.

État, secrets et confiance dans les changements

La plupart des arguments Terraform vs Pulumi reviennent à une peur : « Est‑ce que ce changement fera ce que je pense sans casser la prod ? » L'état, les secrets et les previews sont les endroits où cette confiance se gagne ou se perd.

Terraform suit la réalité via un fichier d'état. Il peut être local, mais les équipes le déplacent généralement vers un backend distant avec verrouillage. Si l'état manque, est obsolète, ou que deux personnes appliquent en même temps sans verrou, Terraform peut tenter de recréer ou supprimer des ressources existantes. Pulumi utilise aussi un état, mais il est stocké par stack. Beaucoup d'équipes apprécient que « stack = environment » soit explicite et que config et état restent liés.

Les secrets sont un autre point délicat. Dans Terraform, marquer une sortie comme sensitive aide, mais les secrets peuvent encore fuir via des variables, des logs ou l'état si on n'y prend pas garde. Pulumi traite les secrets comme des valeurs de première classe et les chiffre dans l'état de la stack, ce qui réduit les expositions accidentelles. Dans les deux outils, la règle la plus sûre est : l'état n'est pas un magasin de secrets, utilisez le secret manager de votre cloud quand c'est possible.

La confiance dans les changements vient du diff. Le plan de Terraform est largement compris et facile à standardiser en revue. Le preview de Pulumi est similaire, mais sa lisibilité dépend de la quantité de logique que vous mettez dans le code. Plus vous faites de programmation réelle, plus vous aurez besoin de conventions.

Pour la gouvernance, les équipes convergent souvent vers les mêmes exigences : état distant avec verrouillage et accès au moindre privilège, une étape de revue incluant le plan/preview, approbations manuelles pour la prod, et environnements séparés avec des identifiants distincts.

Schémas de réutilisation : modules vs components

Dans Terraform vs Pulumi, « réutilisabilité » signifie généralement : pouvez‑vous créer le même type de stack (VPC, base de données, Kubernetes, IAM) pour plusieurs équipes sans copier des dossiers et espérer que personne ne les modifie différemment ?

Le principal bloc de construction de Terraform est le module : un dossier de ressources avec des inputs et outputs. Les équipes publient souvent des modules « golden » (réseau, logging, base de données) et épinglent des versions pour que les upgrades soient un choix, pas une surprise. Ce versioning est simple et efficace. Vous pouvez déployer une nouvelle version module équipe par équipe.

Le bloc de construction de Pulumi est le composant (souvent empaqueté en bibliothèque). C'est du code qui crée plusieurs ressources comme une unité de plus haut niveau. La réutilisation est naturelle parce que vous utilisez les fonctionnalités du langage : fonctions, classes et types. Les composants peuvent être partagés en packages internes pour que les équipes obtiennent les mêmes valeurs par défaut et garde‑fous.

Une approche pratique pour plusieurs équipes est de tracer une ligne claire entre « plateforme » et « application ». Gardez un petit ensemble de blocs partagés possédés par un groupe plateforme (réseau, sécurité, clusters de base). Mettez des valeurs par défaut opiniâtres dans le bloc, et n'exposez que les quelques options dont les équipes ont réellement besoin. Ajoutez de la validation à la frontière (règles de nommage, tags requis, régions autorisées). Versionnez tout, et écrivez en clair ce qui a changé. Fournissez un ou deux exemples qui correspondent à des cas d'usage réels.

Pour éviter le copier‑coller, traitez chaque pattern répété comme un candidat module/composant. Si deux équipes ont besoin « d'une base Postgres avec backups et alarmes », ce devrait être une unité réutilisable avec un petit ensemble d'inputs (taille, rétention, owner), pas deux répertoires presque identiques.

Gérer les environnements sans dérive de configuration

La dérive commence souvent avec une bonne intention. Quelqu'un « bidouille » un security group dans la console cloud, ou corrige un paramètre en prod. Un mois plus tard, le code dit une chose et l'environnement réel une autre.

Terraform et Pulumi supportent l'idée d'une base de code unique et de plusieurs environnements, mais ils la modélisent différemment. Terraform utilise souvent les workspaces (ou des backends d'état séparés) pour représenter dev, staging et prod. Pulumi utilise des stacks, où chaque stack a sa config et son état. Dans la pratique, les résultats sont plus propres quand l'état de chaque environnement est clairement séparé et qu'on évite de partager un même fichier d'état entre environnements.

Le nommage des ressources compte plus qu'on ne le pense. Si les noms se chevauchent, vous obtenez des mises à jour confuses ou des déploiements échoués. Intégrez l'environnement dans les noms et tags pour qu'on voie clairement à quoi appartient chaque chose. Par exemple, api-dev, api-staging, api-prod, avec des labels constants comme env=prod.

Pour séparer comptes ou subscriptions tout en partageant le code, gardez la logique d'infrastructure au même endroit et ne changez que le compte cible et la config par environnement. Cela peut être un compte par environnement plus un job CI qui assume le bon rôle/identité avant d'appliquer les changements.

Les overrides par environnement doivent être petits et intentionnels. Visez une base commune avec une courte liste de différences : utilisez les mêmes modules/composants partout, n'overridez que la taille et les nombres (type d'instance, réplicas), gardez la config dans un fichier par environnement/stack, et évitez de parsemer des logiques du type « if env == prod » dans tout le code. Restreignez les modifications console et traitez les urgences comme des corrections à suivre par un changement de code.

Pas à pas : un workflow sûr pour les changements

Un workflow sûr ressemble presque au même pour Terraform et Pulumi. L'objectif est simple : chaque changement est prévisualisé, revu et appliqué de la même manière à chaque fois, en minimisant les surprises « ça marche sur ma machine ».

Un flux qui tient la route pour la plupart des équipes ressemble à ceci :

• Mettre à jour le code et lancer le formatage et des vérifications basiques.
• Générer un plan/preview (Terraform : plan, Pulumi : preview) et sauvegarder la sortie.
• Revoir le diff dans une pull request, en se concentrant sur les suppressions, les remplacements et les changements à fort impact.
• Appliquer depuis un endroit contrôlé (souvent le CI) en utilisant le commit revu.
• Vérifier avec un petit test de fumée et enregistrer ce qui a changé.

Où exécuter importe. Les runs locaux sont parfaits pour un feedback rapide, mais l'apply final doit être cohérent. Beaucoup d'équipes autorisent le preview/plan local, puis exigent que l'apply/up ne se fasse qu'en CI avec les mêmes variables d'environnement, la même source d'identifiants et des versions d'outil épinglées.

Le verrouillage de version est un sauveur discret. Épinglez la version de Terraform et des providers, ou épinglez votre CLI Pulumi et les dépendances de langage. Les fichiers de lock et contraintes de dépendances réduisent les diffs surprises.

Pour aider les nouveaux venus, gardez une page « comment on fait les changements ici » : les commandes du happy path, qui peut appliquer et depuis où, comment manipuler les secrets (jamais en clair), comment stopper un mauvais changement, et quoi faire si le preview montre une dérive inattendue.

Approches de test que les équipes utilisent réellement

La plupart des équipes ne font pas de « tests unitaires » pour l'infra comme pour le code applicatif. Pour l'IaC, le bon compromis est : vérifications rapides qui attrapent les erreurs évidentes, plus un petit ensemble de tests live qui prouvent qu'un changement fonctionne dans un vrai compte cloud.

Vérifications statiques (rapides)

Pour Terraform, le minimum est le formatage et la validation, puis des contrôles de sécurité et de politique qui échouent la build si quelque chose de risqué apparaît. C'est là que vous attrapez un security group ouvert, un bucket S3 sans chiffrement, ou des tags manquants.

Pour Pulumi, vous faites aussi du linting et des vérifications de types, mais vous pouvez aussi écrire de petits tests d'assertion contre la sortie du programme (par exemple, « chaque base de données doit avoir les backups activés »). Pulumi supporte des vérifications basées sur le preview, et vous pouvez utiliser des mocks pour simuler des ressources cloud afin de lancer des tests sans rien créer.

Ce que beaucoup d'équipes exécutent à chaque PR est similaire quel que soit l'outil : formatage et validation basiques, règles de sécurité statiques, checks de politique contre le changement planifié, un dry‑run preview/plan avec un résumé lisible, et une courte étape d'approbation pour les changements au‑delà d'un seuil de risque.

Preview et tests live (plus lents)

Les tests d'intégration signifient généralement créer un environnement temporaire, appliquer le changement, et vérifier quelques faits clés (le service est joignable, la base existe, les alarmes sont en place). Gardez‑les petits. Par exemple : après un changement sur un module de load balancer, créez une stack de test, confirmez que les health checks passent, puis détruisez‑la. Ça donne de la confiance sans transformer les tests IaC en un second travail à temps plein.

Dérive de configuration : détection, triage et prévention

La dérive commence souvent par une correction rapide dans la console : quelqu'un ouvre un security group, modifie une policy IAM, ajuste l'autoscaling, ou change un flag de base de données pour arrêter une alerte. Le système redevient stable, mais votre IaC ne reflète plus la réalité.

La détection de dérive fonctionne mieux comme une habitude, pas comme une mission de sauvetage. La plupart des équipes lancent un plan/preview en lecture seule de façon planifiée et après des incidents. Que vous utilisiez Terraform ou Pulumi importe moins que le fait que quelqu'un regarde réellement la sortie.

Quand la dérive apparaît, triez‑la avant de la corriger. Une partie de la dérive est du bruit inoffensif (champs gérés par le provider). Une autre partie est un risque réel (accès public ouvert « temporairement »). Une série de questions simples empêche le chaos : le changement était‑il intentionnel et approuvé, affecte‑t‑il la sécurité/coût/disponibilité, peut‑il être représenté proprement en IaC, est‑il urgent, et le corriger provoquera‑t‑il une interruption ?

Ignorer la dérive est acceptable seulement si elle est connue, à faible risque et documentée. Tout le reste doit soit être reverti dans le cloud pour revenir à l'IaC, soit être codifié dans l'IaC pour que le prochain apply ne supprime pas une correction importante.

Pour réduire le bruit, filtrez les diffs récurrents (timestamps calculés) et alertez seulement sur les ressources significatives. Les tags et labels aident à la propriété. Une petite convention suffit : owner, service, env, cost_center, et intent (pourquoi ceci existe).

Erreurs courantes et pièges

Le plus grand piège dans Terraform vs Pulumi n'est pas le langage. C'est le workflow. Les équipes se font avoir par des raccourcis qui semblent plus rapides aujourd'hui et coûtent des jours plus tard.

Traiter le plan comme optionnel est un mode d'échec classique. Si les gens sautent les previews et appliquent depuis leurs laptops, vous perdez une source de vérité partagée et une piste d'audit propre. Cela transforme aussi les mismatches de version d'outil et de credentials en risques réels pour la prod.

Un autre problème discret est de laisser les environnements dériver via des overrides ponctuels. Une adjustment rapide en staging, une correction manuelle en prod, un fichier de variables différent « juste cette fois », et bientôt vous ne pouvez plus expliquer pourquoi la prod se comporte différemment. Le changement suivant devient effrayant parce que vous ne faites plus confiance à l'effet.

L'utilisation excessive de code dynamique est un piège à la Pulumi, mais Terraform peut aussi y tomber avec des templating lourds. Quand tout est calculé à l'exécution, les revues deviennent de la devinette. Si un collègue ne peut pas prédire le diff en lisant le changement, le système est trop astucieux.

Le versioning des modules ou composants est aussi facile à négliger. Changer un module partagé en place peut casser silencieusement des consommateurs à travers des repos ou environnements.

La plupart des équipes évitent ces problèmes avec quelques garde‑fous : exécuter preview/plan en CI pour chaque changement et n'appliquer qu'en CI, garder les différences d'environnement explicites (stacks/workspaces séparés + inputs clairs), préférer un code ennuyeux lisible aux abstractions trop « clever », versionner les modules/composants partagés et upgrader intentionnellement, et verrouiller les modifications manuelles en console avec une règle « urgence puis codifier » claire.

Checklist rapide avant de choisir ou migrer

Choisir entre Terraform et Pulumi dépend moins du goût que de la capacité de votre équipe à faire des changements sûrs chaque semaine sans surprises. Avant de vous engager (ou de migrer), répondez par écrit à ces questions et assurez‑vous que les réponses correspondent à votre façon de travailler.

La checklist « peut‑on faire confiance aux changements ? »

• Peut‑on voir un aperçu clair des changements avant toute application, et les réviseurs comprennent‑ils assez cette sortie pour repérer les modifications à risque ?
• L'état est‑il protégé (contrôle d'accès, chiffrement si nécessaire), sauvegardé et géré par des mainteneurs capables de débloquer l'équipe ?
• Où vivent les secrets au quotidien, et peut‑on les faire tourner sans casser les déploiements ?
• Les environnements sont‑ils séparés par conception, avec des noms et limites clairs (par exemple, dev et staging ne peuvent pas toucher prod par erreur) ?
• Exécutons‑nous des vérifications de dérive régulièrement, et y a‑t‑il une personne nommée qui décide si la dérive doit être corrigée, acceptée ou escaladée ?

Si un item est « on verra plus tard », c'est un signal d'alerte. La plupart des douleurs IaC viennent d'un contrôle du changement faible : previews flous, environnements partagés, et personne responsable de la dérive.

Une façon pratique de tester votre choix est de prendre un workflow réel : « créer une nouvelle queue, la connecter à un service, et la déployer en staging puis en production. » Si vous pouvez le faire avec des revues confiantes et une histoire de rollback propre, vous êtes en bonne posture.

Scénario exemple et étapes concrètes suivantes

Une petite équipe (1–2 ingénieurs + un product owner) gère un portail client avec trois environnements : dev pour le travail quotidien, staging pour les vérifications de release, et prod pour les vrais utilisateurs. Ils ont besoin d'une base de données, de quelques services, de queues, de stockage et de monitoring. Les points douloureux sont prévisibles : revues lentes, gestion des secrets anxiogène, et « ça marchait en staging » qui se répète.

Avec Terraform, cette équipe finit souvent avec une structure de dossiers claire, quelques modules, et des workspaces ou fichiers d'état séparés par environnement. L'avantage est un large écosystème et de nombreux patterns établis. L'inconvénient est que la lisibilité peut souffrir quand la logique grossit, et que les tests restent souvent au niveau « vérification du plan + quelques smoke tests » à moins d'investir davantage.

Avec Pulumi, la même configuration devient du vrai code : boucles, fonctions et bibliothèques partagées. Les revues peuvent être plus simples quand les changements sont complexes, et les tests peuvent sembler plus naturels. L'échange est la capacité de l'équipe : vous gérez maintenant l'infrastructure avec un langage de programmation et il faut de la discipline pour rester simple.

Une règle de décision simple :

• Choisissez Terraform si votre équipe veut un outil standard, peu de code et beaucoup de patterns établis.
• Choisissez Pulumi si votre équipe travaille déjà quotidiennement dans un langage et veut plus de réutilisation et de testing.
• Si la tolérance au risque est faible, privilégiez l'option que vos réviseurs peuvent lire en confiance.

Étapes pratiques qui fonctionnent dans de vraies équipes : pilotez une tranche fine (un service + sa base) sur dev/staging/prod, rédigez des standards courts (nommage, séparation d'environnements, règles sur les secrets et ce qui doit être revu), ajoutez une barrière de sécurité (plan/preview en CI + un smoke test basique après apply), et étendez seulement quand la première tranche devient ennuyeuse et répétable.

Si vous construisez aussi des outils internes autour de ces workflows, AppMaster (appmaster.io) peut vous aider à créer la couche applicative (backend, web, mobile) plus vite, tout en gardant votre IaC concentré sur l'infrastructure que vous devez réellement gérer.