#38 Stanislas Polu (Co-fondateur @ Dust) : Assistant personnel basé sur l’Intelligence Artificielle

Ce qui m'a le plus impressionné, je pense que c'est le moment où moi j'y étais, c'était la densité de talent. Tout le monde dit ça de toutes les boîtes, bla bla bla. Moi j'étais chez Stripe, de 80 employés à 3000 employés. Chez Stripe, la densité de talent était forte au début, mais là OpenAI, c'est un notch au-dessus. Chaque discussion est presque intimidante. Tu as certains moments des expériences où tu te dis Lui, il marche pas pareil que moi. Je suis open head, il y avait une intensité forte de ces expériences.

Bonjour et bienvenue sur Data Driven 101, le podcast qui s'intéresse aux applications concrètes et variées de l'intelligence artificielle et de la data. Je suis Marc Sancelme, spécialiste en IA, et je reçois chaque semaine des professionnels pour nous partager leurs expériences et leur vision sans filtre. Aujourd'hui, je reçois Stanislas Polu, cofondateur de Dust. Après avoir revendu sa start-up à Stripe puis travaillé un temps là-bas, il passe 3 ans chez OpenAI puis fonde Dust. Dust est une plateforme qui aide les entreprises à déployer des assistants d'intelligence artificielle auprès de leurs équipes. Bonjour Stanislas.

Bonjour Marc.

Alors, est-ce que tu peux nous parler un petit peu de Dust? Qu'est-ce que fait cette entreprise exactement?

Oui, bien sûr. On s'intéresse beaucoup au layer produit entre les modèles et les équipes qui vont vouloir gagner en productivité. Donc on a une plateforme qui permet aux entreprises de connecter leurs sources de données DUST, d'accéder aux meilleurs modèles OpenAI, Claude, Anthropic et d'autres modèles, et de créer des assistants spécialisés sur des tâches données qui se basent avec du retrieval sur la donnée de l'entreprise. Ce qu'on a découvert et qui est intéressant, c'est que Même si toutes les entreprises sont des early adopteurs aujourd'hui, tout le monde veut augmenter ses employés avec de l'IA. Quand on rentre dans une entreprise, on se retrouve face à une courbe d'adoption typique. C'est-à-dire qu'il va y avoir des early adopteurs de la technologie qui utilisent déjà ChatGPT toute la journée, mais aussi une grosse partie des employés qui comprennent mal ou n'ont pas encore envie d'utiliser cette technologie. Donc il y a un beau défi produit autour du fait de réussir à déployer ces assistants malgré cette courbe d'adoption de manière efficace sur l'entreprise. Donc c'est un peu notre, d'accord, la chose sur laquelle on s'est attaqué aujourd'hui.

OK. Est-ce qu'une façon de le dire, ce serait que vous faites des sortes de ChatGPT personnalisé sur une certaine base de connaissances d'une entreprise?

Alors en fait, c'est pas vraiment des ChatGPT, c'est évidemment une interface conversationnelle, mais on crée des assistants personnalisés à qui les employés vont pouvoir parler. Mais ces assistants personnalisés vont être spécialisé sur une tâche donnée. Pour donner des exemples, par exemple pour du customer support en général, pour le dernier tiers de customer support en général, avant de se retourner vers l'intérieur de la boîte et aller interrompre un ingénieur, on peut parler à un assistant qui a accès à des sources de données très propres, qui a été prompté, qui a des instructions pour répondre d'une certaine manière qui convient bien à la tâche. Un autre exemple, ça pourrait être on a un assistant qu'on appelle en interne SQL God. En gros, c'est un assistant qui est très facile à reproduire chez nos clients, on met des tables des bases de données des clients, une traduction business-technique parce que le nom des tables n'est pas forcément aligné avec les termes business qui sont utilisés dans les équipes. Et derrière, on lui pose une question et il génère une query SQL à copier dans Metabase ou Redshift. D'accord. Et ça, ça apparaît plus comme un outil qu'un agent conversationnel complètement généraliste qui est dur à appréhender. Là, comme ça a une affordance plus forte, Des gens qui sont pas forcément early adopteurs de cette technologie vont comprendre très vite comment ça marche et après se rendre compte «Ah mais il y a d'autres assistants, ah mais je peux demander à l'un puis à l'autre ou je peux demander à deux en même temps». Donc en fait notre produit, c'est vraiment une interface conversationnelle où plusieurs humains interagissent avec plusieurs assistants. D'accord.

Et donc vous développez un assistant par use case auquel vous pensez ou est-ce que vous faites du sur-mesure un peu?

Alors aujourd'hui, la plateforme est complètement agnostique et générale et donc on a un positionnement assez horizontal, ce qui vient avec certains risques parce qu'il y a le risque de la perte page blanche d'une certaine manière. Pour chaque assistant, il y a en général besoin d'un peu d'instructions ou d'informations spécifiques à l'entreprise, même si on a accès au Slack, au Notion, au Google Drive de l'entreprise et on va dire tiens, pour l'assistant customer support, je vais prendre ces 5 pages Notion et ces 3 pages sur GitHub. Il faut quand même donner à l'assistant du contexte qui est basé sur l'entreprise et donc aujourd'hui ça, c'est quelque chose que nos clients vont faire par eux-mêmes et on les accompagne. Mais à terme, ça se productivise assez bien parce que ça pourrait être un flow où on dit vous voulez faire un assistant pour la data analysis, puis là, on vous pose quelques questions et l'assistant se fait créer à la suite de ce flow de création. Mais aujourd'hui, c'est complètement customisable. Le produit n'est pas customisé par entreprise, mais la création des assistants est customisée pour chaque client et donc on les aide à faire ça de manière efficace. On leur donne des récipes et des choses comme ça.

D'accord. Alors avant de rentrer dans le détail, est-ce que tu peux nous faire l'état des lieux du besoin business tel que tu le perçois?

Le besoin business, il est assez simple, c'est que tout le monde parle d'IA aujourd'hui. Il y a des gains de productivité potentiel énorme sur les développeurs où les produits ont déjà pas mal pénétré la communauté des développeurs avec Copilot. C'est très dur d'argumenter contre le fait que Copilot fait gagner 10-20 du temps d'un développeur. C'est énorme. Et donc on peut espérer faire gagner le même temps à tous les autres employés de diverses manières. Et donc le besoin business, il est très clair, c'est dans une entreprise, le management, même le board dit il faut déployer de l'IA. Déployer de l'IA, c'est pas trivial parce que si on met juste ChatGPT, une grosse partie des employés ne vont pas l'utiliser, ne vont pas comprendre exactement comment on s'y répartit. Donc ce besoin business, c'est vraiment ce besoin de faire un pari sur l'IA et d'avoir une plateforme pour faire ce pari qui va être suffisamment générale et customisable pour tous les besoins d'une entreprise.

