Construisez sur le cloud qui fait tourner Google.

Le cloud, c’est simplement louer des ordinateurs auxquels on accède par internet au lieu d’acheter et d’exploiter les siens. Google (comme Amazon et Microsoft) construit d’immenses centres de données pleins de serveurs, et vous louez exactement ce dont vous avez besoin, quand vous en avez besoin, en ne payant que cela.

Pourquoi cela a tout changé :

• Aucun coût initial — pas besoin d’acheter un serveur à 5 000 $ en espérant grandir ensuite.
• Élastique — besoin de 50 serveurs pour un week-end chargé ? Louez-les vendredi, libérez-les lundi.
• Mondial — servez des utilisateurs à Lagos et à Londres depuis des centres proches de chacun.

Le cloud de Google est physiquement réparti sur la planète. Une région est une zone géographique (par exemple europe-west1 en Belgique) ; chaque région a plusieurs zones (centres de données isolés en son sein). Vous choisissez où vivent vos ressources.

Deux raisons rendent ce choix important : la latence (plus près de vos utilisateurs = plus rapide) et la résilience (répartir sur plusieurs zones pour qu’une panne ne vous arrête pas).

Vous gérez tout via la Cloud Console (le tableau de bord web) ou la ligne de commande gcloud, que vous verrez au niveau intermédiaire.

Tout dans Google Cloud vit dans un projet — un conteneur pour vos ressources, votre facturation et vos permissions. Votre première vraie compétence est de garder les projets propres et de ne pas recevoir de facture surprise.

Trois habitudes qui vous protègent :

• Utiliser l’offre gratuite (Free Tier) — beaucoup de services ont un quota toujours gratuit, et les nouveaux comptes reçoivent un crédit d’essai.
• Mettre une alerte de budget — Google vous envoie un e-mail à, disons, 5 $ pour que rien ne grimpe en douce.
• Supprimer ce que vous n’utilisez pas — un serveur inactif coûte quand même.

« Les données » ne sont pas une seule chose, et Google a un outil différent pour chaque forme.

• Une base de données gère les données vivantes d’une appli — utilisateurs, commandes, messages — avec des lectures et écritures rapides.
• Un entrepôt de données contient d’énormes volumes de données historiques pour l’analyse — répondre à « qu’est-ce qui s’est le mieux vendu l’an dernier ? » sur des milliards de lignes.
• Un lac de données stocke des données brutes de tout type (fichiers, journaux, images) à bas coût jusqu’à ce que vous décidiez quoi en faire.

Choisir le bon est la moitié d’une bonne conception cloud : ne faites pas d’analytique sur la base vivante de votre appli, et n’essayez pas de servir une appli depuis un entrepôt.

BigQuery est l’entrepôt de données phare de Google, et c’est vraiment magique : vous interrogez des téraoctets de données en SQL ordinaire, en quelques secondes, sans serveur à gérer. Vous payez les données scannées par vos requêtes.

Cloud Storage est l’endroit où vivent les fichiers — images, vidéos, sauvegardes, documents. Vous les mettez dans un bucket (un conteneur de haut niveau au nom unique mondialement) et y accédez par URL.

Il propose des classes de stockage qui arbitrent le coût contre la fréquence de lecture : de Standard pour les fichiers souvent utilisés, jusqu’à Archive pour les sauvegardes qu’on ne touche presque jamais mais qu’il faut garder — des centimes par gigaoctet.

Ces mots sont lancés partout ; voici la version honnête. L’intelligence artificielle (IA) est le but large de machines faisant des choses intelligentes. L’apprentissage automatique (ML) est le principal moyen d’y arriver — au lieu d’écrire des règles à la main, on montre à un modèle beaucoup d’exemples et il apprend le motif. L’IA générative est la branche la plus récente : des modèles qui créent du texte, des images et du code, comme Gemini de Google.

L’examen Cloud Digital Leader moderne insiste beaucoup sur ce domaine, car c’est là que la valeur du cloud bouge le plus vite.

