Quel outil d'Infrastructure as Code pour quel problème ?
Une antisèche pour décider vite. Le critère n'est pas l'outil le plus puissant, mais ce que tu déclares : de l'infra multi-cloud, de la configuration post-provisioning, ou un lock-in assumé avec un vendeur.
Pars de Terraform : le plus grand écosystème de providers, indépendant du cloud. Ansible en complément pour la configuration post-provisioning. Pulumi si l'équipe préfère un vrai langage de programmation. CloudFormation seulement si tu es 100% AWS.
Terraform / provisioning déclaratif
Le défaut. Multi-cloud, énorme écosystème.
Choisir si : provisioning d'infra multi-cloud, état versionné, écosystème de providers le plus large.
Éviter si : besoin de logique impérative complexe — HCL reste limité face à un vrai langage.
Pulumi / IaC en langage général
L'infra dans ton langage préféré.
Choisir si : équipe qui préfère TypeScript/Python/Go à un DSL, logique conditionnelle riche, tests unitaires sur l'infra.
Éviter si : équipe déjà à l'aise avec HCL sans besoin de logique complexe — Terraform reste plus simple à lire.
Ansible / gestion de configuration
Provisionner, c'est bien. Configurer, c'est après.
Choisir si : configuration post-provisioning (paquets, services, fichiers), pas d'agent à installer, procédural par nature.
Éviter si : provisioning d'infra cloud à l'état déclaré durablement — pas de state file, moins adapté que Terraform.
CloudFormation / IaC natif AWS
Le choix natif si tu es 100% AWS.
Choisir si : stack 100% AWS, intégration profonde avec les services AWS (rollback natif, StackSets).
Éviter si : multi-cloud — lock-in total avec AWS.
Crossplane / IaC via Kubernetes
L'infra comme une ressource Kubernetes.
Choisir si : déjà sur Kubernetes, veux gérer l'infra cloud avec les mêmes CRDs/GitOps que les workloads.
Éviter si : pas d'infra Kubernetes existante — installer un cluster juste pour ça n'a pas de sens.