Module 2 — Studio, carnets et environnements de travail

Tout le fil rouge s'écrit depuis un carnet. Ce module explique comment le carnet est provisionné, sur quelle machine il tourne, ce qu'il partage entre deux sessions et — le seul point à ne jamais oublier — comment il s'éteint tout seul quand vous fermez l'onglet.

Le domaine et le profil : deux notions à ne pas confondre

SageMaker Studio s'organise autour d'un domaine, créé une fois par équipe ou par entreprise, dans une région AWS donnée. Un domaine contient : un système de fichiers EFS partagé, un VPC d'exécution, une configuration réseau, et un ensemble de UserProfile — un par personne qui travaille dans Studio.

Objet	Portée	Ce qu'il porte
Domaine	Compte AWS, région	EFS, VPC, images autorisées, rôle par défaut
UserProfile	Un utilisateur humain	Rôle IAM propre, tags, préférences, historique
Application	Une session ouverte	Type d'instance, image de noyau, charge active

Un utilisateur n'ouvre pas Studio « en général » : il ouvre une application — un JupyterServer, un KernelGateway pour un noyau donné, un TensorBoard — chacune tournant sur un type d'instance qui sera facturé à la seconde.

L'application JupyterServer et l'application KernelGateway

C'est le point le plus déroutant pour qui vient d'un carnet local. Studio ne fait pas tourner votre code là où l'interface s'affiche. Il sépare :

• une application JupyterServer — l'interface, typiquement sur ml.t3.medium gratuit dans la première année, sinon environ 0,05 $/h ;
• une application KernelGateway — le noyau Python qui exécute vos cellules, sur le type d'instance que vous choisissez pour la charge de travail (par exemple ml.m5.xlarge à 0,23 $/h, ou ml.g4dn.xlarge à 0,74 $/h pour un GPU).

Cette séparation a une conséquence pratique : vous pouvez ouvrir Studio sur un t3.medium bon marché et avoir un noyau sur g4dn.xlarge uniquement pendant l'entraînement, puis fermer le noyau et garder l'interface ouverte. Sans cette hygiène, le GPU tournerait toute la journée pour trois cellules.

Images de noyau et paquets

Chaque noyau s'appuie sur une image Docker qui définit la version de Python et les bibliothèques préinstallées. AWS fournit une douzaine d'images (Data Science 3.0, PyTorch 2.x, TensorFlow 2.x, SageMaker Distribution récente). Le fil rouge utilisera SageMaker Distribution — qui contient pandas, scikit-learn, xgboost, mlflow et le SDK sagemaker — pour ne rien avoir à installer.

Si votre projet a besoin de dépendances qui ne sont pas dans l'image, deux options :

Option pragmatique : %pip install dans une cellule, qui installe dans un dossier persistant sur EFS. Cela survit aux redémarrages du noyau mais pas à un changement d'image, et cela reste local à Studio. Pour un cours ou un prototype, c'est acceptable.

Option de production : construire une image personnalisée — un Dockerfile qui étend une image officielle, publié sur ECR, et enregistré dans le domaine. Chaque redémarrage repart d'une base propre et reproductible. C'est le choix quand plusieurs personnes doivent partager l'environnement, et c'est le pont vers le module 5 (conteneurs personnalisés).

Arrêt automatique — le seul réglage à ne jamais oublier

Un carnet Studio ouvert continue à facturer tant que l'application KernelGateway est démarrée, même si votre onglet est fermé, votre ordinateur éteint, et vous en week-end.

AWS a fini par ajouter une extension d'arrêt automatique (sagemaker-studio-analytics-extension puis, plus récemment, une configuration native au niveau du domaine). Elle éteint les applications inactives depuis un certain temps :

# À placer dans le LifecycleConfig du domaine, exécuté à chaque démarrage
# d'application. Le seuil est en minutes.
IDLE_TIMEOUT=120
echo "Arrêt automatique après ${IDLE_TIMEOUT} minutes d'inactivité"

