Dès qu’un projet GCP dépasse un seul projet et une seule équipe, la question du réseau se pose : est-ce que tout le monde partage le même VPC, ou est-ce que chaque environnement a le sien et on les relie ? Et si on les relie, avec quoi ? La réponse dépend surtout d’où vous en êtes, pas d’un idéal théorique.

Les modèles en présence

Shared VPC

Un projet “hôte” possède le VPC, et le partage avec des projets “service” qui y créent leurs ressources. Tout le monde vit dans le même réseau : mêmes subnets, mêmes tables de routage, un seul domaine de broadcast. L’isolation se fait par IAM (qui a le droit d’utiliser quel subnet), pas par le réseau lui-même.

graph TB
    subgraph HOST["Projet hôte — 1 VPC"]
        SubA["subnet-a"]
        SubB["subnet-b"]
    end
    SvcProject1["Projet service : équipe A"] -->|"Network User"| SubA
    SvcProject2["Projet service : équipe B"] -->|"Network User"| SubB

Simple à opérer, pas de routage à gérer entre réseaux. Le revers : une erreur de firewall ou de route au niveau du hôte impacte tout le monde, et l’équipe qui possède le projet hôte devient vite un point de passage obligé pour toute modification réseau.

Hub & Spoke via VPC Peering

Un hub central, des spokes qui s’y connectent en peering. C’est le modèle que j’ai mis en pratique sur GCP avec Terraform. Chaque spoke garde son propre VPC (donc son propre domaine d’administration), mais le peering VPC natif GCP n’est pas transitif : un spoke ne voit pas un autre spoke à travers le hub sans configuration additionnelle (next-hop routes vers une appliance dans le hub, par exemple).

graph TB
    HUB["Hub VPC"]
    S1["Spoke dev"]
    S2["Spoke prod"]
    S3["Spoke data"]
    S1 <-->|Peering| HUB
    S2 <-->|Peering| HUB
    S3 <-->|Peering| HUB

Bonne isolation par design (pas de connectivité spoke-à-spoke par défaut), mais ça ne scale pas indéfiniment : la limite par défaut est de 25 connexions de peering actives par VPC (extensible, mais avec un plafond). Au-delà d’une dizaine de spokes, la gestion manuelle des peerings et des routes devient pénible.

Network Connectivity Center (NCC)

NCC reprend l’idée du hub & spoke, mais le hub gère nativement le routage transitif entre spokes (VPC, VPN, Interconnect, routeur virtuel) et la connectivité hybride vers l’on-prem fait partie du même modèle plutôt que d’être bricolée à côté. C’est pensé pour des dizaines, voire des centaines de spokes.

graph TB
    HUB["NCC Hub"]
    S1["Spoke VPC dev"]
    S2["Spoke VPC prod"]
    S3["Spoke VPN — on-prem"]
    S4["Spoke Interconnect"]
    S1 <--> HUB
    S2 <--> HUB
    S3 <--> HUB
    S4 <--> HUB
    S1 -.transitif via hub.-> S2

Plus de flexibilité et de scalabilité que le peering, mais aussi plus de surface : le hub devient une pièce critique, et la transitivité par défaut demande d’être explicite sur ce qui doit vraiment communiquer (via des groupes de spokes ou des policies dédiées), sinon on recrée un grand réseau plat comme un Shared VPC, avec la complexité de NCC en plus.

Les autres options

• Private Service Connect (PSC) : pas de connectivité réseau entre VPC, juste l’exposition d’un service précis (une API, une base de données managée) consommable depuis un autre VPC via une IP privée. C’est la surface d’attaque la plus faible des quatre options, pertinent quand on n’a besoin que d’accéder à un service précis, pas au réseau entier.
• VPC isolés, sans connexion : la valeur par défaut. Pas de complexité réseau, isolation maximale. Suffisant tant qu’aucune ressource n’a besoin de parler à une autre à travers les frontières de VPC.

Tableau récapitulatif

Par où commencer quand on ne sait pas de quoi sera fait l’avenir

Ne partez pas sur NCC ou un hub & spoke élaboré parce que “ça pourrait servir plus tard”. Le même principe que pour Kubernetes s’applique : dimensionner pour un futur hypothétique coûte cher tout de suite et rarement pour la bonne raison. Commencez simple, en général un Shared VPC ou même deux/trois VPC isolés selon le nombre d’environnements, et gardez deux décisions bien prises dès le départ, parce que ce sont les seules coûteuses à revenir en arrière :

1. Le plan d’adressage IP. Réservez des plages CIDR non chevauchantes par environnement et par région dès le premier projet, même si un seul VPC existe aujourd’hui. Changer les plages d’un VPC déjà peuplé de ressources est un chantier, pas une commande Terraform.
2. La structure projets/dossiers. Organisez les projets GCP comme si la segmentation future existait déjà (un projet par environnement, par équipe ou par domaine), même s’ils partagent le même réseau pour l’instant. Migrer une frontière IAM/projet est beaucoup plus simple que migrer une frontière réseau.

Le reste (peering, NCC, PSC) se rajoute par-dessus une base bien adressée sans tout casser.

Précautions au passage à l’échelle

• Le plafond du peering arrive plus vite qu’on ne le pense. Si le nombre de spokes croît régulièrement (nouvelles équipes, nouveaux environnements), planifiez la bascule vers NCC avant de taper le plafond, pas après. La migration se fait spoke par spoke, mais elle est plus confortable anticipée que subie.
• Le Shared VPC centralise aussi la charge opérationnelle. Toute création de subnet ou règle de firewall passe par le propriétaire du projet hôte. Au-delà de quelques équipes, ça devient un goulot d’étranglement ; les rôles IAM délégués (Network User par subnet) et les firewall policies hiérarchiques limitent la casse, mais ne suppriment pas le point de contention.
• La transitivité de NCC n’est pas gratuite en clarté. Sans groupes de spokes ou policies explicites, un hub NCC ouvert par défaut recrée un grand réseau plat, avec en plus la complexité d’un hub multi-technologie (VPC, VPN, Interconnect). Documentez qui doit parler à qui avant d’activer la transitivité globale.
• Le blast radius grandit avec la mutualisation. Un Shared VPC ou un hub NCC mal cloisonné, c’est une erreur de règle de routage qui impacte tous les environnements en même temps, y compris la prod à cause d’un changement en dev. Plus le modèle mutualise, plus les revues de changement réseau doivent être strictes.
• La connectivité hybride change les CIDR utilisables. Dès qu’un VPN ou un Interconnect relie à l’on-prem, les plages IP du cloud doivent rester non chevauchantes avec celles du datacenter, pas seulement entre VPC GCP. À vérifier avant, pas après avoir peuplé les subnets.

En résumé

Commencez par le modèle le plus simple qui couvre le besoin réel d’aujourd’hui, en général Shared VPC ou quelques VPC isolés. Passez au hub & spoke par peering quand l’isolation entre environnements devient nécessaire et que le nombre de spokes reste modeste. Passez à NCC quand le nombre de spokes, les besoins de transitivité ou la connectivité hybride dépassent ce que le peering peut raisonnablement gérer. Et réservez PSC pour les cas où seul un service précis, pas tout un réseau, a besoin d’être atteint. Le seul investissement à faire tôt, quel que soit le modèle de départ, c’est le plan d’adressage IP.