Du mindset “reboot” à la gouvernance FinOps à l'ère de l'IA

0:03 Chaque 100 000 gagnés, c'est des mois de plus de salaire ou de survie d'entreprise, le temps de retrouver. C'est le bazar et quelque part, je me fiche pas mal que ce soit le bazar. Et pourquoi? C'est parce qu'en fait, je pense que, à mon humble avis, l'IA est en train de transformer la façon dont on est en train d'écrire du software aujourd'hui. Bonjour à toutes et à tous, bienvenue sur ce nouvel épisode du podcast Tech.Rocks. Je suis Fabien Punin, cofondateur et chief data officer d'Opsima. Un outil FinOps qui permet de réduire sa facture cloud sans toucher à son infrastructure. Je suis également accompagné d'Alexandre Lacroux, lui aussi cofondateur et CTO d'Opsima. Et aujourd'hui, nous avons le plaisir de recevoir Jean-Laurent de Morlhon, Jean-Laurent est SVP Engineering chez Docker, 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 FinOps. Bonjour Jean-Laurent. Bonjour à tous, ravi d'être avec vous aujourd'hui. Et on est ravis également. Jean-Laurent, d'ici quelques minutes, on va aborder ton parcours, ton expérience FinOps au global et notamment chez Docker.

1:11 On parlera également de FinOps en lien avec l'AI, la Gen AI et l'agentique, qui sont des sujets qui passionnent les foules et qui préoccupent aussi beaucoup de CTO et de tech leaders en ce moment. Mais avant d'entrer dans le vif du sujet, Jean-Laurent, est-ce que tu pourrais commencer par te présenter? Oui, merci Fabien. Bien, ce n'est pas la première fois que je passe dans des podcasts chez Tech.Rocks, donc peut-être qu'il y a des gens qui me connaissent déjà un petit peu, donc je vais faire court. Jean-Laurent de Morlhon, 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 l'anecdote que je disais à ma femme, ne t'inquiète pas, c'est une startup, je suis là pour 2-3 ans, je vais aller faire autre chose. 10 ans plus tard, je suis toujours là. Donc j'ai l'impression un peu moi de vivre le monde à travers les lunettes qui sont celles des conteneurs. Donc à Docker, ce que j'ai fait, sur 10 ans, la carrière bouge un peu. J'ai démarré sur l'ingénierie, purement sur l'outil Docker Desktop aujourd'hui. Mais assez rapidement, notamment en 2019, j'ai pris les rênes de l'ensemble de l'ingénierie avec Scott Johnson, le CEO, quand on a fait une restructuration de l'entreprise.

2:17 Et à ce moment-là, effectivement, c'était un rôle de VP Engineering, donc classique autour de gérer les équipes de développement. J'ai fait ça pendant cinq ans et puis l'année dernière, on a un peu rechangé de nouveau la structure de la boîte avec un nouveau CEO. Aujourd'hui, je gère les projets de générer. Donc, pourquoi je suis là aujourd'hui avec vous? Pendant cinq ans, de 2019 à 2024, j'ai géré l'ensemble de l'engineering. Et quand tu gères l'ensemble de l'engineering, effectivement, à un moment donné, il y a des conversations avec les ops, avec la finance autour de, dis donc Jean-Laurent, pourquoi on dépense autant d'argent là? D'un côté, la finance qui arrive là-dessus et les ingénieurs de l'autre côté qui disent, je ne pourrais pas avoir un peu plus accès à cet outil ou ce truc-là. Et effectivement, je trouve que... C'est un bon sujet, si on mixe ça en plus avec les haïs derrière, qui à ce moment-là fait commencer à tourner la tête, de discuter de ces sujets-là. Donc aujourd'hui, je gère les projets Généaï chez Docker, mais avec une grosse expérience pendant cinq ans d'avoir géré une équipe d'ingénierie qui passait de 70 à à peu près 200-250 personnes, donc avec un scale sur 4-5 ans.

3:20 Voilà, tous les aléas et les joies autour de ce genre de scale dans un monde multifuso horaire, puisque Docker, c'est l'ingénierie, c'est la côte ouest des États-Unis, donc San Francisco aussi à tel, jusqu'à ce qu'on a des gens en Bulgarie, un fuseau horaire assez intéressant. Ça va être super intéressant de rentrer dans les détails de tout ça. Jean-Laurent, Docker a pas mal évolué en tant qu'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 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 de n'importe quel type de base de données ou n'importe quel type de serveur web, en général, vous les récupérez du Docker Hub. Donc, up.docker.com. Et en fait, dans les commandes Docker, on fait qu'un Docker pool à Nginx, quelque part, ou Docker pool MongoDB. Et c'est un petit peu la magie de Docker.

4:21 C'est-à-dire, avant ça, c'était quand même compliqué de faire tourner une base ou un système. Et la promesse, la magie de Docker, quelque part, c'est que tu fais… ton produit n'est qu'un Docker pull away de là où tu es. Donc Docker pull Nginx et boum, c'est là. Effectivement, pour faire un Docker pull Nginx, MongoDB ou quoi qu'est-ce, ça demande un certain nombre d'infrastructures pour que ça marche partout, etc. Donc effectivement, Docker Hub, c'est une partie vraiment centrale dans l'infrastructure. C'est en termes de coûts, mais aussi en termes de compute, qui permet, je ne sais plus combien on a, mais je crois de mémoire, on avait quasiment 50 000 pulls par seconde. Donc, c'est une infrastructure assez sympa. Si vous êtes un génie, C'est un endroit marrant à travailler puisque vous êtes sur des contraintes assez costauds. Donc ça, c'est une première partie. Comment tu fais pour ce qu'elle est? En plus des images, là, Ngenix, c'est bien, tout le monde s'en sert, mais en fait, on poste aussi n'importe quel type d'image poussée par n'importe qui, ou quasiment. C'est gigantesque. Je crois qu'on est à plus de 10 petabytes de données. Plus pour la petite histoire, les images Docker, c'est assez rigolo parce que finalement, c'est constitué de couches et les couches sont communes parfois à certaines images.

5:27 Par exemple, un Ngenix de plusieurs versions 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 l'appartenance est commune à plusieurs images. L'autre partie, c'est Docker Desktop. Docker Desktop, quasiment 5 millions d'utilisateurs. Il y a beaucoup de gens qui s'en servent. Et notamment, dans Docker Desktop, tu me diras, oui, mais ça tourne sur ton laptop. Je dis, non, qu'est-ce qu'on s'en fout? En fait, on ne s'en fout pas parce qu'on met des mises à jour régulièrement et il faut les télécharger. Et rien n'est gratuit. Comme l'ensemble de notre infrastructure, à la fois sur Hub, mais aussi pour Docker Desktop et sur AWS, Nous, on paye chaque petit octet qui part de chez AWS et qui arrive chez les gens qui s'en servent. Il y a des coûts assez importants autour de Docker Desktop et notamment de l'optimisation des mises à jour et compagnie. La dernière partie, c'est que dans des entreprises qui ont un certain âge comme Docker, elle est faite d'acquisitions. Notamment, on a fait des acquisitions dans lesquelles une entreprise qui s'appelle Atomist, qui gère aujourd'hui notre produit Docker Harden Image, est entièrement sur Google Cloud.

