Aller au contenu principal

Module 9 — Chaînes de traitement et planification

Les modules 5 à 8 ont produit chacun une brique isolée : entraînement, enregistrement, déploiement. En production, ces briques s'enchaînent — nouvelle donnée le vendredi, prétraitement le samedi matin, entraînement le samedi après-midi, évaluation le dimanche matin, promotion et déploiement le dimanche soir. Azure ML matérialise cet enchaînement dans un pipeline dont chaque étape est un composant réutilisable.

Le composant : la tâche rendue générique​

Un composant est une tâche paramétrée enregistrée dans le workspace sous un nom et une version. Là où une command job est un exemplaire à usage unique, un composant est un modèle appelable depuis plusieurs pipelines. Le composant d'entraînement du fil rouge :

$schema: https://azuremlschemas.azureedge.net/latest/commandComponent.schema.json
name: entrainement_xgb
version: 3
type: command
inputs:
  ventes:
    type: mltable
  alpha:
    type: number
    default: 0.1
  max_depth:
    type: integer
    default: 8
outputs:
  modele:
    type: mlflow_model
  metriques:
    type: uri_file
environment: azureml:env-prev-demande:3
code: ./src
command: >-
  python train.py
  --ventes ${{inputs.ventes}}
  --alpha ${{inputs.alpha}}
  --max-depth ${{inputs.max_depth}}
  --sortie ${{outputs.modele}}
  --metriques ${{outputs.metriques}}

Enregistrement :

az ml component create --file composant-entrainement.yml

On produit de la même façon un composant preparation, un composant evaluation, un composant promotion. Chacun est indépendamment versionné, testable, et réutilisable par une autre équipe.

Le pipeline : la partition qui appelle les composants​

Le pipeline lie les composants et fait circuler leurs sorties comme entrées :

$schema: https://azuremlschemas.azureedge.net/latest/pipelineJob.schema.json
type: pipeline
experiment_name: prev-demande-hebdo
compute: azureml:cpu-cluster-32

inputs:
  ventes_brutes:
    type: mltable
    path: azureml:ventes_magasins:3

jobs:
  preparation:
    type: command
    component: azureml:preparation_ventes:2
    inputs:
      brut: ${{parent.inputs.ventes_brutes}}

  entrainement:
    type: command
    component: azureml:entrainement_xgb:3
    inputs:
      ventes: ${{parent.jobs.preparation.outputs.propres}}
      alpha: 0.08
      max_depth: 10

  evaluation:
    type: command
    component: azureml:evaluation_backtest:2
    inputs:
      modele: ${{parent.jobs.entrainement.outputs.modele}}
      test: ${{parent.jobs.preparation.outputs.test}}

  promotion:
    type: command
    component: azureml:promotion_conditionnelle:1
    inputs:
      modele: ${{parent.jobs.entrainement.outputs.modele}}
      metriques: ${{parent.jobs.evaluation.outputs.metriques}}
      seuil_mape: 0.10

Le graphe se lit sans avoir à connaître le code : preparation → entrainement → evaluation → promotion. Azure ML exécute en parallèle tout ce qui peut l'être — pas grand-chose ici, mais un pipeline plus large avec plusieurs entraînements concurrents en profite.

Le composant promotion_conditionnelle est le garde-fou : il enregistre le modèle uniquement si mape < seuil_mape, et lui appose la balise stade=production. Sans ce garde-fou, un modèle dégradé irait quand même écraser le précédent au déploiement.

Cache d'étape : ne pas recalculer ce qui ne change pas​

Chaque étape d'un pipeline calcule une empreinte de ses entrées et de son code. Si l'empreinte est identique à un run précédent, Azure ML réutilise le résultat sans relancer l'étape. Sur un pipeline hebdomadaire dont seule la nouvelle semaine de données change, la preparation peut réutiliser 95 % de son travail — gain typique 30 à 60 %.

Le cache s'active via enable_step_reuse: true dans le composant, valeur par défaut. Pour le désactiver ponctuellement pendant un débogage, az ml job create --set jobs.entrainement.settings.enable_step_reuse=false.

Planification hebdomadaire​

La planification transforme le pipeline en un service permanent :

$schema: https://azuremlschemas.azureedge.net/latest/schedule.schema.json
name: pipeline-hebdo-prev-demande
display_name: Prévision demande — exécution hebdomadaire
trigger:
  type: recurrence
  frequency: week
  interval: 1
  schedule:
    hours: [22]
    minutes: [30]
    week_days: [Sunday]
  time_zone: Europe/Paris
create_job:
  type: pipeline
  job: ./pipeline.yml
az ml schedule create --file planification.yml

Chaque dimanche à 22 h 30, Paris, Azure lance le pipeline. Aucun serveur à maintenir pour cela — la planification est un objet du workspace.

Déclenchement sur nouvelle donnée​

Un pipeline hebdomadaire tourne même la semaine où aucune donnée nouvelle n'est arrivée. C'est du calcul gaspillé et un modèle réécrit à l'identique. Le déclencheur événementiel corrige cela :

  • Event Grid observe le compte de stockage et émet un événement BlobCreated quand un nouveau fichier arrive dans ventes/2026/
  • Une Azure Function reçoit l'événement, filtre le pattern (fichier .parquet complet et non un .tmp), et appelle az ml job create avec le pipeline en argument

C'est le patron déclenchement sur arrivée de donnée (data-driven trigger). Un peu plus de plomberie qu'une planification cron, il paie sa complexité dès qu'un pipeline coûteux ne doit tourner que sur nouveauté réelle.

Distinguer déclencheur et fréquence

Un déclencheur événementiel bien réglé peut se déclencher plusieurs fois par jour ou zéro fois pendant deux semaines. Ne pas lui superposer un cron hebdomadaire de secours par principe : la duplication silencieuse mène à des modèles écrasés en pleine journée. Si un cron de secours est requis (audit réglementaire par exemple), il doit produire une balise différente et n'écraser aucun modèle validé.

En résumé​

  • Un composant transforme une tâche en modèle réutilisable, versionné et testable
  • Un pipeline relie les composants et fait circuler leurs sorties, avec exécution parallèle quand possible
  • Le cache d'étape évite de recalculer ce qui n'a pas changé — jusqu'à 60 % d'économie sur un pipeline hebdomadaire
  • Planification récurrente pour les cadences fixes, déclenchement événementiel pour économiser les runs inutiles

Le dernier module se penche sur ce qui reste après la mise en route : la surveillance, les quotas et le contrôle des coûts.