Une landing zone GCP bien conçue évite de construire le cloud au hasard: elle fixe dès le départ les règles d’identité, de réseau, de journalisation et de gouvernance qui vont encadrer les premiers déploiements. Je vais ici aller au concret, avec la structure à viser, les choix qui comptent vraiment et les compromis à accepter quand on veut une base sécurisée sans bloquer les équipes. L’enjeu est simple: aller vite, oui, mais sans transformer le premier projet en dette technique durable.
Les points essentiels à garder en tête avant de bâtir le socle
- Une landing zone n’est pas un produit, mais une fondation modulaire qui prépare l’arrivée des workloads d’entreprise.
- Le point de départ est la racine organisationnelle, puis la hiérarchie folders/projects, pas l’inverse.
- Les identités humaines et techniques doivent être séparées, et les clés persistantes de comptes de service doivent être limitées.
- Pour le réseau, Shared VPC convient à la majorité des cas, mais certaines topologies servent des besoins plus spécifiques.
- La journalisation centralisée, les contraintes d’organisation et le chiffrement doivent être posés dès la base.
- Le meilleur socle est celui qui peut évoluer, être automatisé et accueillir plusieurs workloads sans refonte complète.
Ce qu’une landing zone apporte vraiment à un projet cloud
Je la vois comme une fondation de contrôle, pas comme une simple bonne pratique que l’on ajouterait plus tard. Elle sert à cadrer le cloud avant l’arrivée des premiers projets: qui peut agir, où se trouvent les ressources, comment circulent les flux, où vont les logs et quelles règles empêchent une dérive silencieuse. Sans cela, on finit souvent par reconstruire après coup ce qu’il aurait fallu stabiliser dès le départ.
Dans Google Cloud, ce socle doit rester modulaire et évolutif. Ce n’est pas une architecture figée, ni un modèle unique valable pour toutes les entreprises. Une organisation avec peu de contraintes ne construira pas la même base qu’un groupe avec plusieurs entités, des obligations de conformité fortes et des environnements hybrides. C’est précisément pour cela qu’il faut penser la landing zone comme un système vivant, capable de grandir avec les usages au lieu de les subir.
La logique est simple: avant de déployer un premier workload d’entreprise, on met en place le cadre qui évite de multiplier les exceptions. Cela permet d’avancer plus vite par la suite, parce que les équipes n’ont plus à rediscuter les mêmes choix à chaque projet. Une fois ce point posé, la vraie question devient celle des identités, car c’est elles qui ouvrent ou ferment l’accès au reste du socle.
L’identité doit être le premier verrou
Je commence toujours par l’identité, car c’est elle qui donne du sens aux autres contrôles. Une plateforme peut avoir un réseau impeccable et des règles de sécurité très détaillées; si les comptes sont mal gérés, le socle reste fragile. Le bon réflexe consiste à distinguer clairement les utilisateurs humains et les charges de travail, puis à décider où se trouve la source de vérité des comptes.
Dans la pratique, il y a deux grands scénarios: utiliser Google comme source principale d’identités, ou fédérer Google Cloud avec un fournisseur d’identité externe déjà en place. Le second cas est fréquent dans les organisations qui disposent déjà d’un annuaire bien structuré et ne veulent pas dupliquer la gouvernance des comptes.
| Approche | Quand elle est pertinente | Forces | Point de vigilance |
|---|---|---|---|
| Google comme IdP principal | Environnement relativement neuf ou stratégie centrée sur Google | Lifecycle plus simple, intégration directe | Il faut assumer une gestion d’identité centralisée dans Google |
| Fédération avec un IdP externe | Annuaire d’entreprise déjà mature, par exemple Entra ID, Okta ou ADFS | Conserve la source de vérité existante, limite la duplication | Demande une configuration plus soignée du provisioning et du SSO |
Pour les comptes de service, je recommande une discipline beaucoup plus stricte que celle qu’on voit encore trop souvent. Les clés persistantes sont pratiques à court terme, mais elles créent une surface d’attaque durable. La bonne pratique consiste à limiter la création et le téléchargement des clés, puis à privilégier des alternatives plus sûres comme l’impersonation de compte de service ou la fédération d’identité des charges de travail. C’est souvent le point qui change le plus vite le niveau de risque réel.
Le réflexe utile n’est donc pas “comment donner accès au plus vite”, mais “comment donner accès sans distribuer des secrets qui survivront à leur contexte d’usage”. Une fois ce verrou posé, on peut organiser proprement les ressources qui vont accueillir ces identités.
La hiérarchie des ressources doit refléter l’usage cloud, pas l’organigramme
La hiérarchie des ressources est l’un des sujets les plus sous-estimés. Beaucoup d’équipes cherchent à reproduire leur organigramme dans le cloud, puis découvrent que cette logique complique la gouvernance au lieu de la simplifier. Je préfère partir des responsabilités opérationnelles, des besoins de conformité et des environnements réellement nécessaires.
Le modèle de base de Google Cloud est clair: une racine d’organisation, puis des dossiers et des projets. En règle générale, il vaut mieux avoir une seule racine organisationnelle, sauf cas particuliers. Les projets peuvent être placés à différents niveaux de la hiérarchie, ce qui laisse de la souplesse pour organiser les workloads sans bloquer le modèle.
| Niveau | Rôle dans le socle | Ce que j’y mets en pratique |
|---|---|---|
| Organisation | Racine de gouvernance et point d’ancrage des politiques globales | Politiques transverses, contrôle de base, cadrage global des accès |
| Dossiers | Regroupement par environnement, responsabilité ou zone de contrôle | Bootstrap, sécurité, infrastructure partagée, production, non-production |
| Projets | Isolation opérationnelle des workloads et des services | Applications, composants partagés, services d’exploitation, environnements de test |
Ce découpage fonctionne bien parce qu’il permet de séparer les règles sans multiplier la complexité inutilement. Si une équipe a des droits différents en production et en test, on le voit clairement dans la hiérarchie. Si une filiale doit appliquer ses propres politiques, elle peut le faire sans casser le cadre global. Et si l’entreprise grandit, la structure peut s’étendre sans devoir être reconstruite.
Je déconseille en revanche les hiérarchies trop littérales, calquées sur les départements internes. Le cloud fonctionne mieux quand on organise les ressources selon les usages, les niveaux de risque et les besoins de gouvernance. Une fois cette structure en place, le réseau devient la question suivante, car c’est lui qui conditionne la manière dont les workloads communiquent.
Le réseau détermine la forme de la plateforme
Le réseau est souvent l’endroit où les compromis apparaissent le plus vite. Sur GCP, il existe plusieurs modèles, mais un point ressort clairement: Shared VPC par environnement est le choix le plus adapté dans beaucoup de cas, surtout quand on veut centraliser le contrôle des règles de pare-feu, le routage et la gestion des adresses IP. C’est le modèle que je retiens en premier quand l’objectif est une plateforme simple, claire et scalable.
| Option réseau | Quand l’utiliser | Ce que ça apporte | Limite principale |
|---|---|---|---|
| Shared VPC par environnement | Cas général, besoin de contrôle central et d’isolement entre dev, test et prod | Gouvernance simple, réseau centralisé, bonne évolutivité | Moins d’autonomie locale pour les équipes |
| Hub-and-spoke avec appliances centralisées | Besoin d’inspection Layer 7 ou de filtrage via des appliances | Contrôle fin des flux, inspection centralisée | Plus d’exploitation et de complexité |
| Hub-and-spoke sans appliances | Besoin d’autonomie accrue sans inspection par appliance | Structure lisible, moins d’éléments à maintenir | Moins adapté si vous cherchez un contrôle central fort |
| Modèle consumer-producer avec Private Service Connect | Services exposés via des endpoints privés, ports multiples ou protocoles variés | Exposition ciblée, communication privée, bonne isolation | Demande un design plus précis des dépendances |
Pour un environnement hybride, je garde en tête que la connexion vers l’on-premise passe généralement par Cloud VPN ou Cloud Interconnect, selon le niveau d’exigence, la disponibilité attendue et la capacité réseau déjà en place. Le point important n’est pas seulement de “relier” le cloud au SI existant, mais de le faire avec redondance et contrôle.
Il y a aussi quelques règles très concrètes qui évitent les erreurs classiques: utiliser des VPC en mode personnalisé, supprimer le réseau par défaut, limiter les IP publiques, passer par Cloud NAT quand il faut sortir vers Internet, imposer des policies de pare-feu hiérarchiques et garder une DNS hybride cohérente. Je préfère aussi éviter le peering direct entre environnements séparés, car il mélange trop facilement les frontières logiques. Une fois le réseau cadré, la sécurité peut être pensée comme un système cohérent et non comme une suite de rustines.
La sécurité doit être pensée comme un système, pas comme une checklist
La différence entre une base correcte et une base solide se joue souvent sur l’assemblage des contrôles. Je pense la sécurité en trois couches: les contrôles de politique, les contrôles d’architecture et les contrôles de détection. C’est cette combinaison qui permet de prévenir les erreurs, de limiter les impacts et de réagir vite quand quelque chose dévie.
| Contrôle | Recommandation de base | Quand aller plus loin |
|---|---|---|
| Clés de comptes de service | Limiter fortement leur création et leur téléchargement | Si une exception métier impose encore une clé persistante |
| VPC Service Controls | Les appliquer largement, ou au moins sur les projets sensibles | Si vos workloads sont très internet-facing ou si certains services ne sont pas supportés |
| Journalisation | Centraliser les logs d’audit dans un point de collecte unique | Si vous alimentez aussi un SIEM externe ou une chaîne SOC plus large |
| Chiffrement au repos | Accepter le chiffrement par défaut pour la plupart des usages | Si vous devez gérer vous-même les clés avec Cloud KMS et CMEK |
| Contraintes d’organisation | Bloquer les configurations risquées comme les IP publiques inutiles | Si vos exigences de sécurité ou de conformité imposent des restrictions plus fortes |
Sur les identités techniques, j’insiste encore une fois: les clés persistantes sont un vrai problème opérationnel. Une clé oubliée dans un dépôt, un ticket ou un stockage interne devient vite un vecteur d’escalade. Quand c’est possible, je préfère l’impersonation de compte de service ou la fédération de charge de travail, car on remplace un secret durable par un mécanisme beaucoup plus maîtrisable.
Pour les risques d’exfiltration, VPC Service Controls reste une brique utile, mais elle doit être choisie avec réalisme. Elle est très pertinente quand on stocke des données sensibles et que les services supportés s’y prêtent. En revanche, si les workloads exigent un accès Internet large ou dépendent de services non pris en charge, il faut accepter qu’un périmètre trop ambitieux devienne lourd à opérer. Je préfère un périmètre bien appliqué sur un sous-ensemble critique qu’une protection théorique, trop large pour être maintenue.
La journalisation centralisée mérite la même rigueur. Les logs d’audit, les logs de règles de pare-feu et les traces réseau utiles à l’analyse doivent remonter vers un emplacement central, avec des durées de rétention adaptées. Si l’équipe sécurité travaille dans un SIEM externe, il faut décider ce qui reste dans Google Cloud et ce qui en sort, car l’export massif peut vite coûter cher et complexifier l’exploitation. Côté chiffrement, le chiffrement par défaut suffit pour beaucoup de cas; CMEK devient intéressant quand la conformité exige un contrôle explicite des clés. Une fois ces choix verrouillés, il reste la question la plus sensible de toutes: comment déployer sans figer la base dans un design trop lourd.
Déployer sans rigidifier la base
La meilleure manière de rater une landing zone est de vouloir qu’elle couvre tout, tout de suite. Je conseille l’inverse: une première version nette, automatisée et gouvernable, puis des extensions au fil des besoins réels. La documentation Google Cloud va dans ce sens: construire un socle avant les premiers workloads d’entreprise, puis le faire évoluer au rythme des usages.
- Je commence par une équipe transverse qui réunit sécurité, identité, réseau, exploitation et pilotage projet.
- Je choisis ensuite les premiers workloads les plus simples à accueillir, pas les plus complexes.
- Je codifie le socle avec de l’infrastructure as code plutôt que de multiplier les actions manuelles.
- Je définis un chemin d’exception clair pour les cas qui imposent une dérogation.
- Je garde de la place pour la croissance, notamment si une connexion on-premise ou une seconde landing zone devient nécessaire plus tard.
Cette approche évite deux pièges récurrents: le surdesign et le bricolage permanent. Le surdesign apparaît quand on essaie d’anticiper tous les cas d’usage possibles avant même d’avoir déployé un premier workload. Le bricolage permanent, lui, arrive quand on n’a pas posé de garde-fous et qu’on compense ensuite avec des exceptions de plus en plus difficiles à suivre. Entre les deux, il y a une voie pragmatique: un socle suffisant, cohérent et automatisable.
Quand les besoins de conformité, de souveraineté ou de segmentation deviennent très différents d’un groupe d’applications à l’autre, je n’hésite pas à séparer les bases. Une seule landing zone ne doit pas porter des exigences incompatibles sous prétexte de simplicité. Ce qui compte, ce n’est pas de forcer tout le monde dans le même moule, mais de garder un modèle gouvernable qui reste lisible pour les équipes comme pour les auditeurs.
Les arbitrages qui changent le plus votre audit et votre rythme
Si je devais résumer la méthode, je dirais ceci: commencez par une racine claire, une identité maîtrisée, une hiérarchie lisible, un réseau sobre et une journalisation centralisée. C’est ce noyau qui donne de la vitesse sans sacrifier la sécurité. Le reste vient ensuite, par extension et non par empilement.
Trois erreurs reviennent sans cesse: copier l’organigramme au lieu d’organiser l’usage, autoriser trop tôt des clés persistantes, et repousser la centralisation des logs parce qu’elle semble moins urgente que le premier déploiement. En réalité, ce sont souvent ces décisions-là qui coûtent le plus cher à corriger plus tard. Une base propre au départ économise du temps de projet, du temps d’exploitation et beaucoup d’énergie d’audit.
La bonne landing zone n’est pas celle qui prétend tout résoudre. C’est celle qui permet de déployer des ressources sur Google Cloud avec un niveau de confiance suffisant pour que la plateforme devienne un accélérateur, pas un sujet de reprise permanente.
