Commoditech Parlons-en
← Retour aux articles

Services MLOps : dérive des données, CI/CD et body leasing

Publié : 10 septembre 2026 • Guide B2B / MLOps

Le modèle a un F1 de 0,81 sur l'ensemble de données d'avril. En août, ce même endpoint génère des prédictions que personne n'aurait validées manuellement. Personne n'a calculé le PSI. Personne n'a lancé le retrening. Ou inversement : le cron brûle des GPU chaque dimanche, car « c'est dans le runbook », alors que la distribution des caractéristiques n'a pas bougé depuis six semaines.

Ce n'est pas un problème d'algorithme. C'est un problème de boucle. Les services MLOps ne sont pas « du DevOps qui connaît Python ». C'est du CI/CD plus continuous training : détection de dérive, passerelle de retrening, registre de modèle, serving avec le même code de caractéristique que l'entraînement. Sans cette boucle, vous achetez un pickle avec un ticket pour la plateforme.

Ci-dessous, une distinction qui manque dans les briefs « nous cherchons un MLOps » : quand louer une seule personne (body leasing d'un ingénieur MLOps), et quand la dérive et le serving nécessitent un squad DE + DS + MLOps. Nous avons détaillé les taux horaires séparément : combien coûte le body leasing IT en 2026. Ici, nous expliquons pourquoi le retrening sur minuterie est le moyen le plus coûteux d'obtenir un F1 stable.

Une phrase qui ne figure pas sur la diapositive « ML platform »

Kubeflow sans propriétaire de la dérive est du CI pour les images. Pas des services MLOps. Un PSI supérieur à 0,25 est un signal, pas un dashboard. Si personne n'a l'autorisation d'arrêter le serving et de lancer le retrening à partir d'un commit, vous avez une démo avec un GPU.

1. Anatomie : le retraining calendaire n'est pas du continuous training

Une semaine typique pour un modèle en production dans une banque, une entreprise de télécommunications (telco) ou le secteur du retail ne ressemble pas à un tutoriel MLflow. Elle ressemble à trois boucles distinctes :

  • Entraînement. Le Data Scientist dans un Studio / notebook. Artefact : model.pkl ou une carte dans le Model Registry, que personne ne promeut.
  • Déploiement. Un ticket pour le DevOps. Image, probe, Ingress. Le rollback est maîtrisé par l'équipe plateforme. Le rollback de la définition de la feature n'est maîtrisé par personne.
  • « Monitoring ». Grafana pour la latence et les 5xx. Pas pour le Population Stability Index, pas pour le KS, pas pour la baisse du F1 sur une étiquette retardée.

Kreuzberger, Kühl et Hirschl, dans leur revue de l'architecture MLOps (IEEE Access, 2023), séparent le CI/CD du continuous training (CT) : une quatrième boucle qui relie les données, le modèle et le serving. Sans CT, vous avez un pipeline logiciel. Pas un pipeline d'apprentissage. Sculley et al. (NIPS 2015) l'avaient déjà souligné : le code d'apprentissage ne représente généralement qu'une petite fraction du système ; le reste est du « glue code », de la configuration et des dépendances cachées. La modification d'une seule feature entraîne une avalanche — CACE, changing anything changes everything.

Trois symptômes indiquant que vous utilisez cron, et non le CT :

  1. Retraining calendaire. Dimanche 02:00, indépendamment du PSI. Ou jamais, « parce que le modèle est suffisamment bon ». Les deux variantes compromettent soit la qualité, soit les coûts du cloud.
  2. Feature calculée deux fois. Pandas sur un ordinateur portable, SQL dans Airflow. Le fill-rate diverge de 0,3 point de pourcentage et n'est détecté qu'après un trimestre, lorsque la dérive a déjà impacté les décisions.
  3. Étiquette retardée, métrique aveugle. Le F1 en production ne peut être calculé qu'après des semaines. D'ici là, le seul signal est la dérive des entrées (PSI, KS, KL, MMD) — ou rien.

C'est pourquoi un brief « location de DevOps pour les modèles » sans contexte de dérive est le moyen le plus coûteux d'obtenir un autre pickle. Les compétences qui constituent réellement les services MLOps se trouvent sur trois piliers : ingénieurs MLOps, Data Engineering, Data Science. Le GPU serving et les LLM ajoutent AI / RAG et DevOps / SRE.

2. Ce que disent les recherches, pas les decks « ML platform »

Vous n'avez pas besoin d'une énième définition de la maturité MLOps. Vous avez besoin d'un seuil à partir duquel le réentraînement a le droit de se déclencher — et le droit de ne pas se lancer quand la distribution reste stable.

  • PSI > 0,25 n'est pas l'opinion d'un dashboard. Katalay, Dimandja et Masakuna, A Multi-Criteria Automated MLOps Pipeline for Cost-Effective Cloud-Based Classifier Retraining in Response to Data Distribution Shifts (arXiv:2512.11541, décembre 2025) : ils combinent KS, KL, PSI, MMD et ΔAcc/ΔF1 en un score unique et ne déclenchent le réentraînement qu'une fois le seuil franchi. Dans la littérature sur le scoring, un PSI supérieur à 0,25 signale depuis des années un drift significatif ; en dessous de 0,10 — du bruit. Le pipeline ne devine pas. Il calcule.
  • Le réentraînement à chaque alerte coûte plus cher que le drift. Dans la même expérience (autoencoder, jeux de données anomaly detection), quatre politiques : STATIC (zéro réentraînement) maintient une accuracy de 0,69±0,2 pour un coût de 54,8 ; FIXED (intervalle fixe) et NAIVE (réentraînement à chaque drift) montent à 0,75, mais coûtent 160,6 et 130,5 avec 3,0 et 4,3 réentraînements. Auto-MLOps : ce même 0,75±0,03, coût de 108,1, réentraînements à 1,4±1,2. La même qualité qu'un calendrier fixe, un tiers moins cher que FIXED, trois fois moins d'exécutions que NAIVE.
  • Une architecture sans rôles n'est qu'un slide. Kreuzberger et al. (2023) : le MLOps repose sur des pratiques et des rôles (ML Engineer, Data Engineer, DevOps), pas sur un produit de marketplace. Le CT est une boucle, pas un bouton dans Vertex. DORA 2024 ajoute : elite vs low représente un ordre de grandeur d'écart sur la fréquence de déploiement et le lead time. Cinq timesheets (un Data Scientist du vendor A, un Data Engineer du B, « quelqu'un pour Kubernetes » du C) ne construiront pas de lead time performant. Ils produiront trois SLA de remplacement. Nous avons détaillé l'anatomie de cette erreur dans team leasing vs body leasing 2026. Le pipeline de données qui alimente le CT est décrit dans l'article sur l'analytique prédictive.

