Le MLOps pour les entreprises : du modèle pilote à la production

Le MLOps pour les entreprises : du modèle pilote à la production

Le MLOps regroupe les pratiques qui permettent de sortir un modèle de machine learning du carnet d’un data scientist et de le maintenir fiable une fois qu’il est exposé à de vrais utilisateurs et à de vraies données. Pour une entreprise, cela signifie disposer de données et de modèles versionnés, de pipelines automatisés, de mises en production contrôlées, d’une supervision et de responsabilités clairement définies. AWS le décrit comme un ensemble de pratiques qui automatisent et simplifient les workflows et les déploiements de ML, en unifiant le développement du ML avec le déploiement et l’exploitation des systèmes de ML.

La plupart des entreprises ne rencontrent pas de difficultés à créer un modèle prometteur. Elles peinent plutôt à le mettre en production, à le surveiller, à le réentraîner et à l’expliquer aux auditeurs. Ce guide présente les caractéristiques d’un cycle de vie du ML en production, la manière d’évaluer votre niveau de maturité, les pratiques les plus importantes et les critères de choix d’une approche sans acquérir une plateforme plus vaste que nécessaire.

À retenir

• Le MLOps applique la rigueur de l’ingénierie logicielle au ML, mais doit également gérer l’évolution des données et des modèles, et pas seulement celle du code.
• Considérez la maturité comme une progression par niveaux. Pour la plupart des équipes, il est plus avantageux de commencer par automatiser l’entraînement et le déploiement plutôt que d’adopter immédiatement une plateforme complète.
• La sécurité, les pistes d’audit et les plans de restauration doivent être intégrés au pipeline dès le départ, et non faire l’objet d’un examen final.
• Choisissez vos outils par catégorie (open source, cloud managé, hybride) en fonction de votre cloud existant, des compétences de votre équipe et de vos besoins en matière de conformité.
• Commencez par un modèle important pour l’entreprise, rendez son parcours vers la production reproductible, puis réutilisez ce parcours.

Table des matières

• Ce que le MLOps signifie pour une entreprise
• Le cycle de vie du ML en production, étape par étape
• Où en êtes-vous ? Évaluer la maturité de votre MLOps
• Les bonnes pratiques de MLOps qui résistent à l’épreuve de la production
• Comparer les approches des plateformes MLOps
• Comment choisir une approche adaptée à votre entreprise
• Les enjeux économiques d’une mise en œuvre réussie
• Comment nous pouvons vous aider
• FAQ
• Sources

Ce que le MLOps signifie pour une entreprise

Un service web classique doit être résilient et capable de gérer la charge. Un modèle doit relever ces mêmes défis, ainsi que d’autres. Le Guide des praticiens du MLOps de Google souligne que le déploiement d’un modèle implique également de se préoccuper des évolutions des données, des évolutions du modèle et des utilisateurs qui tentent de manipuler le système. Même si le code n’a pas changé, il peut produire de moins bonnes prédictions au trimestre suivant parce que le monde, lui, a évolué.

C’est pourquoi un pipeline DevOps standard est nécessaire, mais pas suffisant. Le même guide énumère les avantages de la standardisation du processus : des cycles de développement plus courts, une meilleure collaboration, une fiabilité et une sécurité accrues, une gouvernance rationalisée et un meilleur retour sur les projets de ML.

À l’échelle de l’entreprise, trois enjeux apparaissent rapidement :

• De nombreux modèles et de nombreuses équipes. Sans normes communes, chaque équipe crée son propre parcours de déploiement, et personne ne peut répondre à la question de savoir quelle version du modèle est exécutée et où.
• Des données réglementées ou sensibles. Quelqu’un doit pouvoir montrer d’où proviennent les données d’entraînement et qui a approuvé une mise en production.
• La responsabilité opérationnelle. Un modèle qui se dégrade silencieusement constitue un problème métier, et non un problème de data science. Une personne d’astreinte doit en être responsable.

MIT Technology Review MIT Technology Review présente la valeur fondamentale comme l’automatisation des étapes répétitives, du développement et de l’entraînement jusqu’au déploiement et à l’exploitation, ce qui réduit les risques et libère les développeurs des tâches routinières. Le même article cite une étude de McKinsey réalisée en 2021, selon laquelle les entreprises qui parviennent à déployer l’IA à grande échelle peuvent augmenter jusqu’à 20 % leur résultat avant intérêts et impôts.

Le cycle de vie du machine learning en production, étape par étape

Chaque grand fournisseur de services cloud publie une architecture de référence, et toutes convergent vers le même modèle. L’architecture MLOps v2 de Microsoft va du patrimoine de données et de l’administration au développement des modèles et aux registres, puis aux environnements de préproduction et aux tests, au déploiement en production et à la supervision. Des déclencheurs peuvent relancer l’entraînement d’un modèle et le renvoyer vers la préproduction ou le développement.

