MLOps pour SAP analytics
À jour au 2026-08-16
La plupart des projets ML échouent après que le modèle fonctionne déjà : un modèle de churn atteignant 85% d'AUC dans un notebook contre des données ACDOCA ne représente que 10-20% de l'ingénierie nécessaire pour le faire tourner de façon fiable en production. Les 80% restants — CI/CD pour le code modèle, feature store adossé à HANA, monitoring de dérive — sont ce qui distingue un modèle qui se dégrade silencieusement en quelques mois d'un modèle qui survit au contact des données SAP réelles. Ce module est le guide de niveau architecture : brancher les Applications, Configurations, Exécutions et Déploiements de SAP AI Core sur un feature store HANA ou Datasphere, intercepter les échecs spécifiques au schéma (BUKRS vide, valeurs `#` de hiérarchie) avant qu'ils n'atteignent la production, et instrumenter les trois types de dérive qui décident du ré-entraînement. Les consultants capables de tenir les quatre volets — ingénierie ML, architecture data SAP, monitoring, livraison SAC ou S/4HANA — sont réellement rares, ce qui place ce travail dans le tier tarifaire architecture et leadership technique, pas dans celui de la data science.
Ce que vous apprendrez
- Architecturer un cycle de vie complet de modèle sur SAP AI Core en utilisant les Applications, Configurations, Exécutions et Déploiements — en packagant le code d'entraînement et de serving dans des conteneurs Docker avec extraction de features hana-ml, stockage des artefacts modèle dans BTP Object Store, et enregistrement des endpoints dans SAP AI Launchpad.
- Concevoir une stratégie de prévention du décalage entraînement-serving en utilisant des Vues de Calcul HANA ou des vues persistantes Datasphere comme couche de calcul des features, et hana-ml ModelStorage pour la persistance versionnée des modèles, afin que les features d'inférence soient équivalentes bit à bit aux features d'entraînement.
- Implémenter un pipeline de monitoring ML en production distinguant la dérive des données, la dérive conceptuelle et la dérive des labels — en utilisant des tests statistiques sur les distributions de features écrites en retour dans HANA, jointes aux tables de résultats de vérité terrain, et exposées comme tableau de bord opérationnel SAC avec des déclencheurs SAP Alert Notification Service.
- Construire un pipeline CI/CD pour le code modèle ML incluant des tests unitaires spécifiques au schéma de données SAP (couvrant les cas limites des champs HANA tels que BUKRS vide, valeurs # de hiérarchie et périodes fiscales manquantes), la construction et le push d'images Docker, et la création automatisée d'Exécutions dans SAP AI Core via l'ai_core_sdk.
L'écart entre un notebook fonctionnel et un système ML en production
L'erreur la plus coûteuse dans les projets ML est de traiter la phase d'entraînement du modèle comme l'essentiel du travail. Entraîner un modèle de churn par gradient boosting dans un notebook Jupyter contre un snapshot de données ACDOCA et atteindre un AUC de 85% représente peut-être 10-20% de l'ingénierie nécessaire pour rendre ce modèle fiable en production. Les 80% restants, c'est ce qu'aborde le MLOps : pipelines reproductibles, intégration continue pour le code modèle, infrastructure de déploiement, monitoring, déclencheurs de ré-entraînement et procédures de rollback. Pour les consultants SAP Analytics, le défi spécifique est que ces 80% doivent s'intégrer avec SAP AI Core et SAP AI Launchpad sur BTP, avec HANA ou Datasphere comme feature store, et avec SAC ou des UIs personnalisées comme couche de consommation.
Module complet réservé aux abonnés. Le module complet ajoute : le cadre de décision · le cas guidé de bout en bout · la grille de KPI · les anti-patterns · les blocs de code · le contrôle de connaissances · les schémas.