MLOps : comment données, modèles et gouvernance s’articulent en production

Beaucoup d’équipes abordent le MLOps en commençant par le modèle : comment il a été entraîné, où il sera déployé et à quelle vitesse il pourra être réentraîné. Mais en production, le modèle n’est qu’un objet dans un système bien plus vaste : la table qui l’a alimenté, la définition de feature qui l’a façonné, l’étiquette arrivée avec trois jours de retard, le schéma modifié en amont et la politique d’accès qui détermine qui peut utiliser la sortie.

C’est pourquoi le MLOps ne se résume pas à « du DevOps pour les modèles ». Le MLOps reprend au DevOps l’automatisation, le CI/CD et la discipline de release, mais il doit aussi gérer des enjeux propres aux modèles auxquels les équipes de développement logiciel ne sont généralement pas confrontées : dérive des données (data drift), dérive conceptuelle, réutilisation des features, écart entre entraînement et serving, explicabilité des modèles, traçabilité des modèles et réentraînement à partir de nouveaux résultats en production. Le MLOps relie ces dépendances afin que les modèles puissent intégrer des applications qui restent fiables à mesure que l’activité, les données et l’environnement opérationnel évoluent.

Le MLOps est l’ensemble des pratiques qui automatisent et standardisent le déploiement, la surveillance et la maintenance des modèles de ML en production. Ces pratiques aident les équipes à gérer tout le cycle de vie du machine learning.

Comme son équivalent logiciel, un modèle dépend du code. Mais il dépend aussi des données d’entraînement, des features, des étiquettes, des paramètres, des métriques d’évaluation, des dépendances d’exécution, de l’infrastructure de serving et du feedback de l’environnement où les prédictions sont utilisées. Le MLOps permet aux équipes de versionner ces actifs, de les tester, de les faire passer par des points de validation, de les déployer de façon cohérente et de vérifier s’ils continuent de se comporter comme prévu.

Un modèle qui évalue des leads, prévoit la demande, oriente les tickets de support ou signale des transactions suspectes n’est pas seulement un actif de data science. Il fait désormais partie d’un workflow opérationnel : les équipes métier s’appuient sur ses sorties, tandis que les équipes techniques doivent le maintenir disponible, à jour et explicable.

Avec des processus MLOps solides, les équipes peuvent mieux assumer cette responsabilité à grande échelle. « Le MLOps est souvent décrit comme un défi d’outillage, mais dans la pratique, le principal obstacle vient de workflows fragmentés », explique Trace Smith, Senior AI/ML Architect, Applied Field Engineering chez Snowflake. « La dynamique actuelle va vers un environnement data et ML plus unifié, où la gouvernance et les workflows de modèles sont réunis dans un même modèle opérationnel. C’est ce qui contribue à réduire les frictions opérationnelles et à accélérer le passage en production. »

Au lieu de traiter chaque modèle comme un projet ponctuel, les équipes peuvent s’appuyer sur des pipelines reproductibles, la surveillance, la gestion des versions et des contrôles de gouvernance pour accélérer la mise en production, détecter les variations de performance et effectuer des mises à jour sans reconstruire le processus opérationnel de zéro.

Le MLOps aide les équipes de trois façons concrètes :

• Délai de commercialisation plus court : Les pipelines automatisés aident les équipes à passer de passages de relais manuels à des processus reproductibles d’entraînement, de test, de packaging et de déploiement.
• Fiabilité améliorée : La surveillance aide les équipes à détecter les changements de performance, les dérives, les problèmes de qualité des données et les échecs à l’exécution avant qu’ils n’affectent discrètement les décisions en aval.
• Scalabilité et gouvernance renforcées : La gestion des versions, la traçabilité des données, les workflows d’approbation et les contrôles d’accès aident les organisations à exploiter davantage de modèles dans plus d’équipes, sans dépendre d’une coordination informelle.