Tu parlais de Notion et de Slack. Quelles sont les sources de données que vous traitez?

Alors aujourd'hui, on a 4 data sources managées, donc c'est-à-dire qu'elles se connectent en un clic. Donc c'est Notion, GitHub, Slack et Google Drive. Donc c'est une stack qui est plutôt la stack des entreprises tech de moins de 10 ans. Donc c'est volontaire puisque c'est les clients qu'on cible aujourd'hui, c'est ce genre d'entreprise, moins de 1000 personnes ou autour de 1000 personnes. Au-dessus, ça commence à devenir un peu compliqué et tout ce qui est en dessous. Après, on peut, certains de nos clients connectent la donnée par eux-mêmes parce qu'on a ce concept de source de données, de data source. Il peut être nourri par API et donc on a certains clients qui ont connecté par eux-mêmes à Salesforce, connecté par eux-mêmes à Intercom, etc. Mais les 4 qu'on supporte de manière automatique sont ceux-là et on va évidemment l'étendre à terme. Mais aujourd'hui, on considère que ça couvre pas mal de territoire pour le type de clients avec qui on a envie de travailler.

D'accord, donc à partir de tout l'historique des conversations Slack, de l'historique de toutes les documentations qui ont pu être faites et peut-être oubliées Notion, on va être capable de retrouver, quand on se pose une question, on va être capable de retrouver éventuellement la bonne réponse quelque part. Et pour comprendre un peu la façon dont c'est cloisonné, j'imagine une conversation, ça peut être plus ou moins privé, accessible à certaines personnes, il y a un niveau de confidentialité. Comment est-ce qu'on gère cet aspect-là?

Ouais, c'est une super question. Alors il y a deux questions dans la question. Il y a un usage qui est général. En fait, on a commencé par ça, par un assistant généralisé qui avait accès à toute la donnée de l'entreprise. Et lui, il est très bien pour ce use case un peu de search. Voilà, j'ai une question, je sais pas sais pas où est la doc, je sais pas si elle existe, je vais poser la question et l'assistant va répondre avec des citations des données qu'il a utilisées. Et ça, c'est un use case intéressant pour, voilà, je sais pas où est la doc d'information et je vais juste essayer de faire en fait une recherche. Mais ce qu'on s'est rendu compte, c'est que pour des cas d'utilisation précis, avoir un assistant qui a accès à toute la donnée de l'entreprise, c'est pas forcément bon. Pourquoi? Parce que la recherche sémantique qu'on utilise pour retrouver la documentation, n'est pas parfaite et que les modèles ne sont pas parfaits. Et donc si on a accès à toute l'information de la boîte, le retrieval va être un peu noisy et donc les modèles, même les meilleurs, vont s'emmêler un peu les pattes quand on a besoin d'une réponse très précise à un use case très précis. Donc c'est pour ça qu'on est passé à ce modèle où on a toujours cet assistant généralisé. Quand on connecte Dust à son entreprise, il y a un assistant Dust qui sait tout en gros. On peut lui demander le code de la porte, qui sont les enfants du président et aussi qu'est-ce qu'on a fait sur ce projet. Cette dernière année. Mais après, on a vu le besoin auprès de nos clients de créer des assistants custom parce qu'on obtient des bien meilleurs résultats en limitant l'information disponible à l'assistant pour certains use cases et en l'instruisant plus particulièrement. En termes d'accès à l'information, Slack et Notion, c'est un peu des plateformes où il n'y a pas tant de cloisonnement que ça. C'est-à-dire qu'un Notion, il y a un team space, le team space, il est accessible à un groupe de personnes, il n'y a pas trop de permissions granulaires à l'intérieur de ce team space. Team space. Slack, c'est pareil, il y a des channels publics et des channels privés. En général, quand Slack est déployé dans une boîte, il y a tout un jeu de channels publics qui sont accessibles à tous les employés de la boîte. Donc là, il n'y a pas tant de défi de granularité de permission. C'est, on accède aux choses publiques à l'intérieur de la boîte, on accède aux choses publiques à l'intérieur du Notion, et tout le monde à l'intérieur de la boîte, de l'entreprise ou de l'équipe, a accès à toute cette information-là. Pour Google Drive, c'est un peu plus, c'est plus complexes en général parce que les permissions de Google Drive sont beaucoup plus granulaires. Et donc aujourd'hui, c'est un travail très compliqué parce que si un assistant crée une réponse sur la base des autorisations d'un utilisateur qui lui a posé la question, mais qu'ensuite cet utilisateur partage la conversation avec un autre utilisateur, ça serait très compliqué de modéliser le fait qu'il y a un leak des permissions à travers la réponse de l'assistant parce qu'il a accédé à la donnée et a fait une réponse sur cette base-là. Donc on prend le parti aujourd'hui de travailler par silos, en gros. Au sein d'une équipe, on peut avoir plusieurs silos d'informations qui sont associés à plusieurs groupes d'employés, mais au sein d'un silo, tout le monde a accès à tout. Mais c'est un peu la direction des entreprises modernes. Plus simple à gérer. Même Stripe a lancé pas mal cette mode de la transparence en interne. Et quand on voit, il y a plein de sociétés récentes, les startups récentes, il y en a très peu qui ont du cloisonnement réel à l'intérieur de leur système d'information.

Cette recherche, ces assistants, est-ce que vous les fine-tunez à partir de modèles préexistants ou est-ce que vous utilisez vraiment des modèles tels que créés par certaines sociétés et vous leur mettez à disposition des bases de connaissances via des Vector Search, etc.?

Alors on fait du RAG, donc Retrieval Augmented Generation, donc c'est recherche, on va chercher des chunks d'information, on les met dans le contexte du modèle. Les contextes grossissent de plus en plus, donc on a de plus en plus de place pour mettre ce retrieval. Après, plus on en met, plus la tâche est difficile pour le modèle de retrouver la bonne information au sein de son contexte. Voilà, on fait du RAG, on fait pas de fine-tuning et pour plein de raisons. La première, c'est si quelqu'un fine-tune un modèle sur sa donnée d'entreprise. En gros, le modèle a été pré-entraîné sur Internet, il a un knowledge graph induit par son pre-training et si on le fine-tune sur la donnée d'entreprise, on va En fait, le signal qu'on lui envoie, la tâche qu'on lui demande, c'est à partir de ton knowledge graph qui n'inclut pas la donnée d'entreprise, génère de la donnée d'entreprise. Donc on lui apprend à halluciner en fait. Parce que la prochaine question, la n+1e question, son entraînement, c'était de dire sur la base de ce que j'ai appris sur internet, j'essaie de répondre sur l'entreprise X. Si on lui pose une autre question, il va essayer de répondre sur l'entreprise X et il va avoir un incentive par ce fine-tuning à inventer une réponse sur l'entreprise X. D'accord.

