Data science : passer d’une question métier à un modèle utile, puis du prototype à la production

Un prototype peut prédire correctement 92 % des cas et ne jamais être utilisé. Avec 78 % de bonnes réponses, une approche plus simple peut réduire les ruptures de stock si ses erreurs sont comprises, ses recommandations arrivent à temps et les responsables savent quand ne pas la suivre.

Le meilleur score n’est pas toujours le meilleur produit.

La data science sert à répondre à des questions de plusieurs natures : que s’est-il passé, pourquoi, que va-t-il probablement se passer, que se passerait-il sous une autre action, et quelle décision respecte le mieux les contraintes ? Confondre ces questions conduit à utiliser une prédiction là où une expérience ou une règle aurait été plus utile.

1. Chiffres clés : le modèle n’est qu’une petite partie du système

Une étude de Google Research fondée sur des entretiens avec 53 praticiens de l’IA dans plusieurs pays a observé des « cascades de données » chez 92 % des participants. Ces problèmes, déclenchés par des pratiques de données insuffisantes, produisaient des effets aval cumulatifs, souvent tardifs et difficiles à voir. Le chiffre ne mesure pas toutes les entreprises, mais il documente la fréquence du phénomène dans des projets à fort enjeu.

Google décrit par ailleurs son système de validation de données utilisé par des centaines d’équipes produit sur plusieurs pétaoctets par jour. Les auteurs insistent sur un comportement trompeur : une chaîne de machine learning peut continuer à tourner avec un schéma inattendu, une distribution anormale ou un écart entre données d’entraînement et de production.

Le référentiel « ML Test Score » du même groupe contient 28 tests et besoins de monitoring, couvrant données, caractéristiques, modèle et infrastructure. Comparé au seul score de précision, ce nombre donne une image plus réaliste du travail de production.

Les compétitions de prévision apportent une autre leçon. M4 a comparé 61 méthodes sur 100 000 séries temporelles. Parmi les 17 approches les plus précises, 12 combinaient plusieurs méthodes. Le gagnant hybride, mêlant lissage exponentiel et réseau neuronal, était proche de 10 % plus précis que le benchmark de combinaison retenu. Les six méthodes de machine learning « pures » ont moins bien performé que ce benchmark dans ce cadre. La sophistication ne domine pas automatiquement une base statistique solide.

Enfin, une probabilité n’est pas toujours une probabilité fiable. La documentation de scikit-learn rappelle qu’un classifieur bien calibré devrait vérifier qu’environ 80 % des cas notés près de 0,8 appartiennent réellement à la classe positive. Le classement peut être correct tout en restant trop confiant ; cette différence modifie les seuils et les coûts.

2. Le contrat de décision

Tout projet commence par un contrat court entre métier, data et opérations. Il ne décrit pas l’algorithme. Il décrit la décision.

Aucune valeur n’apparaît si la décision ne change pas. Prédire qu’une commande arrivera en retard après son expédition définitive produit une information intéressante mais peu actionnable.

Le contrat fixe aussi la capacité. Si l’équipe ne peut traiter que 500 dossiers, optimiser la précision sur l’ensemble est moins utile que classer correctement les 500 premiers.

3. Six familles de questions, six méthodes

3.1. Décrire

La statistique descriptive mesure volumes, distributions, cohortes et évolutions. Elle répond à « que s’est-il passé ? ». Beaucoup de décisions s’améliorent déjà avec une segmentation correcte et des intervalles, sans modèle prédictif.

3.2. Diagnostiquer

Le diagnostic cherche les facteurs associés à un mouvement. Il utilise décomposition, analyse de parcours, régression et connaissance métier. Une association ne prouve pas la cause. Elle réduit l’espace d’enquête.

3.3. Prédire

La prédiction estime un résultat inconnu : demande, churn, défaut, délai. Elle exige un horizon, une vérité observable et une évaluation hors échantillon. Sa qualité dépend du contexte de décision.

3.4. Estimer un effet causal

La causalité demande ce qui aurait eu lieu sans l’action. Un test randomisé est souvent la référence ; des méthodes quasi expérimentales peuvent aider lorsque la randomisation est impossible. Un modèle de churn prédit qui partira. Un modèle d’uplift cherche qui restera grâce à une intervention. Ce ne sont pas les mêmes clients.

