Comment gérer le coût de l'IA pour une entreprise ? Avec Benjamin Drighès

Écouter sur :

Le coût de l'IA explose-t-il vraiment pour les entreprises ? Entre les tokens, les modèles frontier, les abonnements, les agents de code et les workflows agentiques, il devient de plus en plus difficile de comprendre ce qui coûte réellement cher dans l'intelligence artificielle.

Avec Benjamin Drighès, CTO IA et associé chez Galadrim, nous allons voir comment les entreprises peuvent garder le contrôle sur leur facture IA sans sacrifier la performance. Comment choisir le bon modèle ? Faut-il toujours utiliser les modèles les plus puissants ? Quel est le rôle du cache, du contexte, du routing, de l'open source ou encore du harness dans l'optimisation des coûts ?

Un épisode pour comprendre pourquoi le coût de l'IA n'est pas seulement une question de prix, mais surtout une question d'ingénierie.

Transcription brute générée automatiquement par Whisper — peut contenir des imprécisions.

Transcription

Bonjour à tous et bienvenue dans ce nouvel épisode de Génération IA. C'est Guillaume et aujourd'hui je suis avec Benjamin. Benjamin va nous parler notamment du coût de l'intelligence artificielle pour les entreprises parce que récemment les coûts ont explosé pour certaines entreprises et pour certains fournisseurs d'intelligence artificielle. Et du coup c'est une question qui est vraiment critique désormais pour certaines organisations. Avant tout, je vais laisser Benjamin se présenter. Benjamin, c'est un expert en IA. Je ne vais pas spoiler. Benjamin, je te donne directement la parole pour que tu te présentes à l'audience et après on va aborder tous ces points ensemble.

Merci Guillaume pour l'invitation. Donc Benjamin, je suis le CTO IA de Galadrim. Je suis aussi un des associés. Galadrim, c'est une agence de développement sur mesure qui a été créée en 2017 et qui depuis a accompagné plus de 800 clients. Et donc j'ai rejoint Galadrim début 2024, quelques mois je pense après la sortie de ChatGPT justement pour créer toute la branche intelligence artificielle et données au sein de Galadrim.

Et aujourd'hui dans l'équipe, j'encadre environ 40 ingénieurs et consultants. Et donc notre métier au quotidien, c'est d'accompagner tout type de clients. Donc ça va de la PME, de la startup, aux grands... On va faire des études en groupe sur leurs projets digitaux et notamment depuis quelques années de plus en plus sur l'utilisation de l'intelligence artificielle. Et donc on a un ADN très tech qui nous permet d'utiliser les leviers de l'intelligence artificielle pour apporter des solutions.

Et on a une logique assez pragmatique. À chaque fois, on essaie de réfléchir à ce qui apporte le plus de valeur au client. Et donc je pense qu'effectivement, la question du coût de l'intelligence artificielle se pose assez régulièrement aussi pour nos clients. Et donc voilà, on peut en parler. Eh bien, j'ai vu que vous avez des belles références de clients, notamment pas mal de grands groupes aussi. Mais ça va aussi jusqu'à la PME. C'est quoi par exemple la taille d'entreprise que vous accompagnez? Oui, c'est vraiment... On a un tiers, un tiers, un tiers à chaque fois de toute taille d'entreprise.

On peut aussi bien accompagner par exemple du Rexel, qui est dans la distribution de matériel électrique, qui est une entreprise cotée en bourse, qu'une startup qui vient de se créer, qui par exemple souhaite accélérer l'utilisation d'intelligence artificielle pour faire des migrations SAP. Donc on fait vraiment le grand écart entre ces différents types de clients. Et je dirais que la moyenne de nos clients, c'est plutôt une ETI, donc plus de 200 salariés, avec une direction informatique, une DSI, qui veut accélérer... qui veut accélérer sur ces projets digitaux.

Ok. Intéressant d'avoir plusieurs... des clients de plusieurs tailles différentes, parce que du coup, j'imagine que les problématiques que vous rencontrez en fait ne sont pas forcément les mêmes selon la taille de l'organisation. Est-ce que du coup, toi tu as remarqué ça, que selon la quantité de données, par exemple, la taille de l'organisation, les problématiques sont différentes? Et notamment, par exemple, sur le coût de l'IA, on y revient déjà, mais j'imagine qu'il y a des structures qui ne peuvent pas forcément se permettre du jour au lendemain d'avoir un x4 sur leur consommation d'IA, comme ça implique...

alors que d'autres peuvent éventuellement l'absorber et le lisser au fur et à mesure du temps. Oui. En fait, à chaque fois, tu le mets en regard de la valeur que tu apportes avec l'IA. Donc, il faut... Voilà, c'est l'équilibre coût-bénéfice, en fait, que tu fais à... à l'économie. Dans chacun des projets. Et jusque-là, en fait, la question, du coup, un peu paradoxalement, ça n'a pas été forcément la première question qui est posée par nos clients. Nos clients veulent, en premier lieu, pouvoir débloquer de nouveaux cas d'usage et avoir des modèles suffisamment performants pour pouvoir les débloquer.

Et donc, c'est souvent une discussion qu'on a au début. Et en fait, quand ils se rendent compte que c'est très intéressant d'utiliser un modèle plus performant, souvent, ça prend... ça prend le dessus. Et ensuite, en fait, pour... On a toute une mécanique aussi d'observation des coûts, de surveillance des coûts. Donc ça, je dirais que c'est pour la plupart des... Et puis, en fait, il faut différencier, comment dire, les cas d'usage. C'est ça, le point principal.

Et même dans l'utilisation de l'IA, les coûts, il faut rentrer un peu plus finement. Tu sais que, par exemple, les coûts d'input ne sont pas les mêmes que les coûts d'output. Il y a aussi des mécaniques de cash. Enfin, voilà. Tout de suite, on peut rentrer dans un peu plus de détails techniques, mais qui font que chaque tâche est un peu différente. Et chaque tâche peut avoir des coûts IA assez différents.

J'imagine que vous avez des partenaires avec qui vous travaillez ou vous payez directement à la consommation. Quels sont les différents modes de pricing aussi de l'IA? Parce que tu nous parles de input. Donc, j'imagine que c'est en token, input token, output token. Est-ce qu'il y a aussi des pricing par requête ou des abonnements qui permettent d'avoir une grande quantité de requêtes pour un prix fixe, par exemple? Ou c'est que, du coup, à la consommation, par exemple? Oui. Alors, pour les projets où nous, on met de l'IA pour servir des entreprises, donc typiquement des workflows agentiques ou des workflows déterministes avec des tâches de compréhension du langage naturel, du style extraire des informations d'un mail, etc. Donc, on a des informations de documents.

Donc, nous, nos clients, en fait, utilisent les API. Souvent, les API via les cloud providers, puisque ça leur donne davantage de garanties, de sécurité sur l'utilisation des données, etc. Et donc là, en fait, effectivement, c'est plutôt un coût d'entrée, un coût d'input de token et des coûts de sortie. Et donc, ce que je te disais, c'est effectivement le coût d'output est généralement 5 à 10 fois plus élevé que le coût d'input. Et donc, ça veut dire que des tâches qui sont gourmandes en output vont être en fait plus chères que des tâches qui sont plutôt gourmandes en input. Pour donner un exemple, par exemple, analyser ou classifier un mail, ça, c'est plutôt bien parce qu'en fait, c'est plutôt de l'input. Et l'output est simple. Ça veut juste être de dire, ça, c'est un mail pertinent pour telle et telle entité au sein d'entreprise.

Ça, c'est un cas d'usage qu'on traite. C'est par exemple pour un de deux clients dans le courtage. C'est un cas d'usage qu'on traite. On fait toute une mécanique d'orientation de la demande entrante et on permet de trouver les bons gestionnaires sur la demande. Donc, ça, c'est une tâche de classification. Et pour une tâche de classification, c'est plutôt le coût en input. Et donc, on a une tâche qui est relativement peu chère.