Le DevOps se concentre sur la livraison logicielle. Le MLOps va plus loin : il couvre les données et le comportement statistique des systèmes de ML.

Le processus MLOps fonctionne comme une boucle, plutôt que comme une passation linéaire. Les équipes collectent et valident les données, préparent les features, entraînent et évaluent les modèles, enregistrent et déploient les versions approuvées, puis réinjectent les signaux de production dans le cycle suivant de monitoring et de réentraînement.

Collecte et ingestion des données

Le cycle de vie commence avec les données issues de systèmes sources tels que les bases de données, fichiers, flux, API, applications et jeux de données tiers. Pour le ML en production, l’ingestion ne consiste pas seulement à déplacer des données vers un environnement d’entraînement. Elle préserve suffisamment de contexte pour comprendre d’où viennent les données, leur niveau d’actualisation et si elles peuvent être utilisées pour l’objectif prévu.

Validation des données et contrôles qualité

Avant d’utiliser les données pour l’entraînement ou l’inférence, il faut vérifier les valeurs manquantes, les changements de schéma, les valeurs aberrantes, les doublons, les biais, les problèmes de confidentialité et la fraîcheur des données. Ces vérifications permettent d’éviter que des saisies incorrectes ne deviennent un comportement de modèle. Par exemple, une colonne qui passe d’un entier à une chaîne, un flux qui cesse de se mettre à jour ou une étiquette disponible plus tard que prévu peuvent affecter la qualité du modèle bien avant qu’une défaillance visible en production ne soit détectée.

Préparation des données et feature engineering

Le feature engineering (ou ingénierie des caractéristiques) transforme les données brutes en signaux prêts pour les modèles, en les nettoyant, transformant, joignant, étiquetant et enrichissant. Dans les environnements MLOps matures, les équipes définissent une seule fois les features couramment utilisées, puis les réutilisent de manière cohérente pour l’entraînement et l’inférence. Cela réduit le risque qu’une équipe calcule « client actif » ou « volume de transactions récentes » différemment d’une autre, ou qu’un modèle en production utilise une logique de feature qui ne correspond plus à la version utilisée pendant l’entraînement.

Développement de modèles

Les data scientists et les ML engineers entraînent les modèles à l’aide de notebooks, de scripts, du machine learning automatisé (AutoML) ou de frameworks de ML. Ils comparent les algorithmes, les paramètres, les fenêtres d’entraînement et les jeux de données afin d’identifier l’approche la mieux adaptée au problème de prédiction. La principale exigence MLOps pour le développement de modèles est que les expérimentations produisent suffisamment de métadonnées pour qu’une autre personne, un pipeline ou un workflow d’approbation puisse comprendre ce qui a été entraîné, quelles données ont été utilisées et quelles performances le modèle a obtenues.

Suivi des expériences

Le suivi des expériences consigne les versions des modèles, les jeux de données, le code, les paramètres, les métriques, les artefacts et les résultats. Sans lui, les équipes peuvent savoir qu’une exécution a obtenu de meilleurs résultats qu’une autre, mais pas pourquoi. Avec lui, elles peuvent comparer les modèles candidats, reproduire un résultat et expliquer quelle version du modèle a été promue en production.

Validation et évaluation des modèles

L’évaluation des modèles vérifie qu’un modèle entraîné est précis, fiable et adapté au processus métier qu’il doit prendre en charge. L’évaluation inclut le suivi de métriques techniques comme l’exactitude, la précision, le rappel, le score F1, l’AUC, le RMSE et la latence, ainsi que l’équité, la robustesse et les KPI métier. Le processus d’évaluation doit aussi vérifier que le modèle se comporte de manière acceptable pour les segments, régions, gammes de produits ou catégories de risque clés, et pas seulement qu’il affiche de bonnes performances en moyenne.

Packaging et enregistrement des modèles

