Le passage du DevOps au MLOps n'est pas juste l'ajout d'un ou deux nouveaux outils—c'est un changement fondamental dans la façon de penser le déploiement, le monitoring et l'itération. Le DevOps traditionnel se concentre sur la livraison de code stable et prévisible. Le MLOps, lui, traite des systèmes qui apprennent et évoluent, ce qui introduit toute une nouvelle couche de complexité.
L'une des plus grandes différences est la donnée. En DevOps standard, la logique applicative est statique. Une fois déployée, elle se comporte de la même façon jusqu'à la prochaine mise à jour. Avec les modèles ML, le comportement dépend fortement des données sur lesquelles ils ont été entraînés—et ces données peuvent dériver dans le temps. Cela signifie qu'il vous faut des pipelines robustes non seulement pour le code, mais aussi pour le versioning des données, la validation et les workflows de réentraînement.
Le monitoring prend également une nouvelle dimension. Vous ne surveillez plus seulement la disponibilité ou les pics de latence. Vous devez suivre des métriques de performance du modèle comme l'accuracy, la precision, le recall, et détecter quand votre modèle commence à faire de mauvaises prédictions parce que les données du monde réel ont dérivé. Cela nécessite une intégration plus étroite entre votre plateforme ML et votre stack d'observabilité.
Autre changement clé : l'expérimentation devient centrale. Dans le logiciel traditionnel, l'A/B testing est optionnel. En ML, c'est essentiel. Vous comparez en permanence des versions de modèles, testez de nouvelles features, et évaluez si un modèle réentraîné améliore réellement les résultats. Cela signifie que votre infrastructure doit supporter les déploiements parallèles, les tests en shadow mode, et les feature stores.
Enfin, il y a la question de la reproductibilité. En DevOps, vous pouvez reproduire un déploiement avec le même code et la même config. En MLOps, il vous faut aussi les données d'entraînement exactes, les hyperparamètres, et même la graine aléatoire (random seed). C'est pourquoi des outils comme DVC (Data Version Control) et les registres de modèles sont devenus standards dans le monde du ML.
La bonne nouvelle ? De nombreux principes DevOps s'appliquent toujours. L'automatisation, les pipelines CI/CD, l'infrastructure as code—tout cela reste critique. Mais le MLOps exige d'étendre ces pratiques à l'ensemble du cycle de vie ML, de l'ingestion des données au monitoring et au réentraînement des modèles. C'est plus de travail, mais c'est aussi ce qui rend les systèmes ML de production fiables et scalables.
La structure d'équipe et les nouveaux handoffs
Le DevOps a largement résolu le problème de handoff entre développeurs et opérations en rendant les deux responsables du même pipeline et de la même rotation d'astreinte. Le MLOps rouvre ce problème avec un troisième acteur : les data scientists, qui travaillent souvent dans des notebooks, itèrent de façon expérimentale, et ne sont pas toujours incités à écrire du code de qualité production. Les organisations qui réussissent leur MLOps intègrent généralement une fonction plateforme ou ML engineering dont le rôle spécifique est de prendre un notebook validé et de le transformer en service gouverné, monitoré et réentraîné automatiquement—sans demander au data scientist de devenir expert Kubernetes.
Cela change ce que signifie « terminé » pour un modèle. En DevOps, une feature est livrée quand elle passe les tests et la revue de code. En MLOps, un modèle a en plus besoin d'un rapport d'évaluation approuvé, d'une traçabilité documentée du dataset d'entraînement, d'un plan de rollback si la nouvelle version sous-performe en production, et généralement d'une période de canary ou de shadow-traffic avant le déploiement complet. Sauter l'une de ces étapes, c'est comme ça que des équipes se retrouvent avec des modèles en production que personne ne peut expliquer ni faire revenir en arrière en toute sécurité.
L'astreinte a aussi une autre allure. Un ingénieur d'astreinte traditionnel répond aux taux d'erreur, à la latence et à l'épuisement des ressources. Une rotation d'astreinte ML doit en plus répondre à des questions comme « la distribution des entrées a-t-elle dérivé » ou « ce modèle est-il encore calibré pour la population qu'il score aujourd'hui », ce qui exige soit un outillage statistique disponible, soit un chemin d'escalade rapide vers le propriétaire du modèle. Les équipes qui ne définissent pas ce chemin d'escalade à l'avance finissent par alerter la mauvaise personne lors d'un incident réel, ou pire, personne ne remarque la dégradation de la qualité du modèle avant qu'une métrique business ne bouge des semaines plus tard.
La planification des coûts et de l'infrastructure diffère aussi
Les jobs d'entraînement et les workloads d'inférence ont des profils de ressources très différents des services web classiques, ce qui change significativement la planification de capacité. Les runs d'entraînement sont souvent limités par le GPU, en pic de charge, et coûteux à l'heure, ce qui pousse de nombreuses équipes vers de la capacité GPU spot/préemptible avec du checkpointing intégré dans la boucle d'entraînement, afin qu'un run interrompu puisse reprendre plutôt que redémarrer de zéro. L'inférence, à l'inverse, est généralement sensible à la latence et nécessite une capacité prévisible, parfois sur un matériel entièrement différent—inférence CPU pour les modèles légers, GPU ou accélérateurs spécialisés pour les plus gros.
Les feature stores ajoutent une couche d'infrastructure supplémentaire qui n'a pas d'équivalent direct en DevOps : un système de référence pour les features utilisées à la fois à l'entraînement et au serving, conçu spécifiquement pour éviter le training-serving skew—cette classe de bug où un modèle performe bien hors-ligne mais mal en production parce que les features vues à l'entraînement ont été calculées différemment de celles vues en direct. Mettre en place un feature store est un investissement d'infrastructure réel, et les équipes le repoussent souvent jusqu'à avoir été échaudées par un training-serving skew au moins une fois, ce qui est évitable avec une planification plus précoce.
La visibilité sur les coûts doit également remonter plus loin dans le cycle de vie que dans la gestion des coûts DevOps classique. Un modèle qui coûte très peu à servir peut malgré tout avoir consommé d'énormes heures de GPU en recherche d'hyperparamètres ou en expériences de réentraînement répétées, et cette dépense reste invisible si vos tableaux de bord de coûts ne suivent que l'infrastructure de production. Suivez les coûts d'expérimentation aux côtés des coûts de serving dès le premier jour, sinon vous n'aurez aucun moyen d'expliquer à votre équipe finance pourquoi le budget ML ne correspond pas au trafic de production.
Rien de tout cela ne signifie qu'il faille jeter votre investissement DevOps existant. Le CI/CD, l'infrastructure as code et une observabilité solide restent le socle—le MLOps se comprend mieux comme des pratiques DevOps étendues avec du versioning de données, des portes d'évaluation de modèles, et des dimensions de monitoring qui tiennent compte de la dérive statistique et pas seulement de la santé système. Les équipes qui tentent de construire le MLOps comme une discipline parallèle et séparée, plutôt que comme une extension de ce qui fonctionne déjà, ont tendance à dupliquer l'outillage et à créer des frontières de responsabilité confuses entre les deux fonctions.
La gouvernance et la conformité ajoutent une couche que le DevOps a rarement eu à gérer
Les secteurs réglementés exigent de plus en plus l'explicabilité et une piste d'audit pour les décisions automatisées, ce qui impose aux systèmes ML des exigences que la plupart des pipelines DevOps n'ont jamais eu à satisfaire. Il ne suffit pas de savoir quel commit a livré un changement—vous devrez peut-être reconstituer quelle version de modèle a produit une prédiction donnée pour un client donné, quelles données et features l'ont alimentée, et si le modèle opérait dans son enveloppe validée à ce moment-là. Construire cette traçabilité après coup est bien plus difficile que de la concevoir dès le premier déploiement.
Cela pousse de nombreuses plateformes MLOps à traiter les model cards, les datasheets de datasets, et les rapports de biais/équité comme des artefacts obligatoires, au même titre que la couverture de tests. Les équipes livrant vers des secteurs réglementés—finance, santé, recrutement—devraient budgéter cela dès le départ plutôt que d'adapter la conformité après coup.
La leçon pratique est de résister à l'envie de traiter le MLOps comme un simple ajout au DevOps existant. Les fondations de contrôle de version et de CI/CD se transposent directement, mais la gouvernance doit être reconstruite avec les données et les artefacts de modèle comme citoyens de premier rang. Les organisations qui font cela tôt évitent bien des incidents de modèle plus tard.