Conclusion architecturale clé

Les services MLOps commencent par un gate de validation, pas par un cluster. Le détecteur de drift (PSI/KS/KL) émet un événement. La politique décide s'il faut rééchantillonner les données et réentraîner. Le CI valide le schéma des features et la métrique vs baseline. Le CD promeut la version dans le registre. Le serving lit cette même définition de feature. Si la moindre étape repose sur un humain qui colle un CSV, vous n'avez pas de CT. Vous avez une astreinte.

3. Cas de production : le réentraînement du dimanche qui ne résolvait rien

Retour d'expérience ingénierie : du cron au PSI

Scoring de fraude, retail / paiements. Sources : Postgres, événements dans Kafka, features dans dbt, serving sur Kubernetes. Le fonctionnement de l'équipe :

  • entraînement : Data Scientist, SageMaker Studio, export manuel de l'artefact,
  • déploiement : ticket, Docker, Helm, sans test du schéma d'entrée,
  • réentraînement : cron le dimanche, dataset complet, GPU pendant quatre heures,
  • monitoring : p99 et 5xx. Personne ne calculait le PSI.

Problème : après une modification du mix de canaux (nouveau partenaire de paiement), le F1 sur étiquette différée a chuté en deux semaines. Le cron du dimanche s'entraînait sur un mélange où le nouveau canal n'était que du bruit. Le coût GPU augmentait. Pas la qualité.

Changement : calcul du PSI et du KS sur un échantillon du VPC, seuil de 0,25 sous forme d'alerte dans la CI, pas sur Slack « au cas où ». Réentraînement uniquement lorsque le score de drift dépasse τ et que le ΔF1 sur le holdout est négatif. Le registre de modèles (MLflow) promeut la version. Serving avec le même code de feature (offline batch = online). DevOps conserve la main sur l'image et l'IAM. MLOps pilote le gate.