Une fois le modèle évalué avec succès, les équipes le packagent avec ses dépendances et ses métadonnées, puis le stockent dans un registre de modèles. Ce registre offre un espace contrôlé pour gérer les versions, le statut d’approbation, la traçabilité, l’état de déploiement et les métadonnées opérationnelles.

Déploiement des modèles

Le déploiement des modèles met le modèle en production sous forme de tâches par lots, d’API en temps réel, de pipeline d’inférence en streaming, de fonctionnalité applicative intégrée ou de déploiement en périphérie. Le mode de mise à disposition dépend des exigences de latence, de coût, d’actualisation et des besoins métier. Par exemple, un modèle de détection de la fraude peut nécessiter une inférence en temps réel, tandis qu’un modèle mensuel de propension peut s’exécuter comme une tâche de scoring par lots qui réécrit les prédictions dans une table pour une utilisation en aval.

Mise en service des modèles

Après le déploiement, le modèle doit être mis à disposition d’une manière qui respecte les exigences de latence, d’échelle, de coût et d’actualisation de l’application. La mise en service des modèles est la couche d’exécution qui rend les prédictions disponibles via le scoring par lots, les API en temps réel, l’inférence en streaming, la logique applicative intégrée ou les environnements en périphérie. Cette couche doit gérer la préparation des entrées, la récupération des features, les dépendances d’exécution, la mise à l’échelle, les contrôles d’accès, la latence et la gestion des erreurs, afin que la version approuvée du modèle puisse être utilisée de façon fiable en production.

Supervision des modèles

La supervision des modèles vérifie qu’un modèle continue de se comporter comme prévu après son déploiement. Les équipes surveillent généralement les performances en production, la latence, les erreurs, la dérive des données, la dérive conceptuelle, la qualité du modèle, les coûts et la santé opérationnelle.

Feedback et réentraînement

Les prédictions en production créent des informations : étiquettes, actions des utilisateurs, résultats métier, feedback humain et signaux de dérive. Les MLOps réinjectent ces informations dans le cycle de vie afin que les équipes puissent réentraîner, revalider et redéployer les modèles lorsque la version actuelle n’offre plus des performances suffisantes. Le déclencheur du réentraînement peut être planifié, piloté par des événements ou lié à des seuils de supervision, selon le risque et la volatilité du cas d’usage.

Gouvernance et conformité

La gouvernance couvre tout le cycle de vie du ML. Les équipes doivent gérer les accès, les pistes d’audit, l’explicabilité, la traçabilité, la confidentialité, la sécurité, les approbations et les exigences réglementaires, des données brutes jusqu’à l’inférence en production. C’est particulièrement important lorsque les modèles influencent le crédit, la tarification, les soins de santé, l’emploi, la détection de la fraude, la sécurité ou d’autres décisions à fort impact. La gouvernance aide également les équipes à répondre à des questions opérationnelles essentielles : Quelle version du modèle est en cours d’exécution ? Quelles données ont servi à l’entraîner ? Quelles features utilise-t-il ? Qui l’a approuvé ? Qu’est-ce qui a changé depuis la dernière version ?

Les MLOps reposent sur un ensemble de composants connectés. Certaines organisations assemblent ces composants dans plusieurs systèmes, tandis que d’autres privilégient une plateforme intégrée qui rapproche les données, la gestion des features, les opérations liées aux modèles et la gouvernance.

La maturité MLOps progresse généralement à mesure que les équipes automatisent davantage le cycle de vie et renforcent les contrôles liés à la reproductibilité, à la surveillance et à la gouvernance. Le modèle de maturité MLOps de Google Cloud est une référence courante.

Niveau 0 : Processus manuel

Au niveau 0, le travail de ML repose sur des notebooks et reste très manuel. Les data scientists préparent les données, entraînent les modèles, évaluent les résultats et transmettent les artefacts via des processus informels. Cela peut suffire pour expérimenter, mais crée des risques lorsque les modèles doivent être reproduits, mis à jour ou surveillés en production.

Niveau 1 : Automatisation du pipeline ML