3.5. Optimiser

L’optimisation choisit une action sous contraintes : stock, capacité, délai, risque, équité. Elle peut utiliser les prévisions comme entrées. Une meilleure prévision n’améliore pas l’objectif si l’optimiseur ou le processus ne peut pas agir.

3.6. Détecter l’anormal

La détection d’anomalies signale les écarts : fraude, panne, donnée corrompue. Elle travaille souvent avec peu de labels. Le taux d’alerte et le coût d’enquête deviennent alors des métriques centrales.

Le cadrage sélectionne la famille avant la technique. Demander « un modèle IA » court-circuite cette décision.

4. La baseline : le concurrent que le modèle doit battre

Une baseline peut être la moyenne, la dernière valeur, une règle experte ou le processus humain. Elle doit être mesurée honnêtement sur la même période et la même population.

Pour une prévision hebdomadaire, « même semaine l’an dernier corrigée de la tendance » peut être redoutable. Pour le churn, « contacter les comptes sans connexion depuis trente jours » peut capturer une grande partie de la valeur. Si un modèle complexe gagne seulement 0,5 point mais exige une infrastructure lourde, la règle reste préférable.

On mesure aussi le coût actuel. Combien de décisions, de temps, d’erreurs et d’opportunités ? Cette base permet de calculer le gain net, pas seulement la métrique statistique.

La baseline est conservée en production comme fallback. Un système qui ne peut revenir à une règle simple lors d’un incident est fragile.

5. Données : construire la vérité terrain

La cible représente le résultat à apprendre. Sa définition mérite autant d’attention que le modèle.

Un « client perdu » peut signifier résiliation, absence d’achat pendant 90 jours ou non-renouvellement contractuel. Ces définitions créent des populations différentes. Le label doit être observable après l’horizon et stable dans le temps.

La collecte respecte quatre principes.

Représentativité. Le jeu couvre les saisons, canaux, régions, produits et cas rares concernés. Un échantillon issu des clients les plus actifs surestime souvent la qualité.

Temporalité. Une variable utilisée à l’entraînement doit être disponible au moment réel de la décision. Incorporer le statut final d’un dossier dans une caractéristique crée une fuite de cible.

Provenance. Chaque variable conserve source, formule, date et responsable. Les corrections sont versionnées.

Droits. Finalité, minimisation, conservation, accès et information sont cadrés, surtout pour les données personnelles.

Un audit manuel de quelques centaines de lignes révèle souvent des problèmes invisibles dans le code : statut métier détourné, valeur par défaut, événements manquants ou pratiques différentes selon les équipes.

6. Séparer entraînement, validation et test comme le réel

Une division aléatoire n’est pas toujours adaptée. Pour prévoir le futur, on entraîne sur le passé et teste sur une période ultérieure. Pour généraliser à de nouveaux clients, on peut séparer par compte. Pour des images d’un même objet, les prises de vue proches restent dans le même groupe.

Les doublons et quasi-doublons sont retirés entre ensembles. Une photo recadrée présente des deux côtés donne une illusion de généralisation.

Le jeu de validation sert à choisir les paramètres. Le test final reste masqué jusqu’à la sélection. Le consulter à chaque essai le transforme progressivement en jeu d’entraînement.

Après le lancement, un jeu d’évaluation temporel est renouvelé. Le monde change ; un test figé peut continuer à rassurer alors que les cas réels ont dérivé.

7. Choisir la métrique en fonction du coût des erreurs

L’accuracy — part totale de bonnes réponses — est trompeuse lorsque les classes sont déséquilibrées. Si 1 % des transactions sont frauduleuses, prédire « non fraude » partout donne 99 % d’accuracy et aucune valeur.

Le rappel mesure la part des cas positifs détectés. La précision mesure la part des alertes réellement positives. Augmenter l’un peut réduire l’autre. Le seuil traduit le compromis opérationnel.

Pour un classement, on examine la précision dans les premiers dossiers, le lift et le gain cumulé. Pour une probabilité, on mesure discrimination et calibration. Pour une prévision, on compare erreur absolue, erreur relative et intervalles selon les volumes.

Une matrice de coûts est encore plus concrète : euros, minutes, risques ou capacité associés aux quatre résultats. L’évaluation utilise cette unité.