6:28 Donc, on a aussi une toute petite partie sur Google Cloud. Google Cloud chez Docker. Évidemment, comme c'est une grosse boîte, on a aussi un tout petit bout quelque part sur Azure, mais c'est vraiment minime, minime. 90% de notre infrastructure est sur AWS, on va dire 10% en gros à la louche sur Google Cloud. C'est essentiellement, en termes de coûts, c'est essentiellement du storage, puisque 12 péta-bytes avec l'ensemble des inputs-outputs qu'il doit y avoir, c'est assez conséquent. Mais on a pas mal de compute aussi, parce qu'il y a du scale sur Docker Hub, sur les autres parties. Oui, Docker, c'est une techno qui est absolument omniprésente dans le monde de l'infra aujourd'hui. C'est à l'origine, finalement, c'est devenu synonyme de containerisation, donc c'est assez fascinant de pouvoir soulever un peu le capot de l'infra de Docker avec toi. Jean-Laurent, tu as été au cœur d'un impressionnant pivot chez Docker, 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 Docker et l'infrastructure tech de Docker.

7:31 Est-ce que tu peux nous raconter cette expérience, et notamment via le prisme FinOps de la rationalisation de l'infrastructure, de la rationalisation des coûts? Est-ce que tu peux nous dire quelles ont été ta méthode et ton mindset FinOps en but d'adresser ce chantier? 2019, effectivement, l'entreprise n'est pas en grande forme. On a déjà changé de 2-3 fois de CEO à ce moment-là. L'entreprise passe de à peu près 500 personnes et on va dire un milliard de valuation à peu près. On redémarre la boîte avec 70 personnes, c'est-à-dire une cible cliente différente et une valuation qui est en dessous des 100 millions. Donc effectivement, on va dire… On était en live support, comme on dit en anglais à ce moment-là, et c'était un petit peu, OK, comment on fait pour refaire redémarrer ce bateau? C'est le moment où, effectivement, il y a le virage avec Kubernetes qui prend beaucoup d'ampleur, et Docker, à ce moment-là, se restructure sur le poste de développeur. En fait, un conteneur, c'est génial de tourner en production, c'est fantastique. Mais l'idée, c'est comment on peut faire pour que, finalement, ce qui se passe sur ta machine en tant qu'ingénieur, ce soit le plus proche possible de la réalité, sachant qu'effectivement, c'est impossible, puisque ce n'est pas la même chose, mais en tout cas, comment on fait pour s'en approcher le plus possible.

8:44 La promesse, c'est si tu es capable d'avoir ton conteneur qui contient 100% de ce qu'il va contenir quand il sera en production, tu seras un peu plus proche que si tu livrais juste des binaires comme on faisait à la belle époque. Quand tu en pars d'une boîte comme ça, il y a un côté humainement difficile quand tu passes de 500 à 70 personnes. Donc, une grosse partie, la plupart des gens sont partis dans une entreprise qui s'appelle Mirantis, qui ont fait toute une partie, justement, cloud, control plane, au-dessus de Kubernetes et de Swarm à l'époque. Et donc, il n'y a pas eu de licenciement massif. Mais enfin, quand même, tu pars, tu changes quand même de structure d'entreprise. Et notamment, tu pars avec un runway qui est assez court. Le renoi dans les startups, c'est l'argent que tu as jusqu'à ce qu'il n'y en ait plus et que tu ne peux plus payer ni tes salaires ni ton infrastructure. Et donc, Quand tu es dans ce type de mindset, tu es dans un mindset de reboot, de redémarrage. Et quelque part, tu dois faire des coupes drastiques pour, entre guillemets, survivre. C'est l'état d'esprit. L'idée, c'est le bateau coule, comment tu fais pour t'en couper un morceau et tu repars avec un bout de radeau et comment tu fais pour retrouver un bateau un peu plus tard.

9:50 Donc là, je ne veux pas sur le côté humain difficile de ce truc-là, ce n'est pas le sujet. Mais c'est vrai que ça nous a drivé au moment du mindset. Tu te retrouves avec, avant, tu avais, on va dire, 10 équipes qui géraient l'ensemble de l'infrastructure, et tu te retrouves avec 4 gars dans un coin que tu connais à peine. Donc, il y a aussi un petit peu ça. Donc, quand tu es dans ce genre de situation, quelque part, moi, je me rappelle avoir eu les lauriers de l'équipe finance un moment donné en me disant, c'est fantastique, tu as sauvé tant d'argent en réduisant du coup d'infrastructure, parce qu'effectivement, si vous êtes un financier, vous vous dites, j'ai deux ans, trois ans, un an de renouer devant moi. Les coûts d'infrastructure sont importants, c'est plusieurs millions de dollars par an. Donc, effectivement, chaque 100 000 gagnés, c'est des mois de plus de salaire 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 ou quoi que ce soit, c'est juste que c'est un truc de survie. C'est-à-dire qu'à un moment donné, tu te dis, bon, OK, à quoi ça sert toutes ces choses-là?

10:51 Et bien, tu coupes. Et c'est critique? Oui, tu gardes. Ce n'est pas critique. Tu coupes et puis tu verras plus tard ce qui se passe. Pourquoi notamment c'est important de faire ça dans cet esprit-là et pourquoi je le dis là? C'est parce qu'en fait, quand vous passez une entreprise de 570 avec un scope qui est différent, vous vous retrouvez avec énormément de services qui n'étaient pas utiles. On faisait tout un tas de trucs 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 dans des systèmes de staging ou interne, et ensuite pour passer en production. Donc en gros, un des gros coûts, c'était effectivement nos dépenses AWS. Et là, on fait un... découpe à plusieurs centaines de milliers de dollars de sauvegarde, ce qui a rendu très heureux les financiers et qui, moi, me semblait assez facile. Typiquement, on avait un compte Amazon qui était entièrement dédié au système de développement, où les ingénieurs déployaient leur système. Et on avait un compte Amazon complètement différent pour la production, les questions de sécurité et autres. Effectivement, quand on a fait ça, on a coupé très fort.