Au niveau 1, les équipes automatisent le pipeline ML afin que les modèles puissent être réentraînés sur de nouvelles données, avec des étapes de validation, d’entraînement et d’évaluation reproductibles. L’objectif est l’entraînement continu : une approche contrôlée pour mettre à jour les modèles à mesure que de nouvelles données deviennent disponibles. Ce niveau réduit les passages de relais manuels, mais le pipeline lui-même peut encore nécessiter une gestion spécifique pour les distributions.

Niveau 2 : Automatisation du pipeline CI/CD

Au niveau 2, les équipes automatisent la création, les tests et le déploiement des pipelines ML eux-mêmes. Les changements apportés au code, à la logique de validation des données, aux workflows d’entraînement et aux définitions de déploiement passent par des processus CI/CD. C’est à ce stade que les opérations ML ressemblent davantage à une discipline d’ingénierie de production, avec des pipelines versionnés, des tests automatisés et une promotion contrôlée entre les environnements.

Maturité avancée : Opérations autonomes et gouvernées

Certains modèles de maturité ajoutent un niveau supérieur pour les opérations avancées ou autonomes. À ce stade, les signaux de supervision peuvent déclencher des workflows de réentraînement, les contrôles de gouvernance sont intégrés aux processus de promotion et les équipes peuvent gérer un grand nombre de modèles selon des politiques homogènes. L’objectif n’est pas de supprimer le jugement humain, en particulier pour les modèles à fort impact, mais de rendre plus systématiques les processus courants de détection, de validation et d’escalade.

Découvrez comment utiliser Snowflake ML pour créer et opérationnaliser des modèles à grande échelle :

Les opérations de grands modèles de langage (LLMOps) étendent les pratiques MLOps aux applications d’IA générative. Le LLMOps complète le MLOps avec de nouveaux enjeux opérationnels liés aux prompts, à la recherche d’informations, au contexte, à l’utilisation des tokens, à la sécurité et à l’évaluation.

Le LLMOps inclut généralement :

• Gestion des versions des prompts et des instructions système
• Frameworks d’évaluation de l’exactitude factuelle, de la pertinence, du ton, de la sécurité et de l’accomplissement des tâches
• Surveillance des pipelines RAG, notamment l'actualisation des documents et la qualité de la recherche d’informations
• Suivi des coûts liés aux tokens et optimisation de la latence
• Surveillance des garde-fous pour la confidentialité, la toxicité, l’ancrage dans les sources et les violations de politiques
• Boucles de feedback pour la revue humaine et l’amélioration des modèles

Le même principe d’exploitation s’applique toutefois : une application n’est fiable que si les données, le contexte, l’évaluation et la gouvernance qui la sous-tendent le sont aussi.

De bonnes pratiques de MLOps aident les équipes à éviter que le ML en production ne se résume à une série de passages de relais ponctuels. À mesure que les modèles passent du développement aux workflows opérationnels, les équipes doivent disposer de méthodes cohérentes pour versionner les actifs qui influencent leur comportement, tester les changements avant leur mise en production, surveiller les performances en production et mettre à jour les modèles sans perdre la traçabilité.

Versionnez tout ce qui influence le comportement des modèles

Le MLOps doit versionner le code, les jeux de données, les définitions de features, les paramètres, les artefacts de modèle, les dépendances, les résultats d’évaluation et les métadonnées de déploiement. Lorsqu’un modèle évolue, les équipes doivent savoir si les performances ont changé en raison de nouvelles données d’entraînement, d’une nouvelle logique de features, d’un autre jeu de paramètres ou d’un nouvel environnement d’exécution.

Automatisez les tests et le CI/CD là où cela réduit les risques

L’automatisation doit couvrir les contrôles que les équipes doivent répéter de manière fiable : validation des données, validation des features, évaluation des modèles, packaging, déploiement et restauration. Le CI/CD pour le ML doit également inclure des tests propres aux modèles, comme les contrôles de dérive, les tests de biais, les seuils de latence et les garde-fous liés aux KPI métier.

