La Data Science a échoué

Résumé

Une session ciblée sur la raison pour laquelle la data science d’entreprise a souvent sous-performé dans les supply chain et comment y remédier rapidement. Nous explorerons le véritable but des équipes de data science, comment les utiliser efficacement et comment augmenter leur impact dès aujourd’hui.

Transcription complète

Conor Doherty: Voici Supply Chain Breakdown, et aujourd’hui nous allons expliquer pourquoi nous pensons que la data science d’entreprise a échoué.

Une autre opinion peu controversée ici sur Lokad. Je m’appelle Conor; je suis Directeur de la Communication ici chez Lokad.

Et à ma gauche, comme toujours, le fondateur de Lokad, Joannes Vermorel. Avant d’entrer dans le vif du sujet, commentez ci-dessous : êtes-vous immédiatement en désaccord avec notre point de vue ? La data science d’entreprise, dans l’ensemble, a-t-elle échoué ?

Nous le découvrirons au cours de la discussion. Posez vos questions et laissez vos commentaires. Alexey gère le chat en direct aujourd’hui — saluez-le, Alexey.

Et sur ce, Joannes, allons droit au but. Donc, premièrement : la data science d’entreprise—désolé—a échoué. C’est une déclaration provocatrice. Elle est très dans l’esprit de la marque, mais est-ce une exagération ?

Joannes Vermorel: De mon point de vue, non. J’ai eu l’occasion de discuter avec, je pense, environ 200 entreprises — de ce qu’elles font en matière de supply chain et de data science — et jusqu’à présent, je dirais que la quasi-totalité d’entre elles n’a pas connu un seul succès retentissant avec la data science.

Plus précisément, je parle des entreprises non technologiques — en mettant de côté les grandes entreprises technologiques comme Microsoft, Amazon, etc. Je veux dire les entreprises non technologiques qui gèrent d’importantes supply chain. Et quand je dis « la data science a échoué », je fais référence à l’équipe d’entreprise qui opère sous le nom d’équipe de data science.

Cette équipe a-t-elle délivré quelque chose qui contribue réellement à la rentabilité de l’entreprise ? Un critère est : si ces entreprises devaient liquider cette équipe du jour au lendemain, leur rentabilité serait-elle substantiellement affectée — au pire, feraient-elles faillite ?

Si la data science apportait réellement une valeur significative, alors supprimer l’équipe devrait nuire profondément à l’entreprise. Selon moi, pour littéralement toutes les entreprises que j’ai vues, on pourrait supprimer l’équipe de data science et cela ne représenterait guère plus qu’un inconvénient.

Conor Doherty: D’accord — mais définis le problème tel que tu le vois. Comment vois-tu une division de data science ? Quel est, selon toi, le mandat qu’elle est censée remplir et qu’elle rate ?

Joannes Vermorel: C’est là tout le problème : la data science est un moyen, pas une fin. Si nous prenons une analogie — à la fin du 19ème siècle — cette grande nouveauté, l’électricité. L’électricité est fantastique ; on peut en faire tellement. C’est une invention qui définira le siècle suivant.

Imaginez maintenant une entreprise qui crée un « département électricité ». Vous voyez bien qu’introduire un département électricité est une erreur — non pas parce que l’électricité est mauvaise, mais parce que le département électricité en lui-même est problématique. Voilà mon point de vue concernant la data science.

Je ne dis pas que la data science, en tant que sous-discipline de l’informatique, a échoué. Des choses incroyables sont réalisées avec des modèles, des techniques et des perspectives pour traiter les données — c’est une fusée, et GenAI n’en est que la dernière itération.

Cependant, si vous introduisez une division de data science, vous vous retrouvez avec le même genre d’absurdité qu’un département électricité dans votre entreprise. Il s’agit d’un moyen, et non d’une fin. Vous ne voulez pas de l’électricité pour elle-même ; vous voulez ce que vous pouvez en faire — et cela va être extrêmement diversifié.