Les métriques sont segmentées. La moyenne peut masquer une faible performance sur une région, un nouveau produit ou une population vulnérable.

8. Calibration et seuils : transformer un score en décision

Un score de 0,8 n’est utile que si sa signification est connue. La courbe de calibration compare les probabilités annoncées aux fréquences observées. Le score de Brier et la log loss apportent des mesures, mais scikit-learn souligne qu’ils combinent plusieurs propriétés ; la courbe reste nécessaire.

Le seuil n’est pas choisi à 0,5 par défaut. Il dépend de la capacité et des coûts. Une équipe pouvant examiner 200 dossiers prend les 200 risques les plus élevés, à condition que le classement reste stable et que la valeur attendue soit positive.

On peut définir une zone d’abstention. Au-dessus d’un seuil, action ; en dessous d’un autre, absence d’action ; entre les deux, revue humaine. Cette structure est plus honnête qu’une décision forcée sur chaque cas.

Les seuils sont versionnés séparément du modèle. Une capacité opérationnelle ou un coût peut changer sans réentraînement.

9. Explicabilité : fournir la preuve utile

Une importance globale montre les facteurs qui influencent généralement le modèle. Une explication locale montre ce qui a contribué à un score précis. Ni l’une ni l’autre ne prouve la causalité.

L’utilisateur a besoin d’éléments actionnables : « délai fournisseur supérieur à la normale » ou « trois échecs de paiement récents », accompagnés des données sources. Une liste de poids mathématiques sans contexte ne suffit pas.

On teste la stabilité. Si une petite variation sans sens métier change radicalement l’explication, l’interface ne doit pas la présenter comme une justification certaine.

Dans les décisions importantes, l’explication inclut aussi les limites, le recours et la possibilité de corriger une donnée. La transparence concerne le processus entier.

10. Du notebook au service

Le notebook explore. La production répète. Le passage exige plusieurs transformations.

Le code de préparation devient une pipeline testée. Les dépendances sont figées. Les données et paramètres portent une version. L’entraînement est reproductible à partir d’un commit et d’un snapshot. Le modèle est enregistré avec ses métriques et approbations.

La logique de caractéristiques doit être identique entre entraînement et service. Un calcul réalisé différemment dans une API crée un training-serving skew. Les transformations communes, tests sur exemples et contrôles de distribution réduisent ce risque.

Le mode d’inférence suit la décision. Le batch quotidien convient aux listes d’actions. Une API temps réel convient à une réponse immédiate. Le streaming ne se justifie que si le coût du retard dépasse son exploitation.

Le déploiement commence en shadow mode : le modèle prédit sans influencer les décisions. On compare ses résultats aux pratiques actuelles et on observe les contraintes. Puis une fraction du trafic ou une équipe pilote l’utilise.

11. Observabilité : données, modèle, système, décision

Quatre couches sont surveillées.

Données. Schéma, valeurs manquantes, catégories inconnues, fraîcheur, distribution et lignée.

Modèle. score, calibration, taux d’abstention, performance lorsque le label arrive et stabilité par segment.

Système. disponibilité, latence, erreurs, version, coût et files d’attente.

Décision. adoption, contournements, actions prises, résultat métier et effets indésirables.

Une dérive de données ne signifie pas automatiquement une baisse de performance. Elle déclenche une analyse. Inversement, une performance peut baisser sans dérive simple si la relation entre variables et résultat change.

Le label arrive parfois plusieurs mois après. Des indicateurs précoces surveillent alors couverture, score, acceptation et variables, sans prétendre remplacer la vérité finale.

Les alertes possèdent un propriétaire, un seuil et une action. Si personne ne sait quoi faire, le monitoring produit seulement de l’anxiété.

12. Cas pratique : prioriser les relances commerciales

Une entreprise B2B reçoit 12 000 leads mensuels. L’équipe commerciale peut en contacter 3 000 dans les 48 heures. Le taux de signature global est de 4 %.

Le prototype vise à prédire la signature. Une baseline simple classe par taille d’entreprise et complétude du formulaire. Elle obtient 7 % de signatures dans les 3 000 premiers.

Le premier modèle atteint 10 %. L’analyse révèle cependant une fuite : la variable « rendez-vous planifié », enregistrée après la relance, est présente dans l’entraînement. Retirée, la performance tombe à 8,5 %. C’est toujours mieux que la baseline, mais le gain réel est moitié moindre que celui annoncé.

