La différence entre un modèle et un produit

Un modèle prédit. Un produit survit aux erreurs, aux données sales, aux changements métier, aux déploiements ratés et aux responsabilités mal définies. C'est exactement l'écart que le MLOps doit combler. Le but n'est pas d'ajouter de la lourdeur autour du modèle. Le but est de rendre le système simple à livrer, observable et rapide à restaurer quand quelque chose casse.

Gate minimum avant la production

Avant de mettre un modèle ou une fonctionnalité IA en production, je veux couvrir cinq points.

1) Contrat de données

• Schéma d'entrée versionné
• Comportement défini pour les valeurs nulles ou invalides
• Stratégie de backfill documentée
• Cohérence entre features d'entraînement et features d'inférence

Quand le contrat de données est flou, l'incident ressemble souvent à du “model drift”, alors qu'il s'agit d'un drift de pipeline.

2) Reproductibilité

• Environnement figé
• Seeds fixées quand c'est possible
• Jeux de données et artefacts versionnés
• Modèle exact récupérable ou reconstruisible

La reproductibilité sert surtout à l'exploitation : quand la performance baisse, il faut savoir ce qui a changé.

3) CI/CD

• Tests unitaires sur les transformations de features
• Tests d'intégration sur l'endpoint d'inférence
• Seuils qualité bloquants avant déploiement
• Smoke tests après déploiement

Un problème de release doit être trouvé avant les utilisateurs.

4) Registry et rollout

• Version du modèle enregistrée
• Métadonnées : données d'entraînement, owner, usage prévu
• Rollout progressif pour les changements risqués
• Rollback exécutable en une commande

Le registry n'est pas seulement un stockage. C'est le contrat entre expérimentation et exploitation.

5) Monitoring en production

• Latence, taux d'erreur, débit
• Drift des distributions de prédiction
• Anomalies de qualité de données
• Évolution du KPI métier
• Coût par inférence ou par tâche réussie

Le monitoring ne doit pas s'arrêter à l'infra. Un modèle peut être techniquement disponible et inutile si le résultat métier baisse.

Checklist de rollback

Un vrai rollback répond à ces questions avant l'incident :

• Quelle est la dernière version connue comme saine ?
• Comment rerouter le trafic vers elle ?
• Quelles migrations de données sont réversibles ?
• Qui décide pendant et hors heures ouvrées ?
• Quel smoke test prouve que le rollback fonctionne ?

Si le rollback demande de l'archéologie manuelle, le système n'est pas prêt pour la production.

Ce que j'automatise en premier

Je commence par les contrôles qui réduisent le plus de risques :

• Validation du schéma à l'ingestion
• Tests des transformations de features
• Publication des artefacts modèles
• Smoke tests de l'endpoint d'inférence
• Alerting avec owner identifié

Ensuite seulement, j'ajoute des boucles plus poussées de drift et d'évaluation. L'ordre est important : sécurité de release d'abord, dashboards avancés ensuite.

Cas liés

• AI Product Photo Detector — MLOps complet avec CI/CD, registry, drift checks et monitoring.
• Belgium Sports Sales Forecast — prévision ML avec Databricks, MLflow et exports orientés production.
• DAISI – Assistant IA entreprise — observabilité et évaluation planifiée dans un contexte GenAI de production.