Cela aura une signification complètement différente pour les usines par rapport à la finance. Les industriels diraient : « L’électricité est formidable ; nous pouvons avoir des moteurs pour déplacer des charges lourdes. » Les financiers diraient : « Si nous disposons d’une machine informatique très sophistiquée — c’est IBM — peut-être pourrons-nous effectuer des calculs pour nous. » C’est encore de l’électricité, mais d’une manière complètement différente.

Il en va de même pour la data science. La data science d’entreprise échoue parce que, si vous l’isolez dans sa propre division, vous obtenez quelque chose qui ne parvient jamais à fournir quoi que ce soit de réellement impactant — parce qu’elle n’obtient jamais le mandat nécessaire pour cela. Elle n’est pas intégrée dans une division qui a déjà une mission.

Elle n’est ni dans la finance, ni dans le marketing. Et les cas où cela fonctionne, c’est lorsque les personnes opèrent au sein d’un département existant avec un mandat clair.

Conor Doherty: Il y a deux façons d’aborder cela : de manière négative et positive. Commençons par ce qui ne va pas, concrètement. Comment voyez-vous actuellement les équipes de data science déployées — et pourquoi cela ne fonctionne-t-il pas ?

Joannes Vermorel: L’archétype est le suivant : la haute direction lit dans la presse que la data science est une tendance. Cela excite énormément les gens : « Donnez-moi de l’IA ! » Le conseil d’administration se réunit et déclare : « Nous ne pouvons pas passer à côté. Nous avons besoin de cela. »

Ils embauchent une bande de personnes très intelligentes et techniquement compétentes, et ces personnes disent : « Regardez tous ces projets open‑source brillants : pandas, PyTorch — vous l’appelez, c’est là. » Ce sont tous ces jouets scintillants. Faisons appel à ces projets open‑source ; ils sont d’une qualité incroyablement élevée et apportent de la sophistication.

Ces outils ont été déterminants pour permettre aux grandes entreprises technologiques d’obtenir des succès retentissants. Ainsi, les gens disent : « Nous avons tous les ingrédients : d’incroyables projets open‑source et des personnes intelligentes — nous allons imiter les grandes entreprises technologiques. » La conséquence : cela ne fonctionne pas.

Les gens construisent des choses. Le schéma typique est un prototype extrêmement sophistiqué et prometteur — en seulement quelques semaines. Trois semaines plus tard : bam, un prototype très sophistiqué, impressionnant. Un an plus tard, il n’est toujours pas en production. Cinq ans plus tard, il n’existe toujours rien de niveau production dans ce département — et certainement rien de révolutionnaire.

Oui, ici et là vous aurez quelques éléments pilotés par les données, mais en français, on dirait que c’est la roue folle de la voiture : quelque chose de non essentiel.

Conor Doherty: Vous avez mentionné la « production », et je tiens à revenir sur le purgatoire des pilotes. Mais vous avez également parlé de but, d’objectif, de direction, de fonction — des mots qui évoquent la téléologie. Alors encore, quel est selon vous l’objectif d’une équipe de data science — pourquoi existe-t-elle, si tant est qu’elle existe ?

Joannes Vermorel: C’est le problème — elle existe pour la même raison qu’un « département électricité » existerait dans votre entreprise. Envisagez-le ainsi et vous verrez le problème : cela sonne faux parce qu’il s’agit d’un moyen, et non d’une fin — même si vous êtes un fournisseur d’électricité.

Même EDF, fournisseur national d’électricité en France, n’a pas de « département électricité ». L’ensemble de l’activité, c’est l’électricité. Vous devez réfléchir à ce que vous voulez accomplir. Par exemple, si le marketing dit : « Nous voulons optimiser les dépenses pour Google Ads », alors faites l’optimisation des dépenses pour Google Ads.

Ils ne « font pas de data science » ; ils font cette optimisation. Il s’avère qu’il y a beaucoup de données impliquées. Dès que vous adoptez une perspective opérationnelle, cela ne s’appelle plus de la data science. C’est pourquoi je dis que la data science d’entreprise a échoué : chaque fois que je vois une équipe encore appelée « data science », cela reflète des personnes qui sont perdues. Elles n’ont aucun but — et généralement, il n’y a rien de significatif en production.

