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