docs : le spanning-tree du matériel — MSTP, actif, priorité par défaut

Correction d'une déduction fausse : j'avais conclu de son absence du
`show running-config` que le spanning-tree était désactivé. Il est actif —
il n'y figurait pas parce qu'il est aux valeurs d'usine. Une absence dans une
configuration ne veut pas dire une absence de fonction.

La plateforme est en MSTP (802.1s, Force Version 3) alors que
`underlay.stp.mode` déclare rstp. Sur une étoile sans lien redondant les
deux se comportent identiquement ; reste à décider si l'on aligne la
déclaration sur le matériel ou l'inverse.

La priorité de pont est déjà 32768 : la ligne émise pour les switches
d'accès est un non-opérant.

Reste non vérifiée la forme d'ENTRÉE des commandes — `show` donne l'état,
pas la syntaxe. En MSTP la priorité se règle en général par instance, ce que
la forme émise ne fait pas.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CHANGELOG.md

@@ -1,5 +1,26 @@
 # CHANGELOG — Set-OPS
 
+## 2026-08-02 (suite 14) — le spanning-tree du matériel : MSTP, actif, priorité par défaut
+
+`show spanning-tree` sur le commutateur Binardat corrige une déduction fausse et en apporte
+deux faits.
+
+**Correction.** J'avais déduit de son absence du `show running-config` que le spanning-tree
+était probablement désactivé. Il est **actif** : il n'y figurait pas parce qu'il est aux
+valeurs d'usine. Une absence dans une configuration ne veut pas dire une absence de fonction.
+
+**La plateforme est en MSTP** (IEEE 802.1s, *Force Version 3*), alors que `underlay.stp.mode`
+déclare `rstp`. Sur une étoile sans lien redondant les deux se comportent identiquement — la
+question est de savoir si l'on aligne la déclaration sur le matériel ou le matériel sur la
+déclaration.
+
+**La priorité de pont est déjà 32768**, donc la ligne émise pour les switches d'accès est un
+non-opérant : elle écrit ce qui est déjà vrai.
+
+Reste non vérifiée la **forme d'entrée** des commandes de spanning-tree : `show` en donne
+l'état, pas la syntaxe. En MSTP la priorité se règle en général **par instance**, ce que la
+forme actuellement émise ne fait pas.
+
 ## 2026-08-02 (suite 13) — le trunk ne restreignait rien
 
 `switchport trunk allowed vlan ?` sur le matériel réel confirme la syntaxe **et** révèle un

docs/frontiere-opnsense.md

@@ -299,8 +299,15 @@ ansible-vault edit instance/inventories/principal/group_vars/all/vault.yml
   Le devis émet la forme **sans mot-clé**, qui *définit* la liste : `add` l'*ajoute* à
   l'existante, et sur un port trunk neuf — qui autorise tous les VLAN — n'aurait rien
   retranché. Le devis aurait donné l'illusion de restreindre.
-- **Restent non vérifiés sur Binardat** : la syntaxe des ACL (`ip access-list extended`) et
-  celle du **spanning-tree**.
+- **Le spanning-tree, sur Binardat** (`show spanning-tree`, 2026-08-02) : la plateforme est en
+  **MSTP** (IEEE 802.1s, *Force Version 3*) par défaut, priorité de pont **32768**, et il est
+  **actif** — son absence du `show running-config` signifiait « valeurs par défaut », non
+  « désactivé ». Deux conséquences : `underlay.stp.mode` doit dire `mstp` si l'on garde le
+  comportement d'usine, et la ligne de priorité émise pour les switches d'accès (32768) est un
+  non-opérant qui écrit ce qui est déjà vrai.
+- **Restent non vérifiés sur Binardat** : la syntaxe des ACL (`ip access-list extended`) et les
+  commandes de configuration du spanning-tree — `show` en donne l'état, pas la forme d'entrée.
+  En MSTP, la priorité se règle en général par instance, ce qui n'est pas la forme émise.
 - **Les ports physiques restent à nommer** — `<PORT-VERS-PROXMOX>`, `<PORT-VERS-FRONTIERE>`
   et `<PORT-TRUNK>` ; rien dans le modèle ne peut les deviner.
 - ~~**La sortie générale** n'est pas déclarée~~ — **réglé le 2026-08-02.** Elle est