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
- 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.
- 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.
- 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 ».
Set-OPS
Tu viens d'arriver
Unités d'apprentissage
Fondations
Communication
Données
Observabilité
Socle & méthode
- Le GUI (console d'exploitation)
- Virtualisation & clonage
- Sécurité & durcissement
- Infra as Code & idempotence
- Le plan & l'adressage dérivé
- Liaisons (bindings)
Flotte & preuve
Opérations
- Runbooks → dépôt
docs/runbooks-exploitation.md
Repères
- Glossaire
- Référence technique → dépôt
docs/