Je sais pas si j'ai saisi l'incentive. Pourquoi il vient du fine-tuning?

Parce qu'en fait, le fine-tuning, comme c'est une étape, une surcouche sur le pre-training qui est beaucoup plus long, en fait, il n'y a en général pas assez de données dans le dataset de fine-tuning pour faire changer vraiment la connaissance du modèle. Donc en fait, on modifie ses poids un peu de manière superficielle pour essayer de le pousser à générer de la donnée à propos d'X, mais de la donnée qu'il n'a jamais vue sur Internet. Et donc son incentive, c'est d'inventer de la donnée de l'X, dite de sur X, sans l'avoir eu durant son pre-training. D'accord. Donc il y a vraiment des gros risques d'hallucinations.

D'accord.

Nous, dans notre cas, sur du RAG en entreprise pour la productivité, la différence entre GPT-3.5 Turbo et GPT-4, c'est un produit qui n'est utilisable et un produit qui fait gagner 20 de temps à certains employés. GPT-3.5, par exemple, qui est un très beau modèle, qui marche très bien, c'est ce qui a fait exploser ChatGPT, est inutilisable dans ce use case. Il hallucine, il est trop petit, il comprend rien et il se trompe. Etc. Donc on est très loin d'être dans un monde où les modèles même open source qui sont plutôt de la taille en général d'un GPT-3.5 Turbo, ces modèles open source sont pas au niveau pour le use case qu'on a. Donc on utilise GPT-4 et Claude 2 est pas mal aussi. C'est vraiment les modèles qui permettent d'avoir une expérience produit intéressante et ces modèles-là sont énormes. Et donc fine-tuner un modèle comme ça, c'est pas disponible publiquement, mais on pourrait imaginer OpenAI puisse le fournir par API. Mais la donnée nécessaire pour faire un bon fine-tuning des modèles comme ça, elle est incommensurable. La donnée d'une boîte, c'est une goutte d'eau. Donc le fine-tuning, c'est un peu tricky. Tout le monde a envie de fine-tuner ses modèles sur sa boîte, mais c'est pas forcément la bonne solution. Ce qu'il faut, c'est montrer la bonne information au modèle et le prompter de telle sorte à ce qu'il puisse répondre. On s'est donné comme mantra «pas de GPU avant le PMF». PMF, Product Market Fit. OK. Moi, j'ai fait de la recherche chez OpenAI pendant 3 ans et moi, je pense sincèrement que c'est une mauvaise idée de faire de la recherche parce que fine-tuner des modèles, c'est de la recherche. Ça reste un processus compliqué, très itératif, empirique, etc. Je pense que c'est une perte de temps pour une société qui n'a pas encore un produit avec un fit réel. À terme, on réouvrira cette opportunité. On fine-tunera pas sur la donnée des boîtes. Par contre, ce qui serait possible, c'est peut-être de fine-tuner des modèles à être meilleurs pour le use case qu'on utilise. Donc nous, on est énormément dans un use case de, comme je disais, de RAG, donc de Retrieval Augmented Generation. Et donc on pourrait très bien imaginer une loop de RLHF, donc d'alignement final du modèle. Et donc en général, le modèle, il est pré-entraîné, ensuite il est aligné avec du reinforcement learning from human feedback. Ce reinforcement learning from human feedback, il est fait par les laboratoires tels qu'OpenAI ou Anthropic. Il est fait de manière généraliste, il faut qu'il soit bon à résumer, il faut qu'il soit bon à traduire, il faut qu'il soit bon à faire un peu de maths, soit bon, être gentil, etc. On pourrait refaire cette loupe finale spécialisée pour nos use case produits pour que le modèle soit mieux aligné avec le produit. Ce serait pas un fine-tuning sur la donnée de la boîte, ce serait un réalignement du modèle sur des tâches précises pour qu'il soit meilleur à ces tâches-là, qu'il soit plus factuel, qu'il hallucine moins, qu'il ait peut-être moins de hedging. Le hedging, c'est ce qu'on ressent tous quand on utilise ChatGPT. Il dit ah, c'est une bonne question, il y a plusieurs manières d'y penser, peut-être celle-ci, peut-être celle-là et je ne veux pas trop me mouiller, mais je donne un peu tous les trucs. Donc dans un cadre de productivité, ce hedging, il est plutôt contre-productif quand on veut une réponse, on veut la réponse et on veut avancer. Donc on pourrait très bien imaginer dans le futur, une fois qu'on a un bon product-market fit, rouvrir une boîte recherche ou R&D on va dire, autour des modèles. En supposant que des modèles open source à ce moment-là seront au niveau pour être utilisables dans un produit comme le nôtre, on pourrait faire cet alignement final nous-mêmes. Mais ça ne sera pas un fine-tuning sur la donnée de la boîte et je pense que c'est une mauvaise idée de fine-tuner sur la donnée de la boîte.

Du coup, vous faites de la génération augmentée par donc de la recherche sur une base de connaissances. Ça demande de découper en petits morceaux et donc d'encoder les petits morceaux de texte, de connaissances, etc., par leur sens. Donc après, on se retrouve dans un espace où la distance entre deux points correspond à quel point elles sont proches au niveau du sens. Comment est-ce qu'on découpe proprement, efficacement du texte qui peut gagner à être mieux découpé? Qu'est-ce que tu peux nous dire comme truc et astuce?