Elles auront quelques gadgets ici et là, mais si elles existent depuis une décennie et qu’on regarde hors des grandes entreprises technologiques, je n’ai jamais vu ces équipes tenir le destin de l’entreprise entre leurs mains. Au mieux, c’est extrêmement secondaire.

Conor Doherty: Vous avez audité des entreprises technologiques et travaillé dans des entreprises plus petites — pas des FAANG. Vous avez vraisemblablement vu des équipes de data science réussies. Qu’est-ce qui différencie les bonnes de l’échec global de la data science d’entreprise ?

Joannes Vermorel: J’ai audité plus de 100 startups. C’est complètement différent lorsque j’audite une entreprise qui fait de la détection de fraudes.

Évidemment, tel est l’objectif : détecter les fraudes. Ensuite, ils segmentent les types de fraudes ; ils peuvent avoir une équipe dédiée aux arnaques de type « pig‑butchering », avec des heuristiques spécifiques et des algorithmes pour les détecter, y remédier et signaler efficacement aux autorités compétentes.

La data science dans ces entreprises technologiques fonctionne parce que c’est littéralement leur raison d’être. Elles commencent par un problème qu’elles veulent résoudre — par exemple la détection de fraudes, ou la détection d’anomalies en ingénierie mécanique. Pour résoudre le problème, à un moment donné, vous faites appel à des outils sophistiqués.

Elles ne commencent pas par dire : « Nous avons ce package open‑source astucieux ; nous devrions l’utiliser. » Elles commencent par un grand problème sous‑adressé à résoudre. Elles constatent que des solutions simples échouent et, après validation, elles font appel aux moyens les plus conséquents pour le résoudre.

Souvent, elles réalisent que le problème n’est pas résolu parce que tout ce qui est disponible est inadéquat. Open source est fantastique, mais insuffisant pour leur problème spécifique. Ainsi, elles développent leur propre solution technologique et, en sous‑produit, open‑sourcent des composants qui sont des sous‑segments de leur solution.

Exactement comme le font les grandes entreprises technologiques avec des problèmes majeurs — ensuite, elles décident d’open‑sourcer des parties de leur solution. Par exemple, Airflow — de Facebook — est un système de planification de tâches distribué à grande échelle avec dépendances ; ils l’ont développé en interne et, à un moment donné, ce n’était qu’une pièce d’une solution plus grande qu’ils ont open‑sourcée.

Typiquement, telle est l’évolution de ces technologies. Ce qui est problématique, c’est de penser que vous pouvez simplement récupérer ces pièces et les réutiliser dans une grande entreprise, même si votre parcours est complètement différent. Ces morceaux technologiques sont excellents mais proviennent de parcours spécifiques.

La plupart du temps, ils ne conviennent pas à une grande entreprise qui rencontre des problèmes totalement différents de ceux des géants de la tech comme Meta. L’immense majorité des entreprises sur Terre n’a rien à voir avec les problèmes de Meta.

Conor Doherty: Toute personne familière avec le contenu de Lokad sait que vous êtes souvent en désaccord avec la manière dont le budget est dépensé dans les entreprises. Y a-t-il quelque chose de particulièrement pernicieux — particulièrement négatif — dans la façon dont l’argent est dépensé pour la data science, au-delà du simple gaspillage ?

Joannes Vermorel: Non — encore une fois, l’absence de conséquences. En raison du stéréotype selon lequel les équipes de data science sont extrêmement isolées, il n’y a presque pas de conséquences de second ordre. Elles ne polluent pas le reste de l’entreprise ; les dégâts se limitent largement à l’argent gaspillé sur l’équipe.

Elles sont tellement isolées qu’elles ne consomment même pas beaucoup de temps de la part de la haute direction ; peut-être une ou deux réunions par an. La bonne nouvelle, c’est que c’est un problème contenu : des dépenses inutiles qui ne vont pas au-delà de cela.