11:52 Et c'est là où j'ai eu les lauriers de la finance. Alors que finalement, quand vous regardez d'une boîte de 500 à 70, c'est facile, tu coupes, il y a plein de trucs. Effectivement, quand on a tripatouillé là-bas dedans, on s'est rendu compte qu'il y avait beaucoup de choses. On regarde quand même chaque service, on fait la liste de tous les instances OC2, de tous les storage, etc. Donc ça prend un certain temps, ça ne s'est pas fait en 5 minutes, ça nous a pris je pense 2-3 semaines. Mais effectivement on a retrouvé par exemple un truc rigolo, c'est à une époque, Docker, on avait un interface entre Docker et Minecraft, et donc tu pouvais voir, te promener dans un monde 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 de serveurs Minecraft qui traînaient, 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 OC2 à 10 euros, 10 dollars par mois, qui tournait comme ça depuis des années. Donc là, effectivement, avec un coût très faible d'investigation de ton côté, tu es allé à la finance qui te saute au cou en disant« Ah, vous êtes formidable! » Non, pas du tout, mais ce n'est pas grave, c'est comme ça. Donc effectivement, quand tu es dans une restructuration de boîte, aller regarder les dépenses et tout couper court, je pense que c'est assez intéressant.

12:58 Ce n'est pas forcément très difficile à faire. Je vais être un peu critique. On avait plein de services, on repart essentiellement avec Docker Hub, donc c'était tout tourné autour de ça, et puis Docker Desktop aussi. Mais Docker Desktop, c'est surtout du storage, c'est essentiellement du S3, on crée en interne dans le CI des builds de Docker Desktop, on les store sur S3, et ensuite c'est juste le management. Donc le côté desktop, c'était relativement simple. La partie hub, c'était un peu plus complexe. Oui, ça doit être assez enrichissant, du coup, cet épisode de restructuration, avec du coup pas mal de challenges FinOps. On dit d'ailleurs de la FinOps que c'est une discipline qui est à la frontière entre l'engineering et la finance, deux mondes qui se parlent 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 à s'intéresser à l'efficience financière? Et on se demandait quels étaient concrètement les leviers dont tu disposes pour y parvenir. Donc moi, je n'ai pas un diplôme en FinOps. J'ai eu une expérience terrain autour de ces quelques années à gérer ça.

14:02 Et au début, il y avait effectivement toute la restructuration d'entreprise, mais ensuite derrière, le scale-up de 70 à 200 personnes, pas forcément des besoins et tout ça. Donc effectivement, tu essaies de comprendre un peu où vont les coûts. Il y a une partie qui est assez rigolote avec la finance, c'est que la plupart des équipes financières ne comprennent pas grand-chose à l'engineering. Tu peux arriver, leur raconter des belles histoires, ils vont faire« ok». 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 te dois justement de faire cette transformation, de faire en sorte qu'effectivement les coûts qui sont demandés ou les dépenses qui sont faites, elles sont logiques, alignées avec la stratégie de l'entreprise. Parce que c'est super facile de débouler dans la finance et de dire« Oui, non, mais j'en ai super besoin parce que c'est un serveur critique, la base de données, c'est important, vous comprenez, blablabla. » 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 avec le produit, ceux qui sont du produit qui nous écoutent aujourd'hui, qui se font, on va dire, avoir par des... des demandes d'ingénierie, on peut faire avec la finance, c'est encore plus facile à faire.

15:04 Donc en tant que VP ingénierie, tu es un peu le garant de ce truc-là, et de faire en sorte que les coûts sont maîtrisés. Encore une fois, le mindset au départ chez nous, c'était il faut survivre, donc on va couper les coûts. Donc ça, c'était assez facile finalement de sensibiliser les gens à ça. Et après, moi je me rappelle sur Docker Desktop, c'est assez intéressant, personne n'avait vraiment d'idée des coûts que représente le téléchargement d'un Docker Desktop. A l'époque, Docker Desktop, il devait bien faire dans les 500-600 mégas, l'installeur tout seul. Et effectivement, tu te dis, il y a chaque personne qui télécharge Docker Desktop. Donc aujourd'hui, on a 5 millions. A l'époque, je ne me rappelle plus combien d'utilisateurs, probablement 3 ou quelque chose comme ça. Tu te rends compte que tous les mois, il y a un certain nombre de gens qui téléchargent ce machin-là et que tu payes chaque octet. Donc, par exemple, une phase de sensibilisation facile avec l'équipe desktop qui disait, nous, c'est bon, on n'a pas de coût, on n'a pas d'instance, on n'a pas d'instance C2, on n'a pas de coût à part du stockage, c'est facile. Tu leur fais prendre des conséquences, tu leur dis, alors, combien vous avez de téléchargements aujourd'hui? Ah oui, c'est pas mal, super. OK, chaque téléchargement, ça coûte ça. Donc, voilà, chaque jour d'opération de Docker Desktop, ça coûte, je ne sais pas, 10 000 balles, 20 000 balles, je ne m'en rappelle plus les prix.

16:08 Et donc, du coup, tu les sensibilises. Qu'est-ce qui se passe après ça? Quand tu as des ingénieurs qui sont conscients, ou que tu mets en place cet état d'esprit en discutant avec eux, en leur montrant simplement le coût, ils sont arrivés en réduisant déjà la taille de Docker Desktop. Effectivement, les téléchargements, plus 500 mégas, mais je ne sais plus. Combien de Docker Desktop aujourd'hui? Je ne l'ai pas regardé récemment, parce que je ne fais que de la GNI maintenant, mais on doit être entre 200 et 250, ou même peut-être un peu moins. Et donc ça, déjà, tu divises par deux tes coûts 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échargeant l'ensemble du binaire à chaque fois, on a fait tout un travail de mise à jour différentielle. 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à. Faire ça aussi, ça nous a permis de faire des gains d'argent directement.

17:11 Et donc, comment tu fais ça? C'est simple, c'est relativement simple. C'est-à-dire que tu montres les coûts, tu fais prendre conscience aux gens. C'est essentiellement de 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, vous avez déjà entendu ça à 15 fois, avant de télécharger un outil, ils vont dire, attends, moi, je peux le faire. Moi, je sais le coder, ce truc-là. Je n'ai pas besoin de l'acheter. Je suis trop fort. Et ce mindset-là, il amène à se dire, pourquoi j'achèterais quelque chose? C'est tout le délire qu'il y a autour des IDE, où la plupart des systèmes d'environnement de développement sont gratuits. Aujourd'hui, JetBrains, merci, arrive à survivre dans ce monde-là, et survit plutôt pas mal. Mais quelque part, il n'y en a pas beaucoup qui vivent dans ce monde. Visual Studio Code, c'est gratuit. Xcode, c'est gratuit. Tous les gens sur Mac vont me dire, mais non, je ne suis plus de pays. J'ai un abonnement si je veux déployer. OK, mais bon, l'Xcode lui-même me permet de déployer localement sur ta machine gratuitement. Donc, on vit quand même dans un monde, en plus, baigné d'open source, où effectivement, la frontière entre le gratuit et le...