Gemini est la famille de modèles d’IA générative de Google, accessible via Vertex AI (la plateforme d’apprentissage automatique de Google). Vous pouvez l’appeler pour résumer des documents, répondre à des questions, écrire du code ou analyser des images — sans rien entraîner vous-même.

L’IA agentique est l’étape suivante : au lieu d’un modèle qui répond seulement, un agent peut agir — utiliser des outils, appeler d’autres services, accomplir une tâche en plusieurs étapes pour vous. C’est la direction que prend toute l’industrie.

Vous n’avez pas toujours besoin de construire un modèle. Google offre des API pré-entraînées — une IA prête à appeler :

• Vision API — détecter objets et texte dans les images
• Speech-to-Text et Text-to-Speech
• Translation API — texte multilingue instantané
• Natural Language API — sentiment et sens

Utilisez une API pré-entraînée quand une capacité générale suffit ; entraînez un modèle sur mesure (avec AutoML ou Vertex AI) seulement quand votre problème est propre à vos données. La règle : commencez par l’option prête à l’emploi, construisez sur mesure seulement si nécessaire.

Google vous donne une échelle de façons d’exécuter votre code, du plus de contrôle au moins de souci :

• Compute Engine — des machines virtuelles complètes que vous gérez (plus de contrôle).
• Google Kubernetes Engine (GKE) — Kubernetes géré pour les conteneurs.
• Cloud Run — donnez-lui juste un conteneur, il l’exécute et le met à l’échelle, vous ne gérez rien.
• Cloud Functions — exécuter une seule fonction sur événement, sans serveur du tout.

La modernisation, c’est monter cette échelle avec le temps — de la gestion de machines entières vers le fait de laisser Google en gérer plus, pour que votre petite équipe passe son temps sur le produit, pas sur la plomberie.

La sécurité dans le cloud est une responsabilité partagée : Google sécurise les centres de données et le matériel ; vous sécurisez vos comptes, vos données et qui accède à quoi.

L’outil central est l’IAM (gestion des identités et des accès), bâti sur un principe : le moindre privilège — donner à chaque personne et service uniquement l’accès dont il a vraiment besoin, rien de plus. L’IAM répond à « qui peut faire quoi, sur quelle ressource ».

Bien exploiter, c’est dépenser avec sagesse et connaître la santé de son système. Google donne des outils pour les deux.

Coût : les rapports de facturation montrent où va l’argent ; les remises pour usage engagé récompensent l’usage prévisible ; les alertes de budget (leçon 03) évitent les surprises.

Exploitation : Cloud Monitoring et Cloud Logging permettent de surveiller métriques et journaux sur tout ce que vous exécutez — la même discipline du « tout voir » que le cours DevOps, intégrée à la plateforme.

Google organise tout en arbre : Organisation → Dossiers → Projets → Ressources. Les permissions posées plus haut descendent, ce qui permet de gérer l’accès de tout un département en un seul endroit plutôt que ressource par ressource.

Pour une petite équipe, vous n’utiliserez peut-être que des projets — un par appli ou environnement (par ex. monappli-dev et monappli-prod). Garder la production dans son propre projet est la frontière de sécurité la plus simple et la plus solide : une erreur en dev ne peut pas toucher de vrais utilisateurs.

L’IAM accorde l’accès en liant un rôle (un ensemble de permissions) à un membre (une personne ou un service). Préférez les rôles prédéfinis (comme roles/storage.objectViewer) aux vastes Owner ou Editor — c’est le moindre privilège en pratique.

Un compte de service est une identité pour une machine, pas un humain — c’est ainsi qu’un service prouve qui il est à un autre. Votre appli utilise un compte de service pour lire un bucket, par exemple.

L’outil en ligne de commande gcloud fait tout ce que fait la console, en plus rapide et scriptable. Cloud Shell est un terminal Linux gratuit dans votre navigateur avec gcloud déjà installé — rien à configurer, fonctionne depuis n’importe quelle machine.

