Faire du ML en production, c’est 10% de data science et 90% d’infrastructure. Après avoir déployé plusieurs projets ML en prod, voici les vraies métriques qui comptent : combien ça coûte, quelles équipes tu as besoin, et comment justifier le ROI auprès du board.

Le budget ML qui tue

Coûts infrastructure réels

Sur un projet de recommendation engine (100M de users, 50K RPS), voici les vrais coûts mensuels :

Infrastructure Serving (AWS) :

  • Model serving : 12x c5.2xlarge → $3,600/mois
  • Feature store (Redis Cluster) : $2,400/mois
  • Data pipeline (Airflow + workers) : $1,800/mois
  • Monitoring stack (Prometheus, Grafana) : $600/mois
  • Total serving : $8,400/mois

Training Infrastructure :

  • GPU training (p3.8xlarge, 40h/mois) : $4,200/mois
  • Data storage S3 (500TB) : $1,200/mois
  • Compute pour feature engineering : $2,100/mois
  • Total training : $7,500/mois

Équipes nécessaires (coûts annuels) :

  • 2x Data Scientists seniors (140k€ chacun) : 280k€
  • 1x ML Engineer (120k€) : 120k€
  • 0.5x Platform Engineer (130k€) : 65k€
  • 0.3x DevOps spécialisé (140k€) : 42k€
  • Total équipes : 507k€/an

ROI réel : +18% de click-through rate → +2.3M€ de revenus annuels. Payback period de 8 mois. Pas mal, mais c’est jamais linéaire.

Architecture decisions : managed vs self-hosted

Option 1 : Full managed (AWS SageMaker)

  • Coût : 40% plus cher mais 0 ops
  • Time-to-market : 2-3 mois
  • Équipe : 1 ML Engineer suffit
  • Limitation : vendor lock-in, moins de contrôle
  • Recommandé pour : MVP, équipes < 5 personnes

Option 2 : Self-hosted sur K8s

  • Coût infrastructure : -40% vs managed
  • Coût équipes : +200k€/an (DevOps + Platform)
  • Time-to-market : 6-9 mois
  • Flexibilité totale mais complexité opérationnelle
  • Recommandé pour : scale > 100M requests/jour

Option 3 : Hybride (notre choix final)

  • Training sur SageMaker
  • Serving self-hosted sur EKS
  • Feature store managed (Redis Cloud)
  • Monitoring custom (Prometheus)
  • Sweet spot : contrôle du serving + simplicité du training

Décision technique clé : après 6 mois en full managed, on a migré vers hybride. Raison : coûts de serving managed explosent à partir de 1M predictions/jour.

Data pipeline : les vrais problèmes de terrain

Qu’est-ce qui casse vraiment en prod ?

Top 3 des pannes ML qu’on a vécues :

  1. Data drift silencieux (60% des incidents)

    • Symptôme : accuracy passe de 89% à 73% en 2 semaines
    • Cause : changement upstream dans un micro-service
    • Impact business : -12% de conversion pendant 8 jours
    • Coût : 340k€ de manque à gagner
    • Leçon : alertes sur les distributions, pas juste sur les valeurs nulles

  2. Latence qui explose (25% des incidents)

    • Target : p95 < 50ms, réalité : p95 = 800ms
    • Cause : feature store Redis qui swap
    • Impact : timeout frontend → fallback sur recommendations simples
    • Fix : cache L1 en mémoire + monitoring granulaire

  3. Biais non détecté (15% des incidents)

    • Modèle performant sur métriques globales
    • Mais accuracy -15% sur segment “nouveaux users”
    • Découvert 3 mois après par l’équipe business
    • Leçon : monitoring par segments, pas juste global

Métriques de data quality qui comptent vraiment :

  • Distribution drift detection : alertes si KS-test > 0.15
  • Schema validation : 100% de couverture sinon le pipeline s’arrête
  • Freshness : données de plus de 4h = alerte critique
  • Completeness par segment business (pas juste global)
  • Monitoring des seuils par percentile (p99, p95, p75)