Mesure : nombre de réentraînements réduit de 4/mois à ~1,5. Même niveau d'accuracy qu'avec un entraînement systématique, facture GPU plus proche de l'Auto-MLOps de Katalay que du FIXED. Temps écoulé entre l'alerte PSI et la nouvelle version en production : quelques heures, pas un sprint. Ce n'est pas la magie de Vertex. C'est l'ownership de la boucle de CT.

Les chiffres théoriques ne se transposent pas tels quels à votre scoring. En revanche, la mécanique s'applique : le calendrier et l'alerte naïve sont deux façons de brûler du budget. Le gate multicritère en est une troisième — et la seule qui soit réellement auditable devant un comité des risques.

4. Tableau de décision : quel CT, quelle composition

Approche Complexité Qualité en cas de dérive Coût cloud / GPU Surcharge pour l'équipe Quand l'appliquer
STATIC — modèle unique, zéro retraining Faible Diminue avec la dérive (dans l'article 0,69 vs 0,75) Faible Faible, jusqu'à l'explosion PoC, pas de SLA, le jeu de données est stable
FIXED — retraining planifié Faible à moyenne Maintient la qualité lorsque la dérive est régulière Élevé (dans l'article 160,6 vs 108,1) Moyen (astreinte dominicale) Batch régulier, étiquette fiable, le budget GPU n'est pas un problème
NAIVE — retrain à chaque alerte de dérive Moyenne Maintient la qualité, beaucoup de faux départs Élevé (4,3 retrainings vs 1,4) Élevé (bruit d'alertes) Lorsque le détecteur est médiocre et que vous craignez de manquer un shift
Passerelle multicritères (PSI/KS/KL + ΔF1 + CI/CD) Élevée Du même ordre que FIXED/NAIVE Moyen (le plus bas parmi les boucles) Élevé au démarrage, diminue lorsque la boucle est inactive Enterprise, NDA, GPU, la commission des risques souhaite un audit « pourquoi maintenant »
Service géré (SageMaker / Vertex / Azure ML) + propriétaire du CT Moyenne (intégration) Dépend de l'activation du détecteur, pas seulement de l'UI Moyen à élevé (métriques de service) Moins élevé opérationnellement, si IAM est déjà en place Un seul cloud, un seul IAM, quelqu'un doit quand même définir le seuil

MLOps n'est pas du Python CRUD et n'est pas un « DevOps ordinaire ». Fourchette DevOps/SRE : 140–200 / 200–325 PLN/h (spécialiste / client). AI/LLM en production : 180–250 / 240–350 PLN/h. Un ingénieur MLOps avec GPU serving et dérive se situe dans cette fourchette, plus proche du haut lorsque le retraining est inclus dans le SLA. Marge 10–25%. Carte, pas un barème de prix — détails dans les tarifs 2026.

5. Anti-patterns absents du tutoriel Kubeflow

  1. Brief "DevOps avec connaissance de Python" pour le CT. Vous obtiendrez Helm et une probe. Vous n'obtiendrez ni PSI ni de test de schéma de feature. Le marché est saturé : le DevOps classique a de l'offre, pas l'ingénieur de boucle ML. Une annonce mal étiquetée recueille des CV en 48h et zéro compétence pertinente.
  2. Dashboard au lieu d'une passerelle. Evidently dans Grafana, alerte dans Slack, retraining manuel "quand il y aura le temps". C'est du monitoring. Pas des services MLOps. La passerelle a le droit d'arrêter la promotion d'une version sans intervention humaine dans le pipeline.
  3. Retraining sur l'ensemble complet, car c'est plus simple. Katalay et al. montrent pourquoi mélanger le nouveau drift avec l'ancien ensemble de données au lieu de s'entraîner à partir de zéro chaque semaine. Un retraining complet sans détecteur, c'est le FIXED du papier : la qualité est là, la facture aussi.
  4. Fausse équipe ML. Un Data Scientist d'un fournisseur A, un Data Engineer d'un fournisseur B, un MLOps "à 20% de la plateforme". Trois onboardings, zéro DAG commun, zéro Definition of Done commun pour la promotion du modèle. Ce n'est pas du staff augmentation. C'est une taxe d'intégration décrite lors du leasing d'équipes IT.

6. Playbook: qui recruter et dans quel ordre

Ne commencez pas par le cluster. Commencez par la question de savoir quelle boucle bloque le SLA : les données, le modèle, la dérive ou le serving.

  1. Une seule lacune dans une boucle existante. Vous avez Airflow, un registre et quelqu'un qui révise les PR. Il manque un propriétaire pour le PSI et le CD du modèle. C'est un body leasing classique d'ingénieurs MLOps : une seule personne, votre stand-up, votre DoD. Premiers profils en quelques jours, pas en un trimestre — nous sourçons à la demande, nous ne vendons pas de banc nominatif pour demain matin.
  2. Le notebook est le seul artefact. Il n'y a pas de DAG, pas de test de schéma, pas de serving. Une seule personne ne peut pas assembler cela. Composition 3–5 : DE (sources, dbt/Spark), DS (modèle, validation), MLOps (image, dérive, promotion). C'est plus proche du team leasing que de « nous achèterons un autre DevOps ».
  3. Les données ne sortent pas de votre VPC. Le contractant dans votre IAM, votre cloud, NDA et accord de traitement des données. Un Colab avec un dump de production « pour calculer le PSI » est une fuite. Fonctionnalités offline en batch, serving online avec le même code.
  4. Ramp-up. Personne pour une équipe existante : premiers CV en 24–48 h, démarrage après vos entretiens et contrat. Squad à partir de zéro : des semaines, pas un sprint, car vous assemblez les autorisations, les données et le DoD pour la promotion du modèle. Le mensonge « trois seniors MLOps dès lundi » est un CV ou un banc que nous n'avons pas — et nous ne ferons pas semblant.

Commoditech réalise du T&M et du recrutement permanent depuis Varsovie depuis 2012. Plus de 80 spécialistes en réseau, pas de banc inactif. Un brief T&M ou un success fee peut être soumis depuis l'IDE via MCP pour les agents AI, pas seulement via le formulaire. Les montants pour un stack spécifique sont calculés par un humain ; les fourchettes se trouvent dans l'article sur les tarifs, pas dans le JSON de l'agent.

FAQ

En quoi les services MLOps diffèrent-ils du DevOps classique pour les modèles ML ?

DevOps livrera l'image, la probe et le rollback. MLOps livrera en plus : le registre de modèle, le test de schéma de caractéristiques, la détection de dérive (PSI, KS, KL), la passerelle de retrain et le serving avec le même code de caractéristique que l'entraînement. CI/CD sans continuous training est un déploiement de pickle. Pas une plateforme. Kreuzberger et al. (2023) distinguent explicitement le CT comme une boucle distincte — pas « un autre job dans Jenkins ».

Quand engager un seul ingénieur MLOps, et quand un squad ?

Une seule personne, lorsque le DAG, le registre et l'IAM sont déjà en place, et qu'il manque un propriétaire de la dérive et du CD du modèle. Un squad de 3 à 5 personnes (DE + DS + MLOps), lorsque le seul artefact est un notebook, et que le retrain est un ticket Jira. Un MLOps seul sans DE ne corrigera pas la source. Un Data Scientist seul sans MLOps livrera l'AUC. Il ne livrera pas le p99 ni l'audit « pourquoi cette version ». Si vous n'avez personne pour réviser la PR d'un contractant, n'achetez pas de body leasing. Achetez un lead plus un rôle ou un squad.

Combien coûte le body leasing d'un ingénieur MLOps en Pologne en 2026 ?

Le MLOps se situe entre le DevOps/SRE (client 200–325 PLN/h) et l'AI/LLM de production (240–350 PLN/h). Le GPU serving et le retrain sur dérive poussent le taux vers le haut de la fourchette. Marge du fournisseur 10–25 % — si quelqu'un promet 8 % pour un remplacement en 5 jours, ajoutez-le sur une autre ligne. Ceci est une carte du marché, pas une offre. Le montant pour le brief est calculé par une personne. Détails dans les tarifs 2026.

Un contractant MLOps peut-il travailler sur des données sous NDA et RODO ?

Oui : Votre environnement, Votre IAM, Votre cloud ou on-premise, contrat T&M avec NDA, accord de traitement des données et IP côté client. Un dump de production sur l'ordinateur portable du contractant « pour calculer plus rapidement le PSI » est une fuite. Vous calculez la dérive sur un échantillon dans le VPC, pas dans Colab. L'audit d'accès est le vôtre. Clauses : contrats, marges, IP.

Sources