Aller au contenu principal

Module 2 — Carnets gérés et environnements de développement

Le carnet Jupyter reste le point d'entrée quotidien du travail d'un data scientist, et c'est là que Vertex AI est vu pour la première fois. Trois environnements coexistent — instances gérées Workbench, Workbench instances (nouveau format), et Colab Enterprise — et l'on choisit selon la posture de sécurité et l'usage. Ce module ouvre le premier carnet du fil rouge : lecture de la table transactions_bruts de BigQuery, exploration rapide, extraction du jeu d'entraînement.

Trois environnements, trois postures​

Vertex AI Workbench managed notebooks a été la première offre : une machine virtuelle gérée par Google, avec un plan de contrôle qui masque gcloud compute. Google l'a réunifié en 2024 sous Workbench instances : la même expérience carnet, mais s'appuyant sur une VM Compute Engine visible, ce qui permet d'appliquer les politiques d'entreprise (VPC, chiffrement CMEK, OS Login). C'est ce format qui est recommandé aujourd'hui.

Colab Enterprise est l'évolution de Google Colab pour l'entreprise. Il n'y a pas de VM à gérer : Google fournit un exécuteur temporaire, facturé au temps d'exécution effectif. Idéal pour un prototype partagé en équipe, moins adapté à un long entraînement qui doit survivre à une fermeture d'onglet.

Pour le fil rouge, nous prenons Workbench instance : les données de fraude sont sensibles, l'équipe veut du VPC privé et un chiffrement contrôlé.

Créer une instance Workbench​

En une commande :

gcloud workbench instances create fraude-carnet-01 \
  --location=europe-west1-b \
  --machine-type=n1-standard-4 \
  --idle-shutdown-timeout=1800 \
  --service-account=vertex-fraude-runner@paiement-fraude-prod.iam.gserviceaccount.com \
  --labels=equipe=fraude,env=dev

Trois paramètres importent. --idle-shutdown-timeout=1800 éteint la machine après trente minutes sans activité (mesurée sur le noyau, pas sur la souris). C'est la protection principale contre la facture oubliée du vendredi soir. --service-account évite le compte Compute par défaut, dénoncé au module 1. --labels rend la ligne identifiable dans le rapport de facturation à la fin du mois.

Une fois créée, l'instance apparaît dans la console Vertex AI. Un bouton « ouvrir JupyterLab » lance l'onglet, et l'authentification est déjà faite : le carnet hérite du compte de service passé à la création.

Choisir un noyau​

Une instance Workbench arrive avec plusieurs noyaux préinstallés : Python 3 de base, TensorFlow 2 CPU et GPU, PyTorch CPU et GPU, R. On peut ajouter les siens avec conda create ou venv, mais la méthode propre est de partir d'une image de conteneur — c'est cohérent avec l'entraînement du module 4, où le code tournera dans un conteneur.

gcloud workbench instances create fraude-carnet-02 \
  --location=europe-west1-b \
  --container-repository=europe-west1-docker.pkg.dev/paiement-fraude-prod/carnets/xgboost \
  --container-tag=2026-09

Le noyau lu par Jupyter correspond alors exactement à celui qui entraînera le modèle en production. Zéro dérive.

Accès à BigQuery depuis le carnet​

C'est le premier geste du fil rouge. La bibliothèque google-cloud-bigquery est préinstallée, et une magic %%bigquery évite d'écrire le boilerplate :

%%bigquery transactions --project paiement-fraude-prod
SELECT id_transaction, montant, pays, canal, horodatage, est_fraude
FROM `paiement-fraude-prod.transactions.transactions_bruts`
WHERE DATE(horodatage) BETWEEN '2026-06-01' AND '2026-08-31'
  AND est_fraude IS NOT NULL
LIMIT 100000

Après exécution, transactions est un DataFrame pandas dans le carnet. La table réelle fait plusieurs milliards de lignes ; le LIMIT 100000 est un garde-fou d'exploration — le module 3 montrera comment lire à l'échelle sans matérialiser dans le carnet.

Deux pièges méritent d'être connus. D'abord, la magic déclenche une facturation BigQuery à la volée ; un SELECT * sur une table de plusieurs téraoctets coûte plusieurs dizaines de dollars par exécution. Toujours nommer les colonnes et filtrer par date. Ensuite, le carnet a besoin du rôle roles/bigquery.dataViewer sur le jeu de données ; sans lui, la magic renvoie une erreur 403 sur laquelle beaucoup perdent du temps.

Colab Enterprise en une note​

Pour un notebook partagé en atelier, Colab Enterprise se justifie :

gcloud colab notebooks create fraude-atelier \
  --region=europe-west1 \
  --runtime-template=default

Le notebook est stocké dans un bucket, ouvrable par tout membre de l'équipe avec l'IAM adapté. L'exécution est facturée à la seconde d'usage de l'exécuteur, sans arrêt à programmer.

Sauvegarder son travail​

Les carnets Workbench sont stockés sur le disque persistant de l'instance. Si l'instance est supprimée, les carnets disparaissent avec elle. Deux réflexes évitent l'accident :

  • Synchroniser dans un dépôt Git dès le premier commit utile. Une instance Workbench a git préinstallé.
  • Programmer un snapshot du disque (gcloud compute disks snapshot) une fois par jour. Coûte quelques centimes, sauve la journée le jour où un collègue clique « Supprimer l'instance ».
L'arrêt à l'inactivité ne mesure pas la souris

Le compteur d'inactivité regarde l'activité du noyau Jupyter, pas les clics dans l'interface. Un carnet qui n'exécute rien mais dont on fait défiler les cellules s'éteindra quand même. À l'inverse, une cellule bloquée dans un time.sleep(3600) ou un while True: empêche l'arrêt : la machine reste allumée toute la nuit. Toujours prévoir un mécanisme de sortie explicite dans les boucles longues.

En résumé​

  • Workbench instances est le format à privilégier aujourd'hui : VM visible, VPC et CMEK possibles.
  • Colab Enterprise convient aux ateliers courts sans besoin de survivre à la fermeture d'onglet.
  • --idle-shutdown-timeout est la seule protection fiable contre les carnets oubliés — activer dès la création.
  • La magic %%bigquery fait entrer les données dans un DataFrame, mais facture à chaque exécution : filtrer et nommer les colonnes.
  • Les carnets Workbench vivent sur un disque persistant : synchroniser dans Git et prendre un snapshot quotidien.

Module suivant : nous quittons le LIMIT 100000 d'exploration pour construire le jeu d'entraînement complet à partir de BigQuery et Cloud Storage.