Alors, je vais me permettre de redonner un peu de contexte. Donc un modèle a une taille de contexte, donc c'est une fenêtre de contexte qui est limitée. Il ne peut pas générer tout en étant capable de lire pendant qu'il génère au-delà d'un certain nombre de tokens. Et un token, il faut voir ça un peu comme un mot. Donc au-delà de quelques milliers de mots, il ne va pas voir ce qu'il y avait avant. Donc c'est un peu comme une fenêtre glissante de génération. Donc quand on veut répondre à une question et donc faire de la génération augmentée par cette recherche, on est limité dans le nombre de résultats qu'on peut lui mettre. Idéalement, on voudrait un modèle qui pourrait tout lire et répondre sur la base de tout en même temps. Ça, ça serait le cas idéal. Mais cette limite de fenêtre, qui est une limite algorithmique, parce que ça coûterait trop cher en compute d'avoir des fenêtres trop grandes, nous force à mettre des petits morceaux d'informations à l'intérieur du contexte. Donc c'est pour ça qu'on découpe en effet les documents en chunks, on appelle ça des chunks, et qu'on les embed Et donc, embedder, c'est utiliser un autre modèle qui va aller de ce petit morceau d'information vers un vecteur de dimension assez grande, en général plusieurs milliers de floats par vecteur. Et donc ça, ça permet en effet de faire cette recherche sémantique où, étant donné une question, on embedde la question, on la vectorise, et on cherche les morceaux d'information dont les vecteurs sont les plus proches ou les plus alignés, dont le scalaire est le plus grand, quoi. Et on utilise cette recherche sémantique avec les modèles en général parce que c'est à la mode, mais on pourrait faire de la recherche par keywords aussi et prendre les morceaux de texte autour des endroits où on a matché les keywords. Ça serait quelque chose qui est tout à fait imaginable. Et je pense que la meilleure solution, beaucoup de gens font de la recherche sémantique, mais la meilleure solution c'est de la recherche hybride au sens où il y aurait de la recherche sémantique et de la recherche par keywords pour essayer d'avoir un peu le meilleur des deux mondes. Nous aujourd'hui on fait que de la recherche sémantique, mais c'est un des projets qu'on a de faire de la recherche hybride aussi. Donc maintenant on arrive à ces morceaux d'information. En effet, il faut quand on a un document, on peut pas mettre tout le document dans le contexte, donc on est obligé de le couper en petits morceaux. Et c'est ces petits morceaux qui vont être retrouvés indépendamment. Et donc il y a un problème de comment on coupe le document. Ça dépend de la source des documents. En général, ce qu'il faut faire, donc il faut pas prendre des chunks trop gros parce qu'on a envie de, étant donné la taille de contexte limitée, on a quand même envie d'avoir plusieurs, un certain nombre de chunks. Donc on est limité par la taille du chunk. Donc ça va être entre 256 et 512 tokens, ça va être un peu l'endroit où c'est un peu la bonne taille pour la technologie actuelle. Donc ça veut dire entre 200 et 500 mots, c'est pas tant que ça, c'est un paragraphe, un gros paragraphe ou deux. Et donc ça pose évidemment la question de comment le découper. En fait, c'est un processus assez itératif pour nous sur une page. En général, ce qu'on veut faire, c'est au lieu de fixer la taille du chunk à par exemple 256 tokens, il faut plutôt s'autoriser une fenêtre de taille, on va dire entre 256 et 512, ce qui permet de couper à des endroits un peu plus flexibles. Et donc sur un doc Notion qui est en gros du Markdown, il faut essayer de couper autour des paragraphes, autour des titres pour que le morceau d'information semble, soit à peu près cohérent. Évidemment, si au-dessous d'un titre il y a 10 paragraphes et que c'est très long, il y aura irrémédiablement plusieurs chunks. Mais après, ce qui est possible de faire, c'est de répéter les titres dans les différents chunks. Par exemple, si le titre s'appelle Projet Alpha et qui a 10 paragraphes, on peut faire Projet Alpha les 3 premiers paragraphes, Projet Alpha continued les 3 premiers paragraphes. Et donc au moins le modèle aura un peu un contexte du titre tout en comprenant et en contexte que c'est un extrait et qu'il y a quelque chose avant.

D'accord.

Donc il y a plein de techniques qu'on peut utiliser comme ça en fonction des types de documents. Sur Slack, c'est naturel, la thread, tout le monde utilise, enfin de plus en plus les gens utilisent des threads. Voilà, donc c'est une unité assez bien. C'est rare d'avoir des threads qui soient, enfin si, ça existe souvent, mais il y a des threads qui prennent plusieurs chunks, mais ça, ça marche assez bien parce que comme c'est une continuité temporelle, dans Slack, ça se prête bien au découpage. Je pense que les techniques, c'est plutôt sur les documents structurés, c'est de suivre la structure du document, et donc pour le faire le mieux possible, il faut s'allouer la capacité d'avoir une fenêtre de taille permise.

D'accord. Mais on rentre pas plus dans le détail du sens lui-même, on n'utiliserait pas un modèle pour découper en chunks, par exemple?

La réalité, c'est que quand on, la structure, un document est structuré déjà autour du sens. Donc ça serait très bizarre que quelqu'un écrive un paragraphe à propos de A et saute du coq à l'âne à un paragraphe autour de B. Donc là, la localité dans le document donne cette structure et donc c'est assez naturel de découper autour de ça. Et après, quand on réunit les chunks et qu'on le donne en prompt, donc est-ce qu'on n'a pas un risque que ça passe un peu du coq à l'âne et qu'il y ait un peu une perte de Ouais, mais là il faut prompter le modèle pour lui faire comprendre qu'il y a eu un retrieval qui s'est fait, qu'il voit des informations parcellaires, son but est de faire la meilleure réponse possible basée sur ces informations-là. On pourrait imaginer plein de choses différentes. Il y a un trade-off entre instantanéité et qualité de la réponse. On pourrait très bien faire une première passe de retrieval, avoir le modèle qui passe dessus et qui dit ah bah je veux plus d'informations de ce document, je veux avoir ce qui vient avant et ce qui vient après Et pourrait décider de creuser, d'aller lire, peut-être décider d'aller lire le document en entier, en faire un extrait qui va être utile pour la réponse. Il y a plein de choses qui sont possibles de faire. Maintenant, c'est quand même agréable d'avoir une réponse quasi instantanée. Donc ça, ça permet pas de faire ce travail. Et donc c'est des questions à un produit hyper intéressantes. Comment est-ce qu'on crée des interactions qui sont parfois instantanées, qui vont moins creuser, et parfois créer un produit qui permet d'avoir une interaction moins instantanée et qui va donner la possibilité de creuser plus dans l'information et d'avoir des réponses plus précises.

Tu nous as parlé de l'ultra-domination de GPT-4 et Claude 2 sur les autres modèles pour la partie générative. Est-ce que pour l'embedding, tu constates quelque chose de similaire?

Il y a beaucoup plus de modèles d'embedding, mais la réalité, c'est que le modèle d'OpenAI, qui je me souviens plus comment s'appelle, Ada-2 quelque chose, est quand même pas mal. Quand on parle un peu aux gens, tout le monde dit bon bah c'est en gros, il y a peut-être un meilleur, quelque chose d'autre, modèles qui sont au niveau, mais C'est parmi les meilleurs. Et il faut dire qu'OpenAI, ils le vendent, j'en sais rien s'ils le vendent à perte ou pas, mais ça coûte rien. Nous, on embête des millions et des millions et des millions de tokens par jour et ça nous coûte rien.

