00:00:00 Introduction
00:03:17 Pourquoi les forward deployed engineers existent-ils ?
00:09:48 Pourquoi les projets IA echouent dans les grandes entreprises
00:13:35 Le support expert affaiblit-il le logiciel plug-and-play ?
00:18:33 La tendance FDE valide-t-elle l’approche de Lokad ?
00:22:55 Automatisation contre decisions consequentes
00:28:07 Comment un Supply Chain Scientist aborde un nouveau client
00:32:26 Evaluer les experts sur de longues periodes
00:36:12 L’adoption du produit est-elle le bon indicateur de succes ?
00:40:06 Pourquoi l’automatisation est un probleme de zero a un
00:43:09 Impact financier contre impact economique
00:48:05 Pourquoi la prise de decision exige une expertise metier
00:52:32 Comment Lokad identifie les bons Supply Chain Scientists
00:55:22 Automatisation hospitaliere contre decisions medicales
00:57:09 Les FDE invalident-ils les modules d’optimisation plug-in ?
00:58:43 Le probleme de cout des services FDE
01:01:04 Conclusion
Resume
Conor Doherty et Joannes Vermorel examinent pourquoi les forward deployed engineers sont devenus l’une des dernieres tendances du logiciel d’entreprise. Ils discutent des penuries de talents et des initiatives IA ratees qui expliquent leur essor, tout en distinguant l’automatisation ordinaire des decisions financierement consequentes. Joannes soutient que l’automatisation doit supprimer entierement le travail, tandis que les systemes de decision exigent une maintenance continue, un jugement economique et une expertise metier profonde. La conversation compare les FDE aux Supply Chain Scientists de Lokad, remet en question l’adoption comme indicateur de succes et explore si un support humain couteux revele les limites du logiciel d’entreprise pretendument plug-and-play.
Transcription complete
Conor Doherty: Il est presque 18 h, ce qui, a Paris, revient pratiquement a dire qu’il fait nuit. Donc oui, nous travaillons vraiment dur en France, selon les standards francais. Il est donc presque 18 h ici a Paris, et Joannes et moi venons de terminer le podcast sur les forward deployed engineers. Et cela s’est revele assez different de ce que j’imaginais.
Evidemment, j’avais prepare mes questions, puis la conversation a evolue. Je pensais que nous parlerions surtout de ce qu’est un forward deployed engineer, de savoir si c’est de la hype ou non. Nous avons couvert cela, mais la discussion est aussi partie sur l’evaluation de l’offre d’un FDE dans le logiciel d’entreprise, sur ce a quoi ce role devrait vraiment servir, et sur la comparaison avec le poste de Supply Chain Scientist chez Lokad. J’ai donc beaucoup apprecie. J’espere que ce sera aussi votre cas, et dites-nous ce que vous en pensez sur LinkedIn.
Vous pouvez contacter Joannes et moi si vous voulez poser d’autres questions. Mais moi, je vais rentrer chez moi maintenant. Bonne conversation. Alors, Joannes, merci de me rejoindre.
Je t’ai fait venir aujourd’hui pour discuter de la montee des forward deployed engineers. J’ai fait mes devoirs la-dessus. Ce n’est pas un nouveau poste. En fait, il trouve ses racines dans le domaine militaire, mais dans les cercles logiciels, et plus precisement dans le logiciel d’entreprise, c’est un poste tres recent.
Pour donner un peu de contexte sur l’echelle dont on parle, j’ai lu ce matin qu’AWS investit environ un milliard, en fait un peu plus d’un milliard de dollars, pour developper son departement de forward deployed engineers, ou FDE. Y Combinator, le tres celebre accelerateur, a actuellement, au moment ou nous parlons, nous sommes le 27 aout, plus de 100 startups qui recrutent pour ces roles precis, pas des engineers, des forward deployed engineers.
Qu’est-ce que c’est, en termes simples ? J’ai synthetise quelques definitions, car elles varient evidemment, mais dans les grandes lignes, un forward deployed engineer, ou FDE, est un ingenieur logiciel en contact avec le client, qui travaille directement dans l’equipe d’un client, ou avec elle, physiquement ou a distance, afin de construire, personnaliser et livrer un logiciel complexe pour resoudre des problemes complexes du monde reel. Et comme cela t’est surement venu a l’esprit, comme cela m’est venu a l’esprit au moment ou je l’ai entendu et lu, et comme cela est surement venu a l’esprit de tous ceux qui connaissent Lokad, cela ressemble beaucoup a un Supply Chain Scientist. Il y a des differences, nous y reviendrons, mais ma premiere question est generale.
Nous sommes quatre ans apres le boom de l’IA. ChatGPT est sorti a l’automne 2022, et nous sommes maintenant presque a l’automne 2026. Cela parait plus rapide, mais cela fait bien quatre ans. L’IA ecrit son propre code dans beaucoup de contextes, et pourtant nous revoila, comme si le temps etait un cercle plat, revenus a “si vous voulez que ce truc fonctionne, vous devez engager mon expert pour venir le faire fonctionner chez vous”. Donc Joannes, pourquoi ce role existe-t-il encore aujourd’hui ?
Joannes Vermorel: Oui, nous revenons completement au type de dispositif qui a historiquement fait la fortune d’IBM. L’idee du forward deployed engineer etait plus ou moins le dispositif par defaut d’IBM dans les annees 70 et 80 : envoyer des tonnes d’ingenieurs sur site, dirais-je, chez le client pour installer le mainframe. C’etait, je dirais, le defaut.
En fait, nous avons recule par rapport a cela pendant les deux dernieres decennies, et maintenant cela revient en force. Mon point de vue general sur la raison de ce retour, c’est qu’il y a plusieurs forces, mais l’une d’elles est simplement l’effet sociologique du recrutement. Certaines entreprises reussissent incroyablement bien a attirer les talents par rapport a d’autres. Et si vous etes, disons, je lisais cela il y a quelques annees, Google recevait quelque chose comme 4 millions de candidatures par an.
C’etait une information d’il y a une dizaine d’annees. C’est probablement encore le bon ordre de grandeur. Et ce qui est interessant, c’est que certaines entreprises reussissent et d’autres non. Pour donner un chiffre minuscule et totalement anecdotique, chez Lokad, quand nous publions une offre sur LinkedIn, je vois tres souvent que nous avons beaucoup plus de candidats que de tres grandes entreprises de plus de 100 000 employes lorsqu’elles publient une offre comparable.
Conor Doherty: Tu parles precisement du role de Supply Chain Scientist, la ?
Joannes Vermorel: Oui, sur LinkedIn nous le presentons comme business analyst.
Conor Doherty: Ah oui, c’est vrai.
Joannes Vermorel: Parce que sinon, les gens devant leur ordinateur ne savent meme pas vraiment de quoi nous parlons. Donc quand nous publions sur LinkedIn, nous mettons business analyst, et nous recevons generalement beaucoup plus de candidatures que de tres grandes entreprises. Ce que je vois globalement, c’est que certaines entreprises, de toutes tailles, parviennent a attirer enormement de talents, tandis que beaucoup d’autres, souvent plus anciennes et plus grandes, n’y arrivent pas. Cela cree une inclination tres naturelle, je dirais, a se dire : si nous pouvons embaucher toutes ces personnes, ou davantage de ces personnes qui postulent chez nous, nous allons revendre leurs bons services a ces clients.
Et si vous pouvez combiner cela avec une plateforme logicielle, vous vendez le temps de ces personnes intelligentes que vous pouvez recruter, et en plus vous accrochez l’entreprise cliente aux technologies fondamentales que vous vendez. Cela peut devenir une manoeuvre tres rentable sur une tres longue periode. Si nous parlons d’AWS, nous parlons de personnes qui aideront les clients a adopter l’offre cloud d’Amazon. Ce sera la meme chose avec des forward deployed engineers de Palantir : ces personnes construiront sur la plateforme Palantir. Et, dans une certaine mesure, chez Lokad c’est un peu pareil : les Supply Chain Scientists construisent sur la plateforme Lokad.
Mais fondamentalement, je pense que la force sous-jacente, plus grande que la technologie, est cet effet sociologique : les talents semblent affluer vers quelques entreprises qui recoivent un nombre enorme de candidatures, alors que beaucoup d’autres en recoivent tres peu. C’est ainsi que l’on se retrouve, d’une certaine facon, avec des entreprises qui accumulent un peu les talents. Et il y a cette inclination naturelle a dire : je peux embaucher seulement ce dont j’ai besoin, ou je peux decider de me developper et utiliser le fait que je suis tres bon pour attirer les talents afin de revendre ensuite ces talents d’ingenierie a des clients.
Conor Doherty: C’est vrai. Encore une fois, c’est evidemment multifactoriel.
Joannes Vermorel: Oui.
Conor Doherty: Un autre fil qui merite qu’on s’y attarde, et cela revient a l’idee que le temps est un cercle plat. Il y a environ 18 mois, nous avons fait un evenement live sur le generative AI value gap. Nous avions fait un episode enregistre quelques mois avant. Nous parlions du fait qu’il y a beaucoup de recherches, meme de grands cabinets de conseil, qui disent que beaucoup des projets dans lesquels les entreprises injectent des centaines de millions de dollars ne sont d’abord pas adoptes, et ensuite ne generent aucune valeur. En preparant cet episode, je suis retourne voir combien de mes notes de l’epoque restaient pertinentes aujourd’hui. Surprise : toutes. En fait, une etude du MIT l’an dernier, portant sur 400 entreprises, de grandes entreprises americaines, indiquait que 95 % d’entre elles reconnaissaient que l’argent depense dans des projets IA n’avait rien produit.
Le terme utilise etait “aucun impact mesurable”. Beaucoup de ces postes de forward deployed engineers sont tres etroitement associes au fait de faire fonctionner des projets IA. Je suis sur qu’il existe des applications de niche ou l’objectif est simplement de faire decoller un systeme d’enregistrement, et on envoie quelqu’un faire cela. Mais tres souvent, OpenAI, Anthropic, meme des acteurs de notre domaine, vendent des projets IA avec un FDE, ou bien le FDE rendra le projet IA operationnel dans votre contexte.
Donc tu as parle de retention des talents, bien sur, presque comme un investissement pour un besoin futur. Mais en meme temps, au moins selon beaucoup d’institutions, il existe un besoin tres present, car beaucoup de projets IA dans lesquels les entreprises depensent, un peu a l’aveugle, des millions de dollars n’apportent rien. Et le marche dit : vous savez quoi, j’ai un expert pour vous aider a corriger cela. Est-ce que cela te parle ?
Joannes Vermorel: Oui, mais j’attribuerais la cause profonde a quelque chose d’un peu different.
Conor Doherty: D’accord.
Joannes Vermorel: Les grandes entreprises, toutes les entreprises, ont generalement parfaitement maitrise et calibre exactement la quantite de competence et de savoir-faire necessaire pour chaque poste. Le resultat, c’est que vous vous retrouvez avec une pyramide dans l’entreprise ou la majeure partie de la pyramide est remplie de personnes qui sont exactement a leur pic de competence. C’est le principe de Peter : vous etes promu jusqu’a atteindre votre point d’incompetence.
Maintenant, imaginez une entreprise de 50 000 personnes ou presque tout le monde est exactement a la limite de l’incompetence. Ils ne sont pas incompetents, ils sont juste en dessous. Puis vous introduisez une technologie qui, en elle-meme, n’est pas si compliquee, mais qui represente clairement une complication supplementaire. Et vous realisez que presque toute votre pyramide ne peut pas l’absorber, car cela les fait sortir de leur zone de capacite. C’est un peu dur, mais pensez a une entreprise presente depuis des decennies, qui a generalement reussi a extraire chaque pourcent de rentabilite de sa structure de couts.
Cela signifie que si vous employiez des gens plus competents que ce qui etait vraiment necessaire, c’etait de l’argent laisse sur la table. Beaucoup d’entreprises finissent donc, au fil des decennies, par eliminer naturellement tout surplus de competence, sous l’effet des forces du marche. C’est ma lecture habituelle de la situation. Ainsi, lorsque vous introduisez ce type de technologies logicielles disruptives, elles ont besoin de renfort, car si elles essaient de les deployer en interne, elles se heurtent a cette difficulte : presque tout le monde dans la pyramide est deja au maximum de ce qu’il peut gerer. Si vous ajoutez quelque chose, ce n’est tout simplement plus gerable. Et ils n’y arrivent pas.
C’est pourquoi je pense que beaucoup d’initiatives IA echouent. Il faut des personnes qui ont beaucoup de marge, qui sont plus intelligentes, competentes et capables que ce que leur poste actuel exige, afin de pouvoir repenser l’avenir de leur poste une fois l’IA integree. Car avec les technologies IA, ce qui se passe generalement, c’est qu’il faut repenser le travail, et ensuite on peut potentiellement obtenir une productivite 10 fois superieure. Mais ce travail demande une redefinition tres soigneuse, bien au-dela de ce qui etait necessaire historiquement pour simplement maintenir le statu quo.
Conor Doherty: Pendant que tu parlais, une idee s’est cristallisee. Ce n’est pas quelque chose que j’avais note, mais je vais essayer de la formuler. Toute l’idee de l’IA, du moins telle qu’elle a ete vendue, c’est : automatisons autant que possible, et nous allons aussi pouvoir passer a une echelle largement superieure a ce qui etait necessaire ou possible avec, disons, une main-d’oeuvre humaine, ou certainement avec ce qu’une personne pouvait faire. Et maintenant nous en sommes au stade ou, si vous voulez que l’IA fonctionne, il vous faut quelqu’un avec beaucoup de marge de competence pour la faire fonctionner.
Joannes Vermorel: Oui.
Conor Doherty: Et donc, pardon, le point est le suivant, et ensuite tu peux developper : est-ce que cela ne vide pas, ou ne sape pas, toute l’idee de payer et brancher, ou de brancher un nouveau logiciel achete sur etagere, qui serait pret a fonctionner, puisque maintenant il faut acheter quelqu’un d’autre pour le faire fonctionner pour vous ?
Joannes Vermorel: Oui. Je vais donner une anecdote recente. Je contactais tres recemment mon operateur mobile via sa hotline. Une experience merveilleuse. Historiquement, ils avaient les deux premieres minutes de mentions legales incroyablement lentes, dont je me moque, puis “appuyez sur 1 pour ceci, appuyez sur 2 pour cela”, etc.
Ils avaient ce labyrinthe de chiffres pour atteindre ce que vous vouliez, et finalement obtenir un operateur, car aucun chemin ne menait vraiment quelque part. Meme cela etait un peu casse. Ce qu’il faut imaginer, c’est que les ingenieurs faisant de leur mieux dans cette entreprise etaient a peine capables de maintenir quelque chose qui etait essentiellement un arbre de decision avec des chiffres pour orienter les gens. C’etait deja leur pic d’ingenierie, et ils echouaient deja un peu. Et maintenant ils ont recemment refondu leur systeme avec une IA. Cette IA a la pire reconnaissance vocale imaginable. Elle ne comprend rien.
Il m’a fallu environ 20 minutes a me battre avec cette fichue IA pour finalement obtenir un operateur, car ce que je voulais faire n’etait pas possible par ce systeme. C’etait une erreur d’ingenierie epique, mais en realite c’etait tres previsible. Si vos equipes sont deja a la limite de leurs capacites d’ingenierie pour concevoir un arbre de decision, ce qui est deja un defi pour elles, si vous leur demandez de faire un tri fluide base sur l’IA pour les appels entrants, ce sera tres mauvais. Et c’etait interessant, car tout etait mauvais : la reconnaissance vocale etait terrible ; on sentait que le script, la base de connaissances utilisee pour traiter la situation, etaient mauvais.
C’etait un probleme multicouche, ou chaque element logiciel etait mauvais. La reconnaissance vocale choisie etait mauvaise. La synthese vocale etait mauvaise. Le LLM choisi etait mauvais. La base de connaissances fournie au LLM etait mauvaise. C’etait un logiciel mediocre multicouche. Et si l’on revient a la question de pourquoi cela echoue, imaginez une situation ou votre IT lutte deja pour faire fonctionner des choses tres simples. Et encore une fois, je connais les gens qui travaillent dans l’IT de cette entreprise precise ; ce ne sont pas les plus brillants.
C’est le genre d’entreprise qui a enormement de mal a recruter quelqu’un de correct sortant d’une ecole d’ingenieurs en France. Il n’est donc pas surprenant que tout ce qu’ils essaient en IA soit catastrophique. Et donc, le fait qu’il faille apporter de l’aide est simplement la consequence du fait que, des que vous introduisez de la nouveaute, vos equipes ne pourront pas faire face, car elles arrivent a peine a gerer le statu quo.
Conor Doherty: Oui.
Joannes Vermorel: Et meme le statu quo les etire deja beaucoup.
Conor Doherty: J’avais note le mot flux, mais nouveaute est meilleur, car je pense que cela capture vraiment l’esprit de l’un des grands differenciateurs ici. Historiquement, Lokad a toujours associe l’idee que vous avez le logiciel, mais aussi l’expert. Et la raison pour laquelle vous avez l’expert, c’est que votre supply chain sera pleine de nuances, de cas limites qui vont apparaitre. Evidemment, il y aura des decisions quotidiennes banales, mais elles seront gouvernees par beaucoup de flux. Cela n’a jamais ete : achetez simplement cela sur etagere.
Tout le marketing, et en realite la fonction meme du service, etait : cela doit etre construit autour de vos problemes, autour de votre realite. Notre Supply Chain Scientist doit interagir avec vous pour construire la couche de prise de decision.
Joannes Vermorel: Oui.
Conor Doherty: Vois-tu l’emergence du role de FDE dans des entreprises similaires, et nous parlons de pairs, de concurrents, peu importe, comme une validation du fait que tu as toujours soutenu que tout devait etre construit sur mesure ? Qu’on ne peut pas simplement avoir du code copier-coller pour tout ?
Joannes Vermorel: Oui et non. La realite, d’abord, c’est que presque tous les problemes auxquels on fait face quand on entre dans le domaine du logiciel d’entreprise consistent a coller des logiciels entre eux. C’est presque tout le probleme. Vous pouvez avoir un LLM sur etagere ici, un serveur web sur etagere la, une base de donnees transactionnelle sur etagere ailleurs. Mais il faut coller tout cela, et comme votre entreprise existe depuis 50 ans, vous avez des decennies de choses deja en place. Vous n’avez donc pas le luxe de dire : je branche simplement ce produit et il fonctionne.
C’est une situation de greenfield qui marche dans une PME. Cela ne marche pas dans l’entreprise. Pour etre juste avec le marche, l’idee d’utiliser beaucoup de consultants et d’integrateurs pour faire cette plomberie sur mesure existe depuis longtemps. Les gens etaient tres realistes.
La difference principale, je pense, concerne l’automatisation. C’est la difference cle. D’habitude, s’il s’agit seulement de mettre en place un systeme d’enregistrement et de connecter vos systemes d’enregistrement, vous pouviez le faire avec des integrateurs qui etaient generalement bons avec les systemes d’enregistrement. Et ces choses ne sont vraiment pas intelligentes. En termes de conception logicielle, ce sont essentiellement des applications CRUD : create, read, update, delete. C’est aussi vanilla que possible.
Elles ont une fonction simple : maintenir les enregistrements. L’automatisation, c’est autre chose. Nous, chez Lokad, nous nous concentrons sur les decisions, mais meme avant les decisions, il y a enormement de choses qui sont simplement des automatisations de base. Et la, je vois beaucoup de blocages, principalement parce que des que vous aviez une entree en texte libre, une donnee non structuree, une image, quoi que ce soit, vous etiez bloque et deviez mettre un humain dans la boucle. Avec ces technologies IA, la quasi-totalite de l’automatisation banale devient possible. Je ne parle meme pas de la couche decisionnelle comme Lokad.
Je parle de choses comme : un client doit envoyer une copie de sa carte d’identite. Vous recevez une image. Est-ce une image d’une carte d’identite ? Oui. Non. Si vous n’avez pas un systeme capable de dire si c’est une image de carte d’identite ou non, il vous faut un humain pour regarder et se placer au milieu. Je pense donc que l’automatisation est beaucoup plus large que les decisions. Elle concerne litteralement toutes les etapes super granulaires de vos processus, dont la plupart sont tres peu consequentes. Elles doivent simplement etre faites. Ce que vous voulez, c’est que la chose soit faite sans humain dans la boucle, sachant que c’est une tache incroyablement banale, avec des enjeux pas tres eleves, tres directe. Mais si vous vous limitez au paradigme CRUD, create, read, update, delete, ce paradigme ne vous donne pas de moyen d’automatiser cela. Il faut un peu plus. C’est la que les forward deployed engineers peuvent apporter beaucoup de valeur : fournir l’intelligence necessaire pour automatiser au-dela du CRUD, car la plupart des integrateurs ne sont pas capables de faire quoi que ce soit au-dela du CRUD.
Conor Doherty: Absolument. C’est un point qui merite d’etre clarifie. Le contexte de la discussion ici, du moins pour l’essentiel, et certainement en ce qui concerne la comparaison avec la couche Lokad, la couche systeme d’intelligence, c’est que la grande majorite des recherches que j’ai faites, les postes que j’ai regardes, consistent essentiellement a construire du code IA qui aidera les gens a prendre des decisions. Si l’on prend l’exemple du systeme d’enregistrement ERP, c’est un systeme d’enregistrement.
Vous avez vos donnees transactionnelles. Comment passer de cela a : quelles decisions dois-je prendre aujourd’hui, demain, etc. ? C’est la que beaucoup de gens utilisent des forward deployed engineers, ou en tout cas dans le logiciel d’entreprise, c’est la qu’ils sont deployes.
Et dans leur langage, c’est une mission. Vous arrivez, cela peut prendre six mois, un an, deux semaines. A l’inverse, quand tu parles du Supply Chain Scientist, ce n’est pas une chose court terme. C’est une relation continue pour des raisons tres precises.
Joannes Vermorel: Oui. Encore une fois, c’est surtout parce que la quasi-totalite de ce que le marche considere comme relevant des forward deployed engineers ne concerne pas les decisions. Ils automatisent simplement le banal. La decision a deja ete prise.
Ce n’est pas la question. Il s’agit litteralement d’automatiser. Et quand je dis automatiser, pensez a des choses tres simples : par exemple, un enregistrement apparait sur un ecran et doit etre copie-colle, dans certaines situations vers le logiciel A, dans d’autres vers le logiciel B, et la frontiere entre les deux cas est un peu floue. C’est le genre de situation ou, boum, forward deployed engineer. Si vous pouvez avoir une regle hyper simple que vous codez dans Excel, vous n’avez pas besoin de ces gens. Mais si c’est plus nuance, alors oui, vous pourriez en avoir besoin. Et ma lecture est que la rentabilite ne sera atteinte que lorsqu’ils retirent des personnes de l’image. Si ce n’est pas un gain net substantiel de productivite, il n’y aura pas de retour sur investissement. Et encore une fois, si vous dites que votre mission a une limite dans le temps, alors par definition vous ne traitez pas des decisions. Vous traitez simplement de l’automatisation.
Conor Doherty: C’est un point juste.
Joannes Vermorel: Oui, c’est un point juste. Une decision, quelque chose qui a des enjeux financiers attaches, doit etre surveillee et revisee. C’est pourquoi les Supply Chain Scientists ne disparaissent pas.
C’est pourquoi, quand nous demarrons une initiative avec un client, ils restent. Si vous allez ecrire une recette numerique qui peut litteralement depenser des millions de dollars par jour, et elle le fera, car si vous recommandez ce qu’il faut recommander, vous avez une recette numerique qui vous donne votre liste de reassort. C’est litteralement votre liste de depenses. Ce sont des dollars que vous allez depenser a cause de cette recette numerique. Elle doit etre maintenue, car ne pas la maintenir serait de la folie.
A un moment, un changement de marche invalidera les hypotheses faites par votre recette numerique, et ce sera une catastrophe. Il faut donc evidemment de la maintenance, et il faut quelqu’un d’intelligent pour faire cette maintenance. Mais si nous parlons d’automatisations de base, alors non : vous pouvez avoir quelque chose qui necessite quelqu’un d’intelligent pour creer l’automatisation, mais ensuite cette automatisation peut tourner presque jusqu’a la fin des temps.
Par exemple, si vous voulez faire de la reconnaissance de cheques manuscrits. Une fois que vous avez un dispositif capable de faire cette reconnaissance d’ecriture manuscrite, il peut tourner quasiment indefiniment. Mais fondamentalement, ce n’est pas quelque chose avec des enjeux eleves. C’est de la reconnaissance d’ecriture manuscrite. Vous conservez l’image, vous avez la reconnaissance, et vous pouvez automatiser. Tres bien. Vous n’avez pas forcement besoin de garder l’ingenieur qui a concu l’algorithme de reconnaissance d’ecriture a proximite.
Conor Doherty: Il me semble qu’une dimension centrale qui vaut la peine d’etre exploree est la suivante : que vous engagiez un FDE via une autre entreprise, ou que vous travailliez avec Lokad et que vous ayez un Supply Chain Scientist, le principe est d’amener un expert qui, a ce moment-la, ne connait pas encore votre entreprise, n’a pas le code ecrit, ou ne devrait pas l’avoir, car il doit interviewer, comprendre la supply chain afin d’extraire cette information et, vraisemblablement, appliquer une expertise metier. Oui, je ne pense pas que nous soyons en position de commenter la maniere dont un FDE fait cela. Nous n’avons pas de FDE.
Comment un Supply Chain Scientist aborde-t-il cela ? Donc, jour un, il parle aux clients. Sur le papier, cela parait tres simple : parler aux gens, obtenir de l’information. Mais quel type d’information, dans un contexte supply chain, est pertinent pour qu’un FDE ou un SCS commence a construire du code ? Tu peux choisir n’importe quel probleme jouet.
Joannes Vermorel: Dans notre cas chez Lokad, ce que le Supply Chain Scientist doit vraiment faire, c’est essentiellement cartographier le paysage applicatif. Ce sera une discussion technique avec l’IT, simplement pour comprendre quelles donnees sont disponibles. La regle est que les donnees sont ce qu’elles sont. Donc ne vous plaignez pas. L’entreprise arrive a fonctionner avec ces donnees. L’hypothese par defaut est donc que c’est suffisant.
Ce n’est jamais parfait, mais c’est suffisant. Donc cartographier le paysage, c’est une grande partie du travail. Puis l’autre partie consiste a comprendre ce que l’entreprise fait reellement pour le marche, avec ses partenaires, et comment tout cela doit etre quantifie afin d’obtenir un modele economique de l’entreprise.
Cela doit avoir du sens, car le Supply Chain Scientist sera responsable de concevoir une recette numerique. Cette recette numerique consommera les donnees, d’accord, c’est le premier point. Mais a la fin, elle evaluera toutes les differentes options disponibles en euros ou en dollars.
Et pour avoir une evaluation qui ne soit pas absurde, il faut une comprehension profonde de l’activite. Il faut comprendre ce que les clients valorisent vraiment. Quelles contraintes sont vraiment douloureuses pour les fournisseurs ? Ou sont les goulets d’etranglement dans la supply chain ?
Qu’est-ce qui compte comme ressource rare ? Car tout est rare, oui, mais certaines choses dans la supply chain peuvent etre beaucoup plus rares. Vous pouvez donc etre bloque a des endroits tres precis. Il faut en etre conscient.
Et ensuite il faut aussi modeliser toutes les forces qui ont, je dirais, des effets durables mais difficiles a evaluer immediatement. Un exemple serait : si vous vendez au-dessus du prix de vos concurrents, toutes choses egales par ailleurs, il y aura une attrition dans le temps. Vous perdrez progressivement des parts de marche. Si, toutes choses egales, vous etes simplement un peu plus cher que vos concurrents, alors avec le temps, sauf si votre marche est regule ou autre chose, vos clients iront chez les concurrents.
Mais le probleme, c’est que cela sera invisible en quelques semaines, car il y a beaucoup d’habitudes, etc. Le Supply Chain Scientist est donc la pour avoir une perspective intelligente de long terme sur l’economie de l’entreprise, en exploitant les donnees mais sans etre aveugle aux effets de long terme qui ne peuvent etre compris, et je dirais estimes, que parce qu’ils ne peuvent jamais vraiment etre mesures. Encore une fois, nous n’allons pas mener des experiences sur une decennie. Il y a beaucoup de choses qui ne peuvent venir que d’une comprehension de haut niveau. Un exemple : dans le hard luxury, vous ne voulez jamais accorder de remise a aucun client. Si vous vendez une montre couteuse, vous voulez dire a votre client : ce n’est pas une depense, c’est un investissement, cette montre vaudra encore plus dans dix ans. Que ce soit vrai ou non est une autre question, mais si vous commencez a faire des remises, cela ne peut certainement plus etre vrai. C’est pourquoi beaucoup de choses doivent venir d’une comprehension de haut niveau, et vous n’allez pas faire des experiences sur vos clients pour evaluer cela.
Conor Doherty: Ah, donc tu…
Joannes Vermorel: Non.
Conor Doherty: Ah, parce que j’avais note horizons. Je veux parler de l’evaluation de l’impact de l’expert. Encore une fois, que ce soit un FDE ou un SCS, peu importe pour la discussion. Mais tu as mentionne un tres bon exemple, et cela m’a rappele une idee que j’ai entendue au bureau il y a quelques jours. Je ne dirai pas qui, mais cela concernait l’aeronautique, les bons de commande pour des moteurs.
Et tout l’enjeu avec ce client, c’est que par definition il s’agit d’un engagement pluriannuel. Je ne vais pas entrer dans les details, car cela pourrait etre public, mais disons qu’ils achetent dix moteurs. Et l’horizon temporel du projet sur lequel ils travaillent est d’environ cinq ans. Donc c’est dans cinq ans qu’ils sauront vraiment s’il etait judicieux, le 27 aout, d’acheter tous ces moteurs.
Si vous avez un FDE, cette personne sera partie depuis longtemps. Mais si vous travaillez encore avec Lokad, il y a au moins une continuite dans l’evaluation.
Joannes Vermorel: Oui, et cela va dans les deux sens. Mon point de vue est que les FDE devraient produire des gains de productivite qui peuvent etre evalues integralement le jour meme ou leur mission se termine.
Conor Doherty: D’accord.
Joannes Vermorel: Vous voyez, vous avez un processus qui devrait etre automatise. Vous passez potentiellement de 100 personnes a zero pour faire le travail, et peut-etre une personne pour superviser. C’est le livrable. Le FDE, encore une fois, comme nous ne sommes pas a la couche decisionnelle, il n’y a pas d’enjeu.
Vous automatisez completement les choses. Vous retirez les personnes, et c’est votre condition de victoire. Il n’y en a pas d’autre. C’est vraiment : puis-je faire en sorte que ce travail, qui etait fait par 100 personnes, soit fait essentiellement par zero personne, avec un peu de supervision IT pour s’assurer que tout continue a tourner correctement ? C’est tout. Un exemple chez Lokad : la traduction de notre site web dans de nombreuses langues est maintenant completement automatisee. La question est donc de surveiller l’automatisation, pas de jouer les traducteurs.
Conor Doherty: Nous avons de la decision pourtant.
Joannes Vermorel: Je comprends, c’est exactement ce que je dis : les FDE ne traiteront pas les decisions. Pensez a la traduction, c’est une bien meilleure tache. Oui, cela exige de l’intelligence. Oui, c’est le genre de chose que vous ne pouvez pas traduire avec un dispositif rudimentaire ; encore une fois, create, read, update, delete, votre base SQL ne peut pas faire de traduction. C’est cela que les FDE font bien. Vous prenez un processus tres bien defini. Vous savez ce que vous devez obtenir a la fin du pipeline, et ce que vous reingenieriez, c’est que vous retirez les personnes du chemin critique. Vous robotisez ce morceau.
Et la raison pour laquelle la mission peut se terminer, c’est qu’il n’y a pas de decision impliquee. Pas de vraie decision. Pas au sens ou je la definis dans ce livre, c’est-a-dire une allocation de ressources. Il n’y a pas d’allocation de ressources.
C’est simplement un processus ou quelque chose devait etre fait, et maintenant c’est fait sans surveillance, quasiment sans personne. Mais il n’y avait pas d’enjeu specifique. Cela devait etre fait, et maintenant c’est fait automatiquement tout en respectant votre objectif qualite. Et c’est tout.
Conor Doherty: En parlant d’objectifs qualite, le point suivant etait, et encore une fois je ne vais pas citer de noms, mais je recommande vivement a quiconque ecoute de chercher simplement “deployed engineers” avec le nom de votre ville et le mot jobs, vous verrez generalement de quoi je parle. Je donne donc une description representative des criteres d’evaluation d’un FDE selon beaucoup d’entreprises qui publient ces postes. C’est l’adoption des produits. Ce n’est evidemment pas trivial : si vous creez quelque chose et que litteralement personne ne l’utilise, c’est un probleme.
Ce pourrait etre le meilleur logiciel decisionnel du monde, si personne ne l’utilise, c’est un probleme. Nous comprenons tous cela. Mais est-ce suffisant en soi pour dire : c’etait une depense utile en argent, en temps, en effort et en opportunite ? Pour le fournisseur logiciel, l’adoption, au sens ou beaucoup de gens passent beaucoup de temps dessus, est super critique, car c’est ainsi que l’on cree de l’adherence.
Joannes Vermorel: Oui.
Conor Doherty: Mais pour l’entreprise cliente qui le recoit, c’est un piege massif.
Joannes Vermorel: Oui. Vous ne voulez pas quelque chose qui soit adopte. Vous voulez quelque chose qui tourne.
Conor Doherty: Explique cela, car je n’ai pas compris.
Joannes Vermorel: Quel est le taux d’adoption de votre filtre anti-spam ?
Conor Doherty: Ah, d’accord. Je vois.
Joannes Vermorel: Les gens ont-ils adopte l’anti-spam ? Non. L’anti-spam est la. Il fait son travail, et vous ne remarquez meme plus que vous avez un anti-spam.
Il est simplement la. Il fait le travail, et il le fait extremement bien. 99 % de vos emails poubelles sont filtres. Vous ne vous rendrez jamais compte qu’il etait la. C’est fait.
Voila a quoi ressemble l’automatisation. Oui, c’est cela, l’automatisation. C’est quelque chose qui se fond dans le decor, et c’est termine. C’est le probleme quand les gens parlent d’adoption de l’automatisation : de quoi parle-t-on ?
Y a-t-il vraiment un defi d’adoption pour l’anti-spam ? Historiquement, il y en avait un, car a la fin des annees 90, les filtres anti-spam etaient tres mauvais. Les gens devaient personnaliser les regles et faire beaucoup de choses pour que leur boite mail reste a peu pres saine. Mais aujourd’hui, c’est generalement excellent. Et les entreprises qui finissent signalees comme spam l’ont souvent cherche, simplement parce qu’elles ont envoye des millions d’emails, marques par des millions de personnes comme “ceci est un spam”. Maintenant, leurs emails ne passent plus.
Le probleme que j’ai, c’est que lorsque les gens pensent qu’une technologie reussie se mesure a l’adoption, ils adoptent en fait les metriques du fournisseur logiciel ou technologique. Et ce que je dis, c’est que dans le B2B, car nous parlons bien de B2B, vous ne voulez pas un logiciel qui occupe vos employes de nombreuses minutes par jour. Chaque minute passee par un employe a traiter avec un logiciel coute a votre entreprise. Vous voulez que la chose traite le probleme si completement que ces problemes deviennent invisibles. Cela devient le ronronnement de fond de votre entreprise, et plus personne n’y pense.
C’est simplement la. Cela fait le travail.
Conor Doherty: Mais pour atteindre ce stade, et je suis d’accord, j’aime l’analogie, on ne passe pas simplement de zero a un. Nous le savons, ce n’est pas zero a un ; il y a de l’automatisation.
Joannes Vermorel: Non. Pour l’automatisation, c’est toujours strictement zero a un. Je n’ai jamais vu autre chose. Pensez aux taches a faibles enjeux. Il y a quinze ans, j’ai vu des gens dans des compagnies d’assurance dont le travail consistait simplement a appuyer sur un bouton, confirmer que c’etait une carte d’identite, oui, non, appuyer sur un bouton, image suivante, confirmer que c’est une carte d’identite. Et ces gens, vous voyez, non, non, non. C’etait toujours zero a un.
Le probleme est qu’il y a une erreur complete dans l’idee de ramper, marcher, courir. Non. Pour l’automatisation, cela ne marche pas comme cela. Quand on parle de millions de dollars, par exemple, c’est pourquoi je dis que nous ne parlons pas de la meme chose. Lokad opere dans le domaine des decisions, des decisions financieres. Cela exige des decisions aux consequences financieres importantes. C’est la difference. Et nous parlons de decisions qui n’ont pas de plafond sur la qualite avec laquelle elles peuvent etre prises. Revenons a un logiciel qui classe simplement une image pour dire : est-ce une carte d’identite ?
Oui ou non ? Si vous avez quelque chose qui, apres evaluation, depasse deja largement la precision humaine, alors c’est termine. Il n’y a plus d’interet. Et imaginez qu’il n’y ait pas de manoeuvres adversariales, que les gens ne puissent pas tricher, et il y a beaucoup de situations comme cela, alors le probleme est resolu. Vous avez deja resolu le probleme completement, et il faut passer a autre chose.
C’est le type de problemes dont je parle. Une version IA serait : votre fournisseur vous envoie un PDF de facture, et vous voulez extraire le numero de facture dans la codification de votre fournisseur. Cela peut etre fait automatiquement. Une fois que vous avez cela, c’est fait.
Oui, vous pouvez avoir quelqu’un qui ouvre le PDF et fait un copier-coller. Mais si vous avez une automatisation qui le fait, c’est termine. Si l’evaluation montre que vous etes quasiment parfait, il n’y a aucun interet a une adoption graduelle. Cela n’a pas de sens. C’est pourquoi je dis que pour l’automatisation, c’est seulement zero ou un, jamais une adoption graduelle.
Conor Doherty: Si nous comparons des choses comparables, pour des entreprises qui fournissent ou vendent des FDE comme service pour construire le type de logiciel decisionnel que nous pourrions aussi construire, alors nous parlons de metriques d’evaluation differentes. Et pour toi, tu l’as mentionne plus tot, tu ne l’as pas dit explicitement mais tu l’as suggere : decisions financieres, impact financier. La ligne de partage, pour toi, la seule maniere d’evaluer un expert que vous faites venir pour prendre des decisions, prendre cet argent et acheter ceci, allouer ce stock la, planifier des gens pour faire ces choses, cela doit etre l’impact financier, ou au moins l’etoile polaire.
Joannes Vermorel: Oui. Je dirais economique. La distinction est que lorsque vous pensez en termes economiques, certaines choses n’apparaitront pas dans votre etat financier, notamment tous les effets de long terme.
Conor Doherty: Exact.
Joannes Vermorel: Comme le goodwill. Vous ne voulez pas antagoniser vos clients ni faire des choses qui detruiront vos couts directs et indirects.
Conor Doherty: Exactement.
Joannes Vermorel: Tous les couts indirects, toutes les choses pour lesquelles il faut penser long terme. Votre perspective economique est donc beaucoup plus prospective que la perspective financiere, qui tend a etre la version court terme de la perspective economique.
Conor Doherty: Pour ceux qui ecoutent, pourrais-tu developper un peu ce point sur le goodwill ? Cela peut ne pas etre immediatement clair, et comment deplier ce moteur economique ou cette perspective economique, car c’est un point tres interessant.
Joannes Vermorel: Par exemple, si vous laissez les gens acheter des produits sur un site e-commerce et que vous leur dites que l’article sera livre en moins de sept jours, mais qu’en fait, dans disons 30 % des cas, vous manquez votre cible. A court terme, si vous affichez une promesse de delai court, vous pouvez augmenter vos ventes. Mais si vous avez un pourcentage important d’echecs ou vous manquez les dates de livraison annoncees a vos propres clients, vous vous construisez une reputation terrible. Et vous perdrez des parts de marche avec le temps. Cela peut ne pas apparaitre immediatement, mais cela apparaitra.
C’est pourquoi, il y a quelques annees, ce n’est plus trop le cas maintenant, certaines plateformes e-commerce disaient “nous l’avons en stock” alors que ce n’etait pas vrai. Si vous affichez un article en ligne en disant “je l’ai en stock”, oui, vous doublerez probablement vos ventes par rapport au meme produit affiche avec “je ne l’ai pas en stock, mais je passerai commande quand vous commanderez”. Mais si vous n’etes pas honnete avec vos clients, vous ruinez votre reputation, et en quelques annees vous aurez perdu toutes vos parts de marche si vous jouez a ce jeu. C’est cela le goodwill dont je parle : toute la confiance que vos clients ont en vous pour continuer a faire affaire avec vous a l’avenir.
Conor Doherty: Oui, la perspective economique, et je prefere effectivement ce terme.
Joannes Vermorel: C’est correct.
Conor Doherty: C’est utile de nettoyer cela par rapport a perspective financiere. Mais faire comprendre cela aux gens est, je pense, une partie centrale de la perspective du SCS, ou du FDE, mais certainement pour nous de celle du SCS. Il s’agit de comprendre que, par exemple, les penalites de rupture, le cout de ne pas avoir quelque chose, n’apparaissent pas necessairement directement, mais existent evidemment. Si vous n’avez pas quelque chose, vous ne le vendez pas.
Joannes Vermorel: Et je dirais que si vous pensez en termes de FDE, des que vous dites que ces FDE ne sont pas la pour faire seulement de l’automatisation banale, mais pour toucher la couche decisionnelle, alors ma position est qu’il faut une verticalisation. Il faut des personnes expertes du domaine. Si vous traitez simplement de l’automatisation banale, tres bien : prenez des ingenieurs logiciels intelligents, ils peuvent etre FDE, ils regleront cela. Mais si vous voulez toucher la couche decisionnelle, alors vous ne pouvez pas avoir des personnes supposees universellement competentes sur tout. Cela ne marchera pas. Il faut une expertise verticale pour avoir cette comprehension economique correcte.
Conor Doherty: Mais est-ce que je ne peux pas simplement eliciter cela ? Par exemple, jour un, je suis un FDE, j’arrive. D’accord. De combien vos lead times varient-ils en moyenne ? Est-ce que je ne peux pas simplement obtenir cette information ? Pourquoi dois-je etre expert du domaine ? Pourquoi ne puis-je pas simplement etre techniquement brillant et poser des questions ?
Joannes Vermorel: Encore une fois, si nous supposons que vous etes Leonard de Vinci, un genie polymathe…
Conor Doherty: Oui.
Joannes Vermorel: D’accord. Mais si vous sortez tout juste de l’universite, ce n’est peut-etre pas le cas. Mon experience chez Lokad est que lorsque nous prenons des gens intelligents issus de tres bonnes ecoles, Ivy League ou equivalent, il leur faut environ deux ans pour etre capables d’avoir une evaluation de haut niveau correcte de ce qui se passe dans la supply chain d’une grande entreprise. Cultiver ce jugement prend du temps. Typiquement, notre objectif chez Lokad est qu’en six mois, a partir d’une personne tres intelligente, vous ayez quelqu’un capable de maintenir un compte. Beaucoup des decisions architecturales super critiques sur la conception de la recette numerique ont deja ete prises.
Donc maintenir un systeme peut etre atteint en six mois. Mais etre capable de prendre ces decisions correctement et avec sagesse, cela prend plutot deux ans, meme en partant de personnes tres intelligentes et avec un focus exclusif sur une verticale.
Conor Doherty: Oui. C’est vrai.
Joannes Vermorel: Le probleme, a mon avis, c’est que si vous avez des gens qui enchainent une mission apres l’autre, et que ce sont cense etre des missions court terme de quelques mois, il n’y a pas de magie. Ils ne pourront pas avoir cette perspective economique correctement formee. Donc, la plupart de ce qui sortira d’eux, s’ils commencent a travailler sur la couche decisionnelle, sera faux. C’est ainsi. Et chez Lokad, meme pour nous, les cinq premieres annees ont ete extremement difficiles. Les premieres annees de Lokad etaient atroces.
Je n’avais pas compris ce que je devais comprendre. A ma decharge, la quasi-totalite des livres sur la supply chain sont completement bidon, et le sont encore.
Conor Doherty: Je pense que nous avons deja couvert ce terrain.
Joannes Vermorel: Neanmoins, je me comportais effectivement exactement comme un FDE sans veritable expertise verticale, et oui, cela a cause beaucoup de douleur et de misere. Donc mon conseil est que si des entreprises prennent des FDE, assurez-vous qu’ils se concentrent sur l’automatisation stricte et absolue, ou le critere sera tres simple : le headcount. Et pour la couche decisionnelle, assurez-vous absolument d’avoir des personnes vraiment verticalisees. Quand on y pense, c’est du bon sens. Lokad traite des problemes de supply chain, mais imaginez que vous vouliez quelqu’un pour traiter de la fraude financiere dans le systeme bancaire. C’est un domaine incroyablement specialise. Je ne pretends pas savoir exactement comment operent les fraudeurs lorsqu’ils essaient litteralement d’escroquer des banques avec des montages transnationaux, de fausses identites, de faux papiers, etc. Ce n’est pas mon expertise. Si vous pensez pouvoir amener un ingenieur intelligent tout juste sorti d’ecole et traiter des problemes qui exigent une specialisation verticale tres approfondie, cela ne marchera pas. Ces personnes auront besoin de temps, potentiellement des annees, pour devenir vraiment expertes du domaine. Et cela sape la promesse du FDE : vous embauchez ces personnes, elles font leur mission de trois mois, bam, retour sur investissement, elles repartent chez elles, et vous avez un ROI rentable.
Conor Doherty: Pour ceux qui ecoutent, et cela s’appuie sur l’idee que vous avez les competences techniques mais pas encore l’expertise de domaine : comment savoir, et je te demande ton experience anecdotique, comment savoir si quelqu’un ferait un bon SCS ? Parce qu’il sort d’une grande ecole, il ne connait evidemment rien a la supply chain, ou tres probablement rien aux particularites et eccentricites.
Donc comment sais-tu, Joannes, que c’est un bon investissement, que cette personne a suffisamment de competences, etc. ?
Joannes Vermorel: Nous evaluons generalement la capacite brute a apprendre, c’est tout. Et je pense que la plupart des entreprises qui vendent des FDE font exactement la meme chose. Elles disent simplement : nous prenons des gens intelligents qui peuvent apprendre tres vite, et nous accumulons ce talent, et cela fonctionne. Ce que je dis, ce n’est pas que cela ne marche pas. Je dis que si vous voulez operer au niveau de l’automatisation, ce qu’il faut, c’est former les gens a l’art de faire du logiciel, et cela ira. Ce sera tres agnostique. Vous pouvez avoir une perspective completement horizontale : ils peuvent traiter n’importe quelle verticale, ce sera tres bien, si vous traitez seulement de l’automatisation stricte.
Si vous voulez traiter la couche decisionnelle, je dis que vous prenez des gens intelligents, puis il faut les former pour cette verticale. La question devient donc : vous achetez un FDE, un forward deployed engineer, pour votre verticale ; ce FDE a-t-il ete forme explicitement pour cette verticale, oui ou non ? Et si l’entreprise vous dit simplement : non, nous recrutons les meilleurs, faites-nous confiance, tout ira bien, cela n’ira pas.
Ce que je dis, c’est que si vous voulez quelqu’un qui traite une couche de prise de decision qui va trancher sur des situations avancees de fraude dans le systeme bancaire, il vaut mieux avoir quelqu’un qui comprend vraiment ce qui se passe dans le systeme bancaire. Si vous voulez quelqu’un qui va trancher pour un systeme avance de diagnostic medical impliquant la vie de patients, je veux que cette personne soit tres competente en sciences medicales, en plus d’etre ingenieur logiciel.
Quand on y pense, c’est vraiment evident.
Conor Doherty: D’accord. Oui. Oui. Je suis d’accord.
Joannes Vermorel: Mais pour revenir en arriere, prenons l’hopital pour contraster deux missions de FDE. La premiere, que j’ai vue, c’est que des personnes s’inscrivent plusieurs fois dans plusieurs services de l’hopital, et il faut donc reconcilier le fait qu’il s’agit en realite du meme patient.
Conor Doherty: Oui.
Joannes Vermorel: Sinon, vous vous retrouvez avec beaucoup de doublons, car beaucoup de gens s’enregistrent ici, puis la, et il y a des problemes. Il y a donc beaucoup d’enregistrements dupliques. Vous ne pourrez pas resoudre ce probleme de reconciliation des doublons avec un dispositif rudimentaire. Vous faites donc intervenir un FDE, et ces personnes automatisent la reconciliation de ces doublons.
Conor Doherty: Parfait.
Joannes Vermorel: Et vous voyez, c’est un probleme qui ne requiert pas une veritable expertise medicale. Cela se passe dans un hopital, mais au bout du compte, il s’agit de reconcilier des personnes identiques avec potentiellement des fautes dans le prenom, le nom, l’adresse, le numero de telephone, etc. Maintenant, si vous voulez quelque chose qui va trancher sur quoi que ce soit de medical, prendre une decision consequente pour la vie du patient et financierement pour l’hopital, alors vous voulez quelqu’un de bien verse dans les sciences medicales. La ligne n’est pas si subtile en pratique. Je pense que beaucoup d’entreprises confondent simplement l’automatisation intelligente et les decisions intelligentes. Les deux ont, en pratique, des ambiances et des exigences tres differentes.
Conor Doherty: En guise de conclusion, si je devais retenir au moins deux choses, dis-moi si tu es d’accord avec cette evaluation. Penses-tu qu’il est juste de dire, sur la base de ce dont nous avons discute aujourd’hui, et certainement avec l’emergence et la popularisation de ce role, que l’affirmation que nous entendons depuis quelques annees, voire plusieurs annees, selon laquelle si vous voulez optimiser votre prise de decision il suffit d’acheter un module additionnel, de le brancher, et c’est bon, est morte ? Es-tu d’accord ?
Joannes Vermorel: Oui. Oui.
Conor Doherty: Mais nous avons toujours pense cela. Est-ce que tu penses que cela ne marche jamais ? Est-ce que tu penses que le courant dominant dit maintenant tacitement : oui, oui, cela ne marche pas ? C’est ce que j’aurais du dire.
Joannes Vermorel: Je ne sais pas. Clairement, les vendeurs qui vendent des FDE disent cela.
Conor Doherty: Oui. C’est vrai.
Joannes Vermorel: Mais les autres vendeurs qui ne vendent pas de FDE continuent de dire le contraire. Je dirais que le temps le dira. Mais je vois encore que le marche est absolument rempli d’editeurs ERP qui vendent un module d’optimisation des stocks.
Il y a encore, disons, un millier d’entreprises qui font cela. Le temps le dira. Peut-etre, oui, avec le temps. Clairement, c’est une tendance interessante, mais je ne suis pas sur qu’elle soit encore dominante. Une partie du probleme est que les entreprises qui vendent des FDE sont aussi extremement cheres. C’est aussi l’une des faiblesses de ces entreprises tres visibles, comme OpenAI, Anthropic ou Amazon : ce sont des entreprises qui paient des salaires parfois un peu extravagants par rapport aux normes du marche. Par exemple, OpenAI a regulierement recrute des personnes avec des packages annuels de plusieurs millions de dollars.
Le probleme, ce n’est pas que j’estime que ces personnes ne les valent pas. Je dis simplement que si toute votre structure de couts, du point de vue du fournisseur, doit tenir compte de ce type de personnes…
Conor Doherty: Oui.
Joannes Vermorel: Votre prix pour facturer vos FDE sera probablement deraisonnablement eleve. C’est ce que je veux dire. Et si vous regardez l’histoire de Palantir, elle a ete faite d’allers-retours : ils progressent dans le domaine, puis ils progressent enormement, puis ils reduisent la voilure, simplement parce qu’ils sont tres chers et que beaucoup de clients, apres l’enthousiasme initial, disent : c’est trop cher, il faut reduire.
Conor Doherty: Pour demeler un peu cette idee, si je t’ai bien compris, tu es essentiellement d’accord avec moi sur le point suivant : pour bien faire les choses, quoi que ce soit, pour bien faire un projet IA, cela peut etre prohibitif. Et en consequence, il y aura toujours des gens, des vendeurs qui vendent, je ne vais pas dire de l’huile de serpent, mais qui disent : oui, achetez ce module, il optimisera tout. Et c’est une alternative moins chere. Imparfaite, mais moins chere que d’acheter un FDE.
Donc je pense qu’il n’y a pas vraiment de contradiction dans ces termes. Cela peut continuer a exister comme produit, meme si l’existence d’un FDE sape un peu l’idee d’un module d’optimisation. C’est un peu philosophique, mais je pense que c’est le point auquel nous arrivions.
Joannes Vermorel: Oui. Oui. Exactement.
Conor Doherty: Joannes, j’ai beaucoup apprecie, mais je n’ai plus de questions. Merci beaucoup pour ton temps. Et pour ceux qui ecoutent, je dois signaler qu’il y a des postes de Supply Chain Scientist ouverts chez Lokad. Donc si cela vous interesse, consultez notre LinkedIn ou envoyez-nous un email a contact@lokad.com.
Et cela etant dit, il n’y a rien d’autre a dire sinon : retournez au travail.