La calibration montre aussi que les scores sont trop confiants. L’équipe cesse des afficher en pourcentage et utilise des bandes de priorité. Un groupe témoin conserve l’ancienne règle. Après huit semaines, la stratégie augmente les signatures nettes de 12 % dans la capacité traitée, sans dégrader le délai pour les petits comptes.

Le modèle n’est pas déployé sur tous les leads. Les dossiers issus de partenaires restent hors périmètre, car leur comportement diffère et l’échantillon est trop faible. Cette limite est une décision de qualité.

13. Industrialiser avec une porte de passage

Avant production, le projet répond à une revue go/no-go.

1. La décision et l’action sont-elles définies ?
2. La baseline et le coût actuel sont-ils mesurés ?
3. Le label est-il disponible et daté ?
4. Les variables existent-elles au moment de décider ?
5. Le test reproduit-il la généralisation attendue ?
6. Les performances sont-elles segmentées et calibrées ?
7. Les erreurs critiques et le recours sont-ils définis ?
8. La pipeline est-elle reproductible et sécurisée ?
9. Le monitoring et le fallback ont-ils un propriétaire ?
10. La valeur sera-t-elle mesurée par un pilote crédible ?

Un « non » ne signifie pas abandon. Il indique la prochaine expérience. La porte protège la production contre la pression de montrer un résultat.

14. Coût total et valeur

Le coût comprend extraction, annotation, expérimentation, calcul, plateforme, déploiement, monitoring, revue humaine et maintenance. Le modèle initial peut représenter une fraction faible.

La valeur attendue se calcule à partir des décisions : nombre d’actions × changement de résultat × valeur unitaire, moins le coût des actions et erreurs. On ajoute l’incertitude.

Un pilote cherche à estimer ce changement. Une amélioration hors ligne ne suffit pas si les utilisateurs ignorent le score ou si les clients réagissent différemment.

Le coût de maintien est budgété. Nouvelles catégories, évolution du processus, mise à jour du fournisseur et changement réglementaire peuvent exiger une nouvelle version. Sans propriétaire durable, le modèle devient un actif orphelin.

15. Organisation : une équipe autour du produit de décision

Le data scientist formule, explore, modélise et évalue. Le data engineer fiabilise les données. Le ML engineer industrialise. Le métier définit l’action et les coûts. Le product manager organise l’usage. Le juridique et la sécurité cadrent les risques.

Dans une petite équipe, les personnes cumulent ces fonctions. La revue croisée reste nécessaire : l’auteur du modèle ne devrait pas être le seul à valider son test.

Les travaux de données sont planifiés et reconnus. L’étude sur les cascades montre les conséquences d’une culture où « tout le monde veut travailler sur le modèle, pas sur les données ». Corriger une définition ou un processus source peut produire plus de valeur qu’un nouvel algorithme.

16. Feuille de route en quatorze semaines

Semaines 1 et 2 : contrat. Choisir une décision, mesurer la baseline, écrire les coûts et vérifier la capacité d’action.

Semaines 3 et 4 : données. Définir le label, auditer les sources, rechercher les fuites et construire la séparation temporelle.

Semaines 5 et 6 : modèles simples. Tester règle, modèle linéaire et arbre avant les approches plus complexes. Comparer les segments.

Semaines 7 et 8 : décision. Calibrer, choisir les seuils, simuler coûts et capacité, concevoir les explications.

Semaines 9 et 10 : production. Construire pipeline, registre, tests, API ou batch, logs et fallback.

Semaines 11 et 12 : shadow. Observer les scores réels, la latence, les distributions et les réactions, sans agir automatiquement.

Semaines 13 et 14 : pilote. Comparer un groupe de décision, mesurer résultat et effets secondaires, puis statuer : déployer, adapter ou arrêter.

La discipline réside dans les portes. Aller vite ne signifie pas sauter la preuve qui distingue une démo d’un produit.

17. Questions fréquentes

17.1. Combien de données faut-il ?

Cela dépend du signal, du nombre de variables, de la rareté et de la stabilité. Une courbe d’apprentissage montre si davantage d’exemples améliore encore le test. La qualité et la représentativité comptent autant que le volume.

