Table of Contents

Infra as Code & idempotence

① Le concept (générique)
② Comment Set-OPS le fait

L'idempotence ne se décrète pas : elle se mesure

③ Pourquoi c'est transférable
④ À toi de jouer
Pour aller plus loin (dépôt)

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Infra as Code & idempotence

Unité d'apprentissage. Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.

① Le concept (générique)

Infra as Code (IaC) : décrire l'infrastructure dans du code (versionné, revu, reproductible) plutôt qu'à la main. Le serveur devient le résultat d'un fichier, pas d'une suite de clics oubliés.

Déclaratif vs impératif :

impératif = « fais ceci, puis cela » (une recette d'étapes) ;
déclaratif = « voici l'état voulu » (le moteur trouve comment y arriver).

Idempotence : appliquer la même description N fois donne le même résultat. La 1ʳᵉ exécution change des choses ; les suivantes ne changent rien (changed=0). C'est ce qui rend l'IaC sûre à rejouer.

Modèle plan → apply : on décrit (plan), on prévisualise (dry-run), on applique. Tout est en contrôle de version (git), donc auditable et réversible.

② Comment Set-OPS le fait

Ansible = le moteur déclaratif (des rôles décrivant l'état voulu, idempotents).
Le plan (serveurs.yml, applications.yml, bases-donnees.yml) décrit quoi déployer.
make instancier génère l'inventaire statique depuis le plan.
make deployer applique les rôles ; le Vérifier (dry-run) prévisualise d'abord.
Tout vit dans git (ce dépôt) — reproductible, revu, réversible.

L'idempotence ne se décrète pas : elle se mesure

Cette page a longtemps affirmé que redéployer un rôle donnait changed=0. C'était vrai rôle par rôle — et faux à l'échelle de la flotte, ce que personne n'avait vérifié. Le 2026-08-09, après une reconstruction complète, on a compté :

924  taches « changed »   rejeu depuis zero (tout est neuf : normal)
 17  taches « changed »   second passage    (la flotte devrait etre convergente)
  0  taches « changed »   apres correction

Les 17 n'étaient pas du bruit. Elles cachaient deux pannes qui ne se signalaient d'aucune autre façon :

Ce qu'on voyait	Ce que c'était
13× « démarrer node_exporter »	le service était mort — tué par `SIGHUP` à chaque renouvellement de certificat, donc toutes les 24 h, sur les quatorze hôtes
2× « déployer app.ini »	le dépôt faisait tourner le secret JWT de la forge à chaque déploiement, invalidant ses jetons

La leçon dépasse Ansible : un compteur de changements est un instrument de diagnostic. Tant qu'il indiquait 17, aucun de ces deux défauts n'était visible — ils se noyaient dans un fond qu'on avait pris l'habitude d'ignorer. Ramené à zéro, le moindre changed sur une flotte non modifiée devient un signal.

Vérifier le zéro, aussi. Un zéro peut vouloir dire « rien à faire » ou « plus rien ne travaille ». On a compté les tâches exécutées : 2266 au passage à vide contre 2152 au rejeu. Plus de tâches, aucune modification — donc convergence, pas silence.

③ Pourquoi c'est transférable

Set-OPS	Équivalents ailleurs
Ansible	Terraform · Puppet · Chef · SaltStack · OpenTofu
plan → dry-run → apply	`terraform plan/apply`, tout workflow IaC
idempotence	propriété fondamentale de toute IaC sérieuse

Tu as appris le déclaratif, l'idempotence, plan→apply, l'infra versionnée — pas « Ansible ».

④ À toi de jouer

Sens l'idempotence. Redéploie un rôle déjà en place (ex. via la GUI ou make deployer HOTE=…) : la 2ᵉ fois, changed=0. Rien à faire = rien n'est touché.
Le flux déclaratif. Édite le plan (un serveur dans la GUI), ⚙ Appliquer le plan (instancier), puis Vérifier (dry-run) : tu prévisualises avant d'appliquer.
La réversibilité. git diff / git checkout sur le plan : l'état est du code, donc annulable.
Casse & répare. Modifie à la main un fichier géré par un rôle (ex. un .conf), puis redéploie : Ansible rétablit l'état voulu (le code gagne sur la dérive manuelle). Tu sens que la source de vérité, c'est le code.

Pour aller plus loin (dépôt)

Le flux : make instancier → make instancier-appliquer → make deployer (ou la GUI).
Le plan : instance/plan/ ; les rôles : roles/ ; l'autorité : AGENTS.md.
Relations déclaratives entre entités : unité Liaisons (bindings).

Set-OPS

🏠 Accueil

Tu viens d'arriver

🔑 Reprendre l'écosystème

Unités d'apprentissage

Fondations

Communication

Données

Observabilité

Socle & méthode

Flotte & preuve

Opérations

Runbooks → dépôt docs/runbooks-exploitation.md

Repères

Glossaire
Référence technique → dépôt docs/