Aller au contenu
Infrastructure as Code medium
🔐 Alerte sécurité — Incident supply chain Trivy : lire mon analyse de l'attaque

Déclaratif vs impératif en Infrastructure as Code

8 min de lecture

En Infrastructure as Code, une approche déclarative décrit l’état attendu, tandis qu’une approche impérative décrit la suite d’actions à exécuter. Cette différence paraît théorique au début, mais elle change directement votre manière de corriger une erreur, de relancer une automatisation et de maintenir un projet dans le temps.

Comprendre cette opposition aide à éviter un mauvais cadrage. On attend souvent d’un outil impératif le comportement d’un moteur déclaratif, ou l’inverse. C’est là que naissent beaucoup de malentendus sur Terraform, Ansible et les autres outils d’automatisation.

  • expliquer clairement la différence entre déclaratif et impératif ;
  • identifier les avantages et les limites de chaque approche ;
  • mieux comprendre pourquoi les outils IaC ne se comportent pas tous de la même façon.
ApprocheQuestion centraleExemple mental
Déclarative”Quel état final je veux ?""Je veux une VM avec 2 vCPU et 4 Go de RAM”
Impérative”Quelles étapes faut-il exécuter ?""Créer la VM, installer les paquets, modifier le fichier, redémarrer le service”

Dans une logique déclarative, l’outil calcule lui-même comment atteindre l’état décrit. Dans une logique impérative, vous pilotez davantage la séquence d’actions.

Le raccourci mental le plus utile ressemble à ceci :

Comparaison entre logique declarative et logique imperative

Imaginons que vous vouliez mettre en ligne une application web interne.

  • En approche déclarative, vous exprimez surtout l’état cible : une VM doit exister, un réseau doit l’exposer correctement, un DNS doit pointer vers elle, et certaines caractéristiques doivent être respectées.
  • En approche impérative, vous décrivez davantage les étapes : créer la machine, installer le serveur web, déposer le fichier de configuration, ouvrir le port puis redémarrer le service.

Le besoin métier est identique. Ce qui change, c’est la manière dont vous pensez le changement et dont l’outil l’exécute.

Cette distinction a des conséquences très concrètes :

  • sur la reproductibilité ;
  • sur la capacité à détecter la dérive ;
  • sur la façon de relancer un traitement après échec ;
  • sur la manière de lire le code et d’anticiper ses effets.

Une approche déclarative est souvent plus adaptée pour modéliser une infrastructure durable. Une approche impérative est souvent plus naturelle pour décrire une séquence de configuration ou une orchestration opérationnelle.

La différence se voit particulièrement quand vous relancez votre automatisation.

  • Avec une logique déclarative, vous attendez surtout que le moteur compare le réel à l’état attendu puis calcule l’écart.
  • Avec une logique impérative, vous attendez plutôt qu’il rejoue une suite d’actions en espérant qu’elles soient écrites de manière robuste et idempotente.

Pour un débutant, c’est souvent là que le déclic se produit : le déclaratif aide à raisonner en termes de résultat final, l’impératif aide à raisonner en termes de procédure.

Forces :

  • excellent pour exprimer un état cible ;
  • meilleur alignement avec la notion de plan et de diff ;
  • plus adapté aux ressources persistantes ;
  • facilite la reproductibilité.

Limites :

  • demande souvent de comprendre la notion de state ;
  • peut sembler moins intuitive quand il faut raisonner sur le moteur interne ;
  • n’élimine pas les cas limites de dépendances, d’import ou de dérive.

Forces :

  • intuitif pour décrire des suites d’actions ;
  • très utile pour configurer des systèmes ;
  • permet un contrôle fin sur l’ordre et la logique d’exécution.

Limites :

  • plus exposé aux écarts entre machines si l’idempotence est mal pensée ;
  • plus difficile à relancer proprement si les étapes ne sont pas robustes ;
  • moins adapté pour décrire un état cible global complexe.
SituationApproche souvent la plus naturellePourquoi
Décrire une topologie réseau, des VM et des services managésDéclarativeVous voulez surtout exprimer ce qui doit exister
Installer des paquets, déposer des fichiers et gérer des servicesImpérative ou procéduraleVous pilotez une suite d’actions sur des systèmes
Revoir un changement avant exécutionDéclarativeLa comparaison avec l’état cible est centrale
Exécuter une procédure d’administration cibléeImpérativeL’ordre des étapes compte explicitement

Ce tableau ne dit pas qu’une approche est toujours meilleure. Il aide à voir pourquoi certains outils semblent plus naturels selon le périmètre.

  • Terraform est majoritairement déclaratif ;
  • CloudFormation l’est aussi ;
  • Ansible mêle beaucoup d’éléments déclaratifs dans ses modules, mais sa lecture opérationnelle reste souvent plus proche d’une logique impérative ou procédurale ;
  • scripts shell et procédures manuelles sont clairement du côté impératif.

L’idée n’est pas d’opposer ces outils moralement. Il faut surtout comprendre ce que chaque approche rend plus facile ou plus fragile.

Deux erreurs reviennent sans cesse.

  • attendre d’un outil impératif qu’il fournisse une vision globale de l’état cible sans effort de structuration ;
  • attendre d’un outil déclaratif qu’il gère naturellement toutes les opérations fines à l’intérieur d’un système.

Dans les deux cas, la déception vient d’une mauvaise attente sur le modèle d’exécution, pas forcément d’un mauvais outil.

  • Déclaratif = décrire l’état attendu ; impératif = décrire la séquence d’actions.
  • Les outils IaC ne se distinguent pas seulement par leur syntaxe, mais par leur modèle d’exécution.
  • Le déclaratif aide beaucoup pour le provisionnement et la notion d’état cible.
  • L’impératif reste très utile pour la configuration fine et les opérations système.
  • Mélanger les deux sans comprendre leur logique produit vite de la confusion et de la dette technique.

Ce site vous est utile ?

Sachez que moins de 1% des lecteurs soutiennent ce site.

Je maintiens +700 guides gratuits, sans pub ni tracing. Aujourd'hui, ce site ne couvre même pas mes frais d'hébergement, d'électricité, de matériel, de logiciels, mais surtout de cafés.

Un soutien régulier, même symbolique, m'aide à garder ces ressources gratuites et à continuer de produire des guides de qualité. Merci pour votre appui.

Abonnez-vous et suivez mon actualité DevSecOps sur LinkedIn