# 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 ».