18:15 Est quand même assez ancré. Et donc, les gens pensent effectivement que Docker Desktop, c'est entièrement gratuit, ou en tout cas, le coût d'utilisation de ce genre de produit gratuit. Mais à chaque fois que vous téléchargez quelque chose, il y a quelqu'un qui paye la facture. Ç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 hub, on va dire, et puis une équipe desktop, en gros, avec 70, la sécurité, il y a des trucs autour, mais en gros, c'était ça. Bien sûr, toute une partie engine, historique Docker avec l'open source, le Docker, le produit open source. Et quand tu scales, tu te retrouves à avoir plusieurs produits. Aujourd'hui, j'en ai parlé, on a un produit qui s'appelle Docker Harden Image, on a un produit de build, on a plusieurs produits qui tournent sur le cloud et qui chacun vont dépenser un peu de C2, donc un peu de compute, un peu de storage. Et tu as envie de savoir un petit peu qui dépense quoi et comment ça se passe. Après, tu auras une espèce de vision. Tu vois tes coûts avancer, augmenter. Notamment, on va en parler, je pense, dans les négociations avec AWS. Et toi tu as envie de savoir un petit peu comment ça se passe et notamment comment te projeter dans l'avenir. Parce que par exemple quand tu démarres un nouveau projet cloud, qu'est-ce que ça te coûte? Est-ce que c'est peanuts par rapport au coût d'infrastructure des produits existants qui sont excessivement consommés ou pas du tout?

19:20 Et donc ça, on a commencé à prendre tout un... Au début, moi, j'étais complètement aveugle, puisqu'on avait fait ça en mode, encore une fois, réduction de coûts drastiques sans chercher à analyser. Donc, j'avais tous les coûts de ces deux. tous les coûts de storage qui étaient mélangés, j'étais incapable, par exemple, au tout début, de distinguer les pools qui étaient faits du hub des pools de Docker. Et donc ça, on a commencé à taguer l'ensemble des ressources qui étaient créées. Donc ça, à chaque fois que vous créez une instance de CD, vous la taggez avec le nom d'un produit, le nom d'une équipe. Nous, on a fait les noms des équipes au début, comme ça, c'était relativement simple de regrouper après dans des queries. Moi, j'ai un dashboard qui me dit, tiens, les coûts du produit X, il m'a coûté tant, le hub, ça me coûte tant, en storage, en compute, etc. Et ça, ça prend du temps parce qu'effectivement, dans une entreprise comme Docker, avec une centaine d'ingénieurs, des trucs, on déploie toutes les cinq minutes. On arrête aussi toutes les cinq minutes, il faut aligner tout ça. Donc ça, c'était un temps d'investissement d'ingénierie assez conséquent. J'ai trouvé ça super intéressant ce dont tu as parlé avec Docker Desktop, parce que je trouve qu'on dit souvent que les développeurs se fichent des cours.

20:23 Mais je trouve que dans l'engineering, 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 chaque mise à jour coûte de temps et sur les X mises à jour par jour qui sont effectuées, ça adopte assez rapidement. Quelque part, ça peut suffire à déclencher le bon comportement. Pour les ingénieurs, on n'a pas besoin de mettre d'incentive, de programme en place. J'ai trouvé ça super intéressant. Et l'autre aspect aussi, c'est que finalement, ton initiative de réduction de coût, elle donne lieu à moins de patchs, à des mises à jour plus rapides. Et donc, ça a un effet aussi bénéfique sur l'expérience utilisateur. Je trouve intéressant aussi de démarrer par les coûts et d'atterrir à quelque chose qui impacte positivement les users. Et sur le tagging, sinon, c'est vrai que c'est quelque chose qui remonte assez fréquemment comme initiative vraiment cœur dans le FinOps, parce que finalement, c'est ce qui permet de faire le pont entre l'engineering et la finance.

21:27 C'est ce qui permet d'attribuer des coûts. 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 revient assez fréquemment. Jean-Laurent, tu as parlé à quelques reprises d'AWS, qui est un des trois grands hyperscalers, un des trois grands hyperscalers de l'international. On comprend que les budgets cloud d'un acteur de l'envergure de Docker sont assez colossaux, ça parle de plusieurs millions. Quelle est ta relation avec AWS et quel est ton bargaining power ou ton levier de négociation avec AWS? Comment est-ce que tu approches les dimensions achat et négo? Alors ça, c'est vraiment, j'ai appris sur le terrain et puis à la dure, en ayant tout d'un coup la responsabilité de l'ensemble des coûts. Donc, c'est intéressant ce que tu poses comme question, parce que moi, je m'étais imaginé qu'en tant que docker, on avait une puissance de négociation phénoménale. Et en fait, on est un petit acteur. Donc Docker, c'est plusieurs millions de dollars par an de dépenses pour faire tourner Docker et Docker Desktop, et plus l'ensemble des autres services qui sont autour.

22:33 Et en gros, assez rapidement, on se rend compte que la négociation avec Amazon, elle est autour de quelle est la progression que tu vas faire de dépenses chez eux. C'est pour ça que c'était hyper intéressant avant de taguer et de comprendre, parce que du coup, toi, tu peux éventuellement te projeter en te disant, ce service-là, moi, je sais que je ne vais pas trop investir dedans. Donc je sais que mes coûts vont, comme je les ai tagués, je les ai dans mon dashboard, je me dis ces coûts-là, je sais à peu près les connaître. Et par contre, je sais que par exemple, quand je crée des nouveaux produits, ça va me coûter tant, un million. 100 000 ou 500 000 ou 200 000 ou 100 000. Et donc, du coup, je sais que si je commence 5 nouveaux projets, ça va me coûter ça. Et donc, du coup, j'arrive avec la négociation avec Amazon en disant, je sais que cette année, je vais probablement dépenser dans ces zones. Donc, moi, la négociation se faisait tout aux US. Donc, j'avais des gens qui étaient tout en détail, qui m'aidaient dans ces négociations-là. Mais en gros, tu dis, je vais dépenser tant cette année, donc disons 7 millions de dollars, par exemple. Et l'année dernière, je dépensais 6. Et 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 eux.