Et inversement, on a par exemple un cas d'usage où on essaie d'écrire des articles, de générer des articles. Donc là, tu génères beaucoup. Tu as plus d'output. Et donc, ça va être plus élevé. Et après, tu t'évoques les modèles en abonnement. Donc, nous, en tant qu'agence tech, on est aussi un consommateur important d'intelligence artificielle. Donc, on utilise énormément les agents de code. Et donc, nous, on paye plutôt à l'abonnement puisque c'est plus économique, effectivement, pour nous. Et donc, ça, je pense que tu voulais évoquer le fait qu'il y a une sorte de mécanisme implicite de subvention de la part des grands fournisseurs, donc Anthropic avec l'abonnement Claude, OpenAI avec Codex, et puis les autres.

Et effectivement, dernièrement, il y a eu une évolution où quand tu es un gros client du style Uber ou Microsoft, tu ne peux plus vraiment utiliser ces abonnements pour chacun de tes employés, chacun de tes ingénieurs quand tu es dans le code. Et donc, tu dois payer à la consommation. Et comme ça, tu as un peu plus de temps pour faire des abonnements. Et donc, tu dois payer à la consommation. Et si c'est plus subventionné, c'est tout de suite plus cher. Donc, c'est vrai qu'il y a eu une évolution des coûts. Mais si tu regardes unitairement, je pense que tu n'as pas forcément les prix, quand tu les regardes aux tokens, ils n'ont pas explosé. Et même si tu pourrais même te poser la question, simplement, tous les tokens ne se valent pas, parce qu'il y a des tokens qui sont plus ou moins intelligents.

Par exemple, un Fabel qui vient de sortir d'Anthropic ou un Anthropic, un Opus, le token d'Opus est plus intelligent que le token de Haiku, qui est le plus petit des modèles fournis par Anthropic. Et donc, tu pourrais même dire, pour prendre un peu le contre-pied, que finalement, les prix ont baissé. Et donc, d'où vient l'explosion des coûts? Si le prix du token, si tu regardes l'intelligence du token a baissé, il y a notamment, en fait, tous les workflows, tous les workflows agentiques, et utiliser des IA pour faire du code, c'est du workflow agentique. Eux produisent beaucoup plus de tokens. Donc, tu as beaucoup de tokens en entrée, beaucoup de tokens en sortie, puis plein d'allers-retours à chaque fois que tu rappelles une nouvelle tool, etc. Et donc, ça, ça, effectivement, produit beaucoup plus de tokens, mais ça te permet d'aller plus loin.

Et nous, on en fait aussi de plus en plus, en fait, pour nos clients de workflow agentique, parce qu'en fait, tu débloques des cas du token, et ça te permet d'aller plus loin. C'est-à-dire que tu as des usages que tu ne traités pas avant, et tu as vraiment des workflows qui sont autonomes, et tu peux faire beaucoup plus que ce que tu faisais avant. Et donc, là, tu dois toujours revenir à la question, finalement, quelle valeur j'en tire par rapport au coût que tu vas payer à cause de ce workflow agentique.

Clairement. Donc, juste pour préciser, donc, input, c'est tout ce qui concerne, en fait, le contexte qu'on met dans un LLM, parce que, du coup, là, on parle plutôt d'IA génératif sur ce podcast, mais j'ai vu que vous faisiez aussi de l'IA classique, de vision, etc., d'autres choses qu'on ne va pas forcément mentionner, mais voilà, vous ne vous limitez pas seulement au cas d'usage d'IA génératif. Bien sûr. Il y a beaucoup de gens qui ne sont pas techniques de base et qui découvrent l'IA avec Chagibuti, tu vois, mais l'IA existait avant, comme je l'ai dit dans un autre podcast. Et après, il y a donc l'output, c'est simplement la sortie, c'est ce qu'on voit, en fait, la réponse d'une IA générative, donc, voilà pour ça. Et pour les workflows agentiques, c'est intéressant, parce que, du coup, pour rappeler également, c'est ce principe de récursion, en fait, où à chaque fois, l'output est renvoyé en input, etc., jusqu'à obtenir, à la fin, un deliverable, enfin, je ne sais pas comment on dit, mais ça peut être soit un article, comme tu disais, soit une page de classification.

Donc, ces workflows agentiques, ils consomment beaucoup plus de tokens que les IA génératives. et c'est ce que je veux dire. Donc, c'est un peu le principe de la récursion, en fait, et c'est un peu le principe de la récursion, en fait, de une simple inférence classique, à cause de cette récursivité. Et il y a aussi le fait que, du coup, on ne peut pas vraiment prédire le nombre d'étapes aussi que ce workflow agentique va prendre. Donc, j'imagine qu'il y a des techniques pour cadrer ça, mais, en fait, quand on définit, par exemple, un workflow qui va tourner tous les jours, on ne sait pas s'il y aura 15 récursions, 20 récursions, 30 récursions, on ne sait pas combien de tokens il va consommer aussi.

Ça, est-ce que vous arrivez à le cadrer de manière... En général, il y a des techniques ou simplement en promptant le modèle parce qu'il ne faut pas qu'il parte trop loin, tu vois, dans des cas particuliers. Oui. Et donc ça, le mot qui est à la mode aujourd'hui, c'est le mot de harness. C'est quoi un harness, du coup? Vas-y. Le harness, c'est l'ensemble des outils que tu mets à disposition d'un modèle de langue du style... Oui. Claude ou OpenAI.

Et l'idée, en fait, c'est... Tu vas essayer de contrôler ton harness et donc, si tu veux, ton harness, à chaque fois, c'est des outils et donc des morceaux de code qui vont pouvoir être exécutés et qui vont aussi pouvoir réagir en fonction de l'entrée ou de la sortie de ton modèle. Et donc, par exemple, tu parlais de l'aspect récursivité. En fait, tu peux limiter le nombre de tours que tu vas faire, notamment en l'encodant dans ton harness. Tu vas mettre une règle dans ton code pour dire... En fait, au bout de cinq appels, tu vas t'arrêter et tu vas essayer de sortir un résultat. On fait plutôt... Donc, on agit plutôt sur le harness plutôt que sur le prompt parce que, comme tu le sais, le prompt, lui, il va être interprété de manière non déterministe et donc, tu peux moins bien le contrôler.

Et puis, il peut y avoir des instructions contraires un peu dans le prompt. Par exemple, une instruction, de base, qui est l'objectif. Et après, si on lui donne une instruction qui dit de ne pas aller trop loin, c'est un peu contradictoire avec l'objectif, parfois. Il aura besoin de plus d'informations. Donc, par exemple, oui, on peut clairement définir, par exemple, un nombre de tours qu'il va faire ou un nombre d'outils qu'il peut appeler.

D'ailleurs, on dit que c'est des tools, donc des outils de base. Est-ce que tu sais pourquoi on n'appelle pas ça une fonction? Parce que, au moins, un outil, c'est comme une fonction, mais du coup, tout le monde dit... Est-ce qu'il y a une différence? Non, je ne pense pas qu'il y ait de différence. Je pense que c'est... C'est marrant qu'il y ait un vocabulaire un peu différent, ce qui fait qu'on dirait que c'est un truc révolutionnaire, alors qu'en fait, un tool, c'est une fonction que le LLM va appeler.

Ensuite, il va récupérer le résultat. Mais bon, c'est des fonctions spécialisées pour les LLM. Et du coup, souvent, par exemple, ce que va retourner cette fonction, c'est que le LLM va appeler le LLM. On ne va pas sélectionner le résultat injecté dans le contexte pour ne pas le remplir. Par exemple, si c'est un JSON énorme ou avec juste des informations, on va mettre le harness. Pour moi, c'est vraiment de l'engineering pur, de l'ingénierie où on bricole, on essaye de choisir les bons tools.

Est-ce que vous, quand vous avez besoin de créer un workflow agentique pour votre harness, est-ce que vous prenez un pas de recul, comment vous faites pour définir les tools auxquels il aura accès? Est-ce que vous avez une méthode particulière pour spécifier tout ça, cadrer tout ça et lui donner exactement les bons outils sans qu'il en ait trop aussi? Parce que dans mes expériences, parfois, quand on donne trop d'outils, ce n'est pas bon. Le LLM peut se perdre aussi. Et peut-être pour alimenter la distinction tool-function, si tu veux, tool, en fait, tu as l'idée que tu vas appeler, apporter les informations nécessaires à ton LLM pour qu'il comprenne comment utiliser la fonction. Du style, comment utiliser les arguments, une description, c'est assez basique, mais je pense que c'est ça.