Une machine virtuelle Compute Engine est un ordinateur complet dans le cloud que vous contrôlez. Vous choisissez son type de machine (combien de CPU et de mémoire), sa région/zone et son image de système.

Le bon dimensionnement compte : une machine deux fois plus grosse coûte deux fois plus cher, alors commencez petit et grandissez seulement quand les métriques l’exigent. Pour les charges variables, Google peut même redimensionner ou autoscaler pour vous.

Vos ressources vivent dans un VPC (Virtual Private Cloud) — votre réseau privé dans le cloud de Google. Par défaut, presque rien n’est joignable de l’extérieur ; vous ouvrez l’accès délibérément avec des règles de pare-feu.

Une règle de pare-feu dit quel trafic est autorisé : pour un serveur web, vous autorisez le trafic entrant sur le port 80 (HTTP) et 443 (HTTPS), et le SSH (port 22) seulement depuis votre propre adresse. Tout le reste reste fermé.

Quand un seul serveur ne suffit pas — trop de trafic, ou pour éviter un point de défaillance unique — vous en faites tourner plusieurs et placez un équilibreur de charge devant. Il répartit les requêtes entrantes sur vos serveurs et cesse d’envoyer du trafic à ceux qui sont en mauvaise santé.

L’équilibreur de Google est mondial : les utilisateurs sont dirigés automatiquement vers les serveurs sains les plus proches. Combiné à l’autoscaling (ajouter des serveurs quand c’est chargé, en retirer quand c’est calme), c’est ainsi qu’on absorbe un pic de trafic sans paniquer — et sans payer une capacité inactive le reste du temps.

En prolongement de la leçon débutant sur les buckets : le travail de l’ingénieur est d’adapter la classe de stockage aux vrais schémas d’accès et d’automatiser les déplacements. Standard pour les données chaudes, Nearline/Coldline pour un accès mensuel/trimestriel, Archive pour garder-mais-rarement-toucher.

Deux bases gérées couvrent la plupart des besoins. Cloud SQL est du PostgreSQL ou MySQL géré — la base relationnelle familiale, mais Google s’occupe des sauvegardes, des correctifs et de la bascule. Firestore est une base NoSQL de documents gérée qui passe à l’échelle sans effort et se synchronise en temps réel — parfait pour le mobile et le web.

Relationnel (Cloud SQL) quand vos données ont une structure et des relations claires (commandes, factures) ; document (Firestore) quand vous voulez flexibilité et mises à jour en temps réel (chat, tableaux de bord vivants). « Géré » est le mot clé : vous obtenez une vraie base de production sans devenir administrateur de bases de données.

Deux façons d’exécuter des conteneurs, correspondant à l’échelle du niveau débutant. GKE est du Kubernetes géré — pleine puissance et contrôle, pour les systèmes complexes à nombreux services. Cloud Run est la voie facile — donnez-lui une image de conteneur et il l’exécute, la met à l’échelle sous la charge, et la descend à zéro au repos, donc vous ne payez rien quand personne ne l’utilise.

Cloud Monitoring et Cloud Logging de Google collectent automatiquement métriques et journaux de tout ce que vous exécutez. Le travail de l’ingénieur est de construire un tableau de bord des quelques signaux qui comptent (débit de requêtes, taux d’erreur, latence) et de poser une politique d’alerte qui vous prévient quand un vrai problème commence — les quatre signaux d’or, cette fois sur GCP.

Une vérification de disponibilité, c’est Google qui demande régulièrement à votre site « es-tu en ligne ? » depuis le monde entier. S’il cesse de répondre, vous êtes alerté — souvent avant qu’un seul utilisateur ne se plaigne. Associez-la à une politique d’alerte vers e-mail ou SMS.

Tout ce que vous avez fait à la main — VM, réseaux, buckets, permissions — peut s’écrire en code Terraform (le même outil que le cours DevOps, avec le fournisseur Google). Tout votre environnement devient quelques fichiers texte dans Git : relisible, reproductible et reconstructible en une commande.