Conor Doherty: Elles sont tellement isolées — que voulez-vous dire ?

Joannes Vermorel: Vous pourriez imaginer d’autres phénomènes — des tendances de signaling de vertu — qui occupent tout le monde, surchargeant la capacité mentale de l’équipe exécutive. C’est très préjudiciable. La data science n’est pas comme cela. Elle est super isolée et ne constitue pas une charge cognitive pour la haute direction.

Pour moi, c’est une longue tradition ; cela se répète avec des mots à la mode changeants. Il y a vingt‑cinq ans, le mot‑clé était « data mining ». Les entreprises créaient des équipes de data mining. Puis des équipes de « digitalization », des équipes d’« innovation », puis des équipes de « data science » — et bientôt, des équipes de « generative AI ».

Si vous avez une équipe d’entreprise nommée d’après un moyen — comme « électricité » — au lieu d’une fin — comme « détection de fraudes » — c’est une erreur. Vous ne devriez pas avoir une équipe nommée d’après un moyen ; elle devrait être nommée d’après la fin.

Le nom a son importance : il définit la manière dont les gens abordent leur travail, le type de personnes que vous embauchez, et la façon dont ils élaborent leur feuille de route. Si vous avez une équipe de data science, ils proposeront — devinez quoi — une feuille de route de data science. Si vous dites « équipe de détection de fraudes », la feuille de route devient : « Comment éliminons‑nous ces fraudes ? »

Chez Lokad, nous avons en réalité arrêté d’embaucher des « data scientists » il y a une décennie. Nous embauchons désormais des « Supply Chain Scientist ». Cela peut sembler être un petit changement, mais lors du recrutement, nous disons littéralement aux candidats : si vous nous rejoignez, votre mission sera d’optimiser les supply chain de nos clients pour qu’elles fonctionnent aussi harmonieusement que possible.

Nous vous fournirons les meilleurs outils et formations ; vous ne serez pas livré à vous-même. Mais en fin de compte, si vous pouvez y parvenir avec de simples calculs et quelques heuristiques — tant mieux. Nous ne sommes pas là pour publier des articles sur des algorithmes sophistiqués. Si une heuristique incroyablement simple résout le problème, bravo ; la maintenance devient plus facile.

En revanche, quand nous embauchions des « data scientists », les gens s’opposaient en disant : « Nous ne pouvons pas résoudre ceci avec une méthode super‑bête — ce n’est pas à la pointe de la technologie. J’ai besoin de deep learning pour mon CV. » Pour nous : non, ce n’est pas le cas. Si quelque chose de bien plus simple que le deep learning le résout, alors le deep learning n’est pas nécessaire.

Conor Doherty: Avant de poursuivre, nous recrutons des Supply Chain Scientist. Si vous êtes intéressé, envoyez votre CV à notre responsable du recrutement.

Pour vous donner un peu de contexte : des sources comme Gartner rapportent que seulement 48% des initiatives numériques atteignent ou dépassent les objectifs commerciaux, et plusieurs enquêtes montrent que les projets d’IA/ML stagnent en pré‑production. Il y a clairement un « purgatoire des pilotes ». On ne dit pas que c’est un problème univarié — mais dans ce problème multivarié, quelle importance accordez‑vous aux divisions de data science dans ce phénomène ?

Joannes Vermorel: C’est accablant. Généralement, lorsqu’on lance une initiative numérique visant à digitaliser — à mettre en place un système de gestion — cela fonctionne. Par exemple, les dépenses gérées via des tableurs et des courriels : vous mettez en place un système de gestion des dépenses. Six mois plus tard, l’application et les pratiques sont en place, et ça fonctionne.

Les systèmes de gestion sont des initiatives quasi‑sans risque — bien que parfois les fournisseurs soient extrêmement médiocres. Au contraire, dans le domaine des systèmes d’intelligence, la quasi‑totalité échoue. S’ils proviennent d’une équipe de data science, mon expérience montre qu’ils échouent tout le temps.

