L’industrialisation des modèles d’intelligence artificielle en entreprise bute systématiquement sur le même écart : les équipes data science livrent des notebooks prometteurs, mais le passage en production révèle une fragilité structurelle. Les modèles dégradent silencieusement, les dépendances de données évoluent sans alerte, et la traçabilité nécessaire aux audits réglementaires est absente. Le MLOps (Machine Learning Operations) répond à cet écart en appliquant les principes du DevSecOps au cycle de vie complet des modèles, de l’expérimentation au retrait de service. Pour les DSI et RSSI confrontés à une pression réglementaire croissante (AI Act, NIS2), c’est moins une option d’optimisation qu’une exigence de gouvernance.
Le cycle de vie MLOps : au-delà du pipeline DevOps classique
Un pipeline DevOps gère le code. Un pipeline MLOps gère simultanément trois artefacts interdépendants : le code du modèle, les données d’entraînement et l’artefact entraîné lui-même. Cette triple dimensionnalité introduit des contraintes absentes en DevOps standard.
Le modèle de référence, formalisé par Google dans son guide praticien MLOps et largement adopté dans la communauté DevOps, distingue trois niveaux de maturité :
| Niveau | Description | Caractéristiques principales |
|---|---|---|
| ML-0 | Processus manuel | Entraînement ad hoc, déploiement manuel, aucun monitoring |
| ML-1 | Pipeline automatisé | CI/CD du code, entraînement déclenché manuellement, monitoring basique |
| ML-2 | Pipeline CI/CT/CD | Ré-entraînement automatique sur déclencheur statistique, monitoring drift, model registry |
La majorité des entreprises françaises opèrent en ML-0 ou ML-1 en 2026, y compris sur des cas d’usage à risque élevé au sens de l’AI Act. Le saut vers ML-2 est celui qui intéresse les équipes infrastructure, car il implique une refonte des pipelines Kubernetes et des politiques d’accès aux données.
La différence structurante entre ML-1 et ML-2 est le Continuous Training (CT) : un mécanisme qui déclenche automatiquement un nouveau cycle d’entraînement lorsque des seuils statistiques (drift, dégradation de métrique) sont franchis, sans intervention humaine pour initier le pipeline.
Model Registry : la pièce centrale de la gouvernance
Le Model Registry est le registre versionné des artefacts entraînés. Il remplit une fonction analogue à un registre de conteneurs (Docker Hub, Harbor), mais pour les modèles ML. Chaque entrée du registry lie :
- L’artefact sérialisé (weights, pipeline scikit-learn, modèle ONNX)
- Le hash du dataset d’entraînement utilisé
- Les métriques d’évaluation (accuracy, F1, AUC, RMSE selon le cas)
- Le commit Git du code d’entraînement correspondant
- Les approbations de déploiement (validation humaine ou automatique)
- Les métadonnées réglementaires requises par l’AI Act pour les systèmes à haut risque
MLflow est la référence open source (Apache 2.0) pour cette couche. Il expose une API REST qui permet d’interroger le registry depuis n’importe quel pipeline CI/CD existant (GitHub Actions, GitLab CI, Tekton, Kubeflow Pipelines) sans dépendance à une plateforme particulière.
La politique de promotion entre stages (Staging, Production, Archived) doit être formalisée dans la documentation SMSI. Pour les systèmes IA à haut risque (Article 6 et Annexe III de l’AI Act), cette politique constitue une partie de la documentation technique obligatoire.
Détection du drift : le monitoring spécifique au ML
La dégradation d’un modèle en production prend deux formes distinctes, souvent confondues :
Data drift : la distribution des données en entrée s’écarte de celle observée à l’entraînement. Les features reçues en production ne ressemblent plus aux features sur lesquelles le modèle a été optimisé. Les tests statistiques applicables incluent le test de Kolmogorov-Smirnov (variables continues) et le test du chi-carré (variables catégorielles).
Concept drift : la relation entre les features et la variable cible évolue dans le monde réel. Le modèle reçoit des données similaires à celles de l’entraînement, mais la réalité qu’il doit prédire a changé. La détection requiert des métriques métier sur des fenêtres glissantes, ce qui suppose d’avoir accès aux labels réels a posteriori (ground truth).
L’ENISA, dans son rapport Securing Machine Learning Algorithms, souligne que le drift non détecté constitue un vecteur d’attaque indirect : un acteur malveillant peut empoisonner progressivement les données d’entrée pour dégrader les décisions automatisées sans déclencher d’alerte de sécurité conventionnelle.
Les outils de monitoring drift à considérer en production :
- Evidently AI (open source) : rapports HTML/JSON de drift, intégration Prometheus/Grafana
- Whylogs (open source, WhyLabs) : profiling continu des données en streaming
- Amazon SageMaker Model Monitor, Vertex AI Model Monitoring, Azure Machine Learning model monitoring : solutions managées intégrées aux plateformes cloud respectives
L’intégration au stack d’observabilité existant (alertes Alertmanager, dashboards Grafana) est recommandée pour éviter la prolifération de consoles de monitoring dédiées.
Intégration Kubernetes et orchestration des pipelines
Pour les équipes déjà opérant sur Kubernetes en production, l’infrastructure MLOps sur Kubernetes s’articule autour de deux patterns complémentaires :
Orchestration des pipelines d’entraînement : Kubeflow Pipelines (projet CNCF incubating) et Argo Workflows (projet CNCF diplômé) permettent de définir les DAG d’entraînement comme des objets Kubernetes natifs (CRDs). Chaque étape (préparation des données, entraînement, évaluation, enregistrement dans le registry) s’exécute dans un pod isolé avec des quotas de ressources distincts. Cette approche garantit la reproductibilité et l’isolation entre expériences.
Serving des modèles : KServe (anciennement KFServing) expose les modèles enregistrés via une API REST/gRPC standardisée, avec support natif du canary deployment et du A/B testing. La politique de scaling (HPA sur métriques de latence, KEDA sur métriques applicatives) doit être calibrée indépendamment du reste des workloads, les workloads d’inférence ayant des profils de charge distincts.
Les aspects RBAC méritent une attention particulière : les pipelines d’entraînement accèdent à des volumes de données sensibles, et les Service Accounts Kubernetes utilisés doivent respecter le principe de moindre privilège. L’accès aux buckets de données d’entraînement (S3, GCS, Azure Blob) doit être contrôlé via des politiques IAM spécifiques aux namespaces MLOps, distinctes des politiques applicatives.
Exigences réglementaires : AI Act et NIS2
Le Règlement UE 2024/1689 (AI Act), dont les dispositions relatives aux systèmes à haut risque s’appliquent à partir d’août 2026, impose des obligations techniques directement couvertes par une architecture MLOps mature :
- Article 9 (Gestion des risques) : exige une surveillance continue des performances en production, couverte par le monitoring drift
- Article 12 (Journalisation automatique) : impose la conservation des logs d’entrée/sortie du modèle pendant une durée définie, ce qui requiert une politique de rétention dans le pipeline de serving
- Article 11 (Documentation technique - Annexe IV) : liste exhaustive incluant les données d’entraînement, les métriques de validation et les tests de robustesse, dont le Model Registry est le support naturel
Le NIST AI RMF 1.0 (GOVERN / MAP / MEASURE / MANAGE) offre un cadre complémentaire non normatif qui permet de documenter les contrôles MLOps dans un langage compréhensible par les équipes sécurité et les auditeurs.
Pour les organisations soumises à NIS2, les pipelines ML critiques (détection de fraude, supervision de systèmes industriels, scoring crédit) entrent dans le périmètre des mesures de gestion des risques de l’article 21. L’ANSSI recommande d’intégrer ces systèmes au périmètre du SMSI et de les soumettre aux mêmes procédures de gestion des changements que les systèmes d’information critiques.
Sécurisation du pipeline MLOps
Les pipelines MLOps introduisent des surfaces d’attaque spécifiques, documentées par MITRE dans l’extension ATLAS (Adversarial Threat Landscape for AI Systems) du framework ATT&CK. Les vecteurs principaux à adresser :
Supply chain des modèles : les modèles de fondation téléchargés depuis des hubs publics (Hugging Face, TensorFlow Hub) peuvent contenir du code malveillant sérialisé (notamment via pickle Python). Politique recommandée : scanner systématiquement les artefacts téléchargés, utiliser des formats d’échange sûrs (ONNX, safetensors), et maintenir un miroir interne des modèles validés.
Empoisonnement des données d’entraînement : si les données proviennent de sources externes ou agrégées, elles peuvent être manipulées pour biaiser le modèle (backdoor attack). Contrôles : validation statistique des datasets à chaque cycle, hachage et signature des datasets approuvés dans le registry.
Exfiltration via l’API d’inférence : des attaques par extraction de modèle (model stealing) permettent de reconstituer un modèle propriétaire via un volume suffisant de requêtes. Rate limiting, détection d’anomalies sur les patterns de requêtes et authentification forte sur les endpoints d’inférence sont des contrôles de base.
L’intégration du pipeline MLOps dans la chaîne IA technique de l’organisation doit suivre les mêmes processus de revue sécurité que tout composant critique. Cela inclut l’analyse statique du code des pipelines, la revue des images de conteneurs d’entraînement, et l’audit des accès aux données d’entraînement sensibles.
Plan de mise en oeuvre par priorité
La mise en oeuvre d’un MLOps mature est un projet d’infrastructure pluritrimestriel. Une séquence pragmatique pour les équipes en ML-0 ou ML-1 :
- Trimestre 1 - Fondations : versionner systématiquement code et données (DVC ou équivalent), déployer un Model Registry (MLflow), documenter le processus de déploiement existant
- Trimestre 2 - Observabilité : instrumenter les endpoints d’inférence (latence, volume, erreurs), déployer un premier moniteur de data drift sur les modèles critiques, intégrer les alertes dans le stack existant
- Trimestre 3 - Automatisation : construire le pipeline CI pour les modèles (validation automatique des métriques avant enregistrement dans le registry), déployer le canary deployment sur Kubernetes
- Trimestre 4 - Conformité : documenter les systèmes IA à haut risque selon les articles 9, 11 et 12 de l’AI Act, intégrer le MLOps dans le SMSI, préparer la surveillance post-déploiement réglementaire
L’outillage retenu doit être arbitré entre la richesse fonctionnelle des plateformes managées et les exigences de souveraineté des données, particulièrement pour les modèles entraînés sur des données personnelles soumises au RGPD.