vpcgw/v2 : douze opérations déclinées attendent un client, et la collection Ansible en est un

[stephrobert]

stephrobert/collection-scaleway déploie une passerelle publique dans sa
plateforme d'exemple et n'a aucun module pour la lire. Côté feint, douze
opérations vpcgw/v2 sont déclinées, et plusieurs de ces refus nomment
explicitement le client qui les lèverait.

Les deux projets se regardent sans se voir : c'est la meilleure candidate de
l'audit croisé.

Mesuré le 14 septembre 2026

Côté feint (internal/providers/scaleway/pack.go) :

grep -c 'Operation: "vpcgw'   -> 15   routes montées
grep -c '"vpcgw/v2/API\.'      -> 27   mentions, donc 12 déclinées

Côté collection : zéro module vpcgw_* sur 69
(ls plugins/modules | grep -c '^vpcgw'). La transcription réelle du
14 septembre montre la passerelle lue deux fois seulement, et par le script
de l'exemple, jamais par un module.

Or la stack en déploie une, avec deux rattachements
(examples/stack/network.tf).

Les refus qui attendent ce client

Trois d'entre eux nomment leur propre condition de levée :

opération	la raison écrite dans Declined()
UpgradeGateway	« no client this project drives upgrades a gateway in place, which is what this whole block records »
les 6 règles PAT	« no surveyed stack creates one »
RefreshSSHKeys	« the gateway's SSH bastion accepts no connection here »

La première a été refondée dans #765, ce matin, en retirant l'argument de
capacité que MigrateLB portait. Elle dit désormais exactement ce qui la lève :
un client qui le fait.

Ce que la collection gagnerait

Neuf modules, dans sa convention (_info lecture, _action action, sans suffixe
pour l'état déclaratif) :

vpcgw_gateway_info           ListGateways, GetGateway
vpcgw_gateway_network_info   ListGatewayNetworks, GetGatewayNetwork
vpcgw_ip_info                ListIPs, GetIP
vpcgw_pat_rule_info          ListPatRules, GetPatRule
vpcgw_gateway                UpdateGateway     (name, tags, bastion, smtp)
vpcgw_gateway_network        UpdateGatewayNetwork
vpcgw_ip                     UpdateIP
vpcgw_pat_rule               UpdatePatRule, SetPatRules
vpcgw_gateway_action         UpgradeGateway, RefreshSSHKeys

La question d'exploitation, en une phrase qu'un opérateur reconnaîtrait :
« ma passerelle de sortie est-elle saine, sur quelle version, avec un bastion
ouvert sur quel port, et quels ports forwarde-t-elle vers quelle adresse
privée ? »

Les champs qui y répondent sont déjà dans la réponse réelle : bastion_enabled,
bastion_port, bastion_allowed_ips, smtp_enabled, is_legacy, version,
status. Aucun n'est lu par un fichier du dépôt de la collection aujourd'hui.

Un bastion ouvert sur une passerelle de production est une règle d'audit qui
n'existe nulle part, faute du module qui la nourrirait.

Ce que feint gagnerait

Un client mesuré sur douze opérations qui attendent le leur, dont les six règles
PAT. C'est le même mécanisme qui a fait servir vpc/v2/API.GetACL en #343 : un
module _info qui demande une ressource déclinée est la mesure qui manque.

Et le coût de la preuve est nul : la stack déploie déjà la passerelle, donc
aucun Terraform de plus, aucune ressource facturée de plus.

Le périmètre à ne pas prendre

UpgradeGateway change le type commercial, donc la facture. C'est la même ligne
que MigrateLB occupe chez eux : servable ici, exclu de leur exercice réel. À
traiter comme tel plutôt qu'à confondre avec les lectures.

Ordre suggéré

Les quatre _info d'abord : lecture pure, gratuite, et elles seules débloquent
la règle du bastion. Les Update* ensuite. vpcgw_gateway_action en dernier,
avec sa ligne de coût écrite.

---

Relevé par un audit croisé des deux dépôts. Les chiffres sont rejouables avec
les commandes citées. Côté collection, la contrepartie est
stephrobert/collection-scaleway#252.