Le modèle dans le notebook a un AUC de 0.87. En production, la demande de crédit attend 14 jours, parce que la feature « nombre de transactions 30 jours » est un export GUI manuel vers CSV. Ou le p99 d'inférence saute au-dessus de 500 ms, parce que quelqu'un a fourré un pickle de laptop dans un conteneur sans Feature Store.
Ce n'est pas un problème d'algorithme. C'est un problème de pipeline. L'analytique prédictive en enterprise meurt sur un hybride : Jupyter et Dataiku d'un côté, Spark CLI, Airflow et kubectl de l'autre. L'équipe clique, colle, exporte. Le modèle vieillit à la vitesse du backlog « to deploy ».
Ce que la plupart des briefs « il nous faut un Data Scientist » oublient : quand louer une personne (data science staff augmentation, body leasing) et quand le pipeline a besoin d'un squad DE + DS + MLOps. Les tarifs horaires sont dans un autre article : tarifs body leasing IT en Pologne 2026. Ici on compte pourquoi l'AUC tout seul n'arrive jamais en production.
Une phrase absente du slide commercial
Un Data Scientist sans pipeline de données est un chercheur avec un plafond de 8 heures sur Jira. Un pipeline sans Data Scientist est de l'ETL qui ne prédit rien. La staff augmentation d'un rôle marche quand l'autre est déjà dans votre équipe. Sinon vous avez acheté un timesheet, pas une prédiction.
1. Anatomie : un notebook n'est pas un produit
Une journée type d'une équipe d'analytique prédictive dans une banque, un telco ou un retailer ne ressemble pas à un tutoriel scikit-learn. Elle ressemble à un basculement de modalités :
- GUI : contrôles qualité dans un outil BI, export manuel de l'entrepôt, clic sur retrain dans Dataiku / SageMaker Studio, suivi du drift sur un dashboard.
- CLI / API : Spark-submit, dbt run, airflow dags trigger, kubectl rollout, MLflow log, un batch BigQuery.
Chaque bascule est l'endroit où meurt la reproductibilité. Une feature calculée dans un notebook n'est pas la feature calculée dans le service. C'est le training-serving skew : le modèle apprend une définition que la production ne répétera pas. Sculley et al. l'ont nommé en 2015 pipeline jungles et glue code — dette technique ML qui croît plus vite que le modèle lui-même.
Trois signes que vous avez une jungle, pas une plateforme :
- CSV comme interface. La source de vérité, c'est l'export d'hier. Personne ne peut dire de quelle table ni avec quel filtre.
- La feature est calculée deux fois. Pandas sur un laptop, SQL dans Airflow. Un écart de 0.3 pp sur le fill-rate apparaît un trimestre plus tard, quand le drift est déjà dans la décision de crédit.
- Le déploiement comme ticket vers DevOps. Le Data Scientist s'arrête à « model.pkl ». Quelqu'un d'autre packe l'image, une troisième personne pose le probe. De l'idée à l'inférence : des semaines, pas des jours.
C'est pourquoi un brief « embaucher un Data Scientist » sans contexte de pipeline est la façon la plus chère d'obtenir un notebook de plus. Les compétences qui livrent vraiment l'analytique prédictive tiennent sur trois landings : Data Science et BI, Data Engineering, MLOps.
2. Ce que disent les papers, pas les decks MLOps
Vous n'avez pas besoin d'une énième définition de « MLOps maturity ». Vous avez besoin des frontières auxquelles un modèle ne sort jamais du labo.
- La dette ML est dans le glue, pas dans la loss. Sculley et al., Hidden Technical Debt in Machine Learning Systems (NIPS 2015) : dans les systèmes ML, le code d'apprentissage n'est en général qu'une petite fraction. Le reste est configuration, collecte, vérification, serving, monitoring. « Changer une feature » fait détoner une cascade, parce que les dépendances sont cachées. Une pipeline jungle pousse quand vous ajoutez des chemins au lieu de supprimer les anciens.
- Le travail sur ordinateur est hybride. Shi, Wang, Fang, Liang et al., CUA-Universe (arXiv:2609.05374, septembre 2026) : le travail réel mélange l'inspection de l'état visuel et un CLI précis sur un état d'application partagé. Les agents GUI-only produisent des trajectoires inefficaces ; les agents CLI-only deviennent aveugles au layout. L'entraînement sur hybride GUI+CLI a fait progresser un modèle 9B : CUA-Verse +39.3 pts, −37% steps, −60% tokens ; OSWorld SR +16.8 pts, −57% steps, −44% tokens. Ce n'est pas un paper sur le scoring crédit. C'est une mesure de ce que coûte la jonglerie fenêtre-terminal. Une équipe Data Science qui clique dans Studio et colle des commandes dans Confluence paie la même taxe.
- La livraison est une métrique d'équipe, pas une métrique de notebook. DORA 2024 : elite vs low, c'est un ordre de grandeur sur la fréquence de deploy et le lead time des changements. Ces chiffres décrivent des équipes avec un Definition of Done commun. Cinq timesheets séparés (DS du vendor A, DE de B, « quelqu'un pour Kubernetes » de C) ne composeront pas un lead time. Ils composeront trois SLA de remplacement et un statut « in progress ». On a démonté ce mode d'échec dans team leasing vs staff augmentation 2026.
La conclusion d'architecture
Standardiser le pipeline, ce n'est pas « acheter SageMaker ». C'est tuer le basculement GUI↔CLI partout où une API et de l'IaC peuvent le remplacer. Feature Store, un DAG, une image de serving, un test de schéma sur la PR. Le reste, c'est de la cosmétique vendor. Si votre Data Scientist ne peut pas reproduire une feature depuis un commit, vous n'avez pas d'analytique prédictive. Vous avez une démo.
3. Cas de production : un scoring en retard d'un sprint
De la pratique d'ingénierie : de 3 semaines à 3 jours
Une institution financière, un portefeuille de l'ordre de millions de clients. Scoring des demandes et détection de fraude. Sources : Oracle / PostgreSQL, un data lake (S3 + Hive), des logs dans Elasticsearch. L'équipe d'analytique prédictive travaillait ainsi :
- extraction : SQL écrit à la main, export CSV,
- features : Pandas sur un laptop, jointures Excel « au cas où »,
- training : GUI Dataiku, export manuel de l'artefact,
- release : un ticket vers DevOps, Docker « comme ça vient », API Gateway, Kubernetes sans test de schéma.
Problème : de l'idée à l'inférence 3–4 semaines. Les modèles étaient périmés le jour du go-live. p99 des prédictions critiques > 500 ms. Le coût de run croissait avec chaque nouveau pickle.
Changement : pipelines Spark orchestrés par Airflow vers un Feature Store (Hopsworks). Chaque étape (data, train, validate, serve) dans une image. GitOps sur le cluster. Monitoring du feature-drift et de la qualité des données (Prometheus / Grafana). Le DS arrête d'exporter du CSV. Le DE arrête de deviner quelle version de feature emporter dans le batch.
Mesuré ensuite : time-to-production 3 jours au lieu de 3 semaines. Erreurs de pipeline et de deploy −85%. p99 d'inférence < 80 ms. Coût d'infra MLOps −40% — pas grâce à un cloud moins cher, grâce à l'absence de pompiers manuels et de retrains abandonnés.
Ce résultat ne vient pas d'un « meilleur XGBoost ». Il vient du fait que le GUI est resté pour l'inspection, et le CLI/API pour le chemin qui doit se répéter à 03:00. Même leçon que CUA-Universe mesure sur les agents : l'hybride marche quand les deux modalités partagent l'état — pas quand un humain est le bus entre les fenêtres.
4. Tableau de décision : quel pipeline, quelle composition
| Approche | Complexité | Latence p95/p99 | Coût d'infra | Charge d'équipe | Quand l'utiliser |
|---|---|---|---|---|---|
| Notebook + ETL ad-hoc | Faible au départ, croît exponentiellement | Secondes–minutes, souvent manuel | Faible au départ | Élevée (glue, debugging) | PoC, un analyste, pas de SLA |
| MLOps OSS (Airflow, MLflow, Kubeflow, Feast/Hopsworks) | Élevée (plateforme) | ms–s, répétable | Moyen | Moyenne–élevée (DE + MLOps) | Enterprise qui a besoin de contrôle et d'on-prem / hybride |
| Service managé (SageMaker, Vertex, Azure ML) | Moyenne (intégration cloud) | ms–s | Moyen–élevé (compteurs de service) | Plus basse opérationnellement | Quand vous vivez déjà dans un seul IAM cloud et que vous ne traînez pas un GUI legacy |
| Hybride + composition T&M | Très élevée | Bornée par le connecteur le plus faible | Élevé | Élevée jusqu'à ce que GUI et API soient cousus | Banque, pharma, données qui ne sortent pas. En général un squad, pas un seul rôle. |
Python CRUD et Python pour les pipelines de données sont deux métiers. Fourchettes backend 145–200 / 200–280 PLN/h (contractant / client). Les data pipelines sont dans le haut de cette bande. AI/LLM en production : 180–250 / 240–350 PLN/h. Marge 10–25%. Une carte, pas un tarif — détail dans l'article tarifs 2026.
5. Anti-patterns que vous ne trouverez pas dans un tutoriel Kubeflow
- Un brief « Python Developer » pour du scoring. Vous aurez du Django. Vous n'aurez pas de Feature Store. Le marché a clivé : le backend classique a de l'offre, les ingénieurs pipeline et LLM n'en ont pas. Une annonce mal étiquetée se remplit de CV en 48 h et zéro compétence drift.
- Pas de tests de données. La CI lint le modèle, pas le schéma d'entrée. Un changement silencieux de null dans la source passe. La prédiction est « verte ». La décision métier ne l'est pas.
- Une feature sans owner. Le DS la calcule dans un notebook, le DE dans dbt, le BI dans Power Query. Trois définitions de churn. Un dashboard, trois guerres au stand-up.
- Une fausse équipe analytics. DS du vendor A, DE de B, MLOps « quand on aura le temps » du DevOps interne. Trois onboardings, zéro DAG commun. Ce n'est pas de la staff augmentation. C'est la taxe d'intégration décrite sous le leasing d'équipes IT.
6. Playbook : qui louer, et dans quel ordre
Ne commencez pas par le modèle. Commencez par la modalité qui bloque le SLA.
- Un trou dans un pipeline existant. Vous avez Airflow, un Feature Store et quelqu'un qui review les PR. Il manque un senior sur le modèle ou sur Spark. C'est de la data science staff augmentation classique, ou un Data Engineer : une personne, votre stand-up, votre DoD. Premiers profils en jours, pas en trimestre — nous sourçons à la demande, nous ne vendons pas un banc nominatif pour demain matin.
- Le notebook est le produit. Pas de DAG, pas de test de schéma, pas de serving. Une personne ne cousera pas ça. Composition 3–5 : DE (sources, dbt/Spark), DS (modèle, validation), MLOps (image, monitoring du drift). Plus proche du team leasing que d'un « on ajoutera encore un analyste ».
- Les données ne sortent pas du VPC. Contractant dans votre IAM, votre cloud, NDA et clauses de traitement. Un Colab avec un dump de production est une fuite, pas une accélération. Calcul offline des features en batch, serving online depuis le même code de feature.
- Ramp-up. Une personne dans une équipe existante : premiers CV en 24–48 h, démarrage après vos entretiens et le contrat. Un squad à zéro : des semaines, pas un sprint, parce que vous cousez les accès, les données et le DoD. « Trois seniors Python dès lundi » est un pack de CV ou un banc que nous n'avons pas — et que nous ne prétendrons pas avoir.
Commoditech fait du T&M et du recrutement permanent depuis Varsovie depuis 2012. 80+ spécialistes dans le réseau, pas un idle bench. Un brief T&M ou success-fee se dépose depuis un IDE via MCP pour agents IA, pas seulement via un formulaire. Un humain tarife un stack ; les fourchettes sont dans l'article tarifs, pas dans le JSON de l'agent.
FAQ
En quoi la data science staff augmentation diffère-t-elle de l'embauche d'un Data Scientist ?
Un CDI est un FTE dans vos RH. La durée de vie moyenne d'une offre IT sur JobHunt en septembre 2026 est de 50 jours — avant même les entretiens. La data science staff augmentation, c'est du T&M : la personne dans votre équipe, votre Git, votre SLA, avec une clause de remplacement de rôle. Vous n'achetez pas « un modèle en abonnement ». Vous achetez une heure de compétence. Le TCO vs masse salariale (recrutement, bench, indemnités, hardware) est dans les tarifs 2026.
Quand louer une personne vs un squad Data Science ?
Une personne quand le pipeline existe déjà et qu'il manque un trou : senior DS, Spark, MLOps. Un squad de 3–5 personnes quand le notebook est le seul artefact. Un Data Scientist seul livrera l'AUC. Il ne livrera pas le p99, un test de schéma ni un retrain à 03:00. Si personne de votre côté ne peut review la PR du contractant, n'achetez pas de staff augmentation. Achetez un lead plus un rôle, ou un squad.
Combien coûte la data science staff augmentation en Pologne en 2026 ?
Python pour les pipelines de données n'est pas du CRUD : en pratique le client paie le haut de la bande senior 200–280 PLN/h. Quand le modèle part en production avec LLM / RAG, plus proche de 240–350 PLN/h. Marge vendor 10–25% — si quelqu'un promet 8% avec un remplacement en 5 jours, c'est assis sur une autre ligne. Une carte du marché, pas un devis. Un humain tarife le brief.
Un contractant Data Science peut-il travailler sur des données sous NDA et RGPD ?
Oui : votre environnement, votre IAM, votre cloud ou on-prem, un contrat avec NDA, clauses de traitement et IP côté client. Un notebook sur un laptop privé avec un dump de production est une fuite. Features offline en batch, serving online depuis le même code. L'audit d'accès est le vôtre. Le contractant n'emporte pas le dataset « pour calculer plus vite ».
Sources
- Sculley, D. et al. (2015). Hidden Technical Debt in Machine Learning Systems. NIPS 2015. papers.nips.cc
- Shi, H., Wang, W., Fang, W., Liang, Y. et al. (2026). CUA-Universe: A Scalable and Dynamic Environment for Hybrid GUI+CLI Agents. arXiv:2609.05374. arxiv.org/abs/2609.05374
- DORA / Google Cloud (2024). Accelerate State of DevOps Report.
- JobHunt.pl (1er septembre 2026). 21,211 rôles IT actifs, durée de vie moyenne d'une offre 50 jours — contexte time-to-hire vs T&M.