Et ta question, c'est comment, en fait, l'approche chez les scientifiques, on est dans du test and learn, et donc, bien sûr, il y a des gens qui documentent des workflows agentiques, qui font de la recherche dans le domaine. En fait, ce qu'ils font à chaque fois, c'est qu'ils construisent une mécanique d'évaluation. Et par exemple, je peux te parler d'un type de workflow agentique qui est le sujet de la recherche.

Donc, pour construire un moteur de recherche, jusque-là, en fait, la stratégie, si tu veux, c'est d'indexer ta base de connaissances et de trouver une mécanique qui va permettre, à partir de l'expression d'un mot-clé, d'associer l'élément dans l'index. Et une fois que tu as toutes les références dans ton index, tu peux retrouver les informations que tu recherches, les documents candidats. Donc, ça, c'est gérer la recherche classique. Tu peux rajouter des embeddings là-dedans. Donc, un embedding, c'est l'utilisation aussi d'une intelligence artificielle, donc d'un moteur IA, qui va transformer ton texte en vecteur. Et ensuite, tu vas pouvoir faire des opérations sur les vecteurs qui permettent de voir les vecteurs les plus proches. Donc, ça, c'est aussi ce qu'on appelle la recherche sémantique.

Et encore une fois, c'est toujours la même idée. Tu indexes et tu recherches directement en une seule fois. Et ça, c'est intéressant, souvent dans la recherche, tu peux avoir différentes intentions qui se font exprimer par ton utilisateur. Tu peux avoir, par exemple, une recherche qui va étudier tous les documents pertinents sur l'intelligence artificielle, mais ne garde que ceux qui vont parler de l'open source, par exemple. Et donc, tu vas vouloir rajouter une mécanique de filtre. Et donc ça, en fait, si tu veux, tu es obligé de décomposer, de commencer à interpréter finalement ta recherche. Et la recherche dite agentique, elle s'y prête bien parce que tu vas pouvoir avoir un premier tour où tu vas lister des documents pertinents. Et puis un deuxième tour où tu vas rentrer un peu plus en profondeur dans chaque document, tu vas l'analyser et tu vas pouvoir apporter de la précision.

Et donc ça, c'est un cas d'usage de la recherche agentique qui est de plus en plus courant. Et en fait, ce qu'on peut faire, c'est définir des métriques d'évaluation dès le départ. Donc tu travailles sur un jeu de données, tu sais que tel document est pertinent pour tel type de requête. Et donc tu établis ça à l'avance. Et donc tu as un grand nombre de couples requêtes-documents.

Et ce qu'on peut faire, c'est que tu vas lister des documents pertinents. Tu as un score de pertinence. Et donc tu t'appuies sur ça, en fait, pour évaluer ta recherche agentique. Et donc tu vas faire tourner ta recherche agentique sur plein de types de requêtes en entrée. Et comme tu as déjà finalement ce jeu d'évaluation, ça va te permettre de calculer le score total atteint à la fin.

Et donc c'est ça qu'on utilise pour évaluer un harness. Et là, dans ton harness agentique, tu peux faire plein de variations. Donc tu peux dire, OK, dans un premier temps, je vais regarder que le titre de mon document. Donc ça, c'est une façon de faire de retrieval, de faire de la récupération d'informations. Notre tool va être plutôt dans l'analyse profonde. Et donc je souhaite, dans cet autre tool, récupérer un chunk.

Et donc là, tu peux se poser la question de, est-ce que je récupère... Donc un chunk, c'est un morceau du document. Est-ce que je récupère un chunk, deux chunks, trois chunks? Tout ça, tu peux le customiser. Donc tu peux le customiser dans ton harness. Voilà. Et finalement, après, ton ensemble, ta panoplie d'outils que tu mets à disposition de ton modèle de langage va te permettre d'atteindre plus ou moins le résultat. Par exemple, une astuce qui est intéressante dans la recherche agentique, c'est d'avoir un tool qui va permettre de nettoyer un petit peu tous les documents candidats que tu as déjà vus. Tu veux éviter d'aller re-rechercher dans ce que tu as déjà vu. Donc voilà. Mais dans ces logiques de recherche agentique, tu peux aussi utiliser des outils qui sont plus ou moins utiles.

Donc, dans une recherche agentique, on est plutôt, tu vois, sur de l'analyse un peu plus profonde. Un peu comme si, voilà, si tu connais, par exemple, tu peux faire des deep search sur Claude ou des choses comme ça. Et donc, c'est exactement le même type de logique que tu retrouves dans une recherche agentique. Effectivement. Donc, du coup, vous définissez des use case, en fait, des scénarios de l'utilisateur de recherche, par exemple, qui peut faire plus ou moins complexe. Ouais. Et après, vous allez faire tourner votre harness, votre agent IA. Votre workflow agentique. Et selon le résultat, vous allez le noter ou l'évaluer, en fait. Et comme ça, vous pourrez identifier là où il est bon et là où il n'est pas bon. Et du coup, au fur et à mesure, corriger. C'est ça? Ouais.

Exactement. Et on va regarder aussi la… Souvent, ce que nos clients vont regarder, c'est la latence. Enfin, ou en tout cas, la durée totale de l'opération. Et aussi le coût. Et on revient au sujet, effectivement. C'est ça. Ben ça, c'est… En fait, tout ce travail d'optimisation, c'est le travail un peu des ingénieurs. Moi, je suis assez impressionné quand j'utilise Perplexity. Parce qu'en fait, depuis longtemps, ils sont très rapides pour faire de la recherche sur le web. Et du coup, je me dis qu'ils ont fait quand même un sacré travail d'engineering. Parce qu'ils ont indexé tout ça. Ils ont leur propre modèle d'IA. Ils doivent utiliser aussi, j'imagine, la recherche sémantique. Est-ce que, rapidement, tu peux expliquer l'index? Rapidement, tu peux expliquer l'intérêt de la recherche sémantique? Donc, c'est ce que tu disais avec les embeddings et le vecteur.

Parce que quelqu'un qu'on n'a jamais fait, je ne sais pas s'il sait ce que c'est. Mais quel est l'intérêt de faire transformer du texte en vecteur? Donc, en 0 et 1? Et en quoi ça marche mieux que juste faire une recherche dans le texte classique? Oui. Parce qu'en fait, disons que quand tu transformes du texte en vecteur, l'idée, c'est que tu vas avoir une… Par exemple, si tu as deux concepts qui sont propres, tu vas avoir un concept qui est un peu différent. Si tu as deux concepts qui sont proches, du style, je ne sais pas moi, une voiture et une moto, qui sont dans le registre du transport, et bien, en théorie, dans ta représentation vectorielle, dans tes embeddings, ces embeddings vont être proches. Donc, supposons que tu sois sur un moteur de recherche qui permet d'explorer des articles de presse, et en fait, tu recherches des informations sur les différents modes de transport.

Et bien, en fait, tu vas avoir un concept qui est un peu différent. Et bien, en fait, tu vas avoir un concept qui est un peu différent. E E le modèle va comprendre, va pouvoir généraliser un domaine plus large. Au lieu d'avoir une recherche qui va être uniquement sur le texte motocycle, motocyclette, vélo, etc. Il va pouvoir avoir une capacité de généralisation. Et donc ça te permet d'avoir une recherche un peu plus riche de ce point de vue-là. Après, ce qu'on fait souvent, c'est qu'on combine les deux. On a une recherche hybride où on fait à la fois de la recherche syntaxique, où on va regarder la proximité des mots.

C'est un peu compliqué juste de dire mot à mot, c'est un peu plus riche. Et on fait aussi la recherche éventique. Et tu as aussi une astuce qui consiste à utiliser une pipeline d'ingestion à base d'intelligence artificielle qui va extraire des mots-clés. Et en fait, quand tu fais de l'extraction, tu fais aussi une forme d'extraction sémantique parce que tu essaies d'enrichir finalement le vocabulaire. Le sens en fait. Les mots extraits, les mots plutôt que les mots littéralement.