Rien à voir avec GPT-4.

GPT-4 coûte assez cher. Surtout, nous, on utilise GPT-4 avec 32K de contexte qui coûte encore plus cher. Notre facture OpenAI, c'est 99,5%. GPT-4 32K et un demi-pourcent en billing. Alors qu'on en met beaucoup plus qu'on ne génère, mais beaucoup, beaucoup, beaucoup, beaucoup plus.

Mais alors justement sur les 32K, donc vous choisissez d'utiliser un modèle qui a donc ses 32 000 tokens de capacité maximum. Par rapport à ce que tu disais juste avant, si on donne trop d'informations, il a plus de mal à retrouver, etc. Dans le trade-off, vous avez quand même constaté que c'était plus efficace de donner beaucoup de chunks et de remplir les 32K de contexte pour avoir la réponse plutôt que de rester sur un modèle 4K.

Alors on le remplit pas pour un retrieval donné, ça nous permet d'en mettre plus que le modèle 8K, 8K on est un peu serré quand même, on en met plus que ce qu'on pourrait faire avec 8K, on va pas chercher les 32 000 tokens, il y a en effet une espèce de trade-off où quand on en met trop, ça peut être un peu trop noisy, mais c'est bien d'en avoir quand même beaucoup parce que ça permet d'avoir un un filet qui couvre plus de territoire quoi. Par contre, le tronquet est aussi utile pour la continuité de la conversation. Ça nous permet d'avoir un modèle qui arrive à être cohérent avec ce qui s'est passé plusieurs retributs avant et ce que l'utilisateur a demandé au tout début de la conversation. Et ça, ça a une valeur infinie. Évidemment, les modèles coûtent cher, mais les gains de productivité sont immenses. Et on réfléchit pas trop en termes de coûts Les coûts aujourd'hui, parce que le défi c'est de trouver un produit qui accroche et qui crée de la valeur, et les coûts vont fatalement descendre. Les labos se font la guerre, ils veulent tous capturer un maximum de parts de marché. La recherche donne des gains d'efficacité en inférence. Les coûts historiquement n'ont fait que baisser. Je crois qu'entre le—

C'est quand même difficile de cerner OpenAI, à quel point ils peuvent vendre à perte comme tu disais. Certaines choses parce que j'ai un peu l'impression, j'en sais rien, spéculatif, mais d'une stratégie de «on tue le marché» avec des coûts qui sont vraiment quand même pas très gros, quand même mine de rien, ça coûte pas très cher d'utiliser leur service.

Alors ChatGPT coûte lui aussi pas cher du tout. ChatGPT est probablement à perte sur plein d'utilisateurs parce que ça va vite, 30 si on prend les coûts de l'API pour les mêmes modèles avec GPT-4, ça va assez vite OpenAI veut tuer le marché, ça se voit, c'est clair, il n'y a aucune question. Au-delà de ça, ils font énormément, on a fait parce que j'y étais, énormément de recherches sur l'optimisation de l'inférence. Donc il y a des années de R&D sur le fait de faire une inférence rapide et peu chère. Et donc même s'ils ne vendent pas à perte, c'est très très dur de servir un modèle moins cher qu'OpenAI je pense. Parce qu'ils sont at scale avec des années de R&D. Donc même si on prend, et je parle même pas de prendre GPT-4, même servir Llama, disons 65 bi, le servir au prix d'OpenAI, c'est même pour un modèle qui est beaucoup plus petit, c'est un défi. Après, donc il y a évidemment le risque qu'ils inondent le marché, le capturent, tuent la concurrence et après remontent les prix. Vu l'importance de la technologie, ça paraît difficile d'imaginer un avenir dans lequel il n'y a qu'un seul acteur. Et à partir du moment où il y aura plusieurs, il y aura une course au prix le plus bas, je pense.

Ça nous amène un peu à une question que je voulais poser qui était quelles sont les barrières à l'entrée finalement? Quelles sont les barrières à l'entrée de ce genre de modèles?

Alors, pour des sociétés comme les laboratoires comme OpenAI ou pour des sociétés comme nous?

Justement, j'aimerais bien poser les deux questions.

Les barrières à l'entrée pour un projet comme le nôtre sont évidemment pas énorme puisque nous on a fait le choix de se placer au niveau produit. Donc c'est l'histoire des meilleures boîtes de la tech. C'est pas tant la meilleure défensibilité de la plupart des boîtes tech des 20 dernières années, c'est pas tant des barrières à l'entrée forcément très précises, c'est d'être meilleur, meilleur produit, plus rapide et un go-to-market qui fonctionne. Moi je réfléchis pas trop en termes de barrières à l'entrée. On a de la concurrence, on a des centaines de boîtes qui font comme nous. Après, le marché est immense puisque tout le monde parle d'IA, tout le monde veut de l'IA, tout le monde veut trouver une solution AI pour sa société. Donc le marché est aussi immense. Maintenant, comme je l'expliquais tout à l'heure, nous, je pense qu'on a un produit qu'on— c'est assez intéressant parce que c'est auprès de nos utilisateurs qu'on a découvert qu'il fallait des assistants personnalisés pour que les gens vraiment accrochent et sachent les utiliser et vraiment en tirent de la productivité. Et donc ça, c'est une découverte qu'on a faite en se frottant au marché d'une certaine manière. Et c'est en même temps une barrière à l'entrée pour nous puisqu'à partir du moment où quelqu'un nous utilise et commence à créer 10, 20, 50, 100, on a des clients qui ont 100 assistants custom au sein de leur boîte. C'est de la valeur qui va être, enfin, nous quitter, c'est devoir recréer tout ça sur une autre plateforme.

Il y a un lock-in qui s'installe.

Donc il y a un lock-in assez naturel qui s'installe, qui n'est pas nécessairement voulu, mais qui est de facto de la nature du produit et de comment la valeur arrive à se créer.

Et qui est rare avec du SaaS d'habitude.