Feature store : ROI vs complexité

Feature store custom vs managed :

Option 1 : Redis + custom code

  • Coût : 800€/mois (Redis Cloud)
  • Dev : 3 mois à 2 développeurs
  • Maintenance : 0.3 FTE permanent
  • Latence : p95 = 12ms
  • Avantage : contrôle total, coût prévisible

Option 2 : Feast (open source)

  • Coût infrastructure : 1,200€/mois
  • Setup : 6 semaines
  • Maintenance : 0.1 FTE
  • Latence : p95 = 18ms
  • Inconvénient : documentation parfois limitée

Option 3 : Tecton (managed)

  • Coût : 4,800€/mois (pour nos volumes)
  • Setup : 2 semaines
  • Maintenance : quasi zéro
  • Latence : p95 = 8ms
  • Le problème : tarification qui explose avec le volume

Notre choix final : Feast pour batch features, Redis pour real-time serving. Permet d’avoir le meilleur des deux mondes sans se ruiner.

Point-in-time correctness : la feature qui coûte cher mais qui évite les fuites temporelles. On a dû refactorer tout le pipeline pour l’intégrer, mais ça a éliminé 3% de sur-apprentissage qu’on avait pas détecté.

Model serving : performance et coûts

Latence et throughput réels

Benchmarks serving (1M predictions/jour) :

Setup 1 : FastAPI + scikit-learn

  • Latence p95 : 45ms
  • Throughput : 2,000 RPS
  • Coût compute : 1,200€/mois (4x c5.xlarge)
  • Setup simple, idéal pour MVP

Setup 2 : TensorFlow Serving + GPU

  • Latence p95 : 8ms
  • Throughput : 12,000 RPS
  • Coût : 2,800€/mois (2x p3.2xlarge)
  • Overkill pour des modèles simples, parfait pour deep learning

Setup 3 : Seldon Core + auto-scaling

  • Latence p95 : 35ms (+ overhead K8s)
  • Throughput : 8,000 RPS (scaling auto)
  • Coût variable : 800-3,200€ selon la charge
  • Complexité opérationnelle ++

Notre architecture finale :

  • Cache Redis L1 (TTL 5min) : hit rate 67%
  • FastAPI + gunicorn (6 workers par instance)
  • Load balancer AWS ALB
  • Auto-scaling sur CPU et custom metrics
  • Résultat : p95 = 18ms, coût optimisé à 1,400€/mois

Pièges à éviter :

  1. Over-engineering : on a commencé avec Seldon, retour FastAPI après 3 mois
  2. Cache mal dimensionné : Redis 2GB saturé → upgraded 8GB
  3. Monitoring insuffisant : on ratait les timeouts internes (< 50ms mais > SLA)
  4. Pas de circuit breaker : une API upstream lente a cassé tout le serving

A/B testing : ROI vs risque

Test A/B modèle recommendation (cas réel) :

Modèle A (production actuel) :

  • CTR : 3.2%
  • Conversion : 1.8%
  • Revenue/user : 12.4€
  • Latence p95 : 28ms

Modèle B (nouveau challenger) :

  • CTR : 3.7% (+15.6%)
  • Conversion : 1.6% (-11.1%)
  • Revenue/user : 13.1€ (+5.6%)
  • Latence p95 : 45ms (+60%)

Analyse business :

  • Revenue global : +5.6% = +280k€/mois
  • Mais SLA latence non respecté
  • Impact SEO potentiel (Core Web Vitals)

Décision finale : garder modèle A, améliorer l’infrastructure pour supporter modèle B

Outils A/B testing ML :

  • Custom (notre choix) : hash stable user_id, split traffic via load balancer
  • Seldon Core : canary deployments intégrés
  • AWS SageMaker : multi-variant endpoints (cher mais simple)