Et cette extraction, vous la faites avec des LLM? Oui, deux LLM. Ok, super intéressant. Et du coup, on bouclait le harness là sur le coup. On revenait là où on est parti. Demain, il y a un client qui vient vous voir et il vous parle de son business. Donc, vous vous identifiez des workflows, donc des choses répétitives à potentiellement automatiser et vous identifiez qu'on peut y mettre de l'IA parce qu'il prête bien pour ce cas d'usage.

Comment vous choisissez le modèle d'intelligence artificielle à utiliser? Parce qu'aujourd'hui, on est noyé. Tous les fournisseurs de modèles, il y a des modèles open source, il y a des... ce qu'on appelle les frontières modèles, comme Claude Fable, le tout nouveau qui est sorti, qui est ultra puissant, mais ultra cher. Est-ce que... Comment vous faites pour choisir le modèle? Est-ce que vous choisissez... Est-ce que vous changez éventuellement le modèle en cours de route? Et est-ce que vous... Éventuellement, vous utilisez plusieurs modèles parfois ou même vous changez, vous routez vos requêtes à différents modèles dans un même workflow identique. Quel est votre process là-dessus? Ouais. Et par exemple, je n'ai pas mentionné, mais le client, il a aussi un budget, j'imagine, ou en tout cas une fourchette. Et donc, il faut que ce workflow, il n'explose pas le budget du client, en tout cas, pour faire ça.

Ouais. Alors déjà, on commence souvent par ne pas trop se donner de contraintes de coûts au départ quand tu es en phase de développement et que tu réfléchis à est-ce que tu peux automatiser ta tâche avec de l'intelligence, etc.? Oui. Donc, tu as une tâche avec de l'intelligence artificielle. Ton objectif, c'est de démontrer la faisabilité et de dire OK, en fait, aujourd'hui, il y a et est capable... Enfin, les meilleurs modèles, les modèles frontières sont capables de faire. Ensuite, nous, par expérience, on sait qu'il y a certaines tâches que des modèles qui n'ont pas besoin d'être des modèles frontières sont capables de faire. Donc, je dirais que tu as un peu... Moi, je mets un peu en trois buckets, si tu veux, les modèles. Donc, tu as... Et j'aime bien utiliser la terminologie. Tu as du nano, mini, du normal, et puis tu peux avoir un peu plus pro par-dessus.

Ou bien tu peux reprendre la répartition d'anthropique avec du haïku, du sonnet, et puis du opus. Donc, la trois échelles. En vrai, nano, ça représente aussi la taille en nombre de paramètres. Petit modèle, petite intelligence, mais rapide. Ça peut quand même être intelligent. Parce qu'en fait, c'est ça. Plus le temps passe, plus les modèles sont intelligents. Donc, les anciens modèles restent tout aussi intelligents qu'ils l'étaient. C'est juste que la frontière de l'intelligence, elle est de plus en plus repoussée. Donc, en fait, plus le temps passe, et moins on aura besoin des frontières modèles pour faire tous nos workflows agentiques. Mais du coup, ces modèles-là pourront être utilisés pour démontrer un théorème mathématique ou des choses à forte valeur ajoutée. Exactement. C'est pour ça que je pense qu'il y a un peu une dissociation entre tes modèles frontières, où là, vraiment, il y a une compétition, où je pense que, par exemple, nous, en tant qu'utilisateurs, sur le code, on préfère payer le modèle frontière parce qu'en fait, on sait à quel point ça nous aborde de la valeur et que ça nous accélère.

Ça existe beaucoup. Oui, aussi. Et donc, par exemple, comme je te disais au début, le coût n'est pas forcément le critère principal. On l'a bien sûr en tête. Surtout s'il y a un sujet de faisabilité. Par exemple, nous, on travaille de plus en plus sur des sujets où on doit analyser des plans. Donc, c'est des choses un peu plus complexes. Là, le token, en fait, c'est de l'image. Donc, on utilise non plus des modèles de computer vision classiques, mais ces modèles multimodaux qui ont été entraînés à la fois sur du texte, de l'image. Et même aujourd'hui, tu vois, tu as du son. Donc, ça, c'est intéressant. Et donc, quand on a un sujet de faisabilité, on commence d'abord par le modèle frontière. Ensuite, quand il n'y a pas de sujet de faisabilité, on prend le normal globalement.

Et ensuite, on va ajuster en fonction de la latence. On va pouvoir prendre du haïku ou du nano. Donc là, si on veut vraiment réduire le temps de latence. Mais on sait qu'on va avoir un compromis en termes de performance. On est plutôt sur des tâches simples du style classification, extraction très, très simple. Sur de l'extraction un peu plus classique du style j'ai un document, je ne sais pas, une facture et tu veux extraire chaque ligne de la facture, le montant. Là, tu peux mettre du, comment dire, le bucket assez normal, du sonnet ou équivalent. Ça, ça marche plutôt bien. Et ensuite, effectivement, sur des tâches où tu as besoin de créativité aussi. Il y a un peu ce sujet-là. Je te donnais le use case d'écrire des articles. Là, tu vas plutôt utiliser les modèles un peu plus puissants.

Parce que tu veux du, tu veux une sorte de richesse de compréhension plus large. Il y a un sens, comment dire, un comportement encore plus aligné sur le, sur l'humain. Et tu le vois en utilisant les modèles frontières que quand tu leur donnes des instructions, devine aussi un peu le sous texte de ton instruction. Et donc, ils sont un peu plus alignés avec la façon dont tu as. De plus en moins, il y a besoin de créer des longues comptes, en fait, et de plus en plus une phrase. Et en fait, le modèle va directement comprendre tout ça. Tout ce qu'il y a sous l'instant, sans qu'on ait besoin de le préciser. Et parfois même, je crois qu'Entropy recommande désormais de ne plus faire de longs comptes justement, parce que ça pourrait juste, le modèle pourrait être confus.

Et juste lui dire une ligne, ce qu'on veut, ce qu'on a dans la tête, et il va le comprendre directement et découper en étapes, etc. Et tu demandais, est-ce qu'on change le modèle? Oui, ça nous arrive. Donc, tu vois, il y a des mises à jour de modèles. Oui, ça nous arrive. Donc, tu vois, il y a des mises à jour de modèles. Alors, il y a même aussi des sujets de dépréciation. Certains de nos clients ont eu du GPT-4O, par exemple. Oui. Et à un moment donné, le provider dit, j'arrête de servir GPT-4O. Donc, ce n'est pas encore le cas, je crois, sur GPT-4O, mais ça a été le cas sur des générations précédentes. Et à ce moment-là, nous, ce qu'on fait, c'est qu'on peut, comme on a toujours un peu une mécanique d'évaluation, on est capable de regarder avec le nouveau modèle et de vérifier qu'on n'a pas une dégradation de performance.

D'expérience, on n'a pas eu ce type de problème, en fait, où quand tu changes de modèle, tu dois tout rechanger. Alors, peut-être que tu peux retravailler un petit peu, si tu as du prompt entre les deux, dans le processus, tu peux peut-être le retravailler un petit peu, mais ça ne fait pas non plus une différence notable. Et sinon, dans la logique de comment je vais adapter mon niveau de modèle, par exemple, tu peux faire ça, par exemple, tu peux partir d'un modèle frontière et te dire OK, bon là, il est très fort dans cette tâche, et progressivement prendre le modèle en dessous, d'un coup en dessous, et si tu vois que tu ne dégrades pas tes performances, tu continues à l'utiliser. C'est comme ça un peu qu'on a tendance à construire nos solutions. Comment tu sais que quand tu baisses d'intelligence, en fait, et que tu vois que ça se dégrade, comment tu définis que c'est à cause que du modèle et pas de ton harness, qui n'est pas ça?

