Module 8 — Points de terminaison en ligne et par lots

Le modèle prev-demande-xgb:7 est enregistré. Il faut maintenant l'exposer aux consommateurs — l'application de réapprovisionnement en temps quasi réel pour les magasins pilotes, un traitement du dimanche soir pour l'ensemble du parc. Azure ML sépare ces deux besoins en deux objets : le point de terminaison en ligne (managed online endpoint) et le point de terminaison par lots (batch endpoint). Ils partagent un modèle mental mais pas leurs contraintes.

L'objet endpoint et l'objet deployment

Un point de terminaison est une URL stable avec ses secrets d'accès. Un déploiement est une version concrète d'un modèle attachée à ce point, avec sa cible de calcul, son environnement, sa configuration de mise à l'échelle. Un point de terminaison peut porter plusieurs déploiements simultanés avec une répartition du trafic entre eux — c'est ce qui rend possibles les stratégies bleu-vert et canari.

Point de terminaison en ligne pour le fil rouge

Le point est déclaratif :

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineEndpoint.schema.json
name: prev-demande-en-ligne
auth_mode: key

Le déploiement porte le modèle :

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json
name: bleu
endpoint_name: prev-demande-en-ligne
model: azureml:prev-demande-xgb:7
instance_type: Standard_DS3_v2
instance_count: 2
request_settings:
  max_concurrent_requests_per_instance: 4
  request_timeout_ms: 10000
liveness_probe:
  initial_delay: 30
  period: 10

Le lancement crée une VM managée, tire l'image de l'environnement, monte le modèle depuis le registre :

az ml online-endpoint create --file endpoint.yml
az ml online-deployment create --file deploiement-bleu.yml --all-traffic

Le drapeau --all-traffic dirige 100 % des appels vers ce déploiement — première fois que le point est appelé, c'est le comportement voulu.

Modèle MLflow : le scoring sans code

Parce que le modèle est enregistré en format mlflow_model (module 7), Azure génère automatiquement le script de scoring et l'environnement. Aucun score.py à écrire. Le contrat d'entrée est celui inféré de la signature MLflow :

curl -X POST -H "Authorization: Bearer $CLE" \
  -H "Content-Type: application/json" \
  -d '{"input_data":{"columns":["magasin_id","produit_id","semaine"],"data":[[42,17,"2026-09-13"]]}}' \
  https://prev-demande-en-ligne.westeurope.inference.ml.azure.com/score

Pour un modèle non-MLflow, il faut fournir un script score.py avec deux fonctions : init() chargée une fois au démarrage et run(raw_data) appelée à chaque requête. C'est le passage forcé pour un prétraitement lourd non embarqué dans le modèle.

Répartition du trafic : le bleu-vert en une commande

La force du séparateur endpoint/deployment apparaît au moment de mettre en production prev-demande-xgb:8, entraîné cette semaine. On ajoute un déploiement vert sur le même point sans toucher au trafic :

az ml online-deployment create --file deploiement-vert.yml

Puis on ouvre progressivement le robinet :

az ml online-endpoint update --name prev-demande-en-ligne \
  --traffic "bleu=90 vert=10"

10 % du trafic va au nouveau déploiement. On surveille dans Application Insights la latence, le taux d'erreur, et une métrique métier journalisée depuis le script. Si tout va bien après une heure, on passe à bleu=0 vert=100. Si un signal tourne au rouge, on remet bleu=100 vert=0 en une commande — bascule instantanée, sans redémarrage.

La répartition n'existe qu'entre déploiements du même point

Une erreur fréquente : supprimer le déploiement bleu juste après avoir promu vert. La procédure est correcte, mais si le déploiement vert s'écroule dans les minutes suivantes, il n'y a plus de retour arrière possible. Attendre 24 à 72 heures d'observation en production avant de supprimer l'ancien déploiement.

Mise à l'échelle automatique

Un déploiement en ligne s'adosse à un autoscaler basé sur Azure Monitor : on définit une règle sur l'UC ou le nombre de requêtes en file, et Azure ajoute ou retire des instances entre min_instances et max_instances. Deux principes de calibrage :

• min_instances >= 2 en production, jamais 1 : la mise à jour d'une instance sans coupure exige au moins un pair
• Régler la règle sur la file d'attente plutôt que sur l'UC : sur un modèle rapide et un serveur en pool de threads, l'UC monte peu même quand la latence explose

Point de terminaison par lots pour le fil rouge

Pour la prévision hebdomadaire sur les 12 000 couples magasin-produit, un appel HTTP synchrone n'a pas de sens. Le batch endpoint est fait pour cela : on lui pointe un MLTable d'entrée, il lance des tâches sur une grappe (module 2), écrit les résultats sur le stockage, envoie un événement quand c'est terminé.

$schema: https://azuremlschemas.azureedge.net/latest/batchDeployment.schema.json
endpoint_name: prev-demande-lots
model: azureml:prev-demande-xgb:7
compute: azureml:cpu-cluster-32
mini_batch_size: 500
instance_count: 4
max_concurrency_per_instance: 2
output_action: append_row
output_file_name: previsions.csv

mini_batch_size détermine la granularité — 500 lignes par mini-lot, 4 nœuds en parallèle avec 2 processus par nœud, soit 8 processus qui traitent chacun un mini-lot. Sur 12 000 lignes, la prévision hebdomadaire s'exécute en 4 à 6 minutes ; sur cpu-cluster-32 avec min-instances: 0, la grappe redescend à zéro nœud dans les 5 minutes qui suivent, coût total sous \$0.20.

Comparatif rapide

Aspect	En ligne	Par lots
Latence	ms à quelques centaines de ms	minutes à heures
Facturation	à l'heure de la VM, tant que le déploiement existe	à la seconde, uniquement pendant les tâches
Cas d'usage fil rouge	prévision pour l'app mobile magasin	prévision hebdomadaire complète
Autoscaling	par instance	par nœud de grappe

En résumé

• Endpoint + déploiement(s) avec répartition du trafic rendent le bleu-vert et le canari triviaux
• Un modèle MLflow déploie sans script ; sinon il faut fournir init() et run() dans score.py
• En ligne pour la latence courte et le flux continu ; par lots pour les gros volumes périodiques
• Garder l'ancien déploiement au moins 24 h après promotion, min_instances à 2 en production

Le module suivant orchestre l'entraînement, l'évaluation et le déploiement en un pipeline planifié chaque semaine.