[J-Story 3] Dix ans de DataScience : ce qui a vraiment changé. Anil Palali – Lead Data Scientist @Unlimitail
Pourquoi cette J-Story ?
Dans cette édition, on parle de data science, de MLOps et d’IA générative, mais surtout de ce qui se passe vraiment quand une équipe data passe du bricolage à l’industrialisation. Comment faire évoluer un métier qui a tout changé en dix ans, garder la maîtrise des fondamentaux quand les outils font de plus en plus à votre place, et construire des systèmes qui créent de la valeur réelle plutôt que de belles démos.
Ce que vous allez apprendre ?
- Comment le métier de data scientist a évolué en dix ans, du statisticien artisanal au rôle stratégique
- Pourquoi le cloud a changé la culture de l’expérimentation bien plus que la puissance de calcul
- Ce que le MLOps a vraiment transformé dans la façon de déployer et maintenir des modèles
- Pourquoi l’IA générative rend la maîtrise des fondamentaux encore plus critique, pas moins
- La vraie différence entre un POC réussi et un modèle réellement industrialisé et adopté
À qui cette J-Story s’adresse-t-elle ?
Data Scientists, Lead Data Scientists, Data Engineers, Engineering Managers et Head of Data, et toutes les équipes qui cherchent à faire passer leurs projets data du stade de l’expérimentation à celui du produit qui tient dans le temps.
1. Peux-tu nous raconter ton parcours depuis tes débuts dans la data jusqu’à aujourd’hui chez Unlimitail ?
Je m’appelle Anil Palali, je suis Lead Data Scientist chez Unlimitail, et ça fait dix ans que je travaille dans la data. Quand je repense à mes débuts, la première chose qui me frappe, c’est qu’on ne s’appelait pas encore “data scientist”. On était “chargé d’études statistiques” ou simplement “statisticien”. Moins vendeur, certes, mais au fond, le vrai travail était déjà là.
Ma première expérience, c’était chez AFNOR. Tout était local, artisanal, sans infrastructure cloud ni culture MLOps. On construisait des choses qui fonctionnaient, mais chaque projet repartait presque de zéro.
Chez Malakoff Humanis ensuite, j’ai découvert une organisation data vraiment mature. Plus d’une centaine de personnes, des rôles clairement séparés entre data engineering, data science, visualisation et gouvernance. Ça m’a servi de référence pour tout le reste de ma carrière.
Le Crédit Agricole, c’était un autre terrain. Dans la banque, les données sont massives, les contraintes réglementaires sont fortes, et la valeur peut prendre des formes très diverses, la prédiction de comportement client, l’anticipation du risque, des dashboards qui changent la façon dont une équipe lit son activité.
J’ai ensuite fait du conseil, chez Sia Partners avec une motivation simple : comprendre comment les organisations utilisent leurs données. Ce que j’en retiens, c’est que les banques et de assurances sont des terrains extraordinaires pour la data, des volumes immenses, des problèmes complexes, mais aussi souvent des organisations qui n’exploitent qu’une fraction de ce qu’elles ont.
Aujourd’hui, je suis chez Unlimitail, une alliance entre Carrefour et Publicis dans le retail media. Ce qui m’a attiré ici, c’est la rareté de la situation, construire les briques data presque from scratch dans une structure qui a déjà une ambition claire. Ce n’est pas souvent qu’on a l’occasion de réfléchir à la fois aux modèles, à l’architecture, à la collecte des données et à la manière dont tout ça crée de la valeur concrète pour les métiers.
2. Quand tu as commencé il y a dix ans, à quoi ressemblait concrètement le métier de data scientist ?
À l’époque, le métier était beaucoup plus artisanal qu’aujourd’hui. Une grande partie du temps n’était même pas consacrée à la modélisation elle-même, mais à la préparation de la donnée.
On cherchait les données, on essayait de comprendre leur structure, on les nettoyait, on les réconciliait entre elles. La modélisation était la partie visible, mais elle n’était que la dernière étape d’un travail long et souvent ingrat.
Les outils étaient limités. On travaillait en local, sur des notebooks, avec des ressources de calcul contraintes. Lancer un entraînement un peu lourd, c’était une conversation avec l’IT, parfois plusieurs jours d’attente.
Et la mise en production était très rudimentaire. Quand on disait qu’un modèle était en production, ça pouvait vouloir dire un script qui tournait quelque part sur un serveur, sans monitoring, sans pipeline, sans suivi. Si le modèle dérivait, on ne le savait souvent que quand quelqu’un remarquait que les résultats semblaient bizarres.
Ce qui me frappe rétrospectivement, c’est aussi l’isolement du métier. Les data scientists travaillaient dans leur coin, avec une connexion souvent faible aux enjeux business réels. On nous donnait un problème, on produisait une réponse, et rarement on questionnait si c’était vraiment le bon problème à résoudre.
3. Quelles ont été les grandes ruptures technologiques que tu as vécues ces dix dernières années ?
Je dirais qu’il y a quatre grandes ruptures qui ont profondément transformé le métier.
La première, c’est l’arrivée du cloud. La révolution ne vient pas seulement du fait que les serveurs soient à distance. Ce qui change vraiment, c’est le rapport à l’expérimentation. Aujourd’hui, on peut lancer une instance de calcul en quelques minutes, tester une hypothèse, puis tout arrêter si ça ne fonctionne pas. Cette élasticité a complètement changé la vitesse à laquelle on peut expérimenter. Elle a permis de rendre l’échec bon marché.
Le deep learning ensuite. Je me souviens de problèmes sur lesquels on passait des semaines avec des méthodes classiques, sans vraiment y arriver. Le deep learning a rendu certaines choses soudainement possibles. Mais honnêtement, beaucoup d’équipes ont surtout adopté la complexité sans avoir les problèmes qui la justifient. C’est un piège que j’ai vu souvent.
Le MLOps, c’est la rupture la plus sous-estimée. Ce n’est pas glamour, ça ne fait pas de bonnes démos, mais c’est ce qui sépare un projet data science d’un vrai produit. Aujourd’hui, on pense au monitoring, à la reproductibilité, aux mises à jour. C’est là que j’ai appris que la data science sans ingénierie, c’est du bricolage.
L’IA générative, enfin. C’est la rupture de productivité la plus visible, mais c’est aussi celle qui produit le plus d’illusions. J’y reviendrai.
4. Tu dis que le cloud a rendu “l’échec bon marché”. Qu’est-ce que cela change dans la manière de travailler ?
Ça change la relation à l’incertitude.
Avant, tester une hypothèse avait un coût réel : en temps, en ressources, parfois en capital politique. Il fallait être assez convaincu pour justifier l’effort. Du coup, on testait moins, on choisissait ses batailles, et parfois on abandonnait des pistes prometteuses trop tôt.
Avec le cloud, ce calcul change. Une instance coûte quelques euros. Un test raté ne coûte presque rien. Et ça, ça transforme profondément la culture d’une équipe data.
Ce que j’observe, c’est que les équipes qui ont vraiment intégré cette logique itèrent beaucoup plus vite. Pas parce qu’elles sont plus intelligentes, mais parce qu’elles se donnent le droit d’essayer plus de choses. Elles ne cherchent pas la bonne réponse du premier coup. Elles convergent vers elle.
Le cloud n’a pas rendu les data scientists meilleurs. Il a rendu l’expérimentation accessible à tous.
5. À quel moment as-tu senti que le métier passait d’un rôle analytique à un rôle plus stratégique ?
Le changement s’est fait progressivement, mais je pense qu’il y a un moment clé : celui où le data scientist ne se contente plus de répondre à des questions, mais commence à les poser.
Aujourd’hui, on passe beaucoup de temps à comprendre le problème business avant même de penser à la solution technique. Le travail consiste souvent à reformuler un problème, à identifier les bons indicateurs et à proposer une manière de l’aborder avec la donnée.
Il y a aussi un signal organisationnel, à partir du moment où la data est présente autour de la table quand les décisions sont prises, et pas seulement convoquée pour valider des choix déjà faits, le rôle change de nature. Ce n’est pas juste une évolution de carrière. C’est une évolution de la place de la data dans l’entreprise.
6. Concrètement, qu’est-ce que ça veut dire être Lead Data Scientist chez Unlimitail ?
Ça veut dire que je passe ma journée à naviguer entre trois rôles qui n’ont pas grand-chose en commun, et que ma valeur tient surtout à ma capacité à passer de l’un à l’autre.
Le premier rôle, c’est le référent technique. Je suis responsable de l’ensemble des sujets data science du groupe. Ça implique d’arbitrer des choix d’architecture, de valider des approches, de m’assurer que ce qu’on construit sera maintenable dans un an et pas seulement dans deux semaines.
Le deuxième rôle, c’est ce que j’appelle le débloqueur. Je travaille au quotidien avec la squad lab, et l’objectif est de faire avancer plusieurs chantiers en parallèle. Ça ressemble parfois à du management, parfois à du pair programming, parfois à une conversation de dix minutes qui débloque plusieurs jours de travail.
Le troisième rôle, c’est l’interface avec les métiers et les stakeholders. Et c’est probablement le plus difficile à bien faire. Parce que ce n’est pas juste de la communication, c’est de la traduction. Traduire un enjeu business en problème data, puis traduire un résultat data en décision business. Si cette traduction échoue, le modèle le plus performant ne servira à rien.
7. Qu’est-ce qui distingue encore un bon data scientist aujourd’hui ?
La question que je me pose plutôt, c’est qu’est-ce qui disparaît ?
Ce qui disparaît, c’est la valeur du data scientist qui code vite. L’IA générative a considérablement réduit cet avantage. Générer une fonction, structurer un pipeline basique, produire de la documentation, tout ça s’accélère. Il n’a jamais été aussi simple de produire quelque chose qui ressemble à du bon travail.
Et c’est précisément pour ça qu’il n’a jamais été aussi important de vraiment maîtriser ce qu’on fait. Quand tout le monde peut générer du code en quelques secondes, la différence ne se fait plus sur la vitesse d’exécution. Elle se fait sur la capacité à comprendre pourquoi un modèle fonctionne, et surtout pourquoi il échoue. À identifier ce qui cloche dans un résultat qui semble correct. À concevoir une architecture qui tiendra dans six mois, pas seulement dans la démo de demain.
Les fondamentaux n’ont jamais été aussi précieux qu’aujourd’hui. Statistiques, probabilités, compréhension des mécanismes sous-jacents, c’est ce qui permet de valider ce que les outils produisent, pas de juste leur faire confiance.
Mais maîtriser les fondamentaux ne suffit pas si on résout le mauvais problème. J’ai vu beaucoup de projets échouer non pas parce que le modèle était mauvais, mais parce que personne n’avait vraiment questionné ce qu’on essayait de résoudre. On optimise une métrique qui ne correspondait à aucun enjeu business réel.
Et puis il y a quelque chose de plus difficile à mettre dans un CV : la capacité à faire adopter ce qu’on construit. Un modèle non utilisé ne vaut rien, même s’il est brillant techniquement. J’ai appris ça assez tôt, et ça a changé ma façon d’aborder les projets.
8. Comment l’IA générative change-t-elle ton quotidien ?
Elle a changé mon rapport au temps sur certaines tâches.
Des choses qui prenaient une demi-journée, structurer un pipeline, générer de la documentation, prototyper une fonction, peuvent maintenant prendre vingt minutes. Et cette compression de temps libère de l’espace mental pour ce qui compte vraiment : comprendre le problème, concevoir l’architecture, s’assurer que ce qu’on construit répond à un vrai besoin.
Je la vois comme une calculatrice avancée. La calculatrice n’a pas empêché les mathématiciens de réfléchir, elle leur a permis de réfléchir à des problèmes plus complexes. L’IA générative fait pareil pour le code.
9. Quelle est la plus grande illusion autour de l’IA générative en entreprise ?
Tout le monde veut faire de la l’IA générative. Et c’est compréhensible, les démos sont bluffantes, les cas d’usage semblent infinis. Mais c’est justement là que se trouve la plus grande illusion, penser qu’on en a besoin partout.
La pression pour l’intégrer dans chaque projet est réelle. Et cette pression fait qu’on ne se pose plus la vraie question : est-ce que c’est le bon outil pour ce problème ? L’effet démo accentue cet effet, il ne crée pas seulement l’illusion que tout est simple à construire. Il crée aussi l’illusion que tout mérite d’être construit autour de l’IA générative.
Ce qu’on oublie, c’est que ces modèles introduisent une complexité réelle. Ils sont non déterministes. Mais entre une démonstration et un système fiable en production, il y a un monde. Valider, monitorer, maintenir un système qui ne produit pas deux fois la même réponse, c’est un défi que beaucoup d’équipes sous-estiment.
Ce qui distingue une organisation mature sur le sujet, c’est savoir quand ne pas l’utiliser. Un modèle classique bien calibré sera souvent plus robuste, plus maintenable et mieux compris par les équipes qu’un LLM surdimensionné pour un cas d’usage qui ne le justifie pas.
La GenAI crée une valeur réelle, mais uniquement sur les bons problèmes. Et le jugement sur ce qu’est un bon problème ne vient pas de l’outil. Il vient de la personne entre l’ordinateur et la chaise.
10. Comment le MLOps a-t-il transformé la manière dont on déploie les modèles ?
Il a déplacé la ligne d’arrivée.
Avant, un data scientist considérait son travail terminé quand le modèle performait bien sur un jeu de test. Le déploiement était presque une formalité, souvent laissée à quelqu’un d’autre.
Le MLOps a changé ça, radicalement. Aujourd’hui, on pense au déploiement dès les premières lignes du projet. La reproductibilité, le versioning, les tests automatisés, le monitoring en production, la détection de dérive, tout ça fait partie du travail, pas de l’après.
Ce que ça a transformé en profondeur, c’est la collaboration entre data scientists et data engineers. On n’est plus dans deux mondes séparés. On partage les mêmes contraintes, les mêmes outils, parfois les mêmes responsabilités.
Et personnellement, c’est la discipline qui m’a le plus appris sur la différence entre un modèle qui marche et un système qui tient dans le temps. Ce n’est pas la même chose du tout.
11. Qu’est-ce qui distingue un POC réussi d’un modèle réellement industrialisé ?
Un proof of concept sert principalement à répondre à une question simple : est-ce que c’est possible ?
Il est souvent réalisé dans un environnement contrôlé, avec des données propres et des hypothèses favorables. L’objectif est de valider une direction. L’industrialisation, c’est une discipline entièrement différente. Le modèle doit fonctionner dans la durée, à grande échelle, et dans des systèmes qui évoluent.
Mais la vraie distinction, c’est celle de l’adoption. Un modèle industrialisé doit être utilisé par les équipes. S’il n’est pas adopté, même le meilleur modèle ne crée aucune valeur.
12. Peux-tu nous parler d’un projet marquant chez Unlimitail ?
Dans le retail media, certaines métriques sont critiques pour nos clients : les impressions, les clics, les conversions. Quand quelque chose déraille, chaque heure compte.
Le problème qu’on avait, les anomalies n’étaient détectées qu’après plusieurs jours. Le temps qu’une équipe remonte un écart, l’identifie comme une vraie anomalie et pas du bruit normal, et déclenche une investigation, il pouvait s’être passé plusieurs jours.
On a construit un système de détection automatique qui tourne quotidiennement sur l’ensemble de nos retailers. La vraie contrainte n’était pas algorithmique, les méthodes de détection d’anomalies existent. La contrainte, c’était l’échelle. Plusieurs dizaines de retailers, 5 métriques chacun, des comportements saisonniers différents, des volumes hétérogènes.
Ça représente des centaines de modèles à faire tourner, monitorer et maintenir en parallèle.
Ce projet m’a rappelé quelque chose d’important, la difficulté n’est presque jamais dans le modèle. Elle est dans tout ce qui l’entoure, la robustesse, l’échelle, l’adoption par les équipes qui reçoivent les alertes. Aujourd’hui, une anomalie est détectée en moins de 24h.
13. Avec dix ans de recul, quelle est la plus grande transformation apportée par la data ?
La réponse attendue, c’est qu’on prend de meilleures décisions. C’est vrai, mais ce n’est pas la plus profonde.
Ce qui m’a le plus marqué en dix ans, c’est que la data a cassé des silos qui existaient depuis des décennies. Une donnée produite par la finance peut éclairer une décision marketing. Elle circule là où elle a de la valeur, pas là où elle est produite. Et sur le long terme, ça ne change pas seulement les processus. Ça change la culture.
La data a fait la même chose à l’échelle des individus. Elle est venue légitimer l’expérience terrain. Une conviction forgée sur le terrain pouvait être contestée, minimisée, ignorée. La data raconte la même histoire, mais de manière factuelle. Et un fait, ça ne se conteste pas de la même façon qu’une opinion.
C’est peut-être là sa contribution la plus durable, elle n’a pas remplacé l’expérience humaine. Elle lui a donné une voix que personne ne peut ignorer.
Ce qu’on retient de cette J-Story :
- Le cloud a rendu l’expérimentation rapide et accessible
- Le MLOps est devenu essentiel pour industrialiser les modèles
- L’IA générative accélère la production mais ne remplace pas les fondamentaux
- La différence entre un POC et un modèle réellement utile se joue dans l’industrialisation et l’adoption
- La data devient stratégique lorsqu’elle aligne réellement les décisions métier
————————————————————————
Chez Jissen, nous accompagnons les organisations sur ces sujets : structuration des plateformes data, industrialisation des modèles, MLOps et intégration de l’IA dans des systèmes robustes et exploitables par les métiers.
Si ces enjeux résonnent avec vos projets data ou IA, nos équipes seront ravies d’en discuter avec vous.