Est-ce que ton harness n'est pas suffisamment optimisé? Ou est-ce que ça peut être les deux, mais une balance à trouver, un équilibre à trouver? Oui, je pense que ça peut être les deux. Après, tu vois, sur le harness et les cas agentiques, c'est, j'ai envie de dire, nos derniers clients qui sont vraiment bénéficiaires, parce que c'est quand même des choses assez récentes. Et en fait, toujours dans nos solutions, on a des mécanismes de feedback utilisateurs. Donc on voit assez rapidement, si le feedback est moins bon, et si, comment dire, il voit une dégradation de la performance. Et après, on peut aussi jouer ça sur des jeux de données qu'on aura préparé. Et ça nous permet aussi d'avoir des métriques qui sont un peu plus précises sur la qualité de sortie. Ça, c'est un sujet, le feedback, c'est hyper important.

Et il y a pas mal de gens, un peu, dans la Silicon Valley, à droite à gauche, qui parlent d'un peu de self-improving agents, donc des agents qui vont s'auto-améliorer, donc soit grâce au feedback qu'ils reçoivent, soit directement eux-mêmes en analysant leurs propres résultats, en fait, entre guillemets. Est-ce que c'est un sujet que vous avez déjà exploré? J'imagine que le mettre en production à des clients, c'est pas forcément tout de suite la chose à faire, parce que c'est un peu dangereux et partir dans tous les sens. Mais est-ce que tu as un avis là-dessus? Ouais, que... En fait, bon, c'est assez drôle, mais on nous demande souvent est-ce que l'IA apprend? Et bon, ça cache parfois derrière le fait que les gens n'ont pas conscience que c'est juste une machine à qui tu donnes des tokens et qui va t'en donner de nouveaux tokens, en fait.

Et donc, d'elle-même, le modèle de langage ne va pas apprendre, en fait, si tu cherches pas à soit faire évoluer ses paramètres, soit faire évoluer, je veux dire, le prompt que tu utilises. En fait, à l'ensemble... En fait, le modèle n'apprend pas. Il reste toujours le même, quoi. Si tu le changes, tu changes pas les paramètres que tu utilises. Le modèle, c'est quoi? C'est un espèce de grand fichier de réseau de neurones, etc. Ouais, tout à fait. Il bouge pas, sauf si on le fine-tune. Donc, on peut le changer, mais si on le fait pas, enfin, il change pas. Ça, il pourra pas s'améliorer tout seul comme ça, sans intervention d'ingénieurs qui vont, en fait, créer des mécanismes. Et créer des mécanismes pour le faire. Ouais, exactement. Donc ça, on essaie de... Parce que c'est vrai que les gens se disent que, bah, quand j'interagis avec ChatGPT, bah, ils commencent à mieux me comprendre, ils parlent mon langage, etc.

Et donc ça, c'est vrai que t'as des... Alors, sans modifier les paramètres du modèle, tu peux jouer, en fait, sur le contexte. Donc, en gros, ce que font ChatGPT ou Claude, quand ils utilisent leurs outils sur Internet, ils vont enregistrer une mémoire. Donc, ils vont dire, OK, euh... Toi, t'aimes bien parler d'automobile ou autre chose. Et donc, ils vont se dire, bah, mon utilisateur aime bien tel et tel sujet. Et à un moment donné, ils vont le mettre dans le contexte. Et donc, c'est toute la logique de comment je vais réintégrer la mémoire dans mon contexte qui fait qu'on peut dire que ton IA apprend. Et après, pour répondre à ta question, oui, on commence à le faire, le fait de, comment dire, d'avoir ce boucle de rétroaction. C'est sûr que le système est pas safe improving, c'est-à-dire qu'on a toujours une, comment dire, une intervention de...

Humanized....d'un ingénieur chez nous pour l'instant. Mais c'est ce qu'on peut faire. C'est... Et ce qu'on fait, d'ailleurs, c'est, en gros, on peut orchestrer une sorte de script qui va prendre les feedbacks, qui va analyser, par exemple, les erreurs et qui va proposer des évolutions de prompt. Et à un moment donné, l'ingénieur va voir l'output. Bah, comme tout à l'heure, on évoquait le fait que tu peux mettre un agent cloud, il a terminé, il va dire, j'ai terminé.

Voilà, on peut avoir ce type de mécanique pour pouvoir faire de l'amélioration continue, en fait, des solutions qu'on met en place pour nos clients. Ok. D'ailleurs, là-dessus, du coup, tu m'as tendu une perche en parlant de mémoire. C'est un sujet, je pense, que j'ai jamais abordé sur le podcast, la mémoire des IA, entre guillemets. Et tu as évoqué le contexte, que c'était lié au contexte. Donc, est-ce que tu peux clarifier un peu? Est-ce que tu peux clarifier un peu ça? Est-ce que tu peux, parce que la mémoire, en fait, c'est quand même un gros problème pour les IA, à cause de cette limitation de la taille de contexte. Bien que maintenant, les modèles, par exemple Gemini, ils ont un million de tokens. Mais du coup, tu ne peux pas injecter trop, trop d'informations parce que du coup, ça va se perdre avec ton prompt et il faut que ce soit très bien fait.

C'est un problème qui est en train d'être un peu résolu, j'ai l'impression, avec les agents autonomes. Là, on parle souvent de cerveau pour les agents. Des outils qui font ça. Est-ce que tu peux un peu élaborer sur ce problème de mémoire? Parce que, en fait, c'est très frustrant et c'est le cas de plein de gens. Tu fais une session sur CodeCode ou tu parles à Tchad GPT. Bon, Tchad GPT garde le dossier d'ailleurs, mais tu peux, après une longue session, tu en recommences une autre et tu lui expliques exactement la même chose que tu lui as expliqué avant. Et du coup, c'est un peu frustrant. Ça consomme plus de tokens. Donc, tu peux... Ça coûte plus cher. Et tu peux répéter chaque jour la même chose. Tu te laisses juste élaborer sur la mémoire.

En fait, comme tu le dis, le sujet de la mémoire, c'est le contexte et la taille du contexte. Et ça, je pense que la mauvaise nouvelle, c'est que ça ne va pas non plus... Aujourd'hui, tu vois, les fournisseurs propriétaires atteignent un million de tokens en taille de contexte. Qu'est-ce que ça veut dire? Ça veut dire qu'on peut mettre au plus un million de tokens pour obtenir un million de tokens. Pour obtenir deux nouveaux tokens de la part d'un modèle de langage. Est-ce que tu penses juste qu'il y aura un nouveau... Enfin, que ce cap de un million va être cassé et il y aura une nouvelle innovation et pas 10 millions? Enfin, ça, c'est des suppositions. En fait, le sujet derrière, c'est un peu technique, mais c'est lié à l'architecture de... Notamment des GPU, qui sont les processeurs graphiques qui sont utilisés.

Et en fait, ces GPU, ils sont utilisés pour... Pour quoi? Ces GPU, ils sont limités sur la bande passante mémoire qui permet en fait de copier les paramètres du modèle vers l'endroit, qui est la mémoire la plus vive en fait du GPU, où se fait l'exécution parallèle du code. Et donc ça, en fait, tu as une bandwidth, donc une bande passante qui est limitée. Et en fait, à chaque génération, donc la nouvelle génération Nvidia, Rubin, tu continues à faire exploser ta capacité de calcul, mais pas autant d'un point de vue bande passante mémoire. Et pourquoi je t'en parle? Parce qu'en fait, ce que tu fais quand tu fais un modèle de langage, c'est un modèle dit auto-agressif. Donc en gros, chaque token que tu dois générer, il faut que tu prennes... Tu dois porter attention, donc c'est le mécanisme de l'attention, à chacun des tokens précédents.

Et ce qui est fait pour éviter d'avoir à faire un... un coup de calcul quadratique, c'est qu'en gros, tu vas en fait stocker ce qu'on appelle un KV cache, qui est en gros une... Tu mets en cache, si tu veux, tous les moments où tu as utilisé tes tokens précédents dans ton mécanisme de l'attention. Et donc plus ton KV cache grossit, plus tu vas occuper en fait ta bande passante mémoire au moment où tu vas faire l'inférence. Et donc, si tu veux ton 1 million de tokens, il va avoir un impact en fait sur cette... Si tu veux passer à 2 millions de tokens, tu vas encore faire exploser ton KV cache. Et donc là, il y a eu des innovations récentes, c'est vrai. Donc notamment ce que tu... Parce qu'il y a eu des innovations de la part de DeepMind, qui est le laboratoire de Google, où ils sont capables de mieux compresser l'information et d'avoir un cache qui est beaucoup plus petit.

