transit : bifrost-1/-2 en .1/.2, le SVI du switch remonte en .6

Les frontières occupent le bas du /29, le SVI du switch le haut. `.3` reste
libre pour une future IP virtuelle CARP si les deux OPNsense passent en
haute disponibilité — ce jour-là, `passerelle_sortie` pointera sur la VIP
plutôt que sur un boîtier nommé, et ce sera le seul changement.

Plan du lien :
  10.0.4.1  bifrost-1   frontière active, sortie par défaut de la flotte
  10.0.4.2  bifrost-2   seconde frontière
  10.0.4.3  libre       réservée VIP CARP
  10.0.4.6  sleipnir-01 SVI du switch routeur

Les deux devis suivent sans intervention : routes du switch vers 10.0.4.1,
routes tenants de la frontière via 10.0.4.6.

Preuves : 24 OK, 0 échec.

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

CHANGELOG.md

@@ -2,19 +2,24 @@
 
 ## 2026-08-01 (suite 6) — nommage : `bifrost` aux frontières, `sleipnir` à la fabric
 
-`bifrost-0` et `bifrost-1` sont réservés aux deux frontières OPNsense — Bifröst est le pont
+`bifrost-1` et `bifrost-2` sont réservés aux deux frontières OPNsense — Bifröst est le pont
 vers l'extérieur. Les switches internes deviennent `sleipnir-01…03` : le cheval qui traverse
 les mondes, pas le pont qui en sort. La division du nom suit celle de l'architecture.
 
-Les deux boîtiers sont déclarés comme hôtes du lien de transit (`10.0.4.2`, `10.0.4.3`) :
+Les deux boîtiers sont déclarés comme hôtes du lien de transit (`10.0.4.1`, `10.0.4.2`) :
 hors flotte Ansible, la déclaration documente le lien et réserve les noms. Le `/29` choisi
 plus tôt les loge tous les deux, comme prévu.
 
+Le plan du `/29` est réorganisé en conséquence : frontières en bas (`.1`, `.2`), SVI du
+switch en haut (`.6`), et `.3` laissée libre pour une future IP virtuelle CARP si les deux
+OPNsense passent en haute disponibilité. Ce jour-là, `passerelle_sortie` pointera sur la VIP
+plutôt que sur un boîtier nommé — un seul endroit à changer.
+
 Conséquence à traiter : la partie B du devis switch aurait listé les deux pare-feux parmi les
 « switches d'accès ». Elle ne retient désormais que les hôtes du **réseau de management** —
 un équipement déclaré ailleurs ne reçoit aucune ligne de configuration de switch.
 
-Le devis frontière nomme le boîtier quand il est déclaré : `frontiere 10.0.4.2 (bifrost-0)`.
+Le devis frontière nomme le boîtier quand il est déclaré : `frontiere 10.0.4.1 (bifrost-1)`.
 
 ## 2026-08-01 (suite 5) — deux incohérences du devis switch
 

docs/frontiere-opnsense.md

@@ -84,11 +84,25 @@ sur ce lien :
 - nom: transit-frontiere
   vlan: 40
   sous_reseau: 10.0.4.0/29
-  passerelle: 10.0.4.1        # SVI du switch L3
-  passerelle_sortie: 10.0.4.2 # la frontière = sortie par défaut de la flotte
+  passerelle: 10.0.4.6        # SVI du switch L3 (sleipnir-01)
+  passerelle_sortie: 10.0.4.1 # bifrost-1 = sortie par défaut de la flotte
 ```
 
-**Nommage.** `bifrost-0` et `bifrost-1` désignent les deux frontières — Bifröst est le pont
+**Plan du `/29`.** Les frontières occupent le bas de la plage, le SVI du switch le haut :
+
+| Adresse | Qui |
+|---|---|
+| `10.0.4.1` | `bifrost-1` — frontière active, sortie par défaut de la flotte |
+| `10.0.4.2` | `bifrost-2` — seconde frontière |
+| `10.0.4.3` | libre, réservée à une IP virtuelle CARP si les deux passent en HA |
+| `10.0.4.4-.5` | libres |
+| `10.0.4.6` | SVI du switch routeur (`sleipnir-01`) |
+
+Le jour où les deux OPNsense passent en haute disponibilité, `passerelle_sortie` devra
+pointer sur l'**IP virtuelle CARP** et non sur un boîtier nommé — c'est le seul changement
+que la bascule exigera, et il se fait à un endroit.
+
+**Nommage.** `bifrost-1` et `bifrost-2` désignent les deux frontières — Bifröst est le pont
 vers l'extérieur. La fabric interne porte un autre nom, `sleipnir-01…03` : le cheval qui
 traverse les mondes, pas le pont qui en sort. Les deux boîtiers sont déclarés comme hôtes du
 lien de transit ; ils sont **hors flotte Ansible**, la déclaration ne sert qu'à documenter le