Data Science : pourquoi elle reste stratégique à l’ère de l’IA générative

À quoi sert encore la Data Science ?

La Data Science reste particulièrement pertinente lorsque l’objectif est de prédire, classer, recommander ou optimiser une décision.

Prévision

Prévoir la demande, les ventes, les stocks, la trésorerie ou la charge permet d’améliorer les décisions opérationnelles. Les modèles de séries temporelles, le machine learning et les approches hybrides peuvent être particulièrement adaptés lorsque l’entreprise dispose d’un historique structuré et d’une variable cible clairement définie.

Pricing

L’analyse de l’élasticité, la segmentation des clients et l’optimisation des prix peuvent permettre d’améliorer marge et conversion. Le sujet dépasse cependant la modélisation : il faut être capable de mesurer les effets d’une décision et, lorsque c’est pertinent, de distinguer corrélation et causalité.

Scoring

Risque, fraude, churn, propension à l’achat ou priorisation commerciale sont des cas d’usage classiques du machine learning. La performance du modèle ne doit toutefois pas être évaluée uniquement sur un indicateur statistique. Il faut mesurer l’impact sur la décision métier : réduction des pertes, augmentation du taux de conversion, diminution du churn, amélioration du temps de traitement, etc.

Recommandation

Recommander un produit, un contenu, une action commerciale ou une prochaine meilleure action constitue un autre domaine historique de la Data Science. Ici encore, la qualité d’un modèle se mesure à son effet dans le parcours utilisateur ou commercial, pas uniquement à son score offline.

Optimisation

Allocation de ressources, planification, tournées, production, stocks ou ordonnancement relèvent parfois davantage de l’optimisation mathématique que du machine learning. Dans certains cas, un problème bien formulé en programmation linéaire, programmation entière ou optimisation sous contraintes sera plus robuste et plus explicable qu’une approche fondée sur un modèle génératif.

Data Science ou IA générative ?

La question n’est pas de savoir quelle technologie est la plus moderne. Il faut d’abord comprendre la nature du problème à résoudre.

Problème	Approche souvent pertinente
Prévoir une demande	Séries temporelles / ML
Détecter une fraude	Classification / détection d’anomalies
Prédire le churn	Machine learning
Optimiser une allocation	Optimisation mathématique
Recommander un produit	Recommendation systems / ML
Extraire une information d’un document	LLM / NLP / Document AI
Résumer ou générer du contenu	LLM
Interroger un corpus documentaire	LLM + RAG
Automatiser un workflow complexe	LLM + outils + règles métier

Un modèle de forecasting peut ainsi être beaucoup plus approprié qu’un LLM pour une prévision numérique. À l’inverse, un LLM est particulièrement pertinent pour comprendre, transformer ou générer du langage et traiter des documents non structurés.

Le bon partenaire doit donc savoir orienter le problème vers la bonne famille de méthodes, et non chercher systématiquement à appliquer un LLM.

Guide GenAI →

Le vrai critère : la décision à améliorer

Une erreur fréquente consiste à commencer par la technologie :

« Quel modèle pouvons-nous utiliser ? »

Il vaut mieux commencer par la décision :

« Quelle décision voulons-nous améliorer, et comment mesurerons-nous sa valeur ? »

Cette formulation permet de remonter vers :

décision → KPI → données → méthode → modèle → intégration → monitoring.

Par exemple, un projet de prédiction de churn n’a de valeur que si l’entreprise sait ensuite quelle action déclencher, auprès de quel client, à quel moment et avec quel coût. Le modèle n’est donc qu’une brique du système de décision.

Les compétences à vérifier chez un partenaire

Une équipe Data Science sérieuse doit réunir plusieurs compétences complémentaires.

Statistiques et expérimentation

Tests statistiques, causal inference, design d’expériences, A/B testing et mesure d’impact. Ces compétences deviennent essentielles dès lors que l’entreprise cherche à démontrer qu’un modèle ou une action cause réellement une amélioration.

Machine learning

Modèles supervisés et non supervisés, classification, régression, clustering, détection d’anomalies et séries temporelles.

Feature engineering et qualité des données

Un modèle performant avec des données instables ou mal définies restera fragile. Il faut notamment comprendre :

• la disponibilité des données ;
• leur qualité ;
• leur fraîcheur ;
• les biais ;
• les données manquantes ;
• le risque de data leakage ;
• la stabilité des variables dans le temps.