17.2. Faut-il toujours du machine learning ?

Non. Une règle, une analyse descriptive, une expérience ou une optimisation déterministe peut mieux répondre. Le ML est utile lorsqu’un motif généralisable existe et qu’une action exploitable suit.

17.3. Quelle différence avec l’IA prédictive ?

L’IA prédictive désigne les systèmes qui anticipent un résultat et l’intègrent à une décision. La data science couvre plus largement description, diagnostic, causalité, expérimentation, optimisation et cycle de vie méthodologique. Les deux se recouvrent, sans être synonymes.

17.4. Quand réentraîner ?

Lorsque la performance, les données ou le processus sortent des seuils, ou selon une fréquence justifiée. Réentraîner automatiquement chaque semaine peut amplifier une anomalie. Une validation précède la promotion.

17.5. Comment expliquer un modèle complexe ?

En montrant facteurs utiles, preuves sources, limites et recours, puis en testant la fidélité et la stabilité de l’explication. Une visualisation ne transforme pas une corrélation en cause.

18. Ce qu’une règle de data science peut démontrer sur le résultat avant un déploiement

La recette comporte une baseline métier, un jeu temporel jamais utilisé pour apprendre, des segments minoritaires et des cas limites. Elle compare performance moyenne, calibration, coût d’erreur, stabilité et délai de réponse. Une amélioration d’AUC ne suffit pas si le seuil opérationnel augmente les faux refus les plus coûteux.

Le test à blanc exécute la prédiction sans influencer la décision. Les équipes comparent recommandation et résultat, mesurent l’écart avec la règle actuelle et observent les données réellement disponibles au moment utile. Cette phase révèle les fuites temporelles qui n’apparaissent pas dans le notebook.

Avant l’activation, le responsable métier sait pourquoi le seuil a été choisi, l’exploitation sait revenir à la règle précédente, la sécurité connaît les flux, le support peut expliquer les erreurs et le registre indique version, population, métriques, limites, propriétaire et date de revue ; cette combinaison importe davantage qu’un score isolé, car elle montre que le modèle produit une décision contrôlable dans le processus réel, sous charge, avec données manquantes et possibilité de correction.

Après le lancement, une cohorte progressive limite l’exposition. Les premiers résultats ne déclenchent une extension que si valeur, équité, fiabilité et charge opérationnelle restent dans leurs garde-fous.

Le procès-verbal conserve également les scénarios rejetés, les variables abandonnées, les intervalles d’incertitude, les décisions humaines qui ont contredit la recommandation et les incidents survenus pendant la cohorte, afin qu’une future révision ne sélectionne pas uniquement les exemples favorables et puisse distinguer une amélioration durable d’un hasard de période, d’un changement de population ou d’une intervention exceptionnelle de l’équipe projet.

19. Ce que Logiks recommande

Définissez la décision et sa baseline avant d’ouvrir un notebook. Faites ressembler le test au futur réel, recherchez activement les fuites et mesurez la calibration. Puis déployez progressivement avec un fallback, des seuils versionnés et une expérience capable d’estimer la valeur. Un modèle doit mériter son exploitation.

20. Sources principales

• Google Research, Data Cascades in High-Stakes AI, entretiens avec 53 praticiens : https://research.google/pubs/everyone-wants-to-do-the-model-work-not-the-data-work-data-cascades-in-high-stakes-ai/
• Google Research, Data Validation for Machine Learning : https://research.google/pubs/data-validation-for-machine-learning/
• Google Research, The ML Test Score, 28 tests et besoins de monitoring : https://research.google/pubs/the-ml-test-score-a-rubric-for-ml-production-readiness-and-technical-debt-reduction/
• Makridakis, Spiliotis et Assimakopoulos, The M4 Competition: 100,000 time series and 61 forecasting methods : https://www.sciencedirect.com/science/article/pii/S0169207019301128
• Makridakis et al., résultats et enseignements de M4 : https://www.sciencedirect.com/science/article/abs/pii/S0169207018300785
• scikit-learn, documentation sur la calibration des probabilités : https://scikit-learn.org/stable/modules/calibration.html
• Google Research, Hidden Technical Debt in Machine Learning Systems : https://research.google/pubs/hidden-technical-debt-in-machine-learning-systems/