Cours Google Cloud (GCP) — organisation, projets, IAM, Compute Engine, Cloud Storage, VPC, facturation et gcloud en lecture

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. décrire la hiérarchie organisation, dossiers, projets, ressources et dire ce qu'elle change pour les droits ;
2. expliquer IAM (principal, rôle, politique d'autorisation) et appliquer le moindre privilège ;
3. situer Compute Engine, Cloud Storage et les réseaux VPC dans un projet ;
4. expliquer la facturation, les budgets et leur limite (une alerte n'arrête pas la dépense) ;
5. lire l'état d'un environnement avec gcloud sans rien modifier ;
6. identifier les commandes qui créent des coûts ou détruisent des données et prévoir leur retour arrière ;
7. dire ce qui n'est pas vérifié dans ce cours.

Prérequis

• Notions de machine virtuelle, de stockage objet et de réseau IP (adresse, sous-réseau, pare-feu).
• Lire une commande dans Terminal (voir le cours Terminal macOS).
• Aucun compte Google Cloud n'est requis pour lire ce cours. Pour pratiquer : un projet de test jetable, un budget d'alerte posé avant toute création, et jamais de ressource de production.

Parcours et chapitres

1. Organisation, dossiers, projets, ressources

D'après « Resource hierarchy » (état du 13 octobre 2026), les ressources Google Cloud sont organisées en quatre niveaux :

1. l'organisation (racine, par exemple une entreprise) ;
2. les dossiers (facultatifs : services, équipes) ;
3. les projets, unité de base qui contient les ressources ;
4. les ressources de service (machines virtuelles, buckets, etc.).

Les politiques de contrôle d'accès appliquées à un niveau sont héritées par les ressources en dessous. Un projet a trois attributs : un ID de projet (choisi, unique), un numéro de projet (généré, en lecture seule) et un nom affiché (modifiable). La page indique qu'un compte Google Workspace ou Cloud Identity est nécessaire pour accéder à la ressource « organisation » et que celle-ci est créée automatiquement au premier projet créé dans ce cas ; le cas d'un compte Google personnel (sans organisation) n'est pas détaillé dans la page lue : non vérifié.

2. IAM : qui peut faire quoi sur quelle ressource

La page « IAM overview » (13 octobre 2026) définit IAM par trois éléments : des principals (identités humaines ou charges de travail), des rôles (ensembles de permissions) et des ressources. Une allow policy est attachée à une ressource et contient des liaisons (rôle + principals) ; quand un principal authentifié accède à la ressource, IAM consulte cette politique. Les politiques sont héritées le long de la hiérarchie.

Types de rôles cités : prédéfinis (gérés par Google), personnalisés (créés par l'utilisateur) et basiques, que la page qualifie de très permissifs, à réserver aux tests, pas à la production. IAM propose aussi des politiques de refus (deny), des limites d'accès des principals, des conditions IAM et un accès privilégié temporaire.

3. Compute Engine

D'après « Instances overview » : une instance Compute Engine est une machine virtuelle ou une machine physique (types se terminant par -metal) hébergée chez Google ; elle appartient à un projet et à une zone, a un disque de démarrage, peut recevoir des disques supplémentaires, et ses interfaces réseau sont rattachées à des sous-réseaux VPC. Les types de machines sont prédéfinis ou personnalisés. L'accès Linux se fait par OS Login ou clés SSH. Fuseau par défaut : UTC.

La facturation d'une instance arrêtée (disques, adresses IP réservées) n'est pas établie par les pages lues : non vérifié. Règle de prudence : une instance de test se supprime une fois l'exercice terminé, avec ses disques si elle a été créée pour cela.

4. Cloud Storage

D'après « Cloud Storage overview » : le stockage objet est organisé en projets, buckets (conteneurs avec classe de stockage et emplacement géographique) et objets (fichiers immuables). Classes citées : Standard, Nearline, Coldline, Archive et Rapid, avec Autoclass. L'accès se fait par la console, la CLI, des bibliothèques clientes ou l'API REST.

5. Réseau VPC

D'après « VPC networks » (13 octobre 2026) : un réseau VPC est une version virtuelle d'un réseau physique, implémentée dans le réseau de production de Google. Le réseau, ses routes et ses règles de pare-feu sont des ressources globales ; les sous-réseaux sont régionaux. Deux modes : automatique (un sous-réseau par région dans 10.128.0.0/9) et personnalisé (sous-réseaux créés à la main, recommandé pour la production). Un projet démarre normalement avec un réseau default en mode automatique, sauf politique d'organisation contraire. Sur le réseau default, une règle (default-allow-internal) autorise la communication interne ; sur un autre réseau, les règles d'entrée doivent être écrites explicitement.

6. Facturation, budgets et paliers gratuits

Budgets. D'après « Budgets » (page lue) : il existe des budgets d'alerte seule, qui envoient des notifications aux seuils choisis (réels ou prévus), et des budgets à plafond de dépense, qui peuvent mettre en pause certains services éligibles. La page est explicite : un budget d'alerte seule ne plafonne pas l'usage ni la dépense. Les données de coût arrivent avec un délai (plusieurs heures au début). Un compte de facturation accepte jusqu'à 50 000 budgets. La gestion dépend des rôles (administrateur de compte de facturation, propriétaire de projet, rôle personnalisé). Les services éligibles au plafond ne sont pas listés ici : non vérifié.

Paliers gratuits (état consulté le 2026-10-17, à ne pas promettre) : la page « Free cloud features » décrit un essai de 90 jours avec un crédit de 300 dollars pour les nouveaux clients, et des produits « toujours gratuits » avec limites, par exemple pour Compute Engine une instance e2-micro par mois dans certaines régions des États-Unis, et pour Cloud Storage 5 Go-mois de stockage régional (régions des États-Unis). Après l'essai ou l'épuisement du crédit, il faut passer à un compte payant sous peine de perdre l'accès, avec une période de grâce de 30 jours. Conditions, régions, exclusions et changements : à relire sur la page à chaque usage.

7. gcloud CLI : lecture seule

La page d'installation indique la CLI gcloud (version 589.0.0 à la date consultée) ; gcloud init configure l'accès et les valeurs par défaut, gcloud auth list et gcloud config list vérifient l'installation. Le cours ne couvre pas l'installation. Les commandes ci-dessous lisent seulement ; elles supposent un compte déjà configuré par Stéphane.

gcloud --versiongcloud auth listgcloud config list

• Contexte : poste avec gcloud CLI installée.
• Droits : aucun droit cloud particulier.
• Effet : affiche la version, les comptes connectés et la configuration active (compte, projet par défaut).
• Vérification : le projet affiché est bien le projet de test voulu.
• Retour arrière : sans objet (lecture).

gcloud organizations listgcloud projects listgcloud projects describe <ID-PROJET>gcloud projects get-iam-policy <ID-PROJET>

• Contexte : projet et organisation de test.
• Droits : lecture sur l'organisation et le projet.
• Effet : liste les ressources et affiche la politique IAM du projet.
• Vérification : repérer les rôles basiques (propriétaire, éditeur) accordés.
• Retour arrière : sans objet. La sortie contient des adresses de principals : ne pas la copier dans un dépôt ni dans un prompt.

gcloud compute instances list --project=<ID-PROJET>gcloud compute networks list --project=<ID-PROJET>gcloud compute networks subnets list --project=<ID-PROJET>gcloud storage buckets list --project=<ID-PROJET>gcloud billing accounts list

• Contexte : projet de test ; API Compute Engine activée pour les trois premières commandes (sinon la CLI propose de l'activer : refuser sans validation).
• Droits : lecture des ressources concernées.
• Effet : inventaire des instances, réseaux, sous-réseaux, buckets et comptes de facturation.
• Vérification : comparer avec l'inventaire attendu ; toute ressource inconnue est à investiguer (coût possible).
• Retour arrière : sans objet.

8. Créer puis supprimer une ressource de test (à effet et coût)

Exemple pour comprendre le cycle ; non exécuté par ce corpus.

Attention, effet notable. Crée une machine virtuelle facturable (coût). Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

gcloud compute instances create <NOM-INSTANCE> --project=<ID-PROJET> --zone=<ZONE> --machine-type=e2-micro

• Contexte : projet de test avec facturation activée.
• Droits : rôle permettant de créer des instances.
• Effet : crée une VM, son disque de démarrage et une interface réseau ; génère des coûts tant qu'elle existe (le palier gratuit, s'il s'applique, a des conditions de région : voir chapitre 6).
• Vérification : gcloud compute instances list la montre.
• Retour arrière : commande suivante.

Attention, effet notable. Supprime la machine virtuelle (données perdues). Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

gcloud compute instances delete <NOM-INSTANCE> --project=<ID-PROJET> --zone=<ZONE>

• Contexte : même projet de test.
• Droits : rôle permettant de supprimer des instances.
• Effet : supprime la VM ; selon les options, les disques peuvent être supprimés avec elle (comportement par défaut non vérifié dans les pages lues).
• Vérification : l'instance et ses disques n'apparaissent plus dans les listes ; la facturation du lendemain ne montre plus de ligne associée.
• Retour arrière : aucun ; les données non sauvegardées sont perdues.

Exercices et vérifications de fin de cours

Tous sont sur papier ou en lecture seule.

1. Hiérarchie. Placer sur le schéma : une VM, un bucket, un réseau VPC et une liaison IAM « lecture seule » accordée à une équipe.
2. Moindre privilège. Remplacer un rôle basique « éditeur » par un rôle prédéfini plus étroit pour un besoin fictif, en citant le niveau choisi.
3. Budget. Rédiger les seuils d'un budget d'alerte pour un projet de test (par exemple 50 %, 90 %, 100 %) et lister ce qu'il n'empêche pas.
4. Lecture. À partir d'une sortie fictive de gcloud projects get-iam-policy, repérer les rôles trop larges.
5. Nettoyage. Écrire la liste de contrôle de fin d'exercice (instances, disques, adresses IP, buckets, règles de pare-feu, budget conservé).

Critères de réussite

• Expliquer l'héritage des droits dans la hiérarchie.
• Distinguer alerte de budget et plafond de dépense.
• Ne jamais placer de clé ni de jeton dans un fichier, un dépôt ou un prompt.
• Dire ce qui n'est pas vérifié et distinguer documentation et usage réel.