C'est pareil quand on est chez Stripe, on a toute sa stack de paiement, tout l'historique de customers, c'est dur à switcher. C'est vrai un peu partout. Donc des barrières à l'entrée, je pense que le côté wrapper de GPT-4, tout ce mème autour des wrappers GPT-4, en fait quand on veut vraiment résoudre un vrai problème produit, c'est plus qu'un wrapper, c'est un wrapper, c'est une plateforme, c'est la création d'expériences personnalisées au sein des boîtes et pour chacun des employés. Et donc c'est des choses qui sont naturellement, qui ont une valeur intrinsèque. Barrière à l'entrée pour OpenAI, il faut trouver 20 milliards. Quelle est assez forte. On a nos amis de Mistral en France qui s'attaquent à ça et c'est génial. C'est avec des moyens évidemment moins élevés. Ils ont moins de ressources qu'un OpenAI. Moi, la manière dont j'imagine la chose, c'est que chaque GAFAM et plus plus voudra potentiellement un accès privilégié à cette technologie. Microsoft a payé le prix fort pour avoir un accès privilégié à OpenAI. On a l'impression qu'Anthropic, c'est un peu la même histoire qui se répète avec Amazon. Et donc il y a des places à prendre. Qui sera la darling d'Apple? Qui sera la darling? Facebook a un peu FAIR en interne, donc ils ont quand même pas mal de force de frappe là-dessus. Mais par exemple, Apple, On peut tout à fait imaginer qu'Apple ait besoin d'internaliser un labo comme ça, ou en tout cas d'avoir un accès privilégié à un labo de recherche de ce type-là. Et on peut parler de la même chose de Salesforce, etc. Donc je pense qu'il y aura toujours de l'appétence du marché pour créer des labos de recherche autour de cette techno, au moins dans un ordre de grandeur de la douzaine. Donc je pense qu'il y a des opportunités pour créer ces labos et Mistral qui le fait très bien l'a démontré. Mais pour être à l'échelle d'OpenAI, il faut se lever de bonne heure parce que ça fait longtemps qu'ils y sont. Moi j'ai rejoint OpenAI et j'y suis resté presque 4 ans avant que ChatGPT existe. Donc ça fait longtemps qu'on travaille sur cette techno-là. Et aujourd'hui, ils ont un accès privilégié à des fonds et ils construisent des clusters qui ont une taille très élevée comparé à ce que tous les autres concurrents peuvent avoir. Ils ont une longueur d'avance intéressante.

Parmi les avantages, comme tu dis, qui finissent par être des barrières à l'entrée, il y a le produit, avoir le meilleur produit, être meilleur. Est-ce qu'au niveau de l'interface utilisateur, de l'expérience utilisateur, tu penses que la guerre va être féroce sur votre créneau? Est-ce que c'est là que ça se joue? Qu'est-ce que tu penses que ça a comme place, l'expérience utilisateur?

Elle est énorme. Le défi pour nous, c'est de créer une plateforme et un produit qui accélère l'adoption de cette technologie au sein des équipes d'une entreprise. On a certaines fonctions aujourd'hui, il y a des gens qui nous disent Utiliser Dust, ça me fait gagner 10 heures par semaine. Même moi, j'en reviens pas. Il y a d'autres fonctions, ils nous disent Dust, ça me fait gagner 3 heures par semaine. C'est déjà génial. Le but, c'est vraiment de créer un produit qui nous amène à ces gains-là le plus rapidement possible au sein d'une entreprise. Et ça, ça ne passe, c'est quasiment que de l'UX. Nous, on se focalise sur le cas de l'interaction entre humains et assistants au sein d'une entreprise, donc dans un contexte de productivité. Et donc il y a plein de choses intéressantes à faire. Aujourd'hui, nos conversations, c'est plusieurs humains qui interagissent avec plusieurs modèles. On peut pinger un humain, pinger un modèle dans la conversation, c'est un peu la même chose. Pouvoir faire ce travail à plusieurs avec des modèles, c'est quelque chose qui n'est pas dans l'ADN d'un ChatGPT par exemple. Qui va être un peu plus consumer-facing. Et donc trouver ces bonnes expériences utilisateurs pour le contexte de productivité et de travailler avec des modèles, c'est clé quoi, c'est central, c'est clair.

Qu'est-ce que tu dirais aujourd'hui qui est une tâche qui marche bien avec les LLM, sur lesquelles les LLM sont bons, et une tâche ou plusieurs tâches sur lesquelles les LLM sont mauvais?

Alors être un peu le savant d'une équipe, c'est quelque chose sur lequel les LLM sont plutôt bon. Donc vraiment, le use case de customer support est intéressant. Ce qui est intéressant, c'est que pour faire ce travail très bien, il faut avoir accès à, c'est un peu le pari qu'on avait fait au début, à plusieurs sources d'informations. Parce qu'en général, l'information nécessaire pour répondre bien à une question, elle vit en général, si on utilise Intercom, il y a une knowledge base dans Intercom, mais la réalité, c'est que la moitié de la knowledge base, elle est aussi dans Notion et qu'il y a une partie dans Slack à des endroits qui sont très intéressantes. Et donc, par exemple, nous, on est en confrontation avec Intercom sur certains clients. Donc Intercom a produit un assistant qui s'appelle Finn et on arrive à avoir des résultats bien meilleurs de par cette capacité à aller chercher l'information partout plutôt que seulement dans Intercom. Donc ce use case d'être un peu le sachant sur un sujet, ça marche bien. Évidemment, les use cases de code sont excellents. Copilot, ça marche super bien. Un peu similaires, c'est tout ce qui permet d'aller d'une modalité à l'autre. Donc changement de langue, ça marche très très bien. Résumé, ça marche très bien si on change la longueur. Text to SQL, ça marche très très bien aussi. Quels sont les endroits où les modèles pêchent? C'est marrant parce que c'est un peu inversé entre image et texte. Dans la modalité textuelle, c'est tout ce qui a à voir avec un peu la créativité ou la réflexion profonde. Par exemple, si on pense au journalisme, un modèle écrit probablement mieux que la plupart des journalistes. Il peut produire avec des sous-contraintes très rapidement des textes excellents. Mais quand on lit un, si on génère un article from scratch, que généré par un modèle, c'est plat. On sent que c'est un peu plat. Il y a pas ce narrative qui est créé par un journaliste qui va parler à travers son texte et nous attirer, enfin attirer notre attention sur certaines choses. Quand un modèle génère quelque chose, c'est un peu C'est un peu fast-food. Donc les changements de modalité, donc il n'y a pas de besoin de créativité particulière, pas besoin de réflexion, de structuration profonde, ça marche très bien. À partir du moment où il faut une structuration profonde, enfin il faut une réflexion un peu plus lente, c'est plutôt les use cases où ça marche moins bien. Évidemment moi je faisais de la, donc chez OpenAI je faisais de la recherche sur l'application des modèles aux maths. Ça c'est quelque chose où les modèles sont pas bons quoi. Après pas bons faut définir pas bons, meilleurs que la plupart des humains. Mais on est très très loin de faire avancer la recherche en mathématiques avec l'intelligence artificielle. Très très très très loin.