Pièges A/B testing ML :

  1. Biais temporel : nouveaux users comportement différent
  2. Sample bias : ne pas oublier les segments minoritaires
  3. Contamination : cache partagé entre modèles
  4. Métrique vanity : focus sur business metrics, pas juste accuracy

Monitoring ML : au-delà des métriques vanity

Stack monitoring production

Notre setup actuel :

  • Prometheus + Grafana : métriques système et business
  • DataDog : APM et traces distribuées
  • Custom dashboard : métriques ML spécifiques
  • PagerDuty : alerting intelligent (pas de spam à 3h du mat')

Coût monitoring : 1,200€/mois (DataDog APM + infra + logs)

Métriques ML qui comptent vraiment

1. Business Impact (priorité absolue)

  • Revenue impact : +/- en euros, pas en %
  • Conversion rate par segment
  • Time-to-value des nouvelles features
  • Customer satisfaction (NPS impact)

2. Model Performance (technical)

  • Accuracy par segment (pas juste globale)
  • Prediction confidence distribution
  • Model staleness (dernière ré-entraînement)
  • Feature importance drift

3. Operational Health

  • Prediction latency (p50, p95, p99)
  • Error rate par endpoint
  • Cache hit rate
  • Queue depth (pour batch processing)

Alertes qui marchent (après 18 mois d’itérations) :

Niveau 1 - Critical (PagerDuty) :

  • Serving completement down
  • Error rate > 1% pendant 5 minutes
  • Latence p95 > 200ms (SLA breach)
  • Revenue impact > -5% vs yesterday

Niveau 2 - Warning (Slack) :

  • Accuracy drop > 3% vs baseline
  • Data drift score > 0.15
  • Cache hit rate < 50%
  • Training pipeline fail

Niveau 3 - Info (Dashboard) :

  • Model performance trending
  • Resource utilization
  • Feature usage statistics

Le piège des faux positifs : on a commencé avec 47 alertes différentes. Après 6 mois : 8 alertes utiles, le reste était du bruit.

Lessons learned : ce qu’on aurait aimé savoir avant

Budget réaliste pour démarrer

MVP ML en production (0-100k users) :

  • Infrastructure : 2,500€/mois
  • Équipes : 1 ML Engineer + 0.5 DevOps
  • Outils : 800€/mois (monitoring + CI/CD)
  • Total : ~15k€/mois (avec salaires)

Scale-up (100k-1M users) :

  • Infrastructure : 8,000€/mois
  • Équipes : 2 ML Engineers + 1 Data Scientist + 1 Platform Engineer
  • Total : ~45k€/mois

Enterprise (1M+ users) :

  • Infrastructure : 25,000€/mois
  • Équipes : 4-6 personnes spécialisées
  • Total : ~80k€/mois

Recommandations techniques

Si tu commences aujourd’hui :

  1. Start small : FastAPI + scikit-learn + Redis. Pas de K8s avant d’avoir du trafic réel
  2. Monitoring first : investis dans l’observabilité dès le jour 1
  3. Managed services : utilise SageMaker/Vertex AI pour le training tant que c’est pas ton core business
  4. Data quality : 80% des problèmes viennent de là, pas du modèle
  5. Team first : un bon ML Engineer vaut mieux que 3 Data Scientists sans expérience prod

ROI réaliste

Sur 12 projets ML qu’on a accompagnés :

  • 4 ont eu un ROI positif (payback < 18 mois)
  • 3 sont neutres (break-even à 24 mois)
  • 5 ont été arrêtés (pas de product-market fit ou coûts trop élevés)

Success factors :

  • Metric business claire dès le début
  • Équipe mixte (tech + business)
  • Infrastructure simple et robuste
  • Monitoring granulaire

Le ML en production, c’est 10% de data science et 90% d’ingénierie. Si tu veux faire de la recherche, reste en lab. Si tu veux de l’impact business, investis dans l’infrastructure.