Ansible vs Terraform en 2026 : Infrastructure as Code et Questions d'Entretien DevOps

Ansible vs Terraform représente l'une des questions de comparaison les plus courantes lors des entretiens DevOps, mais cette formulation révèle souvent une incompréhension : ces outils résolvent des problèmes différents. Ansible 2.20 gère la gestion de configuration et le déploiement d'applications, tandis que Terraform 1.15 provisionne les ressources d'infrastructure. Comprendre quand chaque outil excelle, où ils se chevauchent et comment ils se complètent distingue les ingénieurs DevOps seniors de ceux qui apprennent encore les fondamentaux.

Déclaratif vs Procédural : La Différence Fondamentale

Terraform utilise une approche déclarative. Un fichier de configuration décrit l'état final souhaité, et Terraform calcule les changements nécessaires pour l'atteindre. Cette approche fonctionne bien pour l'infrastructure qui doit être créée, modifiée ou détruite comme une unité.

# main.tf
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
  
  tags = {
    Name        = "web-server"
    Environment = "production"
  }
}

resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow HTTP and HTTPS"
  
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

L'exécution de terraform apply crée les deux ressources si elles n'existent pas, ou les met à jour pour correspondre à la configuration. Exécuter la commande à nouveau sans changements ne produit aucune opération : Terraform compare la configuration à son fichier d'état et ne trouve rien à faire.

Ansible utilise une approche procédurale avec des tâches exécutées dans l'ordre. Bien que les modules Ansible soient souvent idempotents (les exécuter deux fois produit le même résultat), le playbook lui-même décrit une séquence d'actions plutôt qu'un état final.

# webserver.yml
- name: Configure web server
  hosts: webservers
  become: true
  
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true
    
    - name: Copy nginx configuration
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: Restart nginx
    
    - name: Ensure nginx is running
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true
  
  handlers:
    - name: Restart nginx
      ansible.builtin.service:
        name: nginx
        state: restarted

Chaque tâche s'exécute en séquence. Le pattern notify/handler offre un comportement déclaratif : le handler ne s'exécute qu'une seule fois à la fin, quel que soit le nombre de tâches qui le déclenchent.

Gestion de l'État : Un Sujet Critique en Entretien

Terraform maintient un fichier d'état qui mappe la configuration aux ressources réelles. Cet état suit les identifiants de ressources, les dépendances et les métadonnées. Sans lui, Terraform ne peut pas déterminer ce qui existe ou ce qui doit changer.

Ansible n'a pas de fichier d'état équivalent. Il se connecte aux systèmes cibles et exécute les tâches, en s'appuyant sur l'état actuel du système et l'idempotence des modules. Cela rend Ansible plus simple à démarrer mais plus difficile à suivre les changements dans le temps.

Une question d'entretien courante porte sur la sécurité du fichier d'état. L'état Terraform peut contenir des données sensibles : mots de passe de bases de données, clés API, identifiants de ressources. Les déploiements en production stockent l'état à distance (S3, Azure Blob, Terraform Cloud) avec chiffrement et contrôles d'accès.