Mais en structurant un peu avec les raisonnements step by step, etc., on voit quand même qu'ils arrivent à dérouler un peu du raisonnement.

Ouais, ça déroule un peu du raisonnement, on arrive à pousser, il y a plein de techniques, on pousse, on pousse, mais on reste un peu bébête, quoi. On peut imaginer que ça va avancer, il n'y a pas de raison que ça s'arrête, mais aujourd'hui on en est très très loin. Ouais, donc le raisonnement profond, la créativité, autant de choses.

Et alors ça, c'est marrant parce que tu l'as dit rapidement, mais ça s'oppose presque à ce qu'on voit dans les images. Ouais. C'est-à-dire que les images sont hyper créatives, au contraire, ça donne plein d'idées.

Après, je suis pas expert, tu vois, je suis pas peintre ni photographe. Peut-être qu'il y a cette fadeur aussi dans la modalité image, mais j'ai l'impression qu'elle est moins saillante, quoi.

Ouais.

Ça crée des bêtes d'images. On est d'accord.

C'était comment OpenAI?

C'était passionnant. Moi, je suis pas chercheur de formation, donc c'est— mais je faisais en pratique, je faisais vraiment de la recherche, donc c'est très différent. Pour moi, c'était une expérience très différente puisque c'est la recherche, c'est très différent de l'ingénierie produit, on va dire. Donc c'est très dur de dire si ça— comme j'avais pas fait de l'argent, je peux pas comparer à d'autres laboratoires de recherche. Mais en résumé, c'était fascinant et génial. Et ce qui m'a le plus impressionné, je pense que c'est la au moment où moi j'y étais, c'était la densité de talent. Tout le monde dit ça de toutes les boîtes, bla bla bla. Moi j'étais chez Stripe de 80 employés à 3000 employés. Chez Stripe, la densité de talent était forte au début. Mais là, OpenAI, c'est un notch au-dessus. Chaque discussion est presque intimidante parce que tu as l'impression de parler à des gens qui fonctionnent pas pareil. J'ai eu quelques expériences dans ma vie en prépa où t'as l'impression d'être— tu sais jamais si c'est faké ou pas, mais t'as l'impression de face à un génie brut. C'est-à-dire que le mec est au fond de la classe, il dort, le prof s'énerve, il dit Qu'est-ce que tu fous? Et il donne un argument sur une preuve qui dure une demi-heure, il se rendort, l'argument tu comprends pas, le prof continue et 25 minutes dans la preuve, il y a l'argument qui sort et tu dis OK, d'accord Alors peut-être qu'il avait déjà vu la preuve et qu'il était juste en avance, mais Certains moments des expériences où tu te dis, lui il marche pas pareil que moi. Chez OpenAI, il y avait une intensité forte de ces expériences.

Et alors chez Stripe, qu'est-ce que tu en retiens?

Stripe, c'était donc on est 80 à 3000 personnes en 5 ans. Donc c'est l'exercice typique de scale massive dans une boîte tech californienne. Enfin moi, c'est l'expérience professionnelle de ma vie. Je me suis régalé, c'était extraordinaire. Qu'est-ce qu'on peut en retenir? Plein de choses. Est-ce qu'il y a des sujets particuliers qui t'intéressent? La data? La data. Je pense que, je vais pas répondre, je vais répondre un peu hors sujet, mais pas complètement. Je pense qu'une des grosses leçons de Stripe, c'est de se rendre compte à quel point les processus sont moins élaborés que ce qu'on pourrait penser de l'extérieur. C'est-à-dire que c'est le fameux fake it until you make it, mais en fait, ça, ça reste vrai longtemps. Au sein d'une boîte, en fait, il y a un bel équilibre où il ne faut pas aller chercher la perfection et il vaut mieux se contenter du bien pour avancer plus vite. Et donc il y a des choses qu'on a réparées chez Stripe des années après les avoir construites et qui, vu de l'extérieur, paraîtraient juste impensables, quoi. Des processus qui étaient complètement cassés, des choses comme ça. Et c'est une bonne chose. C'est ce qui nous a permis d'avancer vite. Sur la data et Stripe, c'est assez classique Stripe. Bon, il y a énormément de data puisque c'est un business de paiement, donc il y a énormément de processing. Un des enjeux de Stripe, c'est évidemment le risque, le risque client, le risque marchand surtout. C'est quand un marchand est frauduleux, c'est de l'argent que Stripe va perdre puisque c'est la responsabilité de Stripe de gérer ses marchands vis-à-vis des réseaux de paiement. Mais la réalité, c'est que c'est moi je travaille pas là-dessus, mais j'ai l'impression que ce sont des techniques classiques qui marchent bien, quoi. Pas forcément de faire des modèles deep learning pour essayer de détecter de la fraude marchande. Mais ça va être intéressant comme ça aussi va être changé parce que, par exemple, analyser des time series de transactions, bon bah c'est des techniques classiques de stats, marchent très bien, des régressions linéaires, ça marche très bien, des boosted de machin, ça marche très bien. Après, Les modèles de langage vont apporter un nouveau signal, une nouvelle feature au sein de cette analyse qui va être la capacité à comprendre la page web d'un client, par exemple. Ça, c'est un travail qui a été fait par des humains. C'est-à-dire qu'il y a des flags, on n'est pas sûr de ce qu'il y a là. Ce qui se passait, c'est qu'il y avait un humain qui allait voir la page web. Il y a des signaux assez forts sur une page web. Est-ce qu'il y a des termes? Est-ce que les termes, on les reconnaît? Ils ont été copiés du même blog qui file des termes à tous les mecs qui font des marchands frauduleux ou des choses comme ça. Des choses qui sautent pas mal aux yeux de l'humain, ça, ça va être quelque chose qui va longtemps pour être pris par un modèle aussi.

Est-ce que tu as une anecdote à nous partager?

