docs : rectification — trois syntaxes d'interface restent non vérifiées

J'ai annoncé « les six familles sont closes » sur la foi d'un
`spanning-tree ?` en mode configuration GLOBALE. Trois lignes du devis
vivent ailleurs et n'y figuraient donc pas :

- `spanning-tree portfast trunk` (interface) — `trunk` est un mot-clé
  Cisco ; l'équivalent s'écrit souvent `portfast` seul, voire `edged-port` ;
- `ip access-group <NOM> in` (interface) — c'est ce qui LIE l'ACL au SVI ;
  sans elle l'ACL existe et ne filtre rien ;
- `ip default-gateway <ip>` (global, absent de l'aide consultée).

`(config-if)#spanning-tree ?` et `(config-if)#ip ?` les donneraient.

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

CHANGELOG.md

@@ -12,9 +12,16 @@ Ajouté : `spanning-tree` seul, qui **garantit l'état actif**. Sans lui, `mode`
 sur un boîtier où le protocole aurait été désactivé configureraient un arbre qui ne tourne
 pas. Sans effet s'il est déjà actif — même logique déclarative que pour les trunks.
 
-**Les six familles de syntaxe sont vérifiées contre le matériel** : VLAN, SVI, trunks, routes,
-ACL, spanning-tree. Deux ont révélé un défaut réel plutôt que de confirmer l'existant — les
-routes (notation CIDR) et surtout les trunks, dont la forme `add` ne retranchait rien.
+Vérifié contre le matériel : VLAN, SVI, trunks, routes, définition des ACL, spanning-tree
+**global**. Deux ont révélé un défaut réel plutôt que de confirmer l'existant — les routes
+(notation CIDR) et surtout les trunks, dont la forme `add` ne retranchait rien.
+
+> **Rectification (même jour).** L'entrée ci-dessus a d'abord annoncé « les six familles sont
+> closes ». C'était faux : l'aide consultée était celle du mode configuration **globale**, et
+> trois lignes du devis vivent ailleurs — `spanning-tree portfast trunk` et `ip access-group
+> … in` au niveau **interface**, `ip default-gateway` en global mais absent de cette aide.
+> Elles restent non vérifiées, et la plus douteuse est `portfast trunk` : `trunk` est un
+> mot-clé Cisco.
 
 ## 2026-08-02 (suite 16) — la syntaxe des ACL vérifiée sur le matériel
 

docs/frontiere-opnsense.md

@@ -314,10 +314,21 @@ ansible-vault edit instance/inventories/principal/group_vars/all/vault.yml
   niveau **global**. La priorité n'a donc pas besoin d'être portée par une instance, même en
   MSTP — la réserve inverse, notée la veille, était infondée.
 
-**Les six familles de syntaxe sont désormais vérifiées contre le matériel** : VLAN, SVI,
-trunks, routes, ACL, spanning-tree. Deux d'entre elles ont révélé un défaut réel plutôt que de
-confirmer ce qui était écrit — les routes (notation CIDR) et surtout les trunks, dont la forme
-`add` ne retranchait rien.
+**Vérifié contre le matériel** : VLAN, SVI, trunks (`switchport …`), routes, définition des
+ACL, spanning-tree **global** (`spanning-tree`, `mode`, `priority`). Deux de ces vérifications
+ont révélé un défaut réel plutôt que de confirmer l'existant — les routes (notation CIDR) et
+surtout les trunks, dont la forme `add` ne retranchait rien.
+
+**Restent non vérifiées, toutes au niveau interface ou hors de l'aide consultée** :
+
+| Ligne émise | Où | Risque |
+|---|---|---|
+| `spanning-tree portfast trunk` | interface | `trunk` est un mot-clé Cisco ; l'équivalent s'écrit souvent `spanning-tree portfast` seul, voire `edged-port` |
+| `ip access-group <NOM> in` | interface | c'est ce qui **lie** l'ACL au SVI — sans elle, l'ACL existe et ne filtre rien |
+| `ip default-gateway <ip>` | global | forme des switches d'accès (partie B) |
+
+L'aide de `spanning-tree ?` en mode configuration **globale** ne couvre pas les commandes
+d'interface : `(config-if)#spanning-tree ?` et `(config-if)#ip ?` les donneraient.
 - **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