Google Cloud guide sur la livraison continue et l’automatisation décompose le travail en six étapes. Les voici en termes simples :

1. Développement et expérimentation. Les data scientists testent des fonctionnalités, des algorithmes et des paramètres. Le résultat est le code source du pipeline, et pas seulement un notebook.
2. Intégration continue du pipeline. Les modifications du code du pipeline sont compilées et testées automatiquement.
3. Livraison continue du pipeline. Le pipeline lui-même est déployé dans l’environnement cible.
4. Déclenchement automatisé. L’entraînement s’exécute selon un calendrier, à l’arrivée de nouvelles données ou lorsqu’un signal de performance est détecté.
5. Livraison continue du modèle. Le modèle entraîné est fourni sous la forme d’un service de prédiction.
6. Supervision. Les statistiques en temps réel sur les performances du modèle alimentent le cycle suivant.

Un cadre universitaire consacré à la gestion du cycle de vie des modèles en entreprise ajoute un point utile : le machine learning en production est itératif et piloté par les événements, plutôt que séquentiel et définitif. La dernière étape n’est pas « déployer ». Il faut superviser, apprendre, réentraîner ou retirer le modèle. Prévoyez également son retrait, car un modèle dont personne n’assume la responsabilité et que personne n’ose désactiver constitue un passif.

Que documenter avant une mise en production

Les recommandations de Google pour la mise en production sont remarquablement opérationnelles. Pour le déploiement, les équipes doivent consigner :

• les approbations nécessaires pour commencer le déploiement
• la manière de mettre un modèle en production
• l’endroit où il est déployé en premier (environnements de préproduction ou canary)
• la procédure à suivre en cas d’échec du déploiement
• la manière d’annuler le déploiement d’un modèle déjà en production

Si votre équipe ne peut pas répondre aujourd’hui à ces cinq points pour votre modèle le plus important, vous avez trouvé votre premier projet MLOps.

Où en êtes-vous ? Évaluation de la maturité MLOps

Les modèles de maturité vous aident à choisir la prochaine étape plutôt que la destination finale. Le modèle de maturité MLOps de Microsoft définit cinq niveaux :

AWS propose une progression similaire dans sa feuille de route des fondations MLOps: Initiale, reproductible, fiable et évolutive. Dans cette feuille de route, la phase reproductible introduit des pipelines automatisés et un registre de modèles, la phase fiable ajoute des tests automatiques dans un environnement de préproduction isolé avec des validations manuelles pour la promotion, et la phase évolutive utilise des modèles pour réduire le temps de développement de plusieurs semaines à quelques jours.

Deux observations honnêtes tirées du terrain. Premièrement, tous les modèles n’ont pas besoin d’atteindre le niveau 4. Un modèle de prévision trimestrielle examiné manuellement par une équipe financière peut très bien rester au niveau 2, tandis qu’un modèle de détection des fraudes qui évalue des transactions en temps réel devrait viser plus haut. Deuxièmement, sauter des niveaux fonctionne rarement. Automatiser le réentraînement à partir de données impossibles à tracer ne fait qu’automatiser la confusion.

Bonnes pratiques MLOps qui tiennent la route en production

Les bonnes pratiques ne sont utiles que lorsqu’elles changent ce que l’équipe fait le lundi. Voici celles qui comptent le plus pour les entreprises, regroupées selon la question à laquelle elles répondent.

Pouvons-nous déployer et effectuer un retour arrière en toute sécurité ?

• Versionnez les données, le code et les modèles ensemble afin que chaque prédiction puisse être reliée aux artefacts exacts qui l’ont produite.
• Faites progresser les modèles dans des environnements de préproduction et de déploiement canari, avec une personne chargée de l’approbation nommément désignée pour la production.
• Conservez une procédure de retour arrière testée. Revenir à une version précédente d’un modèle devrait être aussi courant que revenir à une version précédente d’une application.
• Utilisez une approche fondée sur une liste de contrôle. La liste de contrôle MLOps couvre neuf domaines : gestion des données, expérimentation, observabilité, pipelines, intégration continue, supervision, déploiement, entraînement et gouvernance. Elle constitue une bonne base pour évaluer les lacunes avant tout achat.

Est-ce sécurisé ?

Les pipelines de modèles élargissent la surface d’attaque d’une manière que les évaluations traditionnelles de la sécurité des applications peuvent ne pas détecter. Le livre blanc MLSecOps de l’OpenSSF avertit qu’un MLOps non sécurisé expose les systèmes à l’empoisonnement des données, aux attaques adversariales contre les modèles et aux faiblesses des bibliothèques open source. Il recommande de sécuriser les pipelines dès la phase de planification et de considérer la sécurité comme une responsabilité partagée entre les développeurs ML, les spécialistes de la sécurité et les équipes d’exploitation. Ses contrôles comprennent des outils sécurisés, la gestion des correctifs et des contrôles d’accès fondés sur le principe du moindre privilège.

