Le DevOps a transformé la manière dont les équipes livrent des logiciels. Des pipelines CI/CD automatisés, une collaboration étroite entre développeurs et opérations, des déploiements fréquents et fiables ce modèle a fait ses preuves depuis plus d’une décennie. Alors pourquoi le MLOps est-il apparu comme une discipline à part entière ? Parce que les modèles de Machine Learning ne se comportent pas comme du code ordinaire.
La troisième dépendance : les données
En DevOps, un système dépend de deux artefacts : le code et la configuration. En MLOps, il faut en ajouter un troisième, le plus imprévisible de tous : les données.
Un modèle entraîné sur les données de janvier 2024 peut se dégrader silencieusement en juillet si la distribution des données d’entrée a évolué. Ce phénomène le data drift n’a pas d’équivalent direct en ingénierie logicielle traditionnelle. Vous ne pouvez pas écrire un test unitaire qui détecte que vos clients ont changé de comportement d’achat.
Cela signifie que le cycle de vie d’un modèle ne se termine pas au déploiement. Il doit être surveillé en permanence, et potentiellement réentraîné de manière automatisée ou à la demande. La pipeline ne s’arrête pas à git push.
Versioning : du code au modèle
En DevOps, Git est la source de vérité. Chaque changement est tracé, chaque déploiement est reproductible. En MLOps, cette logique s’étend à trois dimensions simultanément :
- Le code (les scripts d’entraînement, les transformations)
- Les données (les datasets d’entraînement et de validation)
- Les hyperparamètres (les paramètres de configuration du modèle)
Un modèle donné n’est reproductible que si vous pouvez reconstituer exactement ces trois éléments. Des outils comme MLflow, DVC ou Weights & Biases ont été créés précisément pour résoudre ce problème. En DevOps, on ne versionne que le code en MLOps, on versionne des expériences entières.
Le testing change de nature
Les tests unitaires vérifient qu’une fonction retourne le bon résultat pour des entrées données. Ce paradigme s’applique mal aux modèles de ML. Comment tester qu’un modèle de classification est “correct” ? On peut vérifier des métriques sur un jeu de données de validation, mais un modèle peut avoir une excellente précision globale tout en étant désastreux sur un sous-groupe particulier de la population.
Le MLOps introduit donc des catégories de tests spécifiques :
- Tests de performance sur des jeux de données de référence
- Tests d’équité (fairness) pour détecter les biais
- Tests de robustesse face aux données aberrantes ou adversariales
- Tests de latence pour les modèles déployés en temps réel
Ces tests s’intègrent dans les pipelines CI/CD, mais ils nécessitent une infrastructure différente notamment des environnements capables de GPU pour les modèles lourds.
Les environnements : GPU, mémoire et contraintes spéciales
En DevOps classique, une application Node.js ou Python tourne sur n’importe quel serveur avec quelques Go de RAM. Un modèle de deep learning peut nécessiter 16, 32, voire 80 Go de VRAM. L’infrastructure de déploiement doit être pensée différemment : clusters GPU, instances spécialisées (A100, H100), scheduling prioritaire.
Les ingénieurs Cloud habitués à provisionner des instances génériques doivent apprendre à travailler avec des contraintes matérielles beaucoup plus strictes et beaucoup plus coûteuses.
La collaboration : un défi organisationnel
En DevOps, les équipes Dev et Ops fusionnent leurs pratiques. En MLOps, trois profils doivent collaborer en permanence : les data scientists (qui construisent les modèles), les ingénieurs ML (qui productionalisent), et les ingénieurs plateforme (qui maintiennent l’infrastructure). Cette trilogie crée des frictions si les rôles et les responsabilités ne sont pas clairement définis.
Un modèle créé dans un notebook Jupyter par un data scientist ne peut pas être poussé en production tel quel. Le travail de transformation refactoring, packaging, tests, monitoring appartient aux ingénieurs ML. Définir cette frontière est l’un des principaux défis organisationnels du MLOps.
Ce que le DevOps apporte au MLOps
Le MLOps hérite de nombreuses bonnes pratiques du DevOps : infrastructure as code, automatisation, culture du feedback rapide, déploiements canary. Ces fondations restent valides. La différence, c’est l’étendue du problème.
Si vous venez du DevOps, vous avez une longueur d’avance réelle. Mais préparez-vous à repenser votre approche du cycle de vie d’un artefact, de la gestion des dépendances, et surtout de la définition de “correct” dans un contexte où les outputs ne sont jamais déterministes.
Conclusion
DevOps et MLOps ne sont pas opposés le second est une extension naturelle du premier dans un monde où les algorithmes apprennent. L’ingénieur Cloud qui comprend ces différences sera capable de concevoir des systèmes qui ne se contentent pas de fonctionner au déploiement, mais qui restent fiables, équitables et performants dans la durée.