Module 1 — Vertex AI : composants et vocabulaire
Avant d'écrire la moindre ligne d'aiplatform, il faut poser sept mots. Aucun n'est difficile en soi, mais les confondre coûte des heures : une région mal choisie, un compte de service sans droit sur un bucket, une API oubliée. Ce module fait ce nettoyage.
Le projet, unité de tout
Un projet Google Cloud est le conteneur de tout : ressources, quotas, factures, journaux, IAM. Vertex AI n'existe pas en dehors d'un projet. Sur notre plateforme de paiement, l'équipe fraude travaille dans paiement-fraude-prod et dans un jumeau paiement-fraude-dev — même schéma d'accès, données réduites, pas de trafic client.
Chaque projet a un numéro (123456789012) et un identifiant (paiement-fraude-prod). Les scripts utilisent le numéro pour construire des ressources, l'identifiant pour la lisibilité. On les récupère en une commande :
gcloud projects describe paiement-fraude-prod --format="value(projectNumber)"
La région, contrainte à long terme
Une région est un lieu physique : europe-west1 (Belgique), us-central1 (Iowa). Le choix impose trois choses. Un modèle entraîné dans une région ne se déploie que dans la même région ; un carnet dans europe-west1 lit un bucket europe-west1 sans surcoût, mais paye le trafic sortant pour lire un bucket us-central1. Les quotas GPU varient — les NVIDIA A100 sont plus rares en Europe qu'aux États-Unis. Enfin, la résidence des données : pour des transactions bancaires françaises, europe-west9 (Paris) est souvent une exigence contractuelle.
Les API, à activer explicitement
Contrairement à un cloud plus laxiste, GCP exige d'activer chaque API avant usage. Une seule ligne :
gcloud services enable \
aiplatform.googleapis.com \
storage.googleapis.com \
bigquery.googleapis.com \
artifactregistry.googleapis.com \
compute.googleapis.com
Oublier artifactregistry.googleapis.com fait échouer un CustomTrainingJob avec un message sibyllin sur une image Docker introuvable, alors qu'elle est bien poussée. Toujours activer les cinq d'un coup au démarrage d'un projet Vertex.
Les comptes de service, où tout se joue
Un compte de service (service account) est une identité non humaine. Vertex AI en utilise deux qu'il faut distinguer, sous peine d'erreurs PermissionDenied incompréhensibles.
Le premier est le compte Vertex AI Service Agent, créé automatiquement à l'activation de l'API. Son adresse suit la forme :
service-<numero-projet>@gcp-sa-aiplatform.iam.gserviceaccount.com
C'est lui qui, sous le capot, orchestre les tâches — il lit vos données, écrit vos modèles. S'il manque un droit sur un bucket, aucun message d'erreur ne dira « le service agent n'a pas accès », vous verrez seulement « Job failed ».
Le second est le compte d'exécution que vous attachez au job. Par défaut, Vertex utilise le compte Compute Engine par défaut du projet — jamais une bonne idée en production. On en crée un dédié :
gcloud iam service-accounts create vertex-fraude-runner \
--display-name="Vertex — entraînement fraude"
gcloud projects add-iam-policy-binding paiement-fraude-prod \
--member="serviceAccount:vertex-fraude-runner@paiement-fraude-prod.iam.gserviceaccount.com" \
--role="roles/aiplatform.user"
Il faut trois rôles minimum : roles/aiplatform.user (lancer les tâches), roles/storage.objectAdmin (lire les données, écrire le modèle) et roles/bigquery.dataViewer sur les tables sources. Le principe du moindre privilège s'applique : jamais roles/owner.
La carte des services
Vertex AI regroupe des briques que vous croiserez toutes dans ce cours :
| Brique | Rôle | Module |
|---|---|---|
| Workbench | Carnets Jupyter gérés | 2 |
| Datasets | Catalogue des jeux de données | 3 |
| Training | Tâches d'entraînement personnalisées | 4 |
| Vizier | Réglage d'hyperparamètres | 5 |
| Model Registry | Registre de modèles versionnés | 6 |
| Endpoints | Points de terminaison en ligne | 7 |
| Batch Prediction | Prédiction hors ligne | 8 |
| Pipelines | Orchestration de bout en bout | 9 |
| Model Garden | Catalogue de modèles de fondation | 10 |
Chacune est accessible depuis la même console console.cloud.google.com/vertex-ai, avec le même SDK Python google-cloud-aiplatform — c'est cette unification qui distingue Vertex de l'ancienne AI Platform.
La facturation à la seconde
La facturation Vertex est à la seconde, ce qui change les habitudes prises sur d'autres plateformes. Un carnet oublié allumé toute la nuit coûte huit heures de machine, pas rien mais borné ; un entraînement mal cadré qui tourne trois jours coûte trois jours pleins de GPU — et il n'y a pas de plafond automatique. Trois réflexes protègent l'équipe :
- Arrêt à l'inactivité sur les carnets (module 2).
- Étiquettes (
labels) systématiques :equipe=fraude,env=dev, exploitables pour retrouver qui a lancé quoi dans le rapport de facturation. - Budget d'alerte par projet, à 50 %, 80 % et 100 % du budget mensuel prévu.
Un projet neuf laisse Vertex utiliser le compte Compute Engine par défaut, qui a le rôle roles/editor — quasiment owner. Un carnet compromis peut alors supprimer toutes les ressources du projet. Créez un compte dédié dès le premier job, même en développement : c'est cinq minutes maintenant qui évitent un audit dans six mois.
En résumé
- Un projet contient tout ; garder un jumeau
devavec les mêmes accès queprodévite les mauvaises surprises. - La région est fixée pour la vie du modèle : entraînement, déploiement et données doivent y résider ensemble.
- Il faut activer les API explicitement — cinq services au minimum pour un projet Vertex.
- Deux comptes de service : l'agent Vertex (créé) et le compte d'exécution (à créer, dédié, moindre privilège).
- La facturation à la seconde ne pardonne pas les carnets oubliés :
labelset budgets d'alerte dès le début.
Module suivant : nous ouvrons le premier carnet Workbench, connecté à BigQuery, avec arrêt automatique à l'inactivité.