23:36 Le bargaining power, il est un petit peu, c'est-à-dire que tu peux essayer de jouer sur du multi-cloud, tu peux essayer de jouer, nous on a travaillé avec Cloudflare et Amazon, et donc de temps en temps, on prenait des services de Cloudflare, on prenait des services d'Amazon. Quand tu fais ça, il y a une dimension commerciale, effectivement, comment tu négocies avec l'un ou avec l'autre. Il y a aussi une dimension engineering. Si tu dis, maintenant, j'utilise des services chez Cloudflare ou j'utilise des services chez Amazon, il y a des ingénieurs derrière qui vont faire le boulot pour que ça fonctionne. Donc, tout ça est assez complexe. Tu es dans un gros back-bow qui avance plein de balles. Et si tu veux le diriger, il faut prendre des mesures importantes en amont des négociations. Moi, je sais que la négociation, elle était toujours autour de mars chez nous. Donc ça, c'est des choses qu'on se préparait. Fin décembre, mi-décembre, j'avais mes dashboards complets et on regardait quels allaient être nos coûts. Grosso modo, j'ai envie de dire, quelque part, c'était entre guillemets sans stress. Dans le sens où dans un service qui est aussi utilisé que Docker, tu as une progression naturelle des usages et donc des coûts.

24:44 En gros, tu as 10-15% de progression par an, c'est quasiment entre guillemets sans rien faire. C'est-à-dire maintenant, si tous les ingénieurs qui m'écoutent en me disant« Mais non, qu'est-ce que tu parles? » Juste maintenir, c'est déjà des coûts. Oui, je sais, mais d'un point de vue purement finance et négociation, quelque part, tu sais déjà que tu vas te prendre en compte. de 10 à 15% dans la tête de progression. Et après, c'est à toi de négocier à la marge l'ensemble des éléments. Mais il y a un lock-in fantastique, c'est-à-dire dans un service comme Amazon. Moi, je sais qu'au début, quand j'ai repris les rênes de la boîte en 2019, on a regardé en se disant, OK, nos couches sont sur Amazon, juste par acquis de conscience. Qu'est-ce que ça ferait si on partait chez Azure ou si on partait chez GCP à l'époque? Et donc, je sais que trois fois, ou trois ou quatre fois, et je m'excuse auprès des ingénieurs qui ont fait ce truc-là, on a fait des études pour savoir comment, qu'est-ce que ça nous coûterait de tout quitter et d'aller dans un autre provider. Les coûts sont assez rédhibitoires, notamment chez nous, en partie à cause du storage. C'est-à-dire qu'une grosse partie des coûts de Docker, c'est autour des multi-pétabytes qu'on a de données, qui sont les images que vous stockez sur Docker, et l'ensemble des gens stockent sur Docker.

25:47 Et ça, migrer des pétabytes de données d'un cloud à l'autre, c'est assez complexe, ça coûte très très cher. Et en dehors du côté d'engineering, qui est quand même une belle pirouette, quand même, de passer une cascade un peu complexe à exécuter pour passer d'un cloud à l'autre, si vous devez changer tout nouveau service EC2 vers des services chez Azure ou chez GCP, ça se fait pas en cinq minutes, même avec des conteneurs, même avec des capacités comme le cube et tout ça, c'est pas super simple. Il y a déjà un risque opérationnel, et en plus, le coût est assez rédhibitoire. Je sais que moi, quand on a plusieurs fois regardé comment partir chez Azure, et ça nous a paru 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 storage, C'est assez intéressant. Si vous regardez un petit peu en détail ce que propose Amazon autour du storage, il y a beaucoup de choses autour de l'extraction de données pour le passer chez vous ou ailleurs. Je sais qu'à une époque, il y avait même des camions dans lesquels vous pouvez stocker vos données sur des disques durs qui sont transférés d'un endroit à l'autre, que vous pouvez aussi utiliser pour faire de l'extraction de données.

26:54 Donc, en gros, vous recevez chez vous des cartons avec des disques durs et puis vous les injectez de l'autre côté. En termes de rapidité aussi d'exécution, c'est compliqué. Si vous voulez faire un truc avec zéro downtime sur un sujet comme ça, donc pas d'interruption de service, il va falloir quand même stocker les données à l'endroit, les dupliquer à un autre. Plusieurs petabytes que vous devez transférer sur le réseau, ça ne se fait pas en cinq secondes. Notamment, je sais que les cloud providers ont des services dans lesquels vous arrivez avec des disques durs, vous les stockez chez eux, vous les envoyez les disques durs et en revanche, ils s'occupent de les stocker, de les transférer en local, entre guillemets, sur leur service de stockage distant. C'est tout un monde un peu impressionnant. Pour finir, la négociation est relativement simple si vous y prenez à l'avance et je pense que ça demande vraiment de la préparation. Et là, pour le coup, j'ai envie de dire que c'était la période de l'année que je passais le plus de temps avec la finance. 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é finance qui quand même maîtrisait assez bien qu'est-ce que c'était que S3, qu'est-ce que c'était que C2, qu'est-ce que c'était que l'ensemble des produits et qui avait une bonne image de l'ensemble des données.

27:57 Après, nous, le transfert out de Amazon, on ne l'a pas fait. On ne le fera 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 ne l'a jamais fait. Ça me semble excessivement complexe. Après, le multi-région au sein d'Amazon ou au sein de chacun des cloud providers, je pense que c'est un autre sujet et je pense que c'est très intéressant. À l'époque, au moment où vous écoutez ce podcast, il y a eu un downtime chez Amazon et un autre chez Azure à quelques semaines d'intervalle ou une semaine d'intervalle fin octobre. Ça, ça nous arrive une ou deux fois dans l'année. Donc effectivement, US East 1 chez Amazon, qui est la zone dans laquelle l'ensemble historiquement des services les plus grands de la tech utilisent. Avoir du multirégion, c'est un vrai investissement, je pense, qui est vraiment utile aujourd'hui, parce qu'on a des pannes du US East 1. Je ne sais pas, une ou deux fois par an, je ne sais pas, je parlais d'Aestap. Donc le multi-cloud, je ne vois pas comment le faire de manière opérationnelle à l'échelle d'un produit comme Docker, et je ne ressens pas le besoin. Là, du multirégion, oui, bien sûr, ne serait-ce que pour nos utilisateurs, ça me semble être nécessaire, mais très difficile à faire, effectivement, encore une fois.

