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

Provisionnement vs gestion de configuration

8 min de lecture

Le provisionnement sert à créer les ressources, la gestion de configuration sert à régler ce qui tourne dessus. Cette distinction est le pivot le plus utile pour structurer une pratique d’Infrastructure as Code. Si vous la ratez, vous risquez d’utiliser un outil de configuration pour faire du provisionnement durable, ou un outil de provisionnement pour faire de l’administration fine système.

Dans la vraie vie, les deux besoins coexistent souvent. On crée une VM, un réseau ou un bucket avec un outil comme Terraform, puis on installe les paquets, déploie les fichiers, durcit les services ou applique les politiques système avec Ansible ou un outil voisin.

  • distinguer clairement provisionnement et gestion de configuration ;
  • comprendre pourquoi Terraform et Ansible sont souvent complémentaires ;
  • savoir vers quelle section pratique du site aller ensuite.
SujetQuestion à laquelle on répond
Provisionnement”Quelles ressources doivent exister ?”
Gestion de configuration”Comment ces ressources doivent-elles être configurées et maintenues ?”

Le passage d’une couche à l’autre ressemble généralement à ceci :

Passage du provisionnement a la gestion de configuration

Imaginez que vous deviez mettre en ligne une application interne.

Le provisionnement va surtout couvrir :

  • la création de la VM ou du cluster ;
  • le réseau, les règles d’accès et le stockage ;
  • éventuellement la base managée, le load balancer ou le DNS.

La gestion de configuration va ensuite couvrir :

  • l’installation du serveur web ;
  • le dépôt du fichier de configuration ;
  • la création des utilisateurs ou secrets locaux ;
  • le démarrage, l’activation et le contrôle du service.

Ce fil rouge est utile car il montre que les deux sujets s’enchaînent souvent, mais ne répondent pas à la même question.

  • créer une VM ;
  • allouer un réseau ou un subnet ;
  • créer une base de données managée ;
  • déclarer un bucket, un load balancer ou un cluster.
  • installer Nginx, PostgreSQL ou Docker ;
  • déposer un fichier de configuration ;
  • créer des utilisateurs système ;
  • appliquer un durcissement ou des règles de conformité ;
  • redémarrer un service si sa configuration change.

Quand ce partage est clair, il devient beaucoup plus facile de répondre à des questions simples : qui détient la vérité sur la topologie, quel outil doit être relancé, et où lire un changement avant de l’approuver. Sans cette séparation, les revues se brouillent vite.

Le vocabulaire brouille les frontières. Quand on “prépare un serveur”, on mélange facilement la création de la machine et sa configuration logicielle. Pourtant, ces deux étapes n’ont ni le même rythme, ni les mêmes contraintes, ni les mêmes outils optimaux.

Terraform et Ansible ne sont pas des concurrents directs

Section intitulée « Terraform et Ansible ne sont pas des concurrents directs »

Le faux débat “Terraform vs Ansible” fait perdre du temps. Les deux outils se complètent très bien quand on respecte leur rôle.

BesoinOutil souvent le plus naturel
Créer des ressources cloud ou virtuellesTerraform
Modéliser un état cible d’infrastructureTerraform
Configurer un OS ou une applicationAnsible
Déployer des fichiers, paquets et servicesAnsible
Enchaîner création d’une VM puis configuration logicielleTerraform + Ansible

Cette complémentarité existe aussi avec d’autres outils : Pulumi, CloudFormation, Puppet, Chef ou Rudder.

Pourquoi les rythmes de changement sont différents

Section intitulée « Pourquoi les rythmes de changement sont différents »

Le provisionnement change souvent à un rythme plus lent mais avec un impact structurel plus fort : on ajoute un réseau, une base, un cluster, une ressource managée. La gestion de configuration change souvent plus souvent : une version de paquet, un fichier, une règle système, un service.

Comprendre cette différence aide beaucoup à structurer les dépôts, les pipelines et les revues. Ce n’est pas seulement une différence d’outil. C’est aussi une différence de rythme opérationnel.

  • utiliser un playbook Ansible comme substitut complet à un modèle de ressources durables ;
  • surcharger Terraform avec des actions de configuration système très fines ;
  • ne pas définir où s’arrête la responsabilité de chaque dépôt ou chaque équipe ;
  • mélanger dans un seul workflow des actions de création et de configuration sans logique de séparation.

Vous avez probablement une frontière floue entre provisionnement et gestion de configuration si :

  • le même changement mélange topologie d’infrastructure et réglages système détaillés ;
  • la relecture ne permet pas de distinguer ce qui crée une ressource de ce qui configure son contenu ;
  • l’équipe hésite sur l’outil à relancer quand un service dérive ;
  • les responsabilités entre dépôts ou équipes ne sont pas explicites.

Si votre besoin principal est de créer l’infrastructure, passez vers la section Provisionnement. Si votre besoin principal est de maintenir, configurer et durcir les systèmes, passez vers Gestion de configuration.

  • Le provisionnement crée les ressources ; la gestion de configuration règle ce qui tourne dessus.
  • Ces deux besoins sont différents, même s’ils s’enchaînent souvent dans un même projet.
  • Terraform et Ansible sont fréquemment complémentaires, pas interchangeables.
  • Une bonne séparation des rôles réduit la dette technique et clarifie les workflows.
  • Le bon choix dépend du problème concret que vous automatisez, pas d’une préférence d’outil.

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