Chez Lokad, nous avons même eu des clients avec des configurations côte à côte : Lokad générant des décisions de supply chain et l’équipe interne de data science qui faisait cela pendant une demi‑décennie avant nous — toujours présente, générant des choses inutilisées, tout simplement ignorées. La complexité d’entreprise les maintient en place.

La data science est extrêmement utile — comme l’électricité. C’est un outil polyvalent là où il y a des données — et de nos jours, c’est partout. Est‑ce digne d’intérêt ? Absolument. Mais cela ne justifie pas une équipe dédiée. Elle doit être présente dans chaque équipe où des données existent : marketing, finance, production, achats, planification, etc.

Conor Doherty: Soyons constructifs. D’après ce que vous avez dit, suggérez-vous que chaque membre de l’équipe améliore ses compétences en data science ; ou que chaque équipe devrait avoir un membre en data science ; ou qu’une équipe centrale prête des membres sur la base de tickets ? Quel monde conseillez-vous ?

Joannes Vermorel: Pour chaque fonction de l’entreprise, il existe un potentiel à exploiter les données pour accomplir ce que fait cette fonction—mieux et plus rapidement. Prenez un exemple plus simple que la supply chain : les dépenses marketing sur Google Ads.

Les Google Ads sont complexes : vous pouvez enchérir avec des frais variables pour des milliers de mots-clés ; suivre la performance, le coût par clic, le coût par résultat. C’est assez technique. Vous pouvez développer cette compétence en interne avec de véritables experts, ou l’externaliser complètement à une agence qui gère l’optimisation.

Les deux approches sont valables tant qu’une réelle compétence existe quelque part—en interne ou en externe. Il vous faut des personnes ayant une véritable affinité pour tout ce qui relève de la data science. Vous ne pouvez pas contourner une compréhension approfondie—mais celle-ci se perçoit à travers la fonction que vous optimisez.

Conor Doherty: Une question que j’ai reçue en privé—en jouant l’avocat du diable face à Joannes : « l’échec » n’est-il pas trop sévère si les analyses continuent d’alimenter les réunions et les rapports ? Si la direction se sent mieux informée, cela n’apporte-t-il pas de la valeur ?

Joannes Vermorel: C’est exactement le genre de cas où la data science est isolée et n’a pas de conséquences négatives—sauf qu’ici c’est pire : vous déconcentrez les dirigeants avec des rapports réconfortants. Si ce que vous souhaitez, c’est des statistiques descriptives pour la haute direction, c’est le rôle du BI.

Vous avez déjà une équipe de Business Intelligence ; il n’est pas nécessaire de doubler ce budget pour la data science. D’ailleurs, les divisions BI ont aussi leurs problèmes. Le marketing devrait être responsable de l’élaboration de ses propres indicateurs ; il ne devrait pas externaliser cela à la data science.

Si le seul résultat est des métriques qui rassurent la direction—au mieux, c’est redondant avec le BI—il faut les fusionner avec le BI ; il n’est pas nécessaire d’avoir une division séparée. Mon critère est strict : l’entreprise serait-elle financièrement lésée de manière mesurable si l’équipe de data science venait à disparaître ?

Améliorer le moral de la direction, c’est bien, mais je suis concerné par le compte de résultat—combien de dollars supplémentaires nous apportons à l’entreprise. Produire des milliers, voire des millions de chiffres par jour est extrêmement facile et divertissant ; produire dix chiffres par jour dignes d’intérêt est extrêmement difficile.

Est-ce vous qui produisez ces dix chiffres ? D’après mon expérience : non. Ils produisent des murs de métriques, oui—mais pas ceux d’une valeur aiguë qui, s’ils étaient retirés, nuiraient à l’entreprise.

Conor Doherty: Beaucoup de ces indicateurs viennent d’en haut. Le marketing est un département ; les ventes sont un département. Ils ne sont pas responsables des indicateurs qui leur sont imposés. Et si vous avez déjà le BI qui produit des statistiques descriptives…