Oui, alors il y en a une qui est marrante, c'est comment on s'est retrouvé à rejoindre Stripe justement. Donc nous on a monté une boîte en France qui s'appelait Nitrogram, qui faisait des analytics sur Instagram, et on avait décidé d'essayer de trouver une sortie, une acquisition pour continuer l'aventure au sein d'une autre boîte parce que c'était à l'époque, c'était un monde différent mais on était profitable, on faisait entre 1 et 2 millions d'ARR, ce qui tout à fait honorable. On avait beaucoup de mal à lever une série Z, énormément de mal, parce que le marché du VC, surtout en Europe, était différent de ce que c'est aujourd'hui. Et donc on a parlé pendant très longtemps avec Pinterest, où il y avait un match assez naturel. On faisait des analytics sur Instagram, Pinterest je crois qu'ils voulaient nous intégrer, ils étaient excités par l'idée de nous faire travailler dans l'équipe advertising. Il y avait un match assez naturel. Et on arrive quasiment jusqu'au bout de l'acquisition, ils nous disent ok, on y va, on veut le faire. Et là on se dit, bon, est-ce que c'est Pinterest qu'on veut aller, etc. Et en fait, il y avait une boîte qui nous faisait rêver, nous, qui était Stripe. On était les premiers clients européens de Stripe, si je me souviens bien. On les connaissait un petit peu et de l'extérieur, ils nous faisaient vraiment rêver. Et donc on a tapé à la porte de Stripe et comme on les connaissait un petit peu, on a passé des entretiens très vite. Et au final, au bout de ce processus-là qui a duré 2 jours, c'est que Pinterest a duré 2 mois et ce processus-là a duré 2 jours. Stripe nous dit «Ah, on vous a vraiment adoré, c'était trop cool, mais c'est une de nos premières acquisitions et vous êtes une boîte européenne, donc c'est compliqué, donc on va pas le faire.» Et au final, par le fruit du hasard, moi je travaillais avec un prof qui s'appelle David Mazières sur la cryptocurrency Stellar à l'époque, je creusais un peu des idées avec lui. Et Stellar, il s'avère, avait été financé au début par Stripe, donc il y avait un lien entre Stellar et Stripe, donc un lien entre David Mazières et Stripe. Stripe. Donc je dis à David, ah dommage Stripe ça n'a pas marché, peut-être qu'on aurait pu continuer à travailler ensemble si j'avais rejoint Stripe. Et il s'avère que David envoie un message à Patrick Collison en disant, non Stan tu fais une connerie, il est trop cool. En même temps il me semble que John Collison a un dîner avec quelqu'un qu'on connaît qui est un deuxième signal. Et au final de manière hyper intéressante, ils ont eu l'humilité et eu le courage de revenir sur leur décision et donc le lendemain de nous rappeler et dire «Bon bah en fait finalement on y va.» C'est pas souvent. Non, c'est pas souvent que ça se passe comme ça. Mais c'est intéressant d'être capable de revenir sur une décision, surtout ce genre de décision, c'est pas facile. Donc c'est incroyable qu'il l'ait fait. Génial pour nous parce que je pense qu'on s'est régalé beaucoup plus chez Stripe qu'on aurait pu le faire chez Pinterest.

Alors c'est quoi la suite de Dust?

Bah la suite de Dust, aujourd'hui on travaille avec des design partners plutôt français qui sont entre 100 et 500 personnes. Je pense qu'on a fait cette découverte, cette itération produit dont on a parlé. Et aujourd'hui, on est à une étape où une fois que le produit est déployé dans une boîte, il a une vie de lui-même. Il grossit de lui-même, l'usage est là, c'est bien sticky, les gens l'utilisent et il y a une vraie valeur qui est créée. Et en fait, ça, c'est que le début de l'aventure parce que maintenant, il faut réussir à reproduire ça de manière répétable, quoi, pour aller conquérir un marché. Donc on est un peu à cette jonction entre trouver le produit qui crée de la bonne valeur. Ça, je pense qu'on a coché la case. Ça va continuer à avancer, évidemment, et ça va continuer à augmenter. Mais le prochain défi, c'est vraiment de mettre en place un go-to-market. Mettre en place un go-to-market, ça demande du travail produit parce qu'il y a plein de choses à faire dans le produit pour réduire des frictions et faire en sorte que l'onboarding soit compréhensible, etc. Etc., pour réduire la quantité de travail humain nécessaire à onboarder une boîte efficacement. Et ensuite, donc, passer de ce design partner à commencer à évaluer combien ça coûte, combien de temps ça prend d'aller chercher une autre boîte, enfin une boîte au hasard. Donc je pense qu'on est dans cette phase-là. Moi, je dirais qu'on n'est pas encore en product market fit parce que je mettrais le go-to-market dans le product market fit. Parce que si tu as un produit qui crée de la valeur mais que c'est hyper dur de l'implanter dans une boîte, bah T'as pas vraiment un fit, quoi. Donc on est dans la phase où on a le produit qui tourne et il faut résoudre le P de PMF et il faut résoudre le M. Et ça, c'est un travail de go-to-market. Donc c'est une phase assez différente et hyper intéressante. Et je pense que le marché autour du déploiement de ces assistants à l'intérieur des boîtes va être pas mal basé, comme tous les marchés SaaS, mais particulièrement basé sur une forme de réputation. Donc je pense que l'objectif, ça va être d'aller chercher des noms les mois à venir, quoi. Donc c'est réussir à bien closer nos design partners, réussir à pouvoir dire qu'on travaille avec eux. Avec ça, pivoter sur des boîtes plutôt américanisées parce que c'est important de pas se faire avoir aux États-Unis. Tu veux être fort partout, quoi. Et je pense qu'on veut vraiment mettre l'accent sur le marché américain dans les mois à venir. Et derrière, commencer à mettre des chiffres sur combien ça coûte d'avoir un nouveau client et combien tu arrives à en faire par mois, combien ça te coûte d'humain. Une fois que tu as commencé à avoir ces chiffres, mais c'est des chiffres qui ont besoin d'être assez approximatifs, quoi. Je pense que c'est là où tu as un vrai product market fit et que tu peux commencer à accélérer et penser à une série Z.

Qu'est-ce que tu aimerais entendre dans un prochain épisode de Data Driven 101?

Ce serait bien de creuser l'envers de la médaille de ce dont on a parlé avec Mistral, par exemple. Qu'est-ce que ça veut dire?

J'ai reçu Guillaume Lample dans un épisode.

Avant? Il y a longtemps?

Il y a 3 semaines.

Ah, il y a 3 semaines? Parfait! Je suis content de l'écouter dès que ça sera sorti.

Il est sorti il y a 3 semaines.

Ah, il est sorti? Parfait! Je suis content de l'écouter dès que j'aurai le temps de l'écouter. Merci Stanislas Polu. Merci beaucoup.

Vous venez d'entendre Stanislas Polu, cofondateur de Dust, sur Data Driven 101. Si vous avez aimé et que vous voulez nous soutenir, n'hésitez pas à vous abonner, à liker et à partager. La semaine prochaine, je recevrai Marie Ramondaré, chef de projet Design Innovation au sein de l'Ecolab, pour nous parler de data environnementale publique.

À très vite!

Data Driven 101 est rendu possible par Scopeo, agence d'intelligence artificielle. Donnez de l'élan à vos projets IA en vous rendant sur scopeo.ai.