Donc voilà, et tu as beaucoup de gens qui réfléchissent à ce sujet. Mais c'est vrai que ça reste un problème physique, tu vois, ça vient de ton... de ton GPU. Ouais. Dans tout domaine là, il faut qu'il y ait de l'innovation. Oui. Il faut qu'il y ait de l'innovation que le software, bien quand on peut compresser, compresser, mais au bout d'un moment... Voilà. Et donc, tu es limité en taille de contexte. Et c'est vrai que tu as pas mal de... comment dire... d'influenceurs dans ce sujet qui parlent de, par exemple, de continuous learning. Qui est de dire, bah, supposons que tu aies une taille de contexte infinie. Bah finalement, tu vas être capable de remplacer vraiment un stagiaire ou une personne. Que tu viennes recruter. Parce qu'il va apprendre de toutes ces interactions, etc. Et bon, et donc comme c'est pas possible aujourd'hui, toute l'ingénierie qu'on fait est souvent liée à comment optimiser l'utilisation de notre contexte.

Et donc la mémoire, on peut mimer une sorte de mémoire en ayant des mécaniques qui vont dire, ok, si on me parle de tel et tel sujet, je vais aller chercher des informations dans ma mémoire. Et donc là, on a des... ce qu'on appelle des sortes de rags ou de... Donc on va avoir quelque chose qui va interroger une base de données, une base de connaissances, de mémoire, quoi. Et qui va pouvoir l'intégrer à ton contexte. Donc plutôt qu'avoir toute sa mémoire dans le contexte, utiliser des outils pour récupérer juste la mémoire qu'il faut à tel moment, pour tel workflow, et pas la mémoire non pertinente pour ça, quoi. Ouais. Oui, exactement. Ok, top. Et du coup, on parlait de pas mal de cache, un problème pareil... Un peu d'actualité aussi, parce que, je sais pas si t'as vu, mais il y a cette entreprise aux États-Unis, Factory, qui fait des Coding Agents, là.

Ils viennent de sortir un espèce de modèle de routing du modèle, enfin, de la tâche au bon modèle. Ouais. Un des problèmes que ça pose, c'est que du coup, si tu utilises un modèle qui met en cache ta conversation, on va dire, et que tu changes, bah du coup, tu dois en fait recréer ton cache. Et en fait, ça peut potentiellement consommer plus que ça doit en fait sauvegarder. Et je sais pas si t'as vu ce qu'ils ont sorti. Est-ce que tu penses que ça fonctionne ou est-ce que, en fait, c'est juste sexy sur le papier, mais à cause de ces problèmes de cache, c'est pas forcément bien, quoi. Je bats connaissance de la sortie, mais souvent, en fait, nous, on préfère quand même contrôler notre contexte. Je sais pas si tu te rappelles, mais à un moment donné, via le chat de ChatGPT, il y avait une sorte d'orientation vers des modèles plus ou moins performants.

Et ça avait pas mal fait polémique, parce que les gens comprenaient pas pourquoi, de temps en temps, le modèle était beaucoup moins bon qu'habitué. Et donc ça, en fait, contrôler le modèle que tu utilises, c'est pas forcément bien. Ouais. Donc, contrôler le modèle que tu utilises et aussi toute l'information que tu lui donnes, c'est quand même assez important pour être sûr, tu vois, d'arriver à l'objectif que tu t'étais fixé à l'avance, quoi. Ça te dirait quoi, en fait, sur ton modèle? Enfin, parce que, en fait, tu sais pas si ta tâche va être complexe ou pas. Tu peux le deviner, tu peux le prétire, même avec de l'IA. Mais parfois, une tâche peut s'avérer plus complexe que ça n'y paraît. En fait, ce que tu veux éviter, c'est que… Ouais. Au moment où tu fais le routage, ton routeur dise que ta tâche est moins complexe et du coup, il va faire appel à un modèle moins performant.

Et donc, je pense que ce risque-là, tu essaies quand même de l'éviter, en fait. Tu préfères, en fait, garder ton modèle, j'aimerais dire, normal. Gâchis pour un simple merci, par exemple, d'utiliser le code Fable. Oui, oui. Mais est-ce que tu sais que tu dois dire juste merci, tu vois? C'est… Ouais. En fait, et d'un point de vue un peu conceptuel, c'est comme… Ça voudrait dire que ton modèle de routage doit être encore plus intelligent ou en tout cas avoir une capacité à comprendre beaucoup plus l'intention de l'utilisateur et la complexité de la tâche. Et à vrai dire, si tu es capable de mesurer la complexité d'une tâche, ça veut dire que tu as l'intelligence de la résoudre d'une certaine façon. Enfin, philosophiquement, tu pourrais te dire ça. Et donc, c'est pour ça que je pense que les gens sont parfois sceptiques sur le routage ou sur ces approches-là. Après, ça marche quand même.

Oui, oui. Donc, je ne dis pas qu'il faut jeter le bébé avec l'eau du bain, mais ça peut être intéressant. Même si le contexte, que ça n'y paraît, j'ai l'impression. C'est pour ça que ça n'existe pas forcément dans un GPT ou plein d'autres… Et donc, tu disais que maintenant, la plupart de votre temps, c'était de gérer du contexte et tout ça. J'imagine que toi, du coup, tu développais du code à la main comme tout le monde. Oui. Tu fais partie de cette époque que les nouveaux développeurs ne pourront pas comprendre. Mais en fait, explique-nous un peu cette transformation et en fait que maintenant, le métier d'ingénieur logiciel se transforme un peu en contexte engineering, tu vois, parce que le code, c'est devenu presque une formalité. Bien que… Et maintenant, on pense plus en architecture, en gestion du contexte, etc.

Voilà. C'est une question assez ouverte. Mais qu'est-ce que ça t'évoque, cette transformation aussi du métier, tu vois, de développeur? Parce qu'en fait, il y a plein de gens qui ne sont pas dans la tech et qui n'ont pas vu cette transformation autant arriver parce que j'ai l'impression qu'ils ont visé le code parce que c'était un gros marché, tu vois. Donc, ils se sont dit… Et ça marche très bien pour les LLM, ceux qui ont de l'usage. Et du coup, nous, on était un peu les premiers à… Oui. À vraiment, tu vois, à avoir des outils agentiques très poussés. Et voilà, qu'est-ce que ça t'évoque, ce changement et une nouvelle manière de travailler? Ou est-ce qu'on va aussi à l'avenir, tu vois? On aura encore besoin de nous? Oui. Parce que c'est pas mal de questions effectivement qu'on se pose. Mais oui, c'est… On l'a vraiment senti avec, je pense, en novembre, l'arrivée d'Opus.

Et puis après, il y a eu… Très bien. Voilà. Et là, les gens qui se sont dit « Ah ouais, en fait, ça marche vraiment. Ça code vraiment bien. » On a tous eu un… Les Américains parlent de « Haha moment », quoi, de dire « Ah ouais, c'est impressionnant ». Et oui, oui, je pense, je dirais moi, effectivement, décembre, je m'y suis mis beaucoup plus, effectivement, parce que je voyais que j'arrivais à aller jusqu'au bout d'une tâche. Tu sais, avant, on était dans l'autocomplétion, donc de code. Oui. Donc ça, c'était très bien. Ça permettait quand même d'aller beaucoup plus vite. Mais là, tu pouvais lui confier vraiment des tâches de bout en bout. Et comme tu dis, on travaille de plus en plus sur comment on va utiliser en fait les… Comment on va orchestrer en fait l'utilisation de ces agents.

