MLOps : ce qui sépare un modèle qui marche d'un modèle qui tient

Un modèle qui produit de bonnes prédictions sur un ordinateur portable n'est pas un livrable. C'est une démonstration de faisabilité. Ce qui sépare les deux est un ensemble de composants peu spectaculaires et rarement budgétés.

Les sept éléments

1. Le versionnement conjoint du code, des données et du modèle. Vous devez pouvoir répondre à la question « quel modèle a produit cette prédiction du 12 mars, et sur quelles données a-t-il été entraîné ». Sans cette traçabilité, tout diagnostic d'incident devient une enquête.

2. Un pipeline d'entraînement reproductible. Réentraîner ne doit pas consister à réexécuter un notebook dans un ordre que seul son auteur connaît. Une commande, un environnement figé, un résultat identique.

3. Des tests sur les données d'entrée. Schéma, plages de valeurs, taux de valeurs manquantes, cardinalité des catégories. La majorité des incidents en production ne viennent pas du modèle mais d'un changement silencieux en amont, et ces tests le détectent avant que la prédiction ne parte.

4. Des tests de non-régression sur les prédictions. Un jeu de cas de référence dont on connaît la sortie attendue. Si une modification change la prédiction sur ces cas, elle doit être justifiée explicitement.

5. Le monitoring de dérive. Dérive des données d'entrée et dérive de la relation entre entrées et sortie. Avec un seuil et une alerte nominative : une alerte qui n'arrive à personne n'existe pas.

6. Un plan de repli. La baseline reste implémentée et activable en une commande. Le jour où le modèle doit être désactivé, la question ne doit pas être « et maintenant, on fait comment ».

7. La fiche modèle. Hypothèses, périmètre de validité, limites connues, populations sur lesquelles le modèle est moins fiable, date de dernière validation. C'est aussi ce que votre conformité demandera.

Le coût réel

L'industrialisation représente couramment autant que le développement du modèle, parfois davantage. Ce n'est pas un dépassement, c'est le coût normal du sujet. Une proposition qui ne le chiffre pas est incomplète, et le complément arrivera au pire moment.

Ce qu'il ne faut pas surdimensionner

Il n'est pas nécessaire de déployer une plateforme MLOps complète pour un premier modèle. Sur un cas d'usage unique en inférence par lots quotidienne, un ordonnanceur, un dépôt de code, un stockage de modèles versionnés et quelques tests automatisés suffisent.

Les plateformes complètes se justifient à partir de plusieurs modèles en production et d'une équipe dédiée. Les déployer trop tôt produit une complexité que personne n'exploite et qui devient elle-même une dette.

Le critère de fin de mission

Il doit être vérifiable par vous et non déclaratif : votre équipe interne doit pouvoir réentraîner le modèle, de bout en bout, sans notre aide, et le démontrer devant nous avant la fin de la mission.

Si ce test échoue, le transfert n'a pas eu lieu, quelle que soit la qualité de la documentation remise.