# backend.tf
terraform {
  backend "s3" {
    bucket         = "company-terraform-state"
    key            = "prod/infrastructure.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

La table DynamoDB fournit le verrouillage, empêchant deux ingénieurs de modifier l'état simultanément.

Quand Utiliser Chaque Outil

Terraform excelle dans le provisioning d'infrastructure cloud : machines virtuelles, bases de données gérées, load balancers, rôles IAM, VPCs. Il gère automatiquement les dépendances entre ressources et supporte tous les principaux fournisseurs cloud via une syntaxe HCL cohérente.

Ansible excelle dans la configuration de systèmes existants : installation de paquets, gestion des utilisateurs, déploiement de code applicatif, orchestration de déploiements multi-étapes. Il se connecte via SSH (ou WinRM pour Windows) sans nécessiter d'agents sur les machines cibles.

La zone de chevauchement crée de la confusion. Les deux peuvent installer des logiciels sur une VM. Terraform peut utiliser des provisioners pour exécuter des scripts après la création de ressources. Ansible peut créer des ressources cloud via des modules comme amazon.aws.ec2_instance. Mais utiliser chaque outil en dehors de ses forces crée des problèmes de maintenabilité.

Le Workflow Combiné en Production

La plupart des organisations utilisent les deux outils ensemble. Terraform provisionne l'infrastructure et expose les détails de connexion. Ansible consomme ces outputs pour configurer les systèmes.

# outputs.tf
output "web_server_ips" {
  value       = aws_instance.web[*].private_ip
  description = "Private IPs of web servers"
}

output "db_endpoint" {
  value       = aws_rds_instance.main.endpoint
  description = "RDS endpoint for application config"
}

Un pipeline CI/CD exécute Terraform en premier, capture les outputs, génère un inventaire Ansible dynamiquement, puis exécute les playbooks sur la nouvelle infrastructure.

# ansible/inventory/aws_ec2.yml
plugin: amazon.aws.aws_ec2
regions:
  - us-east-1
filters:
  tag:Environment: production
  instance-state-name: running
hostnames:
  - private-ip-address
groups:
  webservers: "'web' in tags.Role"
  databases: "'db' in tags.Role"

Cet inventaire dynamique interroge AWS directement, regroupant les instances par leurs tags. Aucune gestion manuelle d'IP requise.

OpenTofu : Le Fork Qui a Changé le Paysage

HashiCorp a changé la licence de Terraform pour la Business Source License (BSL) en août 2023. La communauté a répondu en forkant Terraform 1.5 en OpenTofu, maintenant hébergé sous la Linux Foundation.

En août 2026, OpenTofu 1.11.6 reste un remplacement direct pour la plupart des workflows Terraform. La même syntaxe HCL, le même écosystème de providers, le même format d'état. OpenTofu a ajouté des fonctionnalités absentes du binaire open-source de Terraform : chiffrement de l'état, for_each pour les providers, et évaluation anticipée des variables.

Pour la préparation aux entretiens, comprendre la distinction de licence est essentiel. La BSL permet l'utilisation interne mais restreint la création de produits concurrents. Les organisations préoccupées par le verrouillage fournisseur ou avec des exigences de conformité spécifiques peuvent préférer la licence MPL 2.0 d'OpenTofu. L'acquisition d'HashiCorp par IBM en décembre 2024 a ajouté une variable supplémentaire aux discussions sur les relations fournisseurs.

Questions d'Entretien DevOps Courantes

Q : Ansible peut-il remplacer Terraform ?

Pas efficacement. Ansible peut créer des ressources cloud, mais il manque de gestion d'état. Exécuter le même playbook deux fois pourrait créer des ressources en double. Le fichier d'état de Terraform suit ce qui existe et calcule les changements minimaux. Utiliser Ansible pour ce qu'il fait le mieux : la gestion de configuration.

Q : Comment gérer les secrets dans Terraform ?

Ne jamais commiter de secrets dans le contrôle de version. Utiliser des variables d'environnement, l'intégration Vault, ou les gestionnaires de secrets des fournisseurs cloud. Marquer les variables comme sensibles pour éviter qu'elles apparaissent dans les logs :

# variables.tf
variable "db_password" {
  type        = string
  sensitive   = true
  description = "Database password from Vault or environment"
}

Q : Qu'est-ce que l'idempotence Ansible ?

Une opération idempotente produit le même résultat qu'elle soit exécutée une ou plusieurs fois. Le module apt avec state: present installe un paquet s'il manque et ne fait rien s'il est déjà installé. Écrire des playbooks idempotents empêche les changements non intentionnels lors des exécutions suivantes.

Q : Comment tester le code d'infrastructure ?

Terraform : terraform validate vérifie la syntaxe, terraform plan prévisualise les changements, et des outils comme Terratest exécutent des tests d'intégration. Ansible : ansible-lint détecte les problèmes, le mode --check effectue des dry runs, et Molecule teste les rôles contre des conteneurs.

Pour une préparation plus approfondie aux entretiens Terraform, consulter Terraform Interview Questions: Infrastructure as Code Complete Guide. Pratiquer avec les modules Terraform Basics et Ansible Configuration Management.

Compatibilité des Versions et Écosystème

Versions stables actuelles en août 2026 :

L'architecture de collections d'Ansible sépare les fonctionnalités de base des modules spécifiques aux fournisseurs. La collection amazon.aws reçoit des mises à jour indépendamment du core Ansible. C'est important pour le verrouillage de versions dans les pipelines CI/CD.

Le versioning des providers Terraform suit des principes similaires. Les fichiers de verrouillage (terraform.lock.hcl) assurent des versions de providers cohérentes entre les membres de l'équipe et les systèmes CI.

# versions.tf
terraform {
  required_version = ">= 1.15.0"
  
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.60"
    }
  }
}

Choisir Entre Eux : Un Cadre de Décision

La question est rarement Ansible ou Terraform. La question est quel outil gère quelle responsabilité.

Pour une vision complète de comment ces outils s'intègrent dans les workflows de déploiement modernes, consulter CI/CD Pipeline Interview Questions.

Ce Que Les Ingénieurs Seniors Doivent Savoir sur Ansible et Terraform

• Terraform gère l'état de l'infrastructure de manière déclarative ; Ansible configure les systèmes de manière procédurale. Utiliser les deux ensemble produit une infrastructure maintenable.
• La sécurité du fichier d'état est importante. Stocker l'état Terraform à distance avec chiffrement et verrouillage activés.
• OpenTofu fournit une alternative sous licence MPL à Terraform avec des fonctionnalités supplémentaires. La migration est simple pour la plupart des workflows.
• L'idempotence n'est pas automatique. Écrire des playbooks qui produisent des résultats cohérents lors d'exécutions répétées.
• L'inventaire dynamique élimine la gestion manuelle des hôtes. Interroger les fournisseurs cloud directement pour l'infrastructure actuelle.
• Le verrouillage de version prévient les surprises. Verrouiller les versions des providers dans Terraform ; épingler les versions des collections dans Ansible.
• Tester le code d'infrastructure nécessite des approches différentes : terraform plan pour prévisualiser les changements, mode --check pour les dry runs Ansible, frameworks de tests d'intégration pour les deux.