Du côté des conteneurs, les recommandations d’AKS de Microsoft pour le MLOps préconisent d’analyser les images de conteneurs de modèles open source afin d’y détecter les vulnérabilités connues et de conserver des pistes d’audit des données ingérées et des modifications apportées aux modèles. Ces mêmes recommandations indiquent également que des cadres tels que SOC 2, HIPAA et le RGPD sont pris en charge lorsqu’ils vous concernent.

Pouvons-nous l’expliquer et le gouverner ?

La gouvernance échoue lorsqu’elle se résume à un document au lieu de constituer une étape du pipeline. Intégrez-la directement :

• un registre de modèles qui consigne le propriétaire, la traçabilité des données d’entraînement, les résultats de l’évaluation et le statut d’approbation
• des contrôles automatisés qui bloquent la promotion lorsque les seuils d’évaluation ne sont pas atteints
• des revues planifiées des modèles surveillés, avec une personne nommément responsable de chacun
• une procédure de retrait, afin que les modèles ne restent pas en service une fois leur objectif atteint

Si vos modèles influencent des décisions concernant des personnes ou sont accessibles à des utilisateurs de l’UE, la réglementation peut s’appliquer à vous. Nos propres analyses sur la gouvernance de l’IA agentique et la préparation à l’AI Act de l’UE expliquent comment les contrôles doivent suivre le rythme des décisions automatisées. Demandez à votre conseil juridique de confirmer quelles obligations s’appliquent à vos systèmes spécifiques.

Comparer les approches des plateformes MLOps

Il n’existe pas de plateforme universellement optimale, et une comparaison fonctionnalité par fonctionnalité est généralement une mauvaise première étape. Commencez par les capacités dont toute entreprise a besoin, puis demandez-vous quelle approche les fournit avec le moins de contraintes opérationnelles pour votre équipe. Les capacités fondamentales sont le suivi des expérimentations, le versionnage des modèles, l’orchestration des pipelines, le déploiement des modèles et leur supervision.

Les approches se répartissent en trois grandes catégories :

L’erreur la plus courante consiste à considérer que « gratuit » signifie « bon marché ». Les outils open source n’impliquent aucun coût de licence, mais vous devez tout de même exploiter les clusters, corriger les composants et employer une personne qui les comprend. L’erreur inverse consiste à supposer qu’un service géré élimine le besoin d’ingénierie : vous devez toujours concevoir les pipelines, les tests et les étapes d’approbation. La tarification des services gérés évolue souvent ; vérifiez donc les tarifs en vigueur sur la page tarifaire de chaque fournisseur avant d’élaborer une analyse de rentabilité.

Comment choisir une approche adaptée à votre entreprise

Nous vous suggérons de suivre ces étapes dans l’ordre.

1. Dressez l’inventaire de l’existant. Répertoriez vos modèles, leurs responsables, leur lieu d’exécution et leur mode de déploiement actuel. La plupart des grandes entreprises découvrent davantage de modèles fantômes que prévu.
2. Prenez appui sur votre cloud et la gravité de vos données. Si vos données résident dans un seul cloud, les services natifs de ce cloud réduisent généralement le travail d’intégration. Le déplacement de grands ensembles de données constitue un projet à part entière.
3. Adaptez les outils aux compétences de votre équipe. Une plateforme qui nécessite une expertise Kubernetes est un mauvais choix pour une équipe qui n’en possède pas et qui n’a aucun projet de recrutement en ce sens.
4. Répertoriez les contrôles non négociables. Les journaux d’audit, le contrôle des accès, la résidence des données et les workflows d’approbation découlent des exigences de conformité et de sécurité, et non de la liste des fonctionnalités du fournisseur.
5. Choisissez un modèle à forte valeur ajoutée comme projet pilote. Construisez son parcours jusqu’à la production de bout en bout, mesurez le délai de mise en production et le taux d’incidents, puis transformez ce parcours en modèle réutilisable par les autres équipes.
6. Vérifiez l’interopérabilité. Privilégiez les composants dotés de formats et d’API ouverts, afin que le remplacement ultérieur d’un élément n’exige pas de tout reconstruire.
7. Estimez le coût total de possession. Incluez l’infrastructure, les licences, le temps d’ingénierie et le coût des interruptions de service des modèles.

Un projet pilote vous apporte également quelque chose de rare dans les décisions relatives aux plateformes : des éléments probants issus de votre propre environnement, plutôt qu’une démonstration du fournisseur.

L’intérêt commercial d’une bonne exécution