Et là, si tu veux, je peux donner plein d'exemples. Mais notre métier, en fait, c'est surtout de comprendre ce que veut le client. Parce qu'en fait, souvent, donc on… Oui. Si tu parles d'un… Donc, il y a plein de typologies de projets, mais un projet classique, c'est j'ai l'expression d'un besoin métier et j'aimerais une solution logicielle. Mais si tu veux, le client, il n'a pas en face de lui la solution logicielle. Donc, toi, tu es là, tu lui apportes un peu cette dimension artistique, tu crées devant lui et tu essaies de comprendre ce qui a de la valeur pour lui. Donc ça, c'est… Je dirais, notre focus a toujours été… Le prototype arrive devant des clients. Oui. Oui, ça nous arrive en fait. Et même, c'est plutôt… Oui. C'est moins l'équipe tech qui le fait que l'équipe sales.

Maintenant, l'équipe sales peut utiliser Claude Code, peu importe. Tout à fait, oui. Ça, c'est génial, du coup, de pouvoir brainstormer en voyant vraiment le résultat, tu vois. Parce que la communication, les spécifications entre les clients et les développeurs et tout ça, ça a toujours été quand même un gros problème, j'ai l'impression. Oui. Ça énerve la compréhension. Oui. Ça a toujours été quand même un gros problème, j'ai l'impression. Oui. Ça énerve la compréhension, des allers-retours. Et là, du coup, tu te mets directement d'accord sur un espèce de design des fonctionnalités. Et après, bon, c'est aux ingénieurs de faire en sorte que ça marche vraiment en production et pas juste en démo. Et oui, ça, c'est assez génial, j'imagine, de faire ce genre de session. Oui. Oui. Oui. Oui. Et nous, ce dont on parle, on a l'impression qu'il y a un peu une convergence des métiers.

Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. Ouais. et moins mais ça c'est le téléphone arabe tu vois à la fin ça ressemble plus vraiment à ce qu'on fait et donc on essaie vraiment d'embarquer nos ingénieurs vraiment sur le et d'ailleurs le terme à la mode c'est forward deployed engineer enfin c'est même oui oui j'ai vu que Anthropic a ouvert des postes en fait c'est des ingénieurs qui vont dans les entreprises c'est ça à implémenter j'ai pas été pris mais ça doit être très pétitif chez Anthropic notre idée c'est de faire ça à notre échelle et on fait ça et effectivement et puis et donc du coup on a une convergence des métiers où le CIS commence à faire du code le tech va pouvoir reprendre ce qui peut être pas mal c'est qu'on peut transformer ce code finalement en spécification donc tu reviens à du langage naturel et tu vas retravailler les spécifications et ensuite c'est là où c'est quand même utile d'être tech c'est que pour répondre aussi à la question est-ce que notre métier va disparaître t'as quand même tout un spectre de connaissances alors bien sûr la connaissance maintenant c'est une commodité puisque tu peux n'importe qui peut interroger avec votre code mais t'as aussi l'expérience et t'as aussi les réflexes que tu peux avoir sur comment tu organises finalement un projet et comment tu vas séquencer ton développement et ça comme t'as pas ton contexte infini pour l'instant ça reste dans le cerveau humain de nos ingénieurs et donc tu vas travailler les specs et nous ce que l'ingénieur sait il sait comment dire faire les choix techniques du style je vais utiliser telle base de données je vais configurer ma CI donc c'est un terme technique pour dire la manière dont le code va être construit puis ensuite déployé et ça l'ingénieur a vraiment une force là-dessus pour dire je sais comment orchestrer tout ça et puis même dans mon développement je sais comment je vais construire toute ma logique de test pour m'assurer que je suis bien conforme à mes spécifications et au fur et à mesure c'est difficile à mesurer tu vois cette compétence de comme tu disais séquencer un peu son implémentation parce qu'on peut coder directement tête baissée mais on peut aussi prendre un pas de recul y aller petit à petit tu vois et ça c'est vraiment c'est pas théorisé nulle part c'est vraiment là j'ai vu un truc super intéressant c'est un nouveau benchmark de coding pour les agents IA c'est ceux qui font le devin là c'est un agent de code aux Etats-Unis et en fait ils ont remarqué que les benchmarks d'avant c'était juste un prompt un unit test sauf que en fait ton code il peut résoudre un test mais il peut être moche tu vois il peut être surcomplexifié il y a plein d'autres critères que juste ça marche tu vois et donc eux ils se sont basés sur ok est-ce que ce code va être fusionné dans un projet open source par le trainer tu vois et en fait parce que quand tu fais une code review là du coup je l'ai fait ce matin parce que je suis maintainer sur un projet open source sur GitHub et du coup en fait c'est beaucoup plus complexe donc moi j'avais codé avec Fable tu vois je suis content du coup il m'a wine shot mais en fait en discutant avec mon collègue il y avait plusieurs points tu vois qui étaient clairement à revoir clairement des choix aussi ça peut être comment tu nommes certaines variables est-ce que c'est compréhensible par l'humain enfin tout un tas d'autres critères que juste ça marche et donc pour moi c'est là encore où l'humain tu vois il a beaucoup de valeur et après jusqu'à quand enfin je sais pas personne sait mais mais voilà il y a aussi des gens je l'ai dit dans d'autres podcasts qui pensent que l'IA va créer plein d'emplois après c'est un sujet un peu hors de notre domaine de compétences on va dire mais voilà je sais pas si tu veux rebondir sur tout ça ouais mais c'est d'accord mais je crois que le chiffre c'était 13% je crois qu'il n'y avait que 13% des PR qui étaient acceptés ou des choses comme ça ça ouais exactement mais oui oui bah mais du coup ça montre bien que le métier a changé où t'es plus dans la effectivement dans la revue de ce que l'IA va produire c'est ça voilà et là c'est vrai qu'il y a plus de code donc il faut beaucoup plus de capacité pour revoir ce code et c'est ça en fait et du coup ça le métier est quand même je dirais qu'il n'est pas plus simple il est quand même d'une certaine façon il est plus complexe parce que t'es en permanence à relire du code et donc tu vois t'as des ingénieurs qui ont qui débutent leur carrière professionnelle et qui passent tout de suite finalement tech lead d'une certaine façon parce qu'ils tech lead leur ils sont en train de manager leur IA et et donc voilà et ça demande finalement une prise de recul plus forte et une montée en compétence aussi plus rapide ça c'est aussi ça que j'ai observé on pouvait se dire effectivement en utilisant l'IA les gens vont plus vraiment apprendre à coder si tu mets le bon équilibre si tu vois entre je produis de l'AI slope et je sais pas bon voilà je push je regarde pas exactement et je fais tout à la main bah je trouve quand même si t'es un peu à la frontière de ça bah finalement je trouve que du coup la courbe de progression est plutôt bonne et en fait si tu te mets dans la disposition de je reste toujours en contrôle de ce qui est produit finalement tu vas apprendre beaucoup plus et c'est même beaucoup plus exigeant de rester en contrôle de tout ce qui est produit et et donc je dirais qu'aujourd'hui ce qui est bien par rapport à 6 mois c'est que si tu veux atteindre un niveau de qualité encore plus supérieur d'un point de vue code d'un point de vue sécurité couverture de test etc bah justement utiliser de de l'IA est quand même une aide assez précieuse je peux donner un exemple nous on et même en tant que manager si tu veux c'est aussi utile ça me permet en fait de suivre une grande quantité de projets et la qualité de code de pas mal de mes ingénieurs en fait j'ai défini de moi-même enfin j'ai une sorte de petit benchmark une méthodologie d'évaluation de la qualité du code selon différents axes et bah j'utilise Claude Code pour le faire tourner régulièrement et ça me permet d'avoir un aperçu de comment les ingénieurs progressent sur tel et tel sujet donc sur la qualité de la CI sur la qualité la sécurité des dépendances ou d'autres choses comme ça et ça je sais je pouvais pas faire ça à la main de manière raisonnable il y a un an tu vois donc ça quand même décuple tes possibilités pour mettre le curseur au bon endroit c'est toujours pareil mais ça doit être un peu difficile pour les juniors qui ont pas connu en fait le code sans les IA de vraiment parce que souvent il faut prendre le temps au début être lent tu vois pour apprendre j'ai l'impression que même du coup les exigences elles sont plus hautes parce que comme on a tous ces outils tu produis pas d'IPR dans la journée enfin tu vois ce que je veux dire et du coup tu prends jamais vraiment le temps de prendre du recul et je trouve aussi que c'est un peu dur de visualiser des changements etc donc servir aussi d'outils de diagrammes tu vois que tu peux aussi générer avec l'IA mais ça devient dur aussi de vraiment se représenter les choses dans la tête de façon concrète et pas vraiment abstraite tu vois ouais mais voilà c'est une compétence qu'on est tous en train de développer j'imagine et pour finir donc cet épisode je voulais revenir sur quelque chose que tu as dit que des boîtes comme Entropy qui sont par exemple des Forward Deployed Engineers des gens qui ont déployé l'IA moi ce que j'aime bien tu vois avec des agences qui sont pas couplées à des fouriers fournisseurs d'IA comme Galadrim, tu vois, c'est que du coup, vous n'êtes pas parti pris parce que, par exemple, un ingénieur d'entrepic, il ne va pas forcément minimiser l'utilisation des tokens, ou alors il ne sera pas incentivé à le faire, tu vois, même si forcément, c'est bien de le faire.