Joannes Vermorel: Exactement—au mieux, c’est redondant. Fusionnez-le avec le BI ; il n’est pas nécessaire d’avoir une division séparée.

Conor Doherty: Encore un message privé : « Je ne peux pas simplement licencier mon équipe de data science. Comment puis-je améliorer les choses dès le premier jour ? » De manière réaliste, que peut-on faire ?

Joannes Vermorel: J’ai fait cela pour certains grands acteurs du le e‑commerce. J’ai suggéré de diviser l’équipe et de redéployer ses membres dans d’autres divisions. Si vous avez une demi-douzaine de personnes : mettez-en deux en finance, deux en marketing, deux en planification. Dites à ces managers qu’ils sont désormais responsables de ces personnes compétentes et de leur utilisation productive.

Si vous gérez cette unité et souhaitez être un héros, convainquez la direction générale de diviser et de répartir cette compétence entre les divisions. La meilleure approche que j’aie vue—mais qui ne fonctionne que pour les très grandes entreprises—est de transformer l’équipe centrale en coachs et mentors pour la data science au sein de chaque département.

Oubliez la livraison d’un prototype fonctionnel pour le marketing ; cinq d’entre vous coacheront le marketing afin qu’il puisse réaliser des choses intéressantes avec les données ; coachez de même les ventes. Cela fonctionne dans des entreprises de 5 milliards d’euros et plus—assez grandes pour supporter une équipe dédiée uniquement à l’évangélisation. Cela doit être transitoire—12, 18, 24 mois, pas plus de deux ans—puis se dissoudre.

Sinon, vous vous retrouvez avec une bureaucratie à demi cachée qui gaspille de l’argent.

Conor Doherty: Des questions provenant du chat. De la part de Neil Knight : Pensez-vous que les data scientists sont ignorés parce qu’ils sont internes—ou parce qu’ils ne sont pas utiles ? Je trouve que les consultants sont souvent écoutés parce qu’ils parviennent aux mêmes conclusions que la direction (McKinsey, Bain, Accenture, etc.). Qu’en pensez-vous ?

Joannes Vermorel: Il y a un proverbe français : on n’est jamais prophète dans son pays. Être un outsider aide, mais, à crédit des consultants, ce n’est pas seulement cela. Une chose qu’ils font bien, c’est de s’attaquer vigoureusement à des problèmes authentiques et importants.

Nous pouvons être en désaccord sur les compétences techniques nécessaires à la résolution, mais lorsqu’il s’agit de se focaliser sur ce qui importe véritablement pour la haute direction, ils excellent. C’est ce que la data science ne fait pas. Parce qu’ils sont isolés, ils ne peuvent pas s’attaquer à des problèmes à fort retour sur investissement—ceux-ci nécessitent de grandes transformations.

J’ai vu des équipes de data science choisir des projets favoris sans conséquence. Nous faisons un calcul rapide et constatons qu’il existe un problème vingt fois plus important juste à côté. Ils disent : « Oui, mais ce problème est délicat ; nous aurions besoin d’approbations à plusieurs niveaux ; nous risquerions de froisser des sensibilités. »

C’est là que les bons consultants gagnent : ils se concentrent sur ce qui compte, et non sur des projets favoris auxquels nous avons peur de toucher. Même si ce qu’ils font est crude, ils se focalisent sur des aspects très concrets. La data science, en étant à l’écart—non intégrée au marketing, à la finance, etc.—n’obtient jamais l’autorité nécessaire pour transformer l’entreprise afin de tirer parti des données.

Prenez la détection de fraude : lorsque vous détectez une fraude, vous devez avoir l’autorité pour dire, « Nous ne servirons pas ce client ; rejetez immédiatement le paiement. » Il y aura des faux positifs—des clients honnêtes en pâtiront. La question est de trouver l’équilibre entre faux positifs et vrais positifs.