29:03 Du multirégion, ça demande un système de complexité qui est au-dessus. Et donc... Vous l'avez tous deviné, des coûts supplémentaires auprès des service providers. Et j'imagine que le dernier downtime chez AWS sur ES61 va inciter pas mal d'acteurs, à mon avis, à investir justement dans le déploiement multirégion. Et comme tu dis, ouvrir des nouvelles problématiques FinOps qui vont un peu se normaliser partout. Donc, quelque part assez intéressant. Et juste un petit commentaire, je trouve ça assez fou de se rendre compte qu'il y a encore des camions qui transportent des disques durs avec des volumes de data énormes pour transférer d'un cloud provider à l'autre. C'est assez rigolo. Merci pour cette anecdote. Ça démystifie pas mal de choses, je trouve. En tout cas, c'est super intéressant, Jean-Laurent, de comprendre comment une boîte comme Docker aborde les sujets FinOps, tels que la culture, la gouvernance, l'achat. J'aimerais maintenant qu'on parle d'un sujet qui est la FinOps appliquée à la Gen AI, que tu connais bien. puisqu'aujourd'hui et depuis à peu près un an, c'est le cœur de ton quotidien.

30:04 Et on sait tous que l'IA a introduit 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 tooling type cursor, cloud code, comment est-ce que tu gères ce budget? Comment est-ce que tu gères la mesure de l'usage? Et comment est-ce que tu mesures le ROI sur ces outils? C'est une super question et la réponse est très claire, c'est le bazar. C'est le bazar et quelque part, je me fiche pas mal que ce soit le bazar. Et pourquoi? C'est parce qu'en fait, je pense que, à mon humble avis, l'IA est en train de transformer la façon dont on est en train d'écrire du software aujourd'hui, que ce soit parce que vous rédigez vos PRD avec Claude ou Gemini ou OpenAI, ou est-ce que parce que vous utilisez des systèmes d'assistance au coding, De toute façon, les investissements sont tels et c'est un changement majeur. Donc quand on a un changement majeur dans l'industrie comme ça, j'ai envie de dire, je ne veux pas rater le coche, je veux comprendre le plus rapidement possible comment ça marche, je veux savoir quel est l'usage que les gens en font en interne,

31:13 Et après, je veux déjà comprendre le mécanisme et le changement dans lequel on est. Ça, c'est mon premier sujet. Et donc, quand je suis dans un changement comme ça, je me fiche un peu, entre guillemets, une proportion gardée du budget et du réo-vie. J'ai déjà envie de comprendre le système. Après, le changement est tellement brusque, il y a tellement d'innovations en ce moment, je ne sais pas, toutes les semaines, il y a un nouveau truc qui sort, que ce soit des avancées technologiques sur les modèles ou bien des outils qui sortent pour des domaines. On le voit maintenant, c'est de plus en plus spécialisé dans des domaines particuliers, sur la production de bugs, sur le CI, sur le coding, sur la planification des tâches. C'est un peu moins majeur que ce que c'était en termes d'impact il y a quelques mois, mais ça reste encore, toutes les semaines, il y a un nouveau truc qui sort, donc il faut essayer de comprendre ce truc-là. Donc quelque part, j'ai envie de dire, je veux embrasser ce modèle-là et je veux le comprendre. C'est le premier point. Donc la calcul sur la ROI aujourd'hui, je ne sais pas te le dire, je n'ai aucune idée du ROI de l'impact. Par exemple, un truc qui est intéressant, c'est que je me suis dit, j'ai pas mal d'ingénieurs qui utilisent, les trois quarts de mes ingénieurs utilisent, ou la majorité des ingénieurs utilisent des outils de coding.

32:24 Super. Donc, j'aimerais savoir, le héros, est-ce qu'il code plus ou il se code moins? J'ai plus de PR, j'ai moins de PR. J'ai plus de CI, j'ai moins de CI. J'ai plus de déploiement, j'ai moins de déploiement. Alors ça, je peux le regarder de manière globale. Je peux regarder de manière générale, est-ce que j'ai plus de pull requests dans GitHub? Est-ce que j'ai plus de déploiements en production? Est-ce que c'est des déploiements en production plan de plus ou plan de moins? Globalement, je n'ai pas vu un changement majeur sur ces éléments-là. La vraie question, c'est combien de ces gens-là, de mes ingénieurs, ont utilisé l'IA pour déployer leur pull request ou pour faire leur changement de code? Ça, aujourd'hui, je ne sais pas le travail. Parce qu'il y a des ingénieurs qui utilisent OpenAI pour essayer de comprendre les problématiques qu'ils ont, pour lire du code. Ça leur a permis de gagner du temps. Oui, très bien, super. Mais par contre, je ne sais pas le mesurer à la fin. Moi, je vois le nombre de PR, donc je peux me dire, OK, j'ai augmenté de 5% ou 10% le 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 ça à un usage particulier d'OpenAI ou de Cloud ou d'autres choses? Pas vraiment aujourd'hui.

33:25 Aujourd'hui, je ne sais pas vraiment faire ce lien. 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. Tout ça, on va en avoir besoin. Tout ça, c'est des choses qu'on va absolument avoir besoin de comprendre. Aujourd'hui, c'est très difficile de relier l'impact qu'un ingénieur a fait avec son usage en particulier de l'IA. Un gars va dépenser 500 dollars chez Claude sur un week-end, sur une semaine. Est-ce que finalement, je suis capable de relier ça avec un gain de productivité de son côté? Non. Est-ce que je le recherche? Non plus. Ce que j'ai envie, c'est qu'il soit plus à l'aise et globalement, qu'il comprenne 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 divers et variés. Je vois des ingénieurs qui sont très jeunes, qui ont plutôt tendance à pas mal s'en servir. Des ingénieurs beaucoup plus expérimentés qui s'en servent pour des choses beaucoup plus contraignantes. On est dans un boom total et donc quelque part la mesure est assez complexe aujourd'hui. Je me rappelle dans ma carrière, j'ai changé trois ou quatre fois d'IDE. J'ai commencé à la semi-dose avec un notepad, un notepad plus plus ou un machin comme ça.

34:30 Après, j'étais dans le monde Java, donc j'ai fait de l'Eclipse. Et puis, j'étais avec les Good Kids, 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à, je viens de vous retracer, par exemple, 20 ans, 25 ans de l'idée. Là, en un an, on est passé de VS Code avec assistance de Copilot à Cursor. Et puis maintenant, Cloud Code ou OpenAI Cortex, le tout en moins d'un an. Et encore, ça continue. Des droïdes, des machins, il y en a des outils de développement, il y en a des palanquets 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 d'IDE sur toute ma carrière que là, dans la dernière année, en gros. Donc c'est un tel maelstrom de choses que je pense qu'il ne faut plus être là dans l'absorption et de comprendre comment ces outils fonctionnent, mais au quotidien déjà, avant de commencer à mesurer les coûts. Et c'est sûr qu'on va arriver à une mesure de coût. Les négociations avec OpenAI, Anthropic et Gemini, aujourd'hui, c'est plutôt dans la… Je calcule les coûts et je regarde l'usage que j'en ai pour essayer de comprendre si ma workforce, mes ingénieurs utilisent ou pas l'IA.

