Set-OPS-Public/wiki/Vérifier-le-déployé.md
Daniel Allaire 85fed974a4 wiki : rattraper la reconstruction, et une unite sur la verification du deploye
Le wiki datait du 3 aout. Verifie avant d'y toucher : toutes les cibles make
citees existent, aucune commande morte.

La-preuve.md annoncait P01-P21 ; le harnais est a P33. Les trois nouvelles
ajoutees, et surtout la page dit maintenant ce que ces preuves NE FONT PAS :
elles sont statiques, elles lisent le depot, et c'est dans cet angle mort
qu'une AC est restee expiree huit heures sous un harnais vert.

Infra-as-Code-et-idempotence.md enseignait l'idempotence comme acquise. Vrai
role par role, faux a l'echelle de la flotte. La page enseigne desormais
depuis les chiffres (924 -> 17 -> 0), raconte ce que les 17 cachaient, et
explique pourquoi il faut verifier le zero lui-meme.

Nouvelle unite « Verifier le deploye » : la difference entre valider du code
et verifier un systeme, avec les trois regles qui separent un devis utile d'un
devis decoratif.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-09 15:11:43 -04:00

103 lines
5 KiB
Markdown

# 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
```
| 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 cinq devis sur ta flotte. 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 ».