Module 3 — Données sur S3 et magasins de variables

Toutes les tâches SageMaker se nourrissent de S3 et y déposent leurs artefacts. Le module précédent a laissé de côté le contenu du seau resiliation-donnees ; celui-ci l'organise, l'expose au conteneur d'entraînement du module 4, et introduit le magasin de variables pour partager les mêmes variables entre entraînement et inférence.

Un préfixe par étape du cycle de vie

Un projet qui grandit finit par mélanger, dans un même seau, données brutes, données préparées, sorties d'entraînement et scores de production. L'organisation par préfixe — S3 n'a pas de vrai dossier, mais utilise le / comme séparateur logique — évite l'accident.

Voici la convention que suivra le fil rouge :

s3://resiliation-donnees/
  brut/                       # export CRM, jamais modifié
    2026-08/appels.csv
    2026-08/clients.csv
  prepare/                    # sortie de la tâche de préparation
    v3/train.parquet
    v3/valid.parquet
    v3/test.parquet
  scores/                     # sortie du scoring mensuel (module 8)
    2026-09/predictions.csv

s3://resiliation-modeles/     # seau distinct
  xgboost/2026-09-01/model.tar.gz
  sklearn/2026-09-01/model.tar.gz

Trois règles se dégagent. Un seau distinct pour les modèles, parce que les politiques d'accès et de rétention diffèrent : les données brutes contiennent parfois des identifiants clients (règles internes RGPD), les modèles non. Un préfixe versionné (v3/) pour la préparation, qui permet de retracer quelle version a servi à quel entraînement. Un préfixe daté (2026-08/) pour les données brutes, qui rend la reprise à un mois donné triviale.

CSV, Parquet, RecordIO : ce que voit le conteneur

SageMaker sait lire trois formats principaux, et le choix n'est pas neutre pour la vitesse et le coût.

Format	Poids	Lecture par XGBoost	Quand l'utiliser
`CSV`	Le plus lourd	OK, mais lent au-delà de 10 Go	Premier prototype, données inspectables à l'œil
`Parquet`	4 à 10 × plus léger	Excellent, colonnaire	Défaut pour tout ce qui dépasse 100 000 lignes
`RecordIO Protobuf`	Compact et rapide	Format natif des algorithmes intégrés	Optimisation fine, entraînement distribué

Sur le fil rouge, resiliation.csv fait 240 Mo brut ; converti en Parquet compressé Snappy, il tombe à 32 Mo, se lit trois fois plus vite, et fait chuter la sortie réseau de S3 vers l'instance d'entraînement — qui n'est pas facturée dans la même région, mais qui influence quand même la durée de la tâche donc la facture d'instance.

import pandas as pd
df = pd.read_csv("s3://resiliation-donnees/brut/2026-08/appels.csv")
df.to_parquet(
    "s3://resiliation-donnees/prepare/v3/train.parquet",
    engine="pyarrow", compression="snappy", index=False,
)

Les canaux d'entrée : `train`, `validation`, `test`

Une tâche d'entraînement reçoit des canaux, chacun étant un préfixe S3 monté dans le conteneur sous /opt/ml/input/data/<canal>/. Les noms train et validation sont conventionnels et reconnus par les algorithmes intégrés ; le canal test sert typiquement à un ensemble tenu à part.

estimateur.fit({
    "train":      "s3://resiliation-donnees/prepare/v3/train.parquet",
    "validation": "s3://resiliation-donnees/prepare/v3/valid.parquet",
})

Deux modes de transfert existent, et ils changent le coût :

File (défaut) : SageMaker copie tout le fichier sur le disque local de l'instance avant de démarrer. Simple, mais monopolise le disque et rallonge la tâche.
Pipe : les données sont lues en flux depuis S3 pendant l'entraînement, sans copie complète. Utile au-delà de quelques dizaines de Go, notamment pour Linear Learner et XGBoost 1.7+.

Sur resiliation-donnees en dessous du Go, File est parfait ; à partir de 50 Go, Pipe gagne 30 à 50 % de temps de tâche.

Chiffrement — le geste par défaut

Un seau S3 utilisé par SageMaker en production doit être chiffré au repos. Trois options :