Si vous dites à l’équipe de data science, « Tant qu’il y aura ne serait-ce qu’un faux positif par an, nous ne pourrons pas mettre cela en production, » cela n’ira jamais en production. C’est un compromis. Vous devez avoir l’autorité pour dire, « Globalement, c’est très bien ; les aspects négatifs sont sous contrôle, » puis affiner les méthodes.

Conor Doherty: Merci, Joannes. Passons à Amarinder : quel est votre point de vue sur le rôle du product manager ou du product scientist ? Est-ce un meilleur moyen de délivrer la valeur finale dont vous parlez ?

Joannes Vermorel: Les product managers évoluent principalement dans l’univers des systèmes de record. La gestion de produit y est cruciale parce que le ciel est la limite en termes de fonctionnalités ; il faut une feuille de route et une priorisation, et savoir dire « non » pour éviter une application monstrueuse.

Pour les systèmes d’intelligence—des processus décisionnels autonomes comme la détection anti‑spam—vous devez améliorer les faux positifs et les faux négatifs. Vous ne pouvez pas y remédier simplement en discutant avec les utilisateurs ou en arbitrant des fonctionnalités. Un autre exemple est le classement des résultats de recherche—comment améliorer la page de résultats de Google ? Très difficile ; ce n’est pas une question de fonctionnalités.

La gestion de produit est importante, mais elle appartient aux systèmes de record. La data science véritablement impactante doit concerner les décisions—donc les systèmes d’intelligence. Le product management ou les « management scientists » ont un rôle à jouer, mais il est mineur et issu du côté des systèmes de record.

Conor Doherty: Pour donner un aperçu de la semaine prochaine : nous consacrerons l’épisode aux systèmes de record, aux systèmes de rapports et aux systèmes d’intelligence. Soyez à l’affût de la promo et assistez.

Ultime réflexion, Joannes. Un appel à l’action pour ceux qui vous rejoignent : quelle est ma première action—que dois-je faire dès maintenant pour opérer le changement ?

Joannes Vermorel: Fondamentalement : il y a beaucoup de choses que vous pouvez faire avec vos données. La grande majorité des entreprises sous-exploitent leurs données. L’intuition qui sous-tend la data science vient d’un bon endroit : vous disposez de tant de données qui ne sont pas mises à profit pour améliorer l’entreprise.

Chez Lokad, c’est predictive optimization de supply chains—c’est ce que nous faisons—mais il y a bien d’autres choses. Un autre atout est la « mechanical sympathy » : des personnes qui embrassent la technicité, de sorte qu’il ne s’agisse pas seulement de suppositions éclairées—mais de personnes ayant une réelle affinité pour le défi.

Ce qui n’est pas bien, c’est de prendre cela et de dire, « Je dois créer une division. » C’est faux—un anti‑pattern ; une manière paresseuse d’aborder le problème. Pensez à la « division électricité ». L’électricité allait être super importante pour toutes les divisions—il en va de même pour la data science.

En tant que leader, mettez au défi chaque division d’exploiter au maximum les données existant dans l’entreprise pour leur fonction. Chaque responsable de division doit être chargé d’optimiser sa fonction. Cela nécessitera des compétences de type data science—internes, externes, avec ou sans consultants.

C’est un message difficile, car les dirigeants seront confrontés à quelque chose d’inconfortable. Pensez à l’électricité et aux ateliers : grâce aux ampoules, il est possible de fonctionner la nuit. Cela change tout. Allez-vous le faire ? Des tonnes de questions—mais vous devez trouver les réponses au sein de la fonction.

Faites participer les gens, mais vous ne pouvez échapper au fait que la technologie transforme ce que vous faites de manière si profonde que vous ne pouvez pas, de façon réaliste, externaliser le problème à une autre division et considérer le travail comme terminé.