Sur le fil rouge, ce seuil est passé à 60 minutes après un incident où un stagiaire a laissé un ml.g4dn.xlarge allumé quatre jours (89 $ pour rien).

Le carnet oublié coûte plus qu'on ne croit

Sur un ml.m5.4xlarge (0,92 $/h), un carnet oublié un long week-end coûte environ 66 $. Sur un ml.g4dn.12xlarge (3,91 $/h), la même négligence coûte 282 $. La ligne de facture n'apparaît qu'un mois plus tard, sans lien évident avec l'oubli. La configuration d'arrêt automatique est le seul geste qui protège vraiment.

Le stockage EFS partagé du domaine

Chaque utilisateur du domaine a un dossier /home/sagemaker-user sur un système de fichiers EFS, partagé entre tous les carnets qu'il ouvre. Cela signifie :

• vos carnets, données locales et environnements virtuels persistent entre deux sessions ;
• vous pouvez fermer un noyau g4dn, en rouvrir un m5 et retrouver votre code ;
• l'espace utilisé est facturé au Go/mois EFS, environ 0,30 $/Go/mois — modeste tant que vous n'y stockez pas des jeux de données.

La bonne discipline consiste à garder sur EFS le code et les notes, et à laisser les données brutes sur S3. Un CSV de 3 Go sur EFS coûte 1 $/mois pour rien, alors que le même fichier sur S3 Standard coûte 7 centimes/mois, avec l'avantage d'être accessible aux tâches d'entraînement sans configuration réseau.

Ouvrir un terminal, pas seulement un carnet

Studio expose aussi un terminal complet, avec git, aws, docker (limité au démon de l'application) et le SDK Python. Trois usages reviennent constamment :

# Cloner votre dépôt sur EFS pour versionner vos carnets
git clone https://github.com/mon-org/resiliation-sagemaker.git

# Copier un fichier local vers S3
aws s3 cp donnees.csv s3://resiliation-donnees/brut/

# Lister les tâches d'entraînement récentes
aws sagemaker list-training-jobs --max-results 5 \
  --sort-by CreationTime --sort-order Descending

Le SDK Python est excellent pour orchestrer, mais un terminal reste indispensable pour lire un journal CloudWatch, corriger un IAM ou déboguer un accès S3.

Une session type sur le fil rouge

Voici la séquence qui reviendra dans tous les modules qui suivent :

1. Ouvrir Studio → application JupyterServer sur ml.t3.medium démarre en 30 secondes.
2. Ouvrir un carnet avec le noyau Data Science sur ml.m5.xlarge → application KernelGateway démarre en 90 secondes.
3. Explorer les données resiliation.csv depuis S3, écrire le script d'entraînement.
4. Lancer une tâche d'entraînement SageMaker (module 4) : elle démarre une autre instance, dédiée, qui s'éteindra seule.
5. Fermer le noyau ml.m5.xlarge à la fin de la journée.
6. L'arrêt automatique à 60 minutes éteint le noyau si vous oubliez.

Cette discipline sépare deux régimes : votre carnet est un environnement d'écriture, il tourne peu et sur une petite machine ; les tâches d'entraînement sont des jobs éphémères qui utilisent la grosse machine et s'éteignent tout seuls.

En résumé

• Studio s'organise en domaine (une fois par équipe), profils utilisateurs (un par personne) et applications (une par session, facturée à la seconde).
• L'interface JupyterServer et les noyaux KernelGateway tournent sur des instances distinctes ; utilisez une petite pour l'interface, une grosse seulement pour la charge de travail.
• Les images de noyau définissent Python et les bibliothèques ; %pip install suffit en prototype, une image ECR personnalisée pour la production.
• L'arrêt automatique est le seul réglage qui protège de la facture surprise ; combiné avec le stockage EFS pour le code et S3 pour les données, il maintient un environnement propre et bon marché.

Module suivant : les données sur S3, l'organisation des préfixes et le magasin de variables Feature Store — sur quoi les tâches d'entraînement iront s'alimenter.