SSE-S3 : AWS gère les clés, transparent, gratuit — le minimum.
SSE-KMS avec une clé AWS gérée : contrôle des accès via KMS, journal CloudTrail, encore transparent.
SSE-KMS avec une clé propre (CMK) : rotation à votre main, permet de couper l'accès en supprimant la clé — obligatoire dès qu'il y a des données réglementées.

Le rôle d'exécution SageMaker doit alors avoir la permission kms:Decrypt sur la clé, faute de quoi la tâche échoue au démarrage avec un message peu explicite (AccessDeniedException sur GetObject). C'est l'une des trois causes d'échec d'entraînement les plus fréquentes en production.

Le magasin de variables `Feature Store`

Sur le fil rouge, la variable nb_appels_support_30j est calculée pendant l'entraînement à partir de appels.csv. Elle doit être la même en production, calculée sur les 30 derniers jours glissants pour chaque client — ni plus, ni moins.

Sans Feature Store, cette variable existe deux fois : une fois dans le script d'entraînement, une fois dans le service d'inférence. Un décalage entre les deux (par exemple 30 jours calendaires contre 30 jours ouvrés) est la définition même de la fuite ou de la dérive silencieuse.

Le magasin de variables résout cela avec deux magasins liés :

Magasin	Support	Latence	Usage
Hors ligne (`offline store`)	S3 + `Glue` catalog	secondes	Entraînement, ré-entraînement, audit historique
En ligne (`online store`)	`DynamoDB` géré	millisecondes	Point de terminaison temps réel

Une feature group est créée une fois, puis les variables y sont ingérées :

from sagemaker.feature_store.feature_group import FeatureGroup

fg = FeatureGroup(name="client_resiliation_v1", sagemaker_session=session)
fg.load_feature_definitions(data_frame=df_features)  # colonnes + types
fg.create(
    s3_uri="s3://resiliation-donnees/feature-store/",
    record_identifier_name="client_id",
    event_time_feature_name="date_calcul",
    role_arn=role,
    enable_online_store=True,
)
fg.ingest(data_frame=df_features, max_workers=4)

À l'inférence, le point de terminaison lit la ligne du magasin en ligne :

enregistrement = fs.get_record(
    feature_group_name="client_resiliation_v1",
    record_identifier_value_as_string="C-9871",
)

Le lien profond entre magasin en ligne et hors ligne est la garantie que l'entraînement et l'inférence voient les mêmes valeurs. Ce cours ne s'y attarde pas plus — le cours 33 est entièrement dédié aux magasins de variables — mais l'introduire dès maintenant place le fil rouge sur des rails.

Quand ne pas utiliser Feature Store

Feature Store a un coût fixe modeste mais réel : environ 1 $/mois pour un magasin hors ligne d'un projet moyen, plus le DynamoDB du magasin en ligne. Pour un prototype ou un modèle qui prédit sur des variables calculées à la volée à partir de la requête, il est inutile. Les cinq variables du fil rouge (nombre d'appels, ancienneté, forfait, retard de paiement, région) le justifient à peine ; on l'introduit ici pour l'exercice pédagogique et parce que la promotion en production le rendra utile.

En résumé

Organisez S3 avec des préfixes distincts par étape (brut/, prepare/v3/, scores/, feature-store/) et un seau séparé pour les modèles.
Le format Parquet compressé remplace CSV dès quelques centaines de milliers de lignes ; il divise le poids par 4 à 10 et raccourcit la tâche d'entraînement.
Les canaux train et validation sont montés dans le conteneur ; le mode File est le défaut, Pipe devient utile au-delà de 50 Go.
Un chiffrement SSE-KMS avec une clé propre est le minimum en production, et le rôle SageMaker doit avoir kms:Decrypt.
Le Feature Store garantit que l'entraînement et l'inférence lisent les mêmes variables, via un magasin hors ligne (S3) et un magasin en ligne (DynamoDB).

Module suivant : les tâches d'entraînement gérées et l'algorithme intégré XGBoost, appliqués au fichier train.parquet qu'on vient de préparer.

Un préfixe par étape du cycle de vie​

CSV, Parquet, RecordIO : ce que voit le conteneur​

Les canaux d'entrée : train, validation, test​

Chiffrement — le geste par défaut​

Le magasin de variables Feature Store​

En résumé​