Set-OPS-Public/wiki/Vérifier-le-déployé.md

Vérifier le déployé — quand la preuve statique ne suffit plus

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

---

① Le concept (générique)

Il y a deux questions qu'on confond tout le temps, et seule la première est facile :

Question	Ce qu'on lit	Ce que ça prouve
« Mon code est-il cohérent ? »	le dépôt	qu'il ne se contredit pas lui-même
« Mon système ressemble-t-il à mon code ? »	les machines	qu'il fait ce qu'on a écrit

Un test unitaire, un linter, une validation de schéma répondent tous à la première. Ils sont rapides, ils tournent partout, et ils ne touchent jamais la machine. C'est leur force et c'est leur limite.

La seconde question exige d'aller demander au système. Et elle est la seule qui compte le jour où quelque chose ne marche pas.

Le piège n'est pas d'ignorer la seconde question. C'est de croire que la première y répond. Un tableau de bord tout vert dit « le code est bon », et on le lit « le service fonctionne ».

---

② Comment Set-OPS le fait

Set-OPS a longtemps eu 31 preuves statiques (make prouver) — zéro appel réseau, zéro SSH. Elles établissent que le dépôt est cohérent avec lui-même : les handlers existent, l'adressage dérive du seed, aucun intrant n'est orphelin.

Le 2026-08-08, l'autorité de certification de la flotte est restée expirée pendant huit heures sous un harnais entièrement vert. Le renouvellement échouait toutes les quatorze minutes. Aucune preuve ne pouvait le voir : aucune ne parlait à une machine.

D'où les devis de service — même patron que les devis réseau (D-23/D-24), porté aux services :

make identite-plan       le realm, la fédération LDAP, la politique de mot de passe, les comptes
make certificats-plan    ce que le disque porte contre ce que la mémoire sert
make expositions-plan    chaque service publié répond-il — depuis l'edge et depuis ton poste
make postgresql-plan     le chiffrement est-il imposé, et à quels réseaux
make courriel-plan       Postfix → LDAP → LMTP → Dovecot → IMAP, file d'attente comprise

Le même patron a ensuite été porté sous les services, au monde physique — mêmes pièces, même refus d'écrire :

make frontiere-plan      les règles de la frontière OPNsense contre leur devis
make proxmox-fw-plan     le pare-feu est-ouest de l'hyperviseur contre le registre des flux
make sdn-plan            la zone EVPN, ses VNets et la sortie des VRF
make underlay-plan       l'underlay déclaré contre ce que le cluster porte vraiment
make placement-plan      chaque VM est-elle là où le plan la met

(Deux mesures voisines ne comparent à rien et ne portent donc pas le suffixe -plan : make mtu-mesurer et make versions-mesurer relèvent un état, sans devis en face.)

Pièce	Rôle
un playbook (playbooks/maintenance/devis-*.yml)	relève le déclaré et le réel, dépose un JSON
un script (scripts/devis_*.py)	compare, affiche les écarts, sort en code 1
make deployer	répare — ce n'est pas le rôle du devis

Trois règles qui font la différence entre un devis utile et un devis décoratif :

Le devis ne redéclare jamais ce qu'il vérifie. Il charge les défauts du rôle et appelle les résolveurs. Un contrôle qui recopie la valeur attendue ne contrôle rien — il se compare à lui-même.

Une vraie requête, jamais un connect(). À travers un pare-feu qui fait de l'anti-usurpation, toute connexion TCP réussit, même vers une adresse où rien n'existe. Et en TLS c'est le client qui parle en premier : le silence après connexion ne distingue pas un service sain d'un trou. Seul un échange applicatif complet tranche.

Un code de retour n'est pas un verdict. Un 502 est une réponse, et pourtant le service est mort derrière.

---

③ Pourquoi c'est transférable

Set-OPS	Équivalents ailleurs
preuves statiques	tests unitaires · linters · validation de schéma · terraform validate
devis de service	tests de bout en bout · sondes black-box · terraform plan sur l'état réel
relevé puis comparaison	drift detection — AWS Config, Chef --why-run, Puppet --noop

Le mot que tout le monde emploie est dérive (drift) : l'écart qui s'installe entre ce qu'on a déclaré et ce qui tourne. Aucun outil ne l'empêche ; ils aident seulement à la voir.

Et la vraie leçon n'est pas technique : une garantie qui n'a jamais échoué n'est pas une garantie, c'est une habitude. Un contrôle qu'on n'a pas vu dire non ne prouve rien — il faut l'éprouver dans les deux sens, en cassant volontairement ce qu'il surveille.

---

④ À toi de jouer

1. Lance les dix devis sur ta flotte — les cinq de service, puis les cinq d'infrastructure. Note le temps que ça prend : quelques minutes pour ce qui demandait une journée d'enquête à la main.
2. Casse quelque chose exprès — arrête un service publié, change un port — et relance le devis concerné. S'il ne dit rien, c'est lui qu'il faut réparer, pas le service.
3. Cherche, dans ton propre outillage, une vérification qui n'a jamais échoué. Demande-toi si c'est parce que tout va bien, ou parce qu'elle ne regarde rien.

Terme	Ce que tu retiens
preuve statique	lit le code ; rapide, universelle, aveugle au réel
devis / drift detection	interroge le système ; seule réponse à « est-ce que ça marche ? »
test négatif	éprouver qu'un contrôle sait dire non

Tu as appris la différence entre valider du code et vérifier un système — pas « les devis Set-OPS ».