Docker - Du mindset “reboot” à la gouvernance FinOps à l’ère de l’IA - Jean-Laurent DE MORLHON, Alexandre LACROUX & Fabien PUNIN - #S07EP25

Chaque 100 000 gagnés, c'est des mois de plus de salaires ou de survie d'entreprise. C'est le bazar et quelque part je ne me fiche pas mal que ce soit le bazar. Pourquoi? Parce que je pense que mon homme la vie, il y a une femme de transformer la façon dont on est en train de décryver du software aujourd'hui. Bonjour à toutes et à tous, bienvenue sur ce nouvel épisode du podcast Tech Rocks. Je suis Fabien Punein, co-fondateur et Chief Data Officer d'Opsima, un outil phynobs qui permet de réduire sa factory cloud sans toucher à son infrastructure. Je suis également accompagné d'Alexandre Lacrou, lui aussi co-fondateur et City Opsima. Et aujourd'hui nous avons le plaisir de recevoir Jean-Laurent de Marlon, Jean-Laurent et SVP Engineering chez Docker. Donc une entreprise et un service qu'on ne présente plus dans le monde de la tech. Et nous allons avoir le plaisir d'échanger en particulier autour du thème de la phynobs. Bonjour Jean-Laurent. Bonjour à tous. Parvive d'être avec vous aujourd'hui. On est ravie également. Jean-Laurent, ici quelques minutes, on va aborder ton parcours, ton expérience phynobs au global et notamment chez Docker. On parlera également de phynobs en lien avec le AI, la généaille et l'agentique, qui sont des sujets qui passent sur les fous et qui préoccupent aussi beaucoup de sites et de tech leaders en ce moment. Mais avant d'entrer dans le live du sujet, je n'en le rends, est-ce que tu pourrais commencer par te présenter? Oui, merci Fabien. C'est pas la première fois que je passe dans des podcasts chez Tech Rocks. Peut-être il y a des gens qui me connaissent déjà un petit peu. Donc je vais faire co-fondre. Donc Jean-Laurent de Marlon, je m'occupe de Docker depuis un certain nombre d'années maintenant. Je me sens vieux pour être honnête. Ça fait presque 10 ans que je suis chez Docker. Je me rappelle toujours un anecdote que je disais à ma femme. T'inquiète pas, c'est une startup. Je suis là pour deux trois ans qui je vais aller faire autre chose. 10 ans plus tard, je suis toujours là. Donc j'ai l'impression un peu moins de développer le monde à travers des lunettes qui sont celles des contenirs. Donc à Docker, parce que j'ai fait, bien, sur 10 ans, la carrière elle bouge un peu. J'ai démarré sur la générie, puis en moins sur ce que Docker destoffre aujourd'hui. Mais assez rapidement, notamment 2019, j'ai pris les reines de l'ensemble de l'engineering avec Scott Johnson, le CEO, quand on a fait une restructuration de l'entreprise. Et à ce moment-là, effectivement, c'était un rôle de VPN de Généryng, donc classique autour de Géré les équipes de développement. J'ai fait ça pendant 5 ans et puis l'année dernière, on a un peu rechangeé de nouveaux structures de la boîte avec un nouveau CEO. Aujourd'hui, je gère les projets de Généry. Pourquoi je suis là aujourd'hui avec vous pendant 5 ans de 2019? En gros, en 2024, j'ai géré l'ensemble de l'engineering et quand tu en gères l'ensemble de la généryng, effectivement, à un moment donné, il y a des conversations avec les Ops, avec la finance autour de. On va dire non-jeurder, pourquoi on dépense autant d'argent-là? D'un côté, la finance qui arrive là-dessus et les ingénieurs de notre côté, qui disent, "Je ne pourrais pas avoir un peu plus accès à cette nouvelle outilie, au subsequent-là." Et effectivement, je trouve que c'est un bon sujet, si on mixe ça en plus avec les ailles derrière, qui, à ce moment, l'a fait commencer à tourner la tête de discuter de ces sujets. Donc aujourd'hui, je gère les projets généries chez Docker, mais avec une grosse expérience pendant 50 avant gérer une expérience générie, qui passait de 70 à 250 personnes. Donc avec un scale sur 4/5 ans, voilà, tous les ailles à et les joueurs autour de ce genre de scale dans un monde, un multifusorère, puisque Docker, si la générie, c'est la côte-ouest des États-Unis, donc ça ne se consiste pas aussi à tel. J'ai l'impression que j'ai l'impression que ça va être super intéressant de rentrer dans les détails de tout ça. J'en l'aurant, Docker a pas mal évolué en contre-entreprise et produit, est-ce que tu pourrais nous parler du produit et à quoi il ressemble aujourd'hui et à quoi ressemble aussi l'infrastructure sous-jacente? Oui, alors rapidement parce que finalement Docker, c'est une entreprise qui a un certain nombre d'années, donc il y a beaucoup de choses. Mais essentiellement, on va dire, les deux parties les plus importantes, c'est aujourd'hui quand vous faites récupérer une image d'importe quel type de base de données ou d'un propre type de. Non, ça va, ouais, en général, vous voulez récupérer du Docker Hub, donc, ".doc.com". Et en fait, dans les commandes Docker, on fait qu'un Docker pool, "Enginex", avec quelque part, ou Docker pool, mon godibi, et c'est un petit peu la magique Docker. Avant ça, c'était quand même compliqué de faire tourner une base ou un système et la promesse et la magie de Docker quelque part, c'est bah, tu fais. Ton produit n'est qu'un Docker pool, ouais, de la haute-wé, donc le Docker pool "Enginex" est donc ça. Effectivement, pour faire un Docker pool "Enginex", mon godibi, ou quoi, qu'est-ce? Ça demande un certain nombre d'infrastructures, pour que ça marche partout, etc. Donc, directement Docker Hub, c'est une partie vraiment centrale dans la infrastructure, c'est en termes de coup, mais aussi en termes de. Deux petits mondes de compiote, qui permet, je sais plus combien on a, mais je crois deux mémoires, on avait quasiment 50 000 pool par secondes, donc voilà, c'est une infrastructure assez sympa. Si vous êtes un géniaire, c'est un endroit marrant à travailler, puisque vous êtes sur des contraintes assez costaud. Donc ça, c'est une première partie, comment tu fais pour skéver? En plus des images, la "Enginex" est bien un tout mon sensaire, mais en fait, on poste aussi "Nap" pour ce qu'elle t'il d'image, c'est par "Nap" en "Taky". Ou quasiment, c'est gigantesque, je crois qu'on est à plus de 10 pétabytes d'un de données, plus pour la petite histoire, les images d'occur, c'est rigolo, parce que finalement, c'est constitué de couches, et les couches sont communes parfois, sans taine d'images. Par exemple, la "Nap" est un géniaire de plusieurs versions, on partage des couches en commun, et donc, quand tu veux effacer ou déplacer quelque chose, ou savoir à qui ça appartient, c'est compliqué, parce que la partenance est commune à plusieurs images. L'autre partie, c'est "Docard Desktop", donc "Docard Desktop" quasiment 5 millions d'utilisateurs, donc il y a beaucoup de gens qui s'inservent. Et notamment, dans "Docard Desktop", tu me diras "Ah bah oui, mais ça te tourne sur le top, j'ai vraiment un qu'est ce qu'on s'en foutre? En fait, on s'en fout pas, parce qu'on met des images à jour régulièrement, et il faut les télécharger et réénégrer à tuy. Comme l'enfant de notre infrastructure, à la fois sur "Hub", mais aussi pour "Docard Desktop" et sur AWS, on paye chaque petit object qui part chez AWS et qui arrive chez les gens qui s'inservent. Il y a des coups assez importants autour de "Docard Desktop" et notamment de l'automation des images à jour avec les compagnies. La dernière partie, c'est que dans des entreprises qui ont un certain âge comme "Docard", elle est faite d'acquisition, et notamment, on a fait des acquisitions dans lequel l'appartient notre précipélatomiste, qui j'ai rejoué notre "Docard Hard & Image" et entièrement sur Google Cloud. Donc on a aussi toute petite partie sur Google Cloud chez "Docard". Et évidemment, comme c'est une grosse boîte, on a aussi un tout petit bouquet de copards sur Azure, mais c'est vraiment un minimum. 90% de notre infrastructure est sur AWS. On va dire un 10% en gros à la luche sur Google Cloud. Donc c'est essentiellement en termes de coups et essentiellement du storage du coup, parce que effectivement, 12 pt à la hite et avec ensemble des input-out-coutes qui vraient voir, c'est assez conséquent. Mais on a pas mal de computer aussi parce qu'on a eu du scale sur "Docard Hard", sur les autres parties. Oui, "Docard" c'est une techno qui est absolument ni présente dans le monde de l'infra aujourd'hui. C'est à l'origine, finalement, c'est devenu synonyme de conténorisation, c'est assez fascinant, de pouvoir souder le capot de l'infra de "Docard" avec toi. J'en l'aurant a été au "Cocard", un impressionnant pivot chez "Docard", un pivot qui a été réussi, qui a démarré, tu l'as dit un peu plus tôt en 2019. Et durant lequel on comprend qu'il a fallu transformer l'organisation d'ocard et l'infrastructure tech de "Docard". Est-ce que tu peux nous raconter cette expérience et notamment via le prisme, donc "Finops" de la rationalisation de l'infrastructure, de la rationalisation des coups? Est-ce que tu peux nous dire qu'elles ont été la méthode et ton mindset "Finops" en vue d'adresse et ce chantier? 2019, effectivement, l'entreprise va et pas en grande forme, on a déjà changé de 3 fois de CEO, on passe à l'entreprise, passe de peu près 500 personnes et on va dire 1 milliard de radiation à peu près, on redémarrera la boîte avec 70 personnes, une cible cliente différente et une validation en dessous des 100 millions. Donc, effectivement, on était en live support, comme on dit en anglais, à ce moment-là, et à cet été un petit peu "OK, comment on fait pour faire des marrises bateaux? C'est le moment où effectivement, il y a le virage avec Ubernet S qui prend beaucoup d'emplaires et "Docard", ce rousse-t-pure sur le post de développeur. Donc, c'est un contenuire, c'est génial de tourner en production, c'est fantastique. Mais l'idée, c'est comment on peut faire pour qu'en finalement, ce qui se passe sur ta machine, en tant qu'un génial, ce soit le plus proche possible de l'armélité, c'est un peu difficile, parce que ce n'est pas la même chose, mais en tout cas, comment on fait pour ça, ça n'a plus possible? La promesse, c'est si t'es capable d'avoir ton contenuire qui contient 100% de ce qu'il va contenir quand il sera en production, tu seras un peu plus proche que si tu vivrais juste des binaires, quand tu en partes d'une boîte comme ça, c'est un côté humainement difficile, quand tu passes de 570 personnes, donc une grosse partie, la plupart des gens sont partis dans ce que ça peut les mirentisse, qui ont fait une partie, justement, cloud, contre all the plain, sur Ubernet S et de soir ma l'époque. Et donc, il n'y a pas eu de licenciement massif, enfin quand même, tu parles du changement, du structure entreprise, et notamment tu parles avec un renoué qui est assez courte, le renoué, quand on est startup, c'est l'argent que tu as jusqu'à ce qu'il n'y en a plus, et que tu peux plus payer l'îte et ça l'hernique, ça entromba ce structure. Et donc quand tu es dans un type de mindset, tu es dans un mindset de reboot, de reter marrage, et quelque part, tu dois faire des contrastiques, quoi, pour rentrer une guillemesse sur Ubernet. C'est l'état d'esprit, le idée, c'est le bateau cool, comment tu fais pour un temps coup, un morceau, et tu repars avec un bout de radeau, et comment tu fais pour trouver qu'un bateau un peu plus tard. Donc là, je ne veux pas sur côté humain difficile, de ce truc-là, ce n'est pas le sujet, mais c'est vrai que ça nous adrêvait un moment du mindset. Je ne sais pas trop avec la vente, on va dire 10 équipes qui j'ai rélensant de la France structure et je te retrouve avec 4 ganes en 1 coin que tu connais appel. Donc il y a aussi un petit casque. Quand tu es dans ce genre de situation, quelque part, moi je me rappelle avoir eu les laurelées de l'équipe finance à mon deuil, mais c'est fantastique, sauvé tant d'argent en coupant en réduisant du con à France structure parce qu'effectivement si vous êtes un financier, vous ne dites pas "g'est à deux ans, trois ans un an de renouveler devant moi, l'écoute à France structure sur un compte important, c'est plusieurs mille noms de dollars par an donc effectivement chaque 100 000 gagnés, c'est des mois de plus de salaires ou de survie d'entreprise le temps de retrouver. Donc effectivement c'était un sujet intéressant. Moi j'ai trouvé ça entre guillemets relativement facile à faire et je ne dis pas ça pour frimer au plus que ce soit c'est juste que c'est un truc de service, c'est à dire que mon allez tu dis "bon, ok, à quoi ça sert tous ces choses là? C'est secretique, oui, tu gardes, c'est pas critique, tu coupes et tu verras plus tard, ce qui se passe. Pourquoi notamment c'est important de faire ça dans ce display là et pourquoi je le dis là? C'est parce qu'en fait qu'on vous passe une entreprise de 570 avec un scope qui est différent, vous retrouver avec énormément de services qui n'étaient pas utilisé tout un patie sur le cloud, on ne les faisait plus, on n'allait plus les faire. Et ça c'est à la fois en termes de production mais aussi en termes de développement, vous savez bien que quand on déploie, on déploie d'abord sur le grand système de St.Gym ou interne, ensuite pour passer en production. Donc en gros, un des gros coups c'était effectivement nos dépenses AWS. Et là, on fait des coups à plusieurs centaines de milliers de dollars sur garde, ce qui rendu très heureux les financiers et qui me semblent assez facile, typiquement. On avait un compte Amazon qui était entièrement dédié au système de développement, donc où est-ce que les ingénieurs déployaient leur système. Et on avait un compte Amazon complètement différent pour la production et question de sécurité et autres. Et effectivement quand on a fait ça, on a coupé très fort, et c'est là où effectivement j'ai eu les liées de la finance alors qu'on va regarder une boîte de 570 à 70. Voilà, c'est facile, tu coupes. Il y a plein de temps. Effectivement quand on a la tripatouillée là-bas dedans, on se rendu compte qu'il y a beaucoup de choses. On regarde quand même chaque service, on fait la liste de tous les instances sous ces deux, de tous les storage, etc. Donc ça prend un certain temps, c'est pas fait en 5 minutes. Ça nous a pris, je pense, 2-3 semaines. Mais effectivement on a retrouvé par exemple un truc de goleau. C'est à une époque d'ocœur. On avait un interface entre d'ocœurs et Minecraft. Donc tu pouvais voir, tu pouvais prendre des uns mon de Minecraft avec tes petits cubes là, et tu pouvais voir tes serveurs, tu pouvais rentrer dedans. Un truc un peu rigolo et assez bien foutu autour de ça. Et entre autres, on avait pas mal le serveur Minecraft qui traînait. Je pense que c'était des ingénieurs qui avaient laissé tourner ça. Et donc ça typiquement, tu te retrouves avec, je ne sais rien, une instance au C2, 10 euros $/m, qui tournait comme ça depuis des années. Donc là, effectivement. Avec un coup très faible d'investigation que ton côté, il y a la finance qui te saute au cours, on s'en a oubse cette forme illave, on ne voit pas du tout, mais c'est pas grave. Donc effectivement, quand tu es dans une restaururation de boîte, à l'égard des dépenses, c'est tout plus court. Je pense que c'est assez intéressant. Ce n'est pas forcément très difficile à faire, c'est un peu critique. On avait plein de services, on repart essentiellement avec Docker Hub. Donc c'était plus tourné autour de ça. Et puis Docker Desktop. Mais Docker Desktop c'est surtout du storage. C'est essentiellement du S3. On a créé en interne dans le CI des builds Docker Desktop. On l'estore sur S3, ensuite, c'est juste de la légion. Donc le COTS Desktop c'était relativement ça. La partie of c'était un peu plus complexe. Ça doit être assez enrichissant du coup, c'était épisode de restaururation avec du coup pas mal de challenge of Finops. On dit d'ailleurs de la Finops que c'est une discipline qui est à la frontière entre l'engineering et la finance. De mon qui se parle assez peu de nature. La question qu'on avait avec Fabien, c'est comment est-ce que tu mets en place une gouvernance Finops. Donc en termes d'outils ou de process, comment tu crées une culture Finops pour inciter la tech, en fait, à s'intéresser à l'efficien financière. Et on se demandait qu'elles étaient concrètement les leviers dont tu disposes pour y pas venir. Donc moi, j'ai pas un diplôme en Finops. J'ai eu une expérience terrain autour de. Voilà, c'est quelques années à G&SR. Et alors à été plus, il y avait effectivement toute la restaururation d'entreprise. Mais ensuite derrière le Scalop, de 70 à 200 personnes, tu a pensé mon débon et tout ça. Donc effectivement, tu essayes de comprendre un peu ouver les coups. Il y a une partie qui a aussi rigolote avec la entre guillemets, avec la finance. C'est que, quelque part, la plupart des équipes financières comprennent pas grand chose à l'engineering. Donc tu peux arriver, à la raconter des belles histoires et on fait un poquet. Parce qu'ils ne peuvent pas vraiment argumenter avec toi. Donc c'est là où il faut être un peu logique et un peu en tant que responsable de l'engineering. Tu dois justement te faire cette transformation de faire en sorte effectivement les coups qui sont demandés ou les dépenses qui ne sont pas tels sont logiques, qui sont alignées avec la stratégie de l'entreprise. Parce que c'est super facile de débouler dans la finance et dire "Ouais, non mais je vais vous dire super besoin." Parce que c'est un serveur critique. Là-bas de neuf c'est important, vous comprenez, bla bla bla. Et donc, quelque part, un petit peu le bullshit que les ingénieurs peuvent, parce qu'ils ont des connaissances, et que parfois ils font un peu produit, ce qui sont des produits qui nous écoutent aujourd'hui, et qui se font, on va dire, avoir par des demandes d'engineering. Mais on peut faire la clafine, c'est encore plus un truc qui m'est facile à faire. Donc en tant que VPN de générique, t'es un peu le garante, ce truc-là, il fait un sort de les coups, son maîtrisé. Quand encore une fois, le mindset au départ chez nous, c'était, bah, il faut survivre. Donc on va couper les coups. Donc ça, c'était assez facile finalement de sensibiliser les gens à ça. Et après, tu. moi je me rappelle, sur Docker Desktop, c'est assez intéressant. Personne avait vraiment d'idée des coups qui représentent le téléchargement d'un Docker Desktop. À l'époque, Docker Desktop lui devait bien faire, dans les 500-600 dégâts, l'installeur tout seul. Et effectivement, tu te dis, bah, voilà, il y a à chaque personne qui télécharge Docker Desktop. Donc aujourd'hui, on a 5 millions, moi, à l'époque, je me rappelle plus que l'un éduculator pour le moment. Ou, juste comme ça, tu te rends compte que tous les mois, il y a 500 de gens qui télécharge ce machinat et que tu payes à chaque octet. Donc par un phase de sensibilisation, facilement avec l'équipe desktop qui disait, "Bon, nous, c'est bon, on n'a pas de coups, on n'a pas d'instance, on n'a pas d'instance ou c'est deux, on n'a pas de coups à part du stockage, c'est facile. Tu leur fais prendre des conséquences. Tu leur dis, "Alors, comment vous êtes téléchargement aujourd'hui? Ah ouais, pas mal, super! Ok, bah, chaque téléchargement, ça coûte ça. Donc voilà, chaque jour d'opération de Docker Desktop, ça coûte, je sais pas, 10 000 mal, 8 bâches, moins plus éprits. Et donc, du coup, bah, voilà, tu es une sensibilisation. Qu'est-ce qui se passe après ça? Bah, quand tu as des ingénieurs qui sont conscients, donc, tu mets en place cet état d'esprit, on discute ton raveu, on leur remonte, on s'enpeu moins le coup. Et bah, ils sont arrivés avec, en réduisant déjà, la taille de Docker Desktop, effectivement, les téléchargements, plus plus 500 mégables, et voilà, je ne sais plus comment il est Docker Desktop, pour du super gader récemment, que je fais que de la génére, il m'a maintenant, mais on doit être entre 200, 200, 250, ou même peut-être un peu moins. Et donc, ça, bah, déjà, tu devises par deux, tu écoutes directement. Ensuite, d'autres choses qu'on a pu faire autour de ça, c'est aussi les mises à jour, plutôt que de faire des mises à jour de Docker Desktop, directement, en téléchargeur, l'ençon du binaire à chaque fois. Donc, on a fait tout un travail de mises à jour différenciels, donc ça consiste à faire un espèce de diff binaire entre une version et n-1, n-2, n-3, et une version à la version actuelle. Et tu proposes juste de télécharger cette partie-là. Alors, faire ça aussi, ça nous a permis de faire des gains, des gains d'argent directement. Et donc, comment tu fais ça? Bah, c'est simple, c'est relativement simple, c'est-à-dire, tu montres les coups, tu feras que prendre conscience aux gens, c'est essentiellement la sensibilisation. La partie rigolote, c'est quand même tous les ingénieurs, quand même, il y a un mindset en tant qu'ingénieur, c'est que quelque part, il veut dire, "J'ai entendu ça à 15 fois, avant de télécharger un outil, il vont dire "Ah, moi, je peux le faire, quand moi, je sais que c'est le truc, il faut besoin de l'acheter quoi, je suis trop fort." Mais ce mindset-là, il a un main à se dire, pourquoi j'achetrai quelque chose? Donc, c'est tout le monde, tout le délire qu'il y a autour, enfin, délire, autour des idées, où on va dire la plupart des systèmes d'environnement de développement sont gratuits. Aujourd'hui, Jen Brains, merci à l'arrivée va survivre dans ce monde-là et sur lui, sur lui plutôt quand même, mais quelque part, il y en a pas beaucoup de civils dans ce monde, la Visual Studio Code s'est gratuite. Xcode s'est gratuite, alors, tous les gens seraient bien comme ils vont dire "Mais là, on va chouler de pays, un abonnement si je veux déployer, ok, mais bon, Xcode lui-même, nous permet de déployer localement sur la machine, je crois." Donc, il y a quand même un. on vit dans un monde, en plus benné d'open source, où effectivement, la frontière entre le gratuit et le licence. Et quand même assez ancré. Et donc, les gens pensent effectivement que Docker Desktop s'est entièrement gratuite, ou en tout cas, que le coup d'utilisation de ce genre de prodégraout, mais à chaque fois vous téléchargez quelque chose, il y a quelqu'un qui peut y faire. Ça, c'est le premier point. Le deuxième point, c'est autour des instances quand vous commencez à faire du scale. Au début, on avait une équipe d'ob, on va dire, et puis une équipe d'estop en gros, avec sur 110, moins de sécurité, des tas de trucs autour, mais en gros, c'était simple. Bien sûr, toute une partie engine, historique Docker avec Open Source, le Docker, le produit de Open Source. Et quand tu sequels, tu te retrouves à avoir plusieurs produits aujourd'hui. J'en ai parlé, on a un produit de Docker, un d'animage, on a un produit de build, on a plusieurs produits qui nous tournent sur le cloud, et qui chacun va dépenser un peu de ces deux, donc un peu de computer, un peu de storage. Et t'envie de savoir un petit peu, qui dépense quoi, et comment ça se passe à facturer une espèce de vision, quoi, tu vois, t'es coût avancé, augmenté. Notamment, on va parler, je pense dans les négociations avec l'AWS. Et toi t'envie de savoir un petit peu comment ça se passe, et notamment comment tu projetais dans la lumière. Parce que par exemple, quand tu dévares un nouveau projet cloud, qu'est-ce que ça te coûte? Parce que c'est pilates par rapport au coût d'infrastructure des produits existants qui sont excessibles en consommé ou en près du tout. Et donc ça, on a commencé à prendre tout un four début, moi, j'étais complètement aveugle, puisqu'on avait fait ça, en mode, une fois, la réduction de cool rustique, sans chercher à analyser. Donc j'avais tous les coups de ces deux, tous les coups de storage qui étaient mélangés. J'étais incapable, par exemple, au tout début de distinguer les poules qui étaient faits du hub des poules de Docker. Donc ça, on a commencé à taguer l'ensemble des ressources qui étaient créées. Donc ça, chaque fois que vous faites un instant socié, vous vous blâtez taguer avec que l'on a produit, et donc d'une équipe, on en a fait des non-des équipes au début, comme ça, c'est très relativement simple, fait de regrouper après être dans des coût riz. Pour avoir que moi, j'ai un dashboard qui me dise, bah, a atteint l'écoute du produit AX, il m'a coûté tant, le hub, ça me coûte tant en storage, en concueur, t'es fait. Et ça, ça prend du temps parce que effectivement, dans une chose de scome de coeur avec une centaine d'ingénieurs, bah à des trucs où on va en déploie toutes les 5 minutes, on arrête aussi toutes les 5 minutes, il faut aligner tout ça, donc ça c'était un temps d'investissement de la générique assez conséquente. J'ai trouvé ça super intéressant, c'est donc ta parler avec le Docker Desktop parce que je trouve qu'on dit souvent que les développeurs se fichent des cours. Mais je trouve dans l'ingénierie, on aime, avant tout, résoudre des problèmes et donc quelquefois juste faire remonter le problème et le rendre visible à savoir pouvoir pointer sur Docker Desktop et dire "chac mise à jour, c'est tout le temps" et sur les X mise à jour par jour qui sont effectués, ça a d'appassaire rapidement. Quelque part ça peut suffire à déclencher le haut comportement. Pour les ingénieurs, on n'a pas besoin de mettre d'inceptive ou de nos programmes en place. Donc j'ai trouvé ça super intéressant. Et l'autre aspect aussi, c'est que finalement, comme initiative de réduction de coup, elle donne lieu à moins de patch, à des mise à jour plus rapides et donc ça a un effet aussi bénéfique sur l'expérience utilisateur. Il faut l'intéresser aussi de démarrer par les coups et d'intérir à quelque chose qui n'a pas positivement des users. Et sur le tagging, sinon, c'est quelque chose qui remonte assez fréquemment comme initiative vraiment cœur dans le finance. Parce que finalement, c'est ce qui permet de faire le pont entre l'ingéniering et la finance, ce qui permet d'attribuer les coups de choses qui ne parlent pas du tout à la finance, des bases de données, des instances, des équipes, des projets. C'est vrai que ça sert à bien assez fréquemment. Et j'en aurai que tu as parlé à quelques reprises d'AWS, donc il y a un des trois grands hyper-skailers, unisseur de cloud de l'international. On comprend que les budgets cloud d'un acteur de l'envergure de docker sont assez colossaux par les plusieurs millions. Quelle est ta relation avec AWS et qu'elle est, tu sais, tu n'en as pas le temps de pargueline, pas ou le vieil de négociation avec AWS, comment est-ce que tu approches les dimensions H&I et Nego? Alors ça, c'est vraiment un apply sur le terrain et puis à la durée, en passant de en ayant tout d'un coup la responsabilité de l'ensemble des coups. Donc c'est intéressant ce que tu poses comme question parce que moi je m'étais imaginé, en tant que docker, on avait une puissance de négociation au phénomélal et en fait on est un petit acteur. Donc docker, c'est plusieurs millions de dollars par an de dépenses, on fait tourner d'ocker, à AWS et d'un coup, les plus lents sont des autres services qui sont autour et en gros, assez rapidement on se rend compte que la négociation à l'acquemaison, elle est autour de quelle est la progression que tu vas faire de dépenses chez eux. Et c'est pour ça que c'était hyper intéressant avant de taguer et te comprendre parce que du coup tu peux éventuellement te projeter entre 10 ans, bah ce service là, moi je sais que je ne veux pas trop investir dedans, donc je sais que comme je les ai taguées, je les ai dans le garage, mais dis bah c'est cool, là, je sais à peu près les connaitres. Et par contre je sais que par exemple quand je crée des nouveaux produits, bah ça va me coûter tant, 1 million de dollars, 500 000 ou 200 000 ou 200 000, et donc du coup je sais que si je commence 5 nouveaux projets, bah ça va me coûter ça. Et donc du coup j'arrive avec la négociation à la Amazon, on dit "en bas, je sais que cette année je vais probablement dépenser dans ces zones". Donc moi la négociation se faisait tout au US, donc j'ai d'avait des gens qui étaient tout en détails qui me aidaient dans ces négociations-là, mais en gros tu dis bah je vais dépenser tant cette année, donc on dit "en 7 millions de dollars par exemple". Et l'année dernière je les pensais 6, et bah du coup tu as un rebate qui est négocié à ce moment-là sur l'ensemble des services, qui est lié à la consommation supplémentaire que tu vas faire chez les autres. Le bargaining power, il est un petit peu certain que tu peux essayer de jouer sur du multicloud, tu peux essayer de jouer, nous on a quand même travaillé avec CloudFair et Amazon, et donc de temps en temps on prend des services de CloudFair, on prend des services d'Amazon. Alors tu fais ça, il y a une dimension commerciale, effectivement, comme tu dégocies avec là, on va avec l'autre. Bah il y a aussi une dimension engineering, c'est un site libre, bah maintenant j'utilise des services chez CloudFair ou j'utilise des services chez Amazon. Voilà il y a des ingénieurs derrière qui vont faire le boulot pour que ce soit ça fonctionne. Donc tout ça est assez complexe, c'est été dans un gros backbô qui avance plein de barles et si tu veux le diriger, il faut prendre des mesures importantes en Amon, des négociations, moi je sais que la négociation a été toujours autour de Mars. Chez nous, donc ça c'est des choses qu'on se prépare, voilà, fin des cendres, au milieu des cendres j'avais mesdages bords de complet et j'ai regardé, on regardait qu'ils allait être nous. Grosomodo, j'ai envie de dire quelque part c'était entre guillemets sans stress, dans le sens où dans un service qui est aussi utilisé d'occur, t'as une progression naturelle des usages et donc des coups en gros t'as à la dis 15% de progression par an, c'est quasiment entre guillemets sans rien faire, c'est là en maintenant. Si tous les ingénieurs qui me écoutent en disant "mais là, auquel tu pèses tu parles avec un c'est juste maintenir, c'est déjà des coups, oui je sais". D'un point du clairement finance et négociation, quelque part tu sais déjà que tu vas te prendre de 15% dans la tête de progression. Et après c'est à toi négocier à la barre, dans son désolation. Mais il y a un loquine fantastique, c'est à dire dans un service comme Amazon, moi je sais qu'au début quand j'ai repris les règles de la boîte en 2019, j'ai regardé, on se dis "Ok, nous couche, on soit Amazon, juste par acquis le conscience, qu'est-ce que ça frais si on partait chez Azure ou si on partait chez C.J.C.P.A. Et donc je sais que trois fois, vous trop quatre fois et je me suis cru surprès des ingénieurs qui ont fait ce truc là, on a fait des études pour savoir comment on, qu'est-ce que ça nous coûterait de tout quitter, de aller dans un autre provider. Et les coups sont assez rédimitoires, notamment chez nous, en partie à cause du store, c'est-à-dire que une grosse partie des coups de Docker, c'est où on a des multiples petabytes qu'on a de données, les images pour le stocker sur Docker, et on s'embrace des gens stock sur Docker, et ça, n'igrerait des petabytes de données d'un cloud à l'autre, c'est assez complexe, c'est très très cher. Et en dehors du côté d'un génering qui est quand même une belle pirouette quand même, de passer une cascade un peu complexe à rexécuter pour passer d'un cloud à l'autre, si vous devez changer tous vos services au C2, vers des services et à Azure ou chez GCP, ça se fait penser à un minute, même avec des containers, même avec des capacités comme le cube et tout ça, super simple. Donc il y a déjà un risque opérationnel, et en plus le coup est assez rédimitoire, je sais que moi, quand on arrive, on a plusieurs fois en la regarder comment on partit chez Azure, et ça nous a parlé, ça nous a parlé très très très complexe. Il y a aussi un autre aspect, c'est quand même que, encore une fois sur le story, c'est assez intéressant. Je suis vous regardant un petit peu, en détail, ce que proposent Amazon autour du story, il y a beaucoup de choses autour de l'extraction de données pour le passer chez vous ou ailleurs. C'est qu'à une époque, il y avait même des camions dans lequel vous pouvez storer vos données sur des discutures qui sont transférées d'un endroit à l'autre, que vous pouvez aussi utiliser pour faire l'extraction de données dans le qu'on vous retrouve pour se laisser vous des cartons et des discutures. Et puis après, il y a des ingénieux de votre côté. En termes de rapidité aussi des discussions, c'est compliqué, si vous voulez faire un truc avec 0.0.3 sur un sujet comme ça, donc il ne va pas d'interruption de service. Il va falloir quand même stoper de données dans le endroit, des duplicés à un autre. J'ai eu un repeat de travail que vous devez transférer sur le réseau, ça ne se fait pas en 5 secondes. Donc notamment, je sais que les cloud pro-réders ont des services dans lequel vous arrivez avec des discutures ou les stockés chez eux. Vous l'envoyez les discussions et on revise s'occupe de les transférer sur leur local, du coup, en tout guillemets, sur leur service de stockage et de temps. C'est un tout un monde un peu impressionnant. Pour finir la négociation, les relatives, c'est un petit que vous y prenez à l'avance et je pense que ça monte vraiment de la préparation. Et là, pour le coup, j'en veux dire, c'était la période de la né que je passais de plus de temps avec la chignance. C'était ce truc-là. Et là, une bonne relation. On avait quelques ingénieurs qui étaient dédiés avec une personne côté chignance qui quand même bêtrisait assez bien, qu'est-ce que c'était cassé trois, qu'est-ce que c'était que c'était qu'en s'en déproduit et qu'il y avait une bonne image de l'ensemble des données. Après nous, le transfert à l'autre Amazon, on l'a pas fait, je pense qu'on ne se confrère jamais. On est très content du service, c'était juste une question d'essayer d'aligner un petit peu. Après, le Multi-Cloud chez nous, on l'a jamais fait, je pense que ça me semble excessément complexe. Après, le Multi-Region au sein d'Amazon ou à Saint-Dach, chacun des cloud pro-réders, ça je pense que c'est un autre sujet et je pense qu'il est très très intéressant à l'époque. Au moment où vous les écoutez, ce podcast, il y a eu un downtime chez Amazon et un autre chez Azure, un quelques semaines, un trois ou une semaine d'intervalle, la Faroq Tabre. Ça, ça nous arrive une ou deux fois dans l'année, donc effectivement, US-6, un chez Amazon, qui est la zone dans laquelle l'ensemble historiquement des services des plus grandes de la tech utilisent. Avoir du Multi-Region, c'est un vrai investissement, je pense qu'il est vraiment utile aujourd'hui, puisqu'on a des panne d'US-6. Maintenant, je pense qu'on a une ou deux fois par an, je pense qu'on a les established. Donc, Multi-Cloud, moi j'ai. Je vois pas comment le faire de manière opérationnelle à l'échelle d'un produit comme de cœur. Et j'en froid sans pas le besoin. Là, du Multi-Region, oui, si bien sûr, ne ça se que pour nos utilisateurs, ça me semble être nécessaire mais très difficile à faire. Effectivement, encore une fois, du Multi-Region, ça demande un système de complexité qui est au-dessus. Et donc, vous allez tout se deviner, du coup supplémentaire, après des services pour aider. Et j'imagine que le dernier d'un time chez AWS sur ES6-1 va inciter pas mal d'acteurs à mon avis à investir justement dans le déploiement Multi-Region. Comme tu dis, ouvrir des nouvelles problématiques Finops qui vont un peu se normaliser partout, donc, que par assez intéressant. Et juste un petit commentaire, tout ça, assez fou de s'encompte, qui est encore des camions qui transportent des discutures avec des volumes de data énormes pour transférer d'un cloud provider à l'autre. C'est assez rigolo, merci pour cet anecdote. Ça démistifie pas mal de choses, je trouve. En tout cas, c'est super intéressant. Je le rende comprendre comme une boîte comme Docker, à bord de les sujets Finops, tel que la culture, la gouvernance, la chat. Et j'aimerais maintenant qu'on parle d'un sujet qui est la Finops appliquée à la généiaille que tu connais bien plus. puisque aujourd'hui et depuis un an, c'est le cœur de ton quotidien. Et on sait tous que l'il y a un produit des nouveaux outils à un rythme super important, des nouveaux services cloud et même des nouveaux modèles de facturation pour ces services. On se demandait sur la partie Poo-ling type Cursor Cloud. Comment est-ce que tu gères ce budget? Comment est-ce que tu gères la mesure de l'usage? Comment est-ce que tu mesure le RUI sur ces outils? C'est une super question. La réponse est très claire, c'est le bazar. Pourquoi? Parce que je pense que mon homme la vie, il y a un train de transformer la façon dont on a un train de décrère du software aujourd'hui. Que ce soit parce que vous rédigez vos périodes avec cloud ou j'ai mini ou OpenAI, ou est-ce que parce que vous utilisez des systèmes d'assistance au coding, de toute façon des investissements sont tels et des changements s'achangement majeurs. Quand on a un changement majeur dans l'industrie comme ça, j'ai envie de dire que je veux pas rater le coche, je veux comprendre le plus rapidement possible comme ça marche. Je veux savoir comment quelle est l'usage que les gens font en interne. Et après, je veux déjà comprendre le mécanisme et le changement dans le québécois. C'est mon premier sujet. Et donc quand je suis dans un changement comme ça, je me fiche un peu, entre guillemets, toute proprement garder du budget, du réopérovique, et de gens envie de comprendre le système. Après, le changement est tellement en brusque, et il y a tellement d'innovations en ce moment. Je ne sais pas, tout le monde y a un de ces deux trucs qui sortent. Que ce soit des avancés technologiques sur les modèles, ou bien des outils qui sortent. Pour des domaines, on voit le revoir maintenant, c'est plus en plus spécialisé dans les domaines particuliers sur la direction bug, sur le CI, sur le coding, sur la planification des tâches. Donc c'est un peu moins majeure que ce que c'était en termes de l'impact, il y a quelques mois, mais ça reste encore une toute l'esmeine et une autre. Donc il faut aussi comprendre ce truc-là. Quelque part, j'ai envie de dire, je veux embrasser ce modèle-là, je veux le comprendre. C'est le premier point. Donc la calcul sur RUI aujourd'hui, je ne sais pas te dire. J'ai aucune idée du RUI de l'impact. Par exemple, un truc intéressant, c'est que je me suis dit, j'ai pas mal d'ingénieurs qui utilisent, la plupart des ingénieurs utilisent, la majorité des ingénieurs utilisent des outils coding super. Donc j'aimerais savoir l'RUI, est-ce qu'il colle plus, il se colle moins. J'ai plus de PR, j'ai moins de PR, j'ai plus de CI et j'ai moins de CI, j'ai plus de déploiement, j'ai moins de déploiement. Alors ça, je peux le regarder le manière bloubane. Je peux regarder le manière générale, je suis que j'ai plus de plurie-coispe dans mon bit-of, est-ce que j'ai plus de déploiement en production, est-ce que c'est de déploiement de production de plombre plus ou de plombre moins. Globalement, j'ai pas vu mon changement majeur sur ce zérément-là. La vraie question, c'est combien de ces gens-là de mes ingénieurs utilisés effectivement liés pour déployer leur code réconceau ou pour faire leur changement de code? Et bah, ça, aujourd'hui, moi, je ne sais pas le tracé, parce que, bah, il y a des ingénieurs qui utilisent, on va dire, au panéraï pour essayer de comprendre le problématique qu'ils ont, pour le lire du code, ça leur a permis de gagner du temps, ouais, pas bien, super. Mais par contre, je ne sais pas le mesure, et à la fin, moi, je vois le nombre de PR, donc je peux me dire, "Oh, OK, je vais vous monter de 5% de 10% de 10% de nombre de PR que j'ai fait." Très bien. Qu'est-ce que j'en fais de ça? Qu'est-ce que je suis capable de relier un usage particulier d'openair et ou de clôt ou d'autre chose? La part vraiment, je ne sais pas vraiment faire ce bien. Et quelque part, je m'en fiche un peu, ce que j'ai envie, c'est déjà moi de comprendre le domaine dans lequel je suis. Je vais tout servir d'avoir besoin. D'accord, tout ça, c'est des choses qu'on va absolument avoir besoin de comprendre. Mais aujourd'hui, c'est très difficile de relier l'impact qu'un ingénieur a fait avec son usage en particulier de lire un gaffe à dépenser 500 dollars chez Klo, sur un week-end, sur une semaine. Est-ce que finalement, je suis capable de relier ça avec un gagne de productivité de son côté? Non, est-ce que je leur cherche? Non plus que j'ai envie, c'est qu'il soit plus à l'aise et globalement, qui comprennent comment être plus efficace avec son outil. Je pense que l'IA pour les ingénieurs est là pour nous assister, elle est là pour nous rendre un peu plus rapide. Il y a des usages diverses évarillées, je vois des ingénieurs qui sont très jeunes, qui ont plus autant dans sa. pas mal son servir. Des ingénieurs beaucoup plus expériment et qui s'inservent pour des choses beaucoup plus, beaucoup plus contraignantes. On est dans un boom total, et donc quelque part, la mesure, elle est assez complexe aujourd'hui. Je me rappelle, dans ma carrière, moi, j'ai changé trois ou quatre fois d'ideux. J'ai commencé à essayer de vous dire, avec un outil pad, notre pad plus plus sur moi, comme ça. Après, j'ai fait jeter dans mon Java, donc j'ai fait l'équipe, et puis j'étais avec les coups kits, donc j'ai fait du JetBrains, et puis ensuite, je suis rentré chez Docker, effectivement, là, on a utilisé les outils de JetBrains sur Go, et puis après, j'ai fait VS Code. Et voilà, là, j'ai bien nous retracé par zimons 20 ans, 25 ans, de l'ideux. Là, en un an, on est passé de VS Code avec la assistance de Copaillote, à Kersor, et puis maintenant, que le Code, ou au planéaire et le Cortex, là, le tout en mandant. Et encore, ça continue, il y a des droits, des vachans, il y en a des outils de développement, il y en a des palonqués qui sortent toutes les semaines. Et donc, ça, c'est pour dire que l'accélération est telle, j'ai changé autant de fois en vidéo sur toute ma carrière, que là, dans la dernière année, on gros. Donc, c'est un tel maillstrom de choses, que je pense qu'il faut plus être là dans l'absorption et de comprendre comment ces outils fonctionnent, mais au quotidien, déjà, avant de commencer à mesurer les coups. Mais c'est sûr qu'on va arriver à une mesure de coups. Les négociations des Copaillot entre PIC et Zimili, elles sont aujourd'hui, c'est plutôt dans la. Je calcule des coups, et je regarde l'usage que j'en ai. C'est de comprendre si ma warque force, la mise ingénieur, sont utilisés ou pas liés à, et effectivement, ça explose. Donc, j'en ai rien à lancer. Je ne sais pas, à 10, 15 % des ingénieurs, aujourd'hui, c'est une grande majorité des ingénieurs à d'auquois, utilisés liés à deux manières différentes. Et on en est pas complètement sur la partie négociation encore, on est plus souvent dans une phase d'expansion telle que on est sans doute de comprendre un peu de toute une certaine façon. Donc, on a des ouais, on a des négociations à le Copaillot, des ingénieurs et ont tropique autour de plutôt comment faire en sorte de comprendre leur business modèle, qui change quand même pas mal à chaque fois, notamment pour essayer de comprendre quelle est l'usage. Après, je regarde toutes les semaines, et puis on a des capes. Donc, quand l'ensemble de la généryne a un café, 5,000 dollars dans le mois, tu t'arrêtes, et puis je suis ou pas au mois dernier, je ne suis plus. Je suis capable de me projeter pour du plutôt l'aide. On a très envie d'embrasser le généé à deux cartes. Donc, c'est plutôt. On a des cartes qui ont été mis en truc, y met chaque amblant avec mes urans, quand même les courants, on observe un lit. Oui, d'accord. Ok, c'est très clair. Je comprends qu'en fait, quand on est dans ce rythme et freiné de sortie dans nos nouvelles outils toutes les semaines, tu surfes sur la vague, sans te préoccuper trop des coups. Ça, c'est intéressant. Et je comprends aussi, dans une boîte comme Docker, même avec ce niveau de maturité, vu le rythme et freiné, en fait, il n'y a pas encore de. Pour les développeurs, parce qu'on fait ça va trop vite. Et puis on a envie d'embrasser le truc, donc tu n'as pas envie de rater le cauches de cours, ce qui se passe. Donc, là. D'accord, c'est intéressant. Ça, c'est sur la partie pooling, du coup, sur la partie fonctionnalité pure chez Docker. Toi, tu es chargé chez Docker, donc, de déployer des nouvelles fonctionnalités, basées sur la généia, comme tu nous disais, notamment, tu nous parlais de l'assistant ou Gordon qui intégrait à Docker desktop. On se demandait, est-ce qu'il y a des nouveaux coups qui sont occasionnés par ces fonctionnalités et est-ce qu'il y a déjà aujourd'hui, un intérêt aux chimiser ses coups et si oui, quels sont les leviers que tu as pu mettre en oeuvre qu'il parvenir? Oui, donc Gordon, c'est un outil intégré à Docker desktop. C'est Gordon, c'est le nom, on a donné à l'assistant, c'est un produit de généia et assez classique aujourd'hui, qui consiste à avoir l'ensemble des données autour de l'utilisation de Docker pour qu'on puisse y déposer des questions. Ce que Docker faut pas se mentir, c'est quand même compliqué. D'accord? D'accord? Avoir l'ensemble des flags, des optimisations, ça demande du temps. Si vous regardez la plupart des Docker files qui sont des composifales qui sont écrit dans le monde, c'est des sujets qui sont assez. Ils sont en général assez mal écrit, parce que c'est compliqué tout simplement. Et aussi que c'est un métier de savoir à écrire ce genre de choses. Et puis aussi, on fait des innovations permanentes dans l'engine et dans Docker en général. Et donc du coup, il faudrait presque avoir une formation de permanence pour peut-être toujours optimiser ces images. L'idée de Gordon, c'est, voilà, vous avez à votre service, un espèce de chatbot assez avancé qui vous permet de ne pas avoir à vous former un Docker en détail ou je vous posez les questions sur l'optimisation de Docker file et vous répondent et puis vous avancez avec ça. Donc c'est un produit de généia et qui tourne sur Openair et aujourd'hui, essentiellement, à travers Azure, en termes de ma infrastructure, parce qu'à mesure, propose des services autour de Openair qui sont très très stables. Et tout le monde, on a assez content de ça. On utilise le sas de Openair directement avec. Si vous vous parlez des couplures chez USH, du S-Hitwan, chez Openair, il récemment, ça a été assez. du vidéo et des bas, des couplures complètes en plusieurs minutes, plusieurs fois. Et donc du coup, avec les instances chez Azure, de Openair, on arrive à avoir un truc de stable. Donc les coups de Gordon, c'est assez simple, c'est pas très élevé. Gordon, il y a pas mal, il y a 15 000 questions qui sont posées par jour, donc c'est un outil qui est relativement et moi, utilisé, qui est assez début, qui sont des coups très très raisonnables. On est moins de 300 euros par jour, à peu près sur en tout cas, les coups purement opérationnels autour de l'AI. Donc ce n'est pas un des sujets sur lequel j'ai envie d'optimiser, très beaucoup, ou pas beaucoup, envie d'optimiser. Les leviers vont être essentiellement de baser ces calculés en gros, combien de coups tu ne question pas. On vous convient une côte à l'utilisateur. Et donc ça, moi, je vais regarder ça. On se voit. Alors qu'on a des réclimités, bien sûr, à la base, dans ce genre d'application, c'est effectivement faire du réclimité, donc de limiter le nombre de interactions si des gens en abusent, telles manières, parce que ça reste. ça reste subtisable pour tout le monde. On n'est pas là non plus pour fournir un service autour de planéries, gratuitement, tout le monde. Alors y'a un tel billet Gordon, réconcentiellement des. question tout d'ockeur, vous ne pouvez pas les questions autour d'autre chose, il va vous dire maintenant, on va vous répondre là-dessus, donc c'est pas un d'opinier, bien sûr, complet, mais vous avez, c'est très taineté d'ockeur, donc on mesure les coups par utilisateur, effectivement on va regarder la flène de contexte, mais on va dire bon maintenant ça va plus, on utilise soit, on limite soit en compacte, la flène de contexte c'est classément, et puis les modèles providers, on va négociper encore là-dessus parce que les coups sont assez faibles, donc voilà, si moi je passe une journée négociée, ça n'est plus cher que le signe, je n'utilisais pas, donc ce qu'on va faire par contre, c'est qu'on va essayer de utiliser le bon modèle, en termes de coup par rapport à l'utilisation qu'on a, donc on a, le Gordon à un 4/5 type de question différentes, on utilise des modèles différents, je sais pas, on fonctionne, on voit un duo mini, on pense à un type de question, des modèles un peu plus compliqués pour d'autres, aujourd'hui c'est scopable. Super, merci Jean-Laurant, donc on a parlé de la Finops dans le cadre du déploiement de la généia avec des outils comme Gordon que tu viens de mentionner, pour finir, on est m'intéressé à l'inverse, à ce que les ailles peuvent apporter à la discipline Finops, et on peut commencer par donner notre perspective chez Optima, nous on développe un cool Finops qui fait la gestion automatisée des engagements financiers, un type RZE instances et saving splans chez AWS, et on a pris le parti de ne pas faire d'agentique dans ce cadre, on utilise du disons du machine learning plus traditionnel avec par exemple du forecasting de paie de séries pour projeter les coups, on s'inspirent du réinforcement learning pour le moteur de décision qui a au coeur de notre service et qui recommande les engagements, mais sinon c'est surtout de l'optimisation assez conventionnelle, donc pas de l'élème, pas d'agent généia, et pourquoi, parce qu'on s'appuie sur la donnée d'usage et de la donnée pricing, qui est de la donnée finalement tablulaire très structurée et qui répond à des mécaniques qui sont très déterministes, et c'est aussi de la donnée qui est volumineuse, et donc, à tendance à faire halluciner les ailles-lèves et les agents. Et avec ce qu'on fait, c'est-à-dire la prise d'engagement financier, avec des impacts financiers potentiels importants pour nos clients, on ne peut pas vraiment se permettre d'approximation d'allucination ou des réinvents. Donc pas l'agentique chez au CIMA, mais ça c'est notre positionnement, en plus qu'à date aujourd'hui, comme tu l'as soumouvé et chose évolué très vite. En tout cas, on était curieux d'avoir ta perspective de savoir d'après-t-toi ce que le LIA et l'agentique peuvent apporter à la discipline finance. Qu'est-ce qui, d'après-t-toi, peut être automatisé ou qu'est-ce qui au contraire va rester de l'ordre de l'humain, en tout cas à court et moyen terme? Donc, j'ai pas un diplôme en finance encore une fois, mais c'est vrai qu'on peut essayer de faire apparailer entre comment on utilise lia dans ma engineering et comment ça peut s'appliquer à l'eau de discipline. Un truc qui est assez marquant avec l'engineering, c'est que aujourd'hui, on va jamais laisser unia pouscher le directeur en production de l'air. Au mieux, on va lui demander d'aller, et vente-tu moins qu'il rêve du code, ok, très bien. Mais finalement, le comité le pouche dans la 90% à 95% des cas, c'est comme un humain qu'il le fait. Et notamment, alors peut-être on va utiliser lia, notamment on utilise beaucoup ça à d'ocœur sur des poules récoestres vues, donc vous avez l'IA qui va analyser le code, vous faites une enquête. C'est très utile dans un car, c'est assez résime dans d'autres. Et effectivement, si t'appliques ça à des données financières, notamment des données structures avec un utilisé, je serai assez prudent comme vous l'êtes. On se que l'IA est là pour nous aider à aller plus vite dans un moment de sujet, l'IA c'est quand même fantastique parce qu'on change un peu d'interface, ou aller d'avoir des interfaces avec des boutons et des données structurées, on se retrouve à être capable d'apprécier du texte, c'est ça l'interface d'open-in putt et d'un putt avec un ear, c'est un peu balancé du texte, et on a ou à avoir un output du texte. Sur des données structurées, effectivement, je pense que c'est assez dangereux. Nous, en tout cas, aujourd'hui, on est actuel des choses. Alors, il y a toujours des gens qui vont vous raconter que tu peux utiliser une lélème asoge, donc c'est une lélème qui va vérifier le résultat de l'élème qui, du coup, serait capable de arriver à un résultat plus intéressant. On a fait beaucoup d'essais à d'ocœurs aussi, ou par exemple, on faisait une boucle avec des agents dans lequel on essaie d'avoir un résultat, mais si on faisait la boucle plus une fois, on avait un résultat qui était assez nul, sur le bout que le deux fois, on avait un résultat qui était plutôt bon, si tu sais, la boucle mille fois, t'avais un résultat qui était parfait, enfin pour un coup, là, c'est quand des lents. Donc, effectivement, peut-être qu'on pourrait arriver en faisant tourner mille fois dans des boucles de vérification des résultats intéressants, aujourd'hui, au regard des coups, ça me semble assez complexe, à être très intéressant. Je pense que l'IA est toujours là pour nous assister. Donc, à voir par exemple, nous, on a un outil en interne, ça fait le profet AI qui est assez sympa, qui est en cas de sécurité, nous permet de. Quand on a un problème de sécurité, qui nous permet de drill down sur l'ensemble, qui va analyser, il va faire la corrélation entre des données auquel on n'avait pas conseillé. Donc, à moi, il va regarder les logs, AWS, avec les IPs, on est où des choses qui viennent de l'IT pour nous permettre de dire "Bat, il y a un tel gars, c'est connecté depuis tellement mois, il a fait tel opération, il a eu une expération privilège, un tel en moment, c'est pas quelque chose qui est d'habitude du visual et tu peux drill down sur ces éléments. Mais là, encore une fois, il n'y a pas de prise de décision, l'IA va être servi, d'un régateur, de l'ensemble des éléments, il va te donner un sonarie ou un résumé assez intéressant d'information qui serait trop difficile à regarder en détail." Donc là, il y a un vrai intérêt à utiliser l'IA pour faire de la résumé et donc permettre d'un réel down vers après à la fin de la décision cette fois qu'il apprend et tu dois avoir les données brut sans être sans qu'elles soient interprétées par l'IA. Donc ça, je trouve que cet aimèl, c'est tellement comme profiterie auxquels je n'ai pas la lavé de la séquion. Ce n'est pas l'appliquer ça à la sécurité, il est assez intéressant et qu'elle peut part la sécurité et la finance des deux sujets sur lequel tu ne veux pas que le machinelle, parce que le truc tout de ça, que tu veux que ce soit toi qui prenne des décisions. Et donc je trouvais de parallèle peut-être visual vous le direz, ce que vous avez passé. Ouais, on est assez d'accord avec toi, tout ce qui est finance et sécurité. On a un tel besoin de contrôle qu'aujourd'hui, alors je récurieux, qu'on se repose cette question dans six mois vu la vitesse à laquelle ça va, mais aujourd'hui, on a encore ce besoin de contrôle et on est encore sceptiques à confier ces tâches-là à des systèmes qui peuvent à l'ufiner ou qui ont encore un taux d'erreur qui existe. Mais oui, oui, je pense qu'on se rejoint sur ce constat. En tout cas, bon, c'est vraiment intéressant de soulever avec toi, je en le rend le capot d'un service comme d'ockeur qu'on utilise tous tous les jours et de comprendre du coup les détails de ton approche finance. Merci pour cet échange, un grand merci. C'était riche en enseignement et en adhéglotte. Donc merci à toi, je en le rend. Merci, c'était toujours un kilo d'organes avec le langue de vous qui aient des spécialistes de la finance. La structure à son question est l'usage et hyper intéressant. Je pense que chaque vie de Pien de générique a de toute façon besoin de comprendre ce domaine-là et c'est souvent un sujet à son échange. On ne pense pas forcément. Donc c'est assez critique et c'est moi, c'est quelque chose que j'ai appris sur le tas. En tout cas, il y a un filet de la finance parce que j'ai dit plusieurs fois dans l'entretien. Et je pense qu'effectivement, c'est assez critique comme sujet et un peu oublié. On pense plus à scaling des équipes d'adenerying, des outils, comment faire scaleer son s'essayé qu'il comment recruter, etc. Mais la finance est un vrai pain de la responsabilité du vie. On est bien d'accord avec toi. Merci à toutes et tous de nous avoir écouté. On vous donne rendez-vous au Tech Rock Summit, les premiers et deux décents de 2005 au théâtre de Paris. À bientôt. [Musique]