Les bénéfices du MLOps se manifestent dans quelques indicateurs que la direction suit déjà : un délai plus court entre l’approbation d’une idée et sa mise en production, moins d’incidents causés par la dégradation des modèles, moins d’outils redondants et des audits plus faciles. Les outils redondants sont le problème le moins visible. Lorsque chaque équipe assemble sa propre stack, le coût caché de l’exécution de plusieurs plateformes déconnectées augmente sous l’effet des licences, du travail d’intégration et du changement de contexte. Un parcours partagé et standardisé jusqu’à la production est la manière dont les grandes entreprises évitent cela.

Pour les responsables technologiques, cela change également le dialogue avec l’entreprise. Au lieu de dire « le modèle est presque prêt », vous pouvez communiquer la fréquence des mises en production, le délai de restauration et l’état de santé suivi du modèle.

Comment nous pouvons vous aider

Chez Ridiculous Engineering, les clients travaillent directement avec des ingénieurs seniors, de la phase de découverte jusqu’à l’amélioration à long terme. Si vous transformez des projets pilotes en systèmes de production, nos services de développement et d’automatisation de l’IA couvrent les solutions d’IA sur mesure et l’automatisation qui les accompagne, tandis que notre accompagnement en conseil et en déploiement logiciel peut vous aider à évaluer où en est votre processus actuel de mise en production. Vous pouvez également consulter notre point de vue précédent sur l’industrialisation de l’IA et le MLOps. Les projets d’IA sur mesure sont définis individuellement, avec une tarification sur demande. Ainsi, demandez un devis en indiquant brièvement votre premier modèle, et nous étudierons ensemble le parcours adapté à vos besoins.

FAQ

Quelle est la différence entre le MLOps et le DevOps ?

Le DevOps automatise la compilation, les tests et la mise en production du code applicatif. Le MLOps fait de même, tout en gérant les données, l’entraînement, les versions des modèles et leurs performances après la mise en production, car un modèle peut se dégrader sans aucune modification du code. Les équipes étendent généralement leurs pratiques CI/CD existantes au lieu de les remplacer.

Par où une entreprise doit-elle commencer avec le MLOps ?

Choisissez un modèle important pour l’entreprise et documentez la manière dont il est actuellement mis en production. Comblez ensuite les principales lacunes : contrôle des versions des données et des modèles, tests automatisés, environnement de préproduction et plan de restauration. Réutilisez ce parcours pour le modèle suivant.

Avons-nous besoin d’une plateforme MLOps dédiée ?

Pas toujours. Certaines équipes progressent efficacement avec leur système CI/CD existant, complété par quelques outils ciblés pour le suivi, le registre et la supervision. Une plateforme plus complète devient pertinente lorsque de nombreuses équipes et de nombreux modèles ont besoin de normes et d’une gouvernance communes.

Comment le MLOps contribue-t-il à la sécurité et à la conformité ?

Il rend les contrôles reproductibles. Les journaux d’audit, les accès selon le principe du moindre privilège, l’analyse des vulnérabilités des conteneurs de modèles et les étapes d’approbation s’exécutent au sein du pipeline plutôt que dans le cadre de vérifications manuelles. Les réglementations applicables, telles que la HIPAA ou le RGPD, dépendent de vos données et doivent être confirmées avec votre équipe chargée de la conformité.

Combien de temps faut-il pour parvenir à une pratique MLOps mature ?

Cela dépend de votre point de départ, du nombre de vos modèles et de votre équipe. Les modèles de maturité décrivent une progression par niveaux, et la plupart des organisations les franchissent une étape à la fois au fil de projets successifs, plutôt que dans le cadre d’un programme unique.

Sources

• Qu’est-ce que le MLOps ? (AWS)
• Un cadre pour la livraison continue et l’automatisation du ML : guide pratique du MLOps (Google)
• Les opérations de machine learning offrent de l’agilité et stimulent l’innovation (MIT Technology Review)
• Opérations de machine learning v2 (Azure Architecture Center)
• Modèle de maturité MLOps (Azure Architecture Center)
• MLOps : pipelines de livraison continue et d’automatisation (Google Cloud)
• Gestion du cycle de vie des modèles de machine learning en entreprise (IJISAE)
• Mise en production (Google for Developers)
• Feuille de route des fondations du MLOps pour les entreprises (AWS)
• Liste de contrôle MLOps d’AWS (AWS Prescriptive Guidance)
• Livre blanc MLSecOps de l’OpenSSF
• Bonnes pratiques du MLOps sur AKS (Microsoft Learn)

Recommandé

• Pourquoi l’IA d’entreprise échoue après la démonstration
• IA d’entreprise : sortir du purgatoire des projets pilotes
• IA d’entreprise : sortir du purgatoire des projets pilotes
• MLOps : une IA industrialisée pour renforcer les stratégies d’entreprise avec Ridiculous Engineering