Et aussi, cette possibilité, tu vois, de changer de fournisseur d'IA, d'avoir l'option modèle open source, est-ce que certains de vos clients, ils arrivent à vous, ils présélectionnent déjà le fournisseur d'IA, tu vois, ou comme tu disais, ça vient avec les cloud providers, tout ça? Oui, souvent, il y a certains clients, on va dire des a priori, ils se disent, je veux utiliser tel modèle, etc. Ça arrive souvent, ouais.

Par exemple, le sujet qui vient, c'est aussi le sujet de la souveraineté, donc c'est un sujet un peu complexe, mais souvent, nos clients disent, bon, je veux de la souveraineté, donc je veux du Mistral. Bon, voilà, c'est un peu plus compliqué que ça. Et, donc, voilà, on essaie de, c'est vrai qu'on le met un peu en avant de dire qu'on est modèle agnostique, on n'est pas lié à un provider, on essaie quand même de coller à ce que ça peut apporter, d'évaluer à chaque fois la valeur que ça apporte. On fait parfois de l'open source, notamment dans des contextes de souveraineté, donc par exemple dans le domaine de la santé, on travaille avec un éditeur logiciel où on a mis en place une brique d'intelligence artificielle pour lui, et là, pour le coup, on utilise un modèle open source qui tourne sur GPU, sur OVH, ou un autre fournisseur de GPU.

Et c'est vrai que je pense que c'est sûr qu'on n'a pas effectivement ce lien direct avec des fournisseurs de modèles, et donc on essaie quand même de trouver la meilleure solution à chaque fois, et comme ça évolue quand même assez régulièrement, on est quand même en permanence en veille sur les capacités. Alors c'est sûr que si tu prends les modèles frontières américains, ils se copient assez régulièrement les uns les autres, tu vois, t'as une nouvelle API qui permet de faire ça, tu vas l'avoir assez rapidement sur l'autre. Un truc récent, par exemple, c'est le flex pricing, c'est en gros, t'envoies une requête à ton modèle de langage, à ton LLM, d'habitude, en normal, en fait, tu attends qu'il réponde le plus vite possible, mais en flex, tu peux dire, ok, je peux attendre un peu plus longtemps, il n'est pas obligé de traiter tout de suite ma requête, il pourra le traiter un peu plus tard, et tu commences à avoir le flex pricing sur un fournisseur, et quelques semaines plus tard, tu l'as sur un autre fournisseur.

Donc il y a aussi une sorte d'homogénéisation, en fait, de ces fournisseurs frontières, et après, je dirais qu'il y a un peu deux classes qui se distinguent. Soit t'es vraiment obligé d'utiliser les modèles frontières, parce que c'est compliqué et t'es obligé d'aller chercher les dernières capacités d'intelligence artificielle, soit effectivement t'es un peu plus libre, enfin t'es sur des tâches plus simples, et donc là, oui, l'open source progressivement se met en, tu vois, et une solution, une approche.

Après, ça reste difficile quand même de... Donc t'as des fournisseurs en API sur de l'open source, c'est plutôt ça qu'on recommande et en fait, en fait, en fait, c'est un vrai métier. En fait, c'est l'inférence de modèle, qui est le fait de proposer à des gens, je prends des requêtes et j'exécute sur un LLM et je te donne la réponse. C'est quand même un métier compliqué et surtout, ça demande du capital parce que c'est une sorte de mise à l'échelle. Si t'as pas cette échelle nécessaire, finalement, ton coût marginal est beaucoup trop important et c'est vraiment pas rentable de faire ton LLM. Donc finalement, t'as pas tant d'acteurs que ça qui te permettent d'utiliser vraiment de manière fiable.

Même des modèles open source. Et quand je dis fiable, si tu veux, en fait, quand tu utilises ton API, tu veux toujours avoir à peu près les mêmes temps de latence. Tu vois, tu vas faire une requête, la nuit, super, ça marche super bien et pile au moment de pic d'activité, ça marche plus du tout. Parce que là, pour ton client, il va pas être content si c'est comme ça que ça se passe. Et donc finalement, t'as pas tant de fournisseurs qui permettent de... d'avoir cette fiabilité dans l'inférence.

Donc ça, c'est un autre sujet, mais je dirais que ça fait partie aussi de notre travail d'identifier les bons fournisseurs à chaque fois. Et donc, nous, on passe souvent sur des... sur les providers et sur les providers cloud. Puisque l'intérêt, c'est que souvent, on déploie nos solutions sur du cloud. Et du coup, t'as le provider cloud qui directement, tu peux utiliser. Ok. Dernière question, tu m'as dit que tu... tu recrutais potentiellement dans ton équipe. C'est quel type de profil et comment on peut te contacter si besoin?

On a une page Welcome to the Jungle pour Galadrim. Et donc là, tu peux... on a plusieurs profils qu'on recrute. On recrute bien sûr des ingénieurs IA. Donc, plutôt des personnes qui ont... qui aiment déjà le développement logiciel, parce que c'est quand même notre métier principal, et qui s'intéressent au fonctionnement de l'intelligence artificielle. Idéalement, qui ont un peu un background data science, parce que même si c'est pas 90% de notre activité, c'est bien d'avoir en fait ce recul pour scientifique, pour poser les choses dans le bon ordre et avoir par exemple une stratégie d'évaluation.

Et voilà, cette rigueur scientifique nous est utile. Et aussi, on recrute des gens qui aiment bien construire du produit. Donc, un peu esprit product builders. Et dans cet aspect un peu convergence des métiers, on recrute des product managers ou des product owners qui vont avoir aussi ce côté un peu plus tech, où ils sont capables d'ouvrir Claude Code et de se lancer dans un POC, etc. Donc voilà.

Tout ce qu'on a dit, effectivement, parce que quand tu dis ingénieur IA, en fait, ça peut être tellement une chose différente. Et c'est bien de préciser tout ça. Écoute, Benjamin, merci beaucoup pour ce podcast. C'était super sympa. Et voilà, je te laisse le mot de la fin, éventuellement, et sinon, on s'arrête là. Merci Guillaume pour l'invitation. Moi, j'adore mon métier, quoi. C'est hyper intéressant d'avoir les évolutions, mais vraiment, en fait, au cœur du... quand même d'une révolution, je pense, sur l'utilisation de l'intelligence artificielle. Et tu vois que c'est au cœur d'une révolution économique, et ça, on le voit parce que nous, on est au contact du tissu économique, tu vois. Donc ça, c'est... Et on voit que, comme je te disais au début, on a tout type de clients qui se posent ces questions. Bien sûr, il y a des gens qui sont un peu sceptiques, techno.

Voilà, tu vois, par exemple, sur Uber, qui a reculé sur l'utilisation, ils l'ont interprété comme ça. Moi, je l'ai interprété plutôt comme, finalement, la demande a dépassé l'offre, tu vois. C'est-à-dire qu'ils avaient absolument besoin d'utiliser l'intelligence artificielle, et c'est plutôt moi comme ça que je le vois dans les années qui viennent. Ok. Super intéressant aussi tout cet aspect. Merci encore et à une prochaine. À bientôt.