Conor Doherty: Dernier choix, Joannes : nous pouvons nous arrêter ici ou répondre à une question de quelqu’un que je sais être un fan de longue date. Allons-y. Joshua demande : d’après votre expérience en dirigeant le “supply chain as a service”, si la plupart des clients disposent encore d’ERPs, de feuilles de calcul et de politiques qui gèrent discrètement les opérations quotidiennes, dans quelle mesure Lokad modifie-t-il réellement l’orientation de la prise de décision ? Qu’est-ce qu’il faut pour que la couche analytique devienne le décideur plutôt qu’un simple conseiller ?

Joannes Vermorel: Chez Lokad, nous restons fermes sur la livraison de décisions autonomes. Nous disposons de numerical recipes qui génèrent des décisions sans intervention. Tant que nous devons ajuster les chiffres, nous continuons d’itérer sur la recette afin de ne rien avoir à modifier ; puis nous assurons la maintenance pour qu’elle continue de fonctionner de manière autonome.

Il faut plusieurs mois d’exécution parallèle, surtout pour les grandes entreprises, pour gagner la confiance—des décisions de niveau production jour après jour. Dans une grande entreprise, cela prendra des mois. Au fur et à mesure, chacun commence à réaliser que nous avons désormais des questions bien plus intéressantes à poser : par exemple, qu’est-ce que la « quality of service » ?

Si vous me dites que la quality of service, c’est le « taux de service », je ne suis pas d’accord—ce n’est pas le taux de service. Pour le DoD, cela correspondrait à la « operational readiness ». Pour un budget donné, quel éventail d’opérations est réalisable versus irréalisable ? Ce sont des questions difficiles.

Lorsque nous déployons cette approche, les gens ont le temps de réfléchir plus en profondeur à ces questions. Le traitement des données apporte de nombreux éléments à la discussion : des catégories entières de questions nouvelles peuvent trouver des réponses dans les données.

Contrairement à une équipe de data science qui tente d’obtenir des réponses par elle-même, ici c’est orienté par l’opération : « Nous voulons faire ceci ; nous avons un goulot d’étranglement. » Examinez les données ; analysez le goulot d’étranglement ; obtenez une meilleure répartition ; puis identifiez le prochain goulot d’étranglement. Si vous isolez la data science, vous obtenez une solution en quête de problème.

Les gens élaborent une solution, puis cherchent un problème qui correspond approximativement. Avec une fonction opérationnelle—par exemple, allouer des dollars pour des pièces d’avion—vous avez un défi concret. Vous itérez pour améliorer la solution à un problème réel.

Conor Doherty: Un suivi de la part de Joshua : lorsque ce changement se produit selon votre perspective, combien de changements de politique sont généralement nécessaires pour qu’un client s’engage ? S’agit-il généralement d’une petite modification, ou d’une révision fondamentale de la manière dont les décisions de supply‑chain sont gouvernées ?

Joannes Vermorel: C’est la deuxième option, mais vous n’avez pas à tout faire en un jour. Pour certaines industries, nous avons même des témoignages—des transformations qui durent depuis une décennie et qui se poursuivent encore.

Pour les organisations complexes—la maintenance des avions de ligne étant extrêmement complexe—il faut du temps. Avec Air France Industries, la transformation est massive sur une décennie. Nous avons abordé les champs de décisions un par un ; je pense que nous avons plus de vingt champs différents là-bas.

Il a généralement fallu quelques mois pour que chaque champ soit déployé et devienne opérationnel. Ceci est consigné dans le domaine public—études de cas et interviews avec des directeurs.

Conor Doherty: J’espère que cela a aidé. Nous sommes un peu à court de temps, mais il est appréciable d’avoir répondu à toutes les questions. Merci, Joannes, pour votre temps—et merci à tous d’avoir participé et posé vos questions.

Certaines personnes préfèrent envoyer un DM en privé ; elles me contactent en direct, et comme vous le voyez, je les transmettrai à Joannes dans exactement les termes qui m’ont été présentés. Si vous avez des questions, envoyez-nous un DM ou publiez-les dans les commentaires.

Nous resterons pour y répondre. Passez une bonne soirée. Nous vous retrouverons la semaine prochaine pour le prochain épisode. Et… retournez au travail.