Surveillez en continu les modèles en production

La surveillance en production doit suivre l’état du système et le comportement des modèles. La latence, les erreurs et les coûts comptent, mais les distributions d’entrée, les distributions de prédiction, les performances des modèles, la dérive et l’actualisation des données sont tout aussi essentielles.

Concevez pour la reproductibilité

Une équipe doit pouvoir expliquer comment un modèle a été produit, quel jeu de données et quelles features ont servi à l’entraîner, quels code et paramètres ont été utilisés, quelles métriques ont justifié sa promotion et quelle version fournit actuellement les prédictions. La reproductibilité facilite le débogage, l’auditabilité, la collaboration et la conformité.

Commencez au niveau de maturité que l’équipe peut maintenir

La maturité MLOps doit être alignée sur les besoins, les compétences et le profil de risque de l’organisation. Une équipe qui gère un seul modèle batch à faible risque n’a pas forcément besoin d’un réentraînement autonome dès le premier jour. Une équipe qui gère de nombreux modèles orientés client, des cas d’usage réglementés ou des données qui évoluent rapidement aura plus rapidement besoin d’une automatisation, d’une surveillance et d’une gouvernance renforcées.

De nombreuses architectures MLOps déplacent les données entre des systèmes distincts pour la préparation, l’entraînement, la gestion des features, le registre, le service et la surveillance. Cette séparation peut créer des copies supplémentaires, une traçabilité des données fragmentée et davantage d’endroits où les politiques d’accès ou les définitions de features peuvent dériver. L’approche de Snowflake consiste à rapprocher une plus grande partie du cycle de vie ML des données gouvernées dans le Snowflake AI Data Cloud.

Avec Snowflake ML, les équipes peuvent créer, entraîner, déployer et surveiller les modèles au plus près des données qu’ils utilisent. Snowflake ML inclut des fonctionnalités comme les API Snowpark ML pour le développement, Snowflake Notebooks pour l’exploration et la collaboration, Snowflake Feature Store pour la gestion des features, ainsi que Snowflake Model Registry pour la gestion des versions et la gouvernance. ML Observability permet de surveiller les modèles de production enregistrés, notamment les métriques de performance, de dérive et de volume, avec une prise en charge actuelle des modèles de régression et de classification binaire.

Les features peuvent être définies une seule fois, gouvernées par des contrôles d’accès et suivies via la traçabilité des données lorsqu’elles passent de l’entraînement à l’inférence. Les modèles, eux, conservent leurs métadonnées, leur historique de versions et leur statut de déploiement dans un registre. Les data scientists peuvent toujours expérimenter dans des notebooks, mais leur travail reste plus proche des données gouvernées, avec une surveillance en place pour détecter le moment où les entrées de production commencent à s’écarter des hypothèses utilisées lors de l’évaluation.

On décrit souvent le MLOps par ses mécanismes de déploiement : pipelines, registres, CI/CD, surveillance et réentraînement. Ces mécanismes sont utiles, mais ils ne résolvent le problème de fond que s’ils restent connectés au contexte de données et de gouvernance qui entoure le modèle. Une version d’un modèle inspire davantage confiance lorsque les équipes peuvent retracer les données qui l’ont entraînée, comprendre les features qu’elle utilise, voir ses performances lors de l’évaluation et détecter les premiers changements de comportement en production.

À mesure que le ML s’intègre à davantage d’applications et de workflows métier, ce contexte opérationnel ne peut plus être considéré comme facultatif. Les équipes ont besoin de moyens pour aller vite sans perdre la traçabilité des données, réutiliser les features sans dupliquer la logique, surveiller les modèles sans les séparer des données dont ils dépendent et mettre à jour les systèmes de production sans s’appuyer sur des passages de relais manuels. Le MLOps fournit cette structure.