Data Engineering

Pipelines, datasets, versioning, orchestration et gestion des dépendances. Le modèle doit pouvoir être alimenté de manière fiable en production.

MLOps

Déploiement, monitoring, gestion des versions, suivi des performances, détection de dérive et réentraînement. Le MLOps est ce qui permet de passer du notebook au système exploité.

Compréhension métier

Enfin, l’équipe doit comprendre le processus dans lequel le modèle va être utilisé. Une excellente modélisation qui ne change aucune décision métier n’est pas un succès Data Science.

Comment choisir son partenaire Data Science ?

Le marché français comprend plusieurs familles d’acteurs : pure players Data Science, cabinets de conseil augmentés par des équipes Data, grandes ESN et boutiques spécialisées.

Aucune catégorie n’est intrinsèquement meilleure qu’une autre. Les pure players peuvent apporter une forte expertise en modélisation et expérimentation. Les grands intégrateurs disposent généralement d’une capacité importante de delivery et d’industrialisation. Les boutiques spécialisées peuvent offrir une forte séniorité avec des équipes resserrées.

Le critère déterminant est ailleurs :

Le partenaire sait-il résoudre votre problème précis et faire fonctionner la solution dans votre organisation ?

Il faut donc vérifier les références sur des problématiques comparables, mais aussi la composition réelle de l’équipe qui interviendra. Demandez notamment :

• Qui sera réellement présent pendant le projet ?
• Qui construit le modèle ?
• Qui travaille avec les métiers ?
• Qui prend en charge le déploiement ?
• Qui assure le monitoring ?
• Qui reste après la mise en production ?
• Quelles compétences seront transférées à l’équipe interne ?

Le passage du modèle au produit

C’est souvent ici que les projets Data Science échouent. Un modèle peut être excellent en expérimentation et ne jamais produire de valeur en production.

Avant de lancer un projet, il faut donc clarifier :

• qui possède le pipeline de données ;
• où le modèle sera déployé ;
• qui possède le code et les artefacts ;
• qui surveille les performances ;
• quels seuils déclenchent une alerte ;
• qui gère la dérive du modèle ;
• qui décide d’un réentraînement ;
• qui traite les incidents ;
• qui est responsable du KPI métier ;
• qui reprend le dispositif à terme.

Cette dernière question est souvent oubliée. Un modèle qui fonctionne uniquement parce que le cabinet qui l’a construit reste présent n’est pas réellement industrialisé.

Le transfert de compétences est une partie du projet

Le transfert ne doit pas être une promesse vague en fin de mission. Il doit être conçu dès le début :

Build → Deploy → Operate → Transfer

À chaque étape, l’entreprise doit savoir quelles compétences elle récupère. Cela peut concerner :

• le code ;
• les pipelines ;
• la documentation ;
• les datasets ;
• les modèles ;
• les procédures de monitoring ;
• les compétences MLOps ;
• les règles de réentraînement ;
• la connaissance métier.

Le bon partenaire doit être capable de préciser ce que l’équipe interne saura faire seule à la fin de la mission.

Le coût du run compte autant que celui du build

Un modèle qui coûte 100 k€ à construire mais plusieurs centaines de milliers d’euros à exploiter n’est pas nécessairement une bonne solution.

Le business case doit donc intégrer le TCO complet :

données + infrastructure + licences + entraînement + inférence + monitoring + maintenance + évolution.

C’est particulièrement important lorsque l’entreprise compare une approche traditionnelle de machine learning avec une architecture fondée sur des modèles génératifs. La sophistication technique ne doit jamais masquer l’économie réelle du système.

Conclusion

La Data Science n’a pas disparu avec l’IA générative. Elle devient au contraire une composante d’un paysage technologique plus large.

Le meilleur partenaire n’est pas celui qui produit le modèle le plus sophistiqué. C’est celui qui sait :

formuler le problème → choisir la bonne méthode → construire le modèle → l’industrialiser → mesurer son impact → transférer la capacité à l’entreprise.

Pour une ETI, la question n’est donc pas :

« Data Science ou GenAI ? »

Mais :

« Quelle technologie permet de prendre une meilleure décision, à quel coût et avec quel niveau de contrôle ? »

← Retour au panorama des cabinets Data & IA