35:38 Et effectivement, ça explose. Il y a un an, c'était 10-15% des ingénieurs. Aujourd'hui, c'est une grande majorité des ingénieurs à Docker utilisent l'IA de manière différente. Et on n'en est pas complètement sur la partie négociation encore. On est plutôt dans une phase d'expansion telle qu'on a l'impression de comprendre un peu plus. Donc, on a des négociations avec OpenAI et Anthropic autour de comment faire en sorte de comprendre leur business model, qui change quand même pas mal à chaque fois, Anthropic notamment, pour essayer de comprendre quel est l'usage. Après, je regarde toutes les semaines les coûts. Et puis, on a des caps. Donc, quand l'ensemble de l'ingénierie a un capé à 5 000 dollars dans le mois, tu t'arrêtes et tu dis, OK, j'en suis où par rapport au mois dernier? J'en suis où plus? Est-ce que je suis capable de me projeter? On est plutôt là-dedans. On a très envie d'embrasser… le généal à Docker. Donc, c'est plutôt une... entre guillemets, un chèque en blanc en mesurant les coûts, en observant les coûts. Oui, d'accord. OK, c'est très clair. Je comprends qu'en fait, tant qu'on est dans ce rythme effréné de sortie d'un nouvel outil toutes les semaines, tu surfes sur la vague sans te préoccuper trop des coûts.

36:45 Ça, c'est intéressant. Et je comprends aussi que dans une boîte comme Docker, même avec ce niveau de maturité, vu le rythme effréné, il n'y a pas encore vraiment de politique d'utilisation des outils IA pour les développeurs parce qu'en fait, ça va trop vite. Et puis, on a envie d'embrasser le truc. Donc, tu n'as pas envie de rater le coche de ce qui se passe. D'accord, c'est intéressant. Ça, c'est sur la partie tooling, du coup, sur la partie fonctionnalité pure chez Docker. Toi, tu es chargé chez Docker de déployer des nouvelles fonctionnalités basées sur la Gen AI, comme tu nous disais. Notamment, tu nous parlais de l'assistant Gordon qui est intégré à Docker Desktop. On se demandait, est-ce qu'il y a des nouveaux coûts qui sont occasionnés par ces fonctionnalités? Et est-ce qu'il y a déjà aujourd'hui un intérêt à optimiser ces coûts? Et si oui, quels sont les leviers que tu as pu mettre en œuvre pour y parvenir? Gordon, c'est un outil intégré à Docker Desktop. Gordon, c'est le nom qu'on a donné à l'assistant. C'est un produit de Gen AI assez classique aujourd'hui qui consiste à avoir l'ensemble des données autour de l'utilisation de Docker pour qu'on puisse lui poser des questions.

37:53 Parce que Docker, il ne faut pas se mentir, c'est quand même compliqué. Connaître l'ensemble des flags, des optimisations, Ça demande du temps. Si vous regardez la plupart des Dockerfiles ou des Composefiles qui sont écrits dans le monde, c'est des sujets qui sont en général assez mal écrits, parce que c'est compliqué, tout simplement. Et aussi que c'est un vrai métier de savoir écrire ce genre de choses. Et puis aussi, on fait des innovations en permanence dans l'engine et dans Docker en général. Et donc, du coup, il faudrait presque avoir une formation, se former en permanence pour toujours optimiser ses images. L'idée de Gordon, c'est que 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. Vous lui posez des questions sur l'optimisation du Docker, il va vous répondre et vous avancez avec ça. C'est un produit de Gen AI qui tourne sur OpenAI aujourd'hui, essentiellement. À travers Azure en termes d'infrastructure, parce qu'Azure propose des services autour d'OpenAI qui sont très stables, nous on est assez contents de ça. On utilisait le SaaS d'OpenAI directement avec des coupures chez US East One.

38:55 Chez OpenAI récemment, ça a été assez une vidéo au débat, des coupures complètes pendant plusieurs minutes, plusieurs fois. Du coup, avec les instances chez Azure d'OpenAI, on arrive à avoir quelque chose de stable. Les coûts de Gordon, c'est assez simple, ce n'est pas très élevé. Gordon, il y a pas mal, il y a 10 à 15 000 questions qui sont posées par jour à peu près. C'est un outil qui est relativement utilisé, qui est assez début, qui sont des coûts très raisonnables. On est moins de 300 euros par jour à peu près, sur en tout cas les coûts purement opérationnels autour de l'EI. Ce n'est pas des sujets sur lesquels j'ai envie d'optimiser. Je n'ai pas beaucoup envie d'optimiser. Les leviers vont être essentiellement d'essayer de calculer en gros combien me coûte une question ou combien me coûte un utilisateur. Donc ça, moi, je vais regarder ça. On a des rate limiting, bien sûr, la base dans ce genre d'application, c'est effectivement de faire du rate limiting, donc de limiter le nombre d'interactions si des gens en abusent, de telle manière que ça reste utilisable pour tout le monde. On n'est pas là non plus pour fournir un service autour d'OpenAI gratuitement à tout le monde.

39:58 Il y a un tel biais, Gordon répond essentiellement à des questions. des questions autour de Docker, vous lui posez des questions autour d'autres choses, il va vous dire maintenant, j'ai envie de répondre, j'ai envie de répondre là-dessus. Ce n'est pas un open AI, bien sûr, complet, mais c'est très teinté Docker. Donc, on mesure les coûts par utilisateur. Effectivement, on va regarder la fenêtre de contexte. On va dire, bon, attends, ça ne va plus. Donc là, on utilise soit, on limite, soit on compacte la fenêtre de contexte assez classiquement. Et puis, avec les modèles provider, on ne négocie pas encore là-dessus parce que les coûts sont assez faibles. Donc, si moi, je passe une journée à négocier, ça m'a fait plus cher que si je n'optimisais pas. Donc, ce qu'on va faire par contre, c'est qu'on va essayer d'utiliser le bon modèle en termes de coûts par rapport à l'utilisation qu'on a. Donc, on a, Gordon a 4-5 types de questions différentes. On utilise des modèles différents chez Oconair en fonction du haut mini pour certains types de questions, des modèles un peu plus compliqués pour d'autres. Aujourd'hui, c'est ce qu'on fait. Super, merci Jean-Laurent. On a parlé de la FinOps dans le cadre du déploiement de la GenIA avec des outils comme Gordon que tu viens de mentionner. Pour finir, on aimerait s'intéresser à l'inverse, à ce que l'AI peut apporter à la discipline FinOps.

41:02 On peut commencer par donner notre perspective chez Opsima. Nous, on développe un tool FinOps qui fait de la gestion automatisée des engagements financiers, type Reserved Instancies et Savings Plans chez AWS. Et on a pris le parti de ne pas faire d'agentique dans ce cadre. On utilise du machine learning plus traditionnel avec par exemple du forecasting de time series pour projeter les coûts. On s'inspire du reinforcement learning. pour le moteur de décision qui est au cœur de notre service et qui recommande les engagements. Mais sinon, c'est surtout de l'optimisation assez conventionnelle. Donc, pas de LLM, pas d'agent Gen AI. Et pourquoi? Parce qu'on s'appuie sur de la donnée d'usage et de la donnée de pricing. Qui est de la donnée tabulaire très structurée et qui répond à des mécaniques qui sont très déterministes. C'est aussi de la donnée qui est volumineuse et qui a tendance à faire halluciner les LLM 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'hallucination ou d'erreur.

42:12 Donc, pas l'agentique chez Opsima, mais ça, c'est notre positionnement, en tout cas à date aujourd'hui, comme tu l'as soulevé, les choses évoluent très vite. En tout cas, on était curieux d'avoir ta perspective, de savoir d'après toi ce que l'IA et l'agentique peuvent apporter à la discipline finance. Qu'est-ce qui, d'après 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, je n'ai pas un diplôme en FinOps, encore une fois, mais c'est vrai qu'on peut essayer de faire un parallèle entre comment on utilise l'IA dans l'engineering et comment ça peut s'appliquer à d'autres disciplines. Un truc qui est assez marquant avec l'engineering, c'est qu'aujourd'hui, on ne va jamais laisser une IA pousser directement en production. Au mieux, on va lui demander d'aller éventuellement écrire du code. Ok, très bien. Mais finalement, le comité le pousse dans la 90%, 95% des cas, c'est comme un humain qui le fait. Et notamment, alors peut-être on va utiliser l'IA, notamment on utilise beaucoup ça à Docker, sur des pull request review, donc vous avez une IA qui va analyser le code et vous faire une requête. C'est très utile dans certains cas, c'est assez risible dans d'autres.

43:16 Et effectivement, si tu appliques ça à des données financières, notamment des données structurées comme tu disais, je serais assez prudent comme vous l'êtes. Je pense que l'IA est là pour nous aider à aller plus vite dans un certain nombre de sujets. L'IA, c'est quand même fantastique parce qu'on change un peu d'interface. Au lieu 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'input et d'output avec une IA. On peut balancer du texte ou avoir un output du texte. Sur des données structurées, effectivement, je pense que c'est assez dangereux. Nous, on a, en tout cas aujourd'hui, dans l'état actuel des choses, il y a toujours des gens qui vont vous raconter que tu peux utiliser une LLM as a judge. C'est une LLM qui va vérifier le résultat d'une autre LLM qui serait capable d'arriver à un résultat plus intéressant. On a fait beaucoup d'essais à Docker aussi, où par exemple, on faisait une boucle avec des agents dans lesquels on essaie d'avoir un résultat. Mais si on faisait la boucle une fois, on avait un résultat qui était assez nul. Si on faisait la boucle deux fois, on avait un résultat qui était plutôt bon. Si tu faisais la boucle mille fois, tu avais un résultat qui était parfait.

44:16 Mais enfin, pour un coup, à ce moment-là, c'est complètement délirant. Donc, 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 coûts, ça me semble assez... complexe, et pas forcément très intéressant. Je trouve que l'IA est toujours là pour nous assister. Nous, on a un outil en interne qui s'appelle Prophet AI, qui est assez sympa, qui en termes de sécurité, quand on a un problème de sécurité, nous permet de drill down sur l'ensemble. Il va analyser, il va faire la corrélation entre des données auxquelles on n'avait pas pensé. Notamment, il va regarder les logs d'AWS avec les IP ou des choses qui viennent de l'IT pour nous permettre de dire, tiens, tel gars, c'est un peu comme ça. est connecté depuis tel endroit, il a fait telle opération, il a eu une escalation de privilèges à tel moment. Ce n'est pas quelque chose qui est d'habitude visuel et tu peux drill down sur ces éléments-là. Mais là, encore une fois, il n'y a pas de prise de décision. L'IA va te servir d'agrégateur de l'ensemble des éléments et va te donner un summary ou un résumé assez intéressant.

45:20 d'informations qui sont trop difficiles à regarder en détail. Donc là, il y a un vrai intérêt à utiliser l'IA pour faire du résumé et de vous permettre de le redire, mais après, à la fin, la décision, c'est toi qui la prends et tu dois avoir les données brutes sans qu'elles soient interprétées par l'IA. Donc ça, je trouve que cet élément comme profétaire, dans lequel je n'ai pas d'action, seront appliqués à la sécurité, est assez intéressant. Et quelque part, la sécurité et la finance, c'est deux sujets sur lesquels tu ne veux pas que l'imachine fasse le truc toute seule, il faut que ce soit toi qui prennes les décisions. Et donc, je trouvais le parallèle peut-être visuel, vous me direz ce que vous en pensez. Voilà. Oui, on est assez d'accord avec toi. Tout ce qui est finances et sécurité, on a un tel besoin de contrôle qu'aujourd'hui, alors je serais 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 sceptique à confier ces tâches-là à des systèmes qui peuvent halluciner ou qui ont encore un taux d'erreur qui existe. Mais oui, je pense qu'on se rejoint sur ce constat. En tout cas, c'est vraiment intéressant de soulever avec toi, Jean-Laurent, le capot d'un service comme Docker qu'on utilise tous les jours et de comprendre les détails.

46:30 de ton approche FinOps. Merci pour cet échange, un grand merci. C'était riche en enseignements et en anecdotes. Merci à toi, Jean-Laurent. Merci, c'est toujours un plaisir de regarder ça avec l'angle, vous qui êtes des spécialistes de la FinOps. La structuration des questions et l'usage est hyper intéressant. Je pense que chaque VP Engineering a de toute façon besoin de comprendre ce domaine-là. C'est souvent un sujet sur lequel on ne pense pas forcément. Donc c'est assez critique et moi c'est quelque chose que j'ai appris sur le tas, entre guillemets, à FinOps, comme je l'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 au scaling des équipes d'ingénierie, des outils, comment faire scaler ses équipes, comment recruter, etc. Mais la FinOps c'est un vrai pan de la responsabilité du Vip. On est bien d'accord avec toi. Merci à toutes et tous de nous avoir écoutés. On vous donne rendez-vous au Tech.Rocks Summit les 1er et 2 décembre 2025 au Théâtre de Paris.

47:31 A bientôt!