Amazon MLA-C01: MLOps et gestion du cycle de vie des modèles — Guide d'étude

By Laurynas Brazys · 3 August 2026 · #amazon #mla-c01 #certification #exam-prep #study-guide

Fait partie du AWS Machine Learning Engineer Associate MLA-C01 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Concept de base

La gestion du cycle de vie des modèles (MLOps) dans AWS consiste à traiter les modèles comme des artefacts versionnés avec une traçabilité auditée, des portes de promotion automatisées et des pipelines reproductibles. Amazon SageMaker fournit les primitives nécessaires : SageMaker Pipelines pour l’orchestration, le SageMaker Model Registry (ModelPackage/ModelPackageGroup) pour le versionnement et l’état d’approbation, SageMaker Projects et CodePipeline pour le CI/CD, et Model Monitor/Clarify pour les contrôles continus de la qualité et des biais. Un cycle de vie robuste commence par des entrées reproductibles : des données d’entraînement immuables dans S3 avec un chiffrement côté serveur KMS et des politiques de bucket restrictives ou des contrôles Lake Formation, du code versionné dans un dépôt source, et l’environnement d’entraînement déclaré dans les URI d’images de conteneur et les types d’instances passés à CreateTrainingJob ou au TrainingStep du SDK sagemaker.

Les contrôles opérationnels incluent l’isolation réseau via VpcConfig de CreateTrainingJob (Subnets et SecurityGroupIds) et EnableNetworkIsolation pour empêcher le trafic sortant, ainsi que des rôles IAM configurés avec le moindre privilège (SageMakerExecutionRole avec s3:GetObject, kms:Decrypt pour le bucket spécifique). Lorsqu’une tâche d’entraînement se termine, enregistrez l’artefact dans le Model Registry en utilisant CreateModelPackage ou l’appel SDK register_model avec un ModelPackageGroupName et définissez ModelApprovalStatus sur “PendingManualApproval” pour piloter les validations humaines. Les métadonnées de traçabilité — hyperparamètres d’entraînement, image Docker, URI S3 des données d’entrée, commit Git — doivent être attachées en tant que métadonnées du paquet de modèle afin que les processus CI/CD et les audits en aval puissent remonter depuis le point de terminaison de production jusqu’au code et au jeu de données.

Le CI/CD pour le ML diffère du CI/CD traditionnel car les artefacts (modèles, baselines, moniteurs) sont volumineux et ont des sorties non déterministes. Implémentez le CI/CD avec les modèles SageMaker Projects ainsi qu’AWS CodePipeline et CodeBuild. Utilisez CodeBuild pour exécuter les tests unitaires, les tests de fumée (smoke-tests) de l’entraînement du modèle (par exemple, des époques courtes ou un sous-ensemble de données), et les tests d’intégration. Utilisez CodePipeline pour orchestrer les étapes source → build → register-model, et incorporez une action d’approbation manuelle (ManualApproval) ou une action personnalisée basée sur Lambda pour changer le ModelApprovalStatus du ModelPackage via UpdateModelPackage. Pour la promotion automatisée, CodePipeline peut appeler les API SageMaker CreateEndpointConfig et CreateEndpoint, ou utiliser des piles CloudFormation générées par SageMaker Projects pour déployer avec une infrastructure-as-code prévisible.

Services clés et configuration

SageMaker Pipelines est la couche d’orchestration : déclarez les objets d’étape ProcessingStep, TrainingStep, ModelStep, TransformStep et RegisterModel en Python. Utilisez CacheConfig sur les étapes (CacheConfig(enable_caching=True, expire_after=timedelta(days=1))) pour que les étapes réutilisent les sorties lorsque les entrées et les paramètres n’ont pas changé ; cela évite le provisionnement inutile d’instances. Pour RegisterModel, utilisez sagemaker.workflow.steps.RegisterModel avec model_package_group_name et model_approval_status définis sur “PendingManualApproval” pour intégrer des portes d’approbation dans le graphe du pipeline. Utilisez l’API pipeline.start() pour lancer des exécutions et pipeline.get_steps() ou la console pour inspecter l’état d’exécution et la traçabilité.

Le SageMaker Model Registry stocke les paquets de modèles sous un ModelPackageGroupName et attribue des identifiants ModelPackageVersion. Les API pertinentes sont CreateModelPackageGroup, CreateModelPackage, DescribeModelPackage et UpdateModelPackage pour changer le ModelApprovalStatus en “Approved” ou “Rejected”. Les objets ModelPackage doivent inclure des champs de métadonnées comme InferenceSpecification (Containers, SupportedContentTypes, SupportedResponseMIMETypes) et ModelApprovalStatus. Lors du déploiement, appelez CreateModel avec ModelName et PrimaryContainer en utilisant l’ARN du paquet de modèle, puis CreateEndpointConfig avec DataCaptureConfig (EnableCapture=true, SamplingPercentage, DestinationS3Uri) pour activer la capture des inférences.

Pour la surveillance et la détection de biais, utilisez SageMaker Model Monitor et SageMaker Clarify. Model Monitor nécessite une baseline créée via DefaultModelMonitor.suggest_baseline, qui appelle CreateProcessingJob pour les statistiques et les contraintes de la baseline ; ces baselines sont stockées dans S3 et référencées dans CreateMonitoringSchedule. Les planifications de surveillance (monitoring schedules) sont créées avec CreateMonitoringSchedule et peuvent être démarrées/arrêtées via StartMonitoringSchedule/StopMonitoringSchedule. Pour des vérifications de biais ad hoc sur un point de terminaison en temps réel, exécutez une tâche SageMaker Processing avec le conteneur Clarify (via sagemaker.processing.ScriptProcessor ou ClarifyProcessor) en utilisant les journaux d’inférence capturés comme entrée ; Clarify prend en charge les vérifications de biais de modèle (Model Bias) et renvoie des rapports vers S3.

Pour agréger des sources de données hétérogènes de manière sécurisée, utilisez AWS Glue et Lake Formation pour découvrir, cataloguer et effectuer l’ETL des données provenant de S3, de sources JDBC (MySQL sur site via le connecteur JDBC d’AWS Glue et éventuellement DataSync pour le transfert en masse), et de sources de streaming. Les tâches AWS Glue (PySpark) peuvent écrire des jeux de données préparés dans un data lake S3 chiffré avec un contrôle d’accès fin via Lake Formation. Pour la détection d’anomalies automatisée avec visualisation, choisissez entre les services gérés : Amazon Lookout for Metrics effectue une détection d’anomalies automatisée sur les séries temporelles, tandis que SageMaker Data Wrangler permet une exploration visuelle et des transformations rapides, et peut exporter des pipelines de prétraitement vers SageMaker Processing ou Pipelines. Pour une détection d’anomalies continue avec des tableaux de bord de visualisation, combinez Lookout for Metrics pour la détection avec Amazon QuickSight pour la visualisation et l’analyse détaillée (drill-down).

Patrons de conception et compromis

Un patron courant est celui du « pipeline-first » : créer un SageMaker Pipeline qui inclut le prétraitement des données (ProcessingStep), l’entraînement (TrainingStep), l’évaluation du modèle (ProcessingStep ou ClarifyProcessor), l’enregistrement du modèle (RegisterModel) et le déploiement (ModelStep ou une promotion manuelle). Utilisez la mise en cache des étapes (step caching) pour minimiser les calculs redondants et accélérer le développement itératif. Pour une promotion sécurisée, définissez model_approval_status sur « PendingManualApproval » et intégrez une action ManualApproval de CodePipeline ou une fonction Lambda d’approbation qui met à jour le package du modèle. Cette conception fournit un chemin auditable depuis les données et le code jusqu’à la production, tout en permettant une gouvernance avec intervention humaine (human-in-the-loop).

Pour le CI/CD, choisissez entre deux compromis : la promotion entièrement automatisée basée sur des seuils de métriques (rapide, moins d’étapes manuelles) ou des flux de travail d’approbation manuelle (conformité). Implémentez le contrôle par seuils de métriques avec CodeBuild exécutant un petit script evaluate.py qui appelle SageMaker Runtime ou charge le package du modèle, calcule les métriques et émet un artefact consommé par CodePipeline pour décider de la réussite ou de l’échec. Si la conformité exige une approbation humaine, insérez une action AWS CodePipeline ManualApprovalAction qui déclenche un e-mail via SNS et nécessite qu’un approbateur désigné poursuive, ou utilisez l’état du Model Registry comme source de vérité canonique et n’autorisez les déploiements que lorsque ModelApprovalStatus est égal à « Approved ».

La réduction de la latence de démarrage des tâches d’entraînement consiste souvent à éviter le provisionnement complet et répété. Si de nombreuses exécutions de pipeline ré-entraînent sur des entrées identiques, activez Pipeline CacheConfig afin que la TrainingStep soit ignorée lorsque les entrées sont inchangées. Pour les itérations qui doivent s’entraîner à chaque exécution mais qui exigent une faible latence, utilisez des types d’instances plus petits pour un prototypage rapide dans SageMaker Studio, ou exécutez plusieurs expériences sur une instance Amazon EC2 persistante ou un orchestrateur d’entraînement personnalisé basé sur EKS pour éviter les démarrages à froid des conteneurs (cold starts) — échangeant une surcharge opérationnelle contre une latence plus faible. Pour une scalabilité de niveau production, acceptez un certain délai de démarrage et privilégiez plutôt l’automatisation de la reproductibilité.

Pièges courants et critères de décision

Une erreur fréquente consiste à se fier uniquement aux journaux du point de terminaison pour la détection de dérive sans activer DataCaptureConfig au moment du déploiement ; sans capture, Model Monitor et Clarify ne peuvent pas analyser les entrées d’inférence réelles. Configurez toujours CreateEndpointConfig avec DataCaptureConfig (EnableCapture=true, DestinationS3Uri, CaptureOptions et InitialSamplingPercentage) et mettez en place une planification de surveillance via CreateMonitoringSchedule en la liant aux statistiques de référence.

Un autre piège est la sécurité inadéquate de S3 et du réseau. Les tâches d’entraînement qui doivent rester isolées doivent utiliser VpcConfig dans CreateTrainingJob et activer le chiffrement KMS pour les objets S3. Ne vous fiez pas aux contrôles d’accès public ; utilisez plutôt des politiques de compartiment S3, des points de terminaison VPC (com.amazonaws.region.s3) et une portée de rôle IAM. Enfin, évitez un CI/CD fragile en intégrant les métriques d’évaluation et les métadonnées de la carte de modèle dans le package du modèle et en utilisant un versionnage immuable (ModelPackageVersion) au lieu d’écraser les artefacts.

Problème pratique : Scénario d’utilisation

AcmePay — détection de fraude pour les flux de transactions. Le défi consiste à construire un cycle de vie sécurisé et auditable qui agrège les journaux de transactions S3, les profils clients et les tables MySQL sur site, entraîne un classifieur de fraude XGBoost, maintient un registre de modèles central avec approbation manuelle avant la production, détecte la dérive des données et des biais à la demande, et minimise la charge opérationnelle pour le versionnage et les exécutions itératives.

1. Centraliser les données : utiliser AWS Glue pour analyser (crawler) les journaux de transactions S3 et le MySQL sur site via le connecteur JDBC d’AWS Glue (avec un transfert DataSync sécurisé ou un peering VPC pour l’accès réseau). Cataloguer les jeux de données dans le Glue Data Catalog et appliquer l’accès via AWS Lake Formation. Stocker les jeux de données d’entraînement préparés dans un préfixe S3 chiffré (KMS CMK) et utiliser des politiques de compartiment ainsi qu’un VpcEndpoint pour empêcher l’accès public.

2. Construire des pipelines reproductibles : créer un SageMaker Pipeline avec une ProcessingStep pour le feature engineering (export Data Wrangler ou Glue ETL), une TrainingStep exécutant le conteneur XGBoost intégré avec des hyperparamètres, et une étape RegisterModel qui appelle RegisterModel avec model_package_group_name=“acmepay-fraud-group” et model_approval_status=“PendingManualApproval”. Activer CacheConfig sur les étapes de prétraitement et d’entraînement pour réutiliser les sorties lorsque les entrées/le code sont inchangés, réduisant ainsi l’approvisionnement répété d’instances.

3. CI/CD et approbation : créer un SageMaker Project qui structure un AWS CodePipeline. Le pipeline exécute des tests unitaires dans CodeBuild, déclenche le pipeline SageMaker et, après RegisterModel, inclut une action CodePipeline ManualApproval. L’action d’approbation manuelle, une fois approuvée, invoque une fonction Lambda qui appelle UpdateModelPackage pour définir ModelApprovalStatus=“Approved”, puis déclenche CreateEndpointConfig et CreateEndpoint pour le déploiement. Utiliser les ressources CloudFormation générées par SageMaker Projects pour garder une infrastructure reproductible.

4. Sécuriser l’entraînement et le déploiement : soumettre les tâches d’entraînement avec CreateTrainingJob VpcConfig (SubnetIds, SecurityGroupIds) et EnableNetworkIsolation=true ; s’assurer que le rôle d’exécution de SageMaker dispose de la permission kms:Decrypt sur la clé KMS et de s3:GetObject uniquement pour le préfixe du jeu de données préparé. Pour les points de terminaison, créer une CreateEndpointConfig avec DataCaptureConfig (EnableCapture=true, SamplingPercentage=100, DestinationS3Uri=s3://acmepay-prod/capture) afin que les données d’inférence soient conservées pour la surveillance.

5. Vérifications de dérive et de biais à la demande : utiliser SageMaker Clarify dans une ProcessingJob sur les données d’inférence capturées et les étiquettes de vérité terrain (si disponibles) pour exécuter des analyses ModelBias et ModelExplainability à la demande ; invoquer via l’API ClarifyProcessor.run() depuis une fonction Lambda ou Step Functions lorsque l’équipe de science des données demande une évaluation. Pour les alertes de dérive en continu, créer une référence Model Monitor via DefaultModelMonitor.suggest_baseline et une MonitoringSchedule ; utiliser CreateMonitoringSchedule pour exécuter des vérifications périodiques et configurer des notifications SNS pour les violations.

Justification AWS : Glue + Lake Formation centralisent et sécurisent les sources hétérogènes avec un minimum de code ETL personnalisé. SageMaker Pipelines + CacheConfig minimisent le renouvellement de l’infrastructure pour les exécutions itératives. Le Model Registry fournit un versionnage immuable et des métadonnées (ModelPackageGroupName et ModelPackageVersion) et s’intègre nativement aux flux de travail d’approbation via ModelApprovalStatus. SageMaker Clarify et Model Monitor fournissent à la fois des évaluations de biais à la demande et une détection de dérive planifiée. L’utilisation de SageMaker Projects et de CodePipeline standardise le CI/CD et impose une promotion auditable et reproductible de l’état “PendingManualApproval” à “Approved” avant le déploiement en production.

← Déploiement de modèles et inférence · Tous les domaines · Surveillance et observabilité des modèles →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Amazon →