Bruno:
Il paraît que la performance est comme la cerise sur le gâteau. Tout le monde la veut, mais on ne sait pas toujours pourquoi. On a tous déjà passé des heures à optimiser une fonction que personne n'utilisera jamais. Mais alors, comment savoir si c'est un vrai levier ou juste un piège à ego ? Faut-il mesurer toutes les exécutions à la microseconde près ou juste s'assurer que ça rame au final pas trop ? Et surtout, est-ce qu'optimiser la CI peut nous sauver des nuits blanches ou juste en créer des nouvelles ? Pour répondre à ces questions de rapidité et un peu d'insomnie aussi, je ne reçois pas Usain Bolt, mais il s'y connaît en sprint bien géré. Adrien, bonjour.
Adrien:
Salut, salut Bruno.
Bruno:
Alors Adrien, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Adrien:
Moi c'est Adrien, je suis dans la tech depuis maintenant à peu près 7-8 ans. J'ai commencé en tant que software engineer dans une boîte qui fait du consulting développement web qui s'appelle Theodo. J'ai passé quelques années là-bas j'ai fait pas mal de projets et du coup depuis maintenant 2 ans, 2 ans et demi j'ai cofondé avec mon cofondateur Arthur, j'ai cofondé Codespeed qui est du coup une boîte qui, s'intéresse pas mal à la performance Alors.
Bruno:
Ça a été quoi la genèse de Codespeed, c'est que vous aviez une lubie, toi et ton associé pour faire des codes les plus rapides possible ou c'était quoi le...
Adrien:
Bah un petit peu mais la genèse, comme je pense qu'il y a, Et un truc assez important aujourd'hui, si tu veux créer une boîte, monter un produit, c'est en fait, on est parti d'un problème. On a vu un problème dans notre espace, dans la tech, et on s'est dit, bah tiens, est-ce qu'il n'y a pas quelque chose à faire ? Et du coup, ce problème, c'était mon associé, Arthur, bossait dans une boîte qui faisait de la reconnaissance d'images pour le retail. Donc en gros, il prenait en photo des rayons de magasin et il regardait sur ses photos si jamais il manquait des produits où des produits étaient mal placés parce qu'aujourd'hui en fait fin peut-être maintenant c'est d'avant ce qu'on parle de c'était il ya cinq ans aujourd'hui c'est un process qui était humain c'était des gens qui passaient dans les dans les magasins dans les rayons pour dire ah bah il manque le shampoing machin et du coup l'idée c'était d'automatiser ça en prenant des photos et du coup mon mon confondateur il bossait sur un robot et du coup un robot qui se baladait dans les rayons et qui prenait en photo les rayons et c'est il faisait le logiciel qui retournait sur le robot. Et son problème c'était que en fait il faisait une mise à jour du logiciel, il faisait du nouveau code et en fait il se disait tiens avant de déployer mon code sur le robot j'aimerais bien m'assurer que si jamais je déploie ce nouveau code ça va pas faire en sorte que la performance du code va être trop lente et que du coup le robot dès qu'il va prendre en photo il va voir qu'il y a un humain devant lui, il va mettre trop de temps à analyser ça et en fait il va commencer à rentrer dans le rayon, rentrer dans les personnes qui sont dans le magasin et du coup il s'est dit j'ai pas envie de tester la performance de mon code que lorsque j'ai uploadé le code dans le robot qui se balade dans les rayons parce que là ce serait catastrophe et du coup il a commencé à chercher sur internet, comment est-ce que je peux tester la performance de mon code et, plus tôt, donc avant de déployer mon code, donc dans ma CI, c'est parce qu'il était habitué à faire des tests de non-régression, des tests unitaires, tout ça, il s'est dit, est-ce que ça existe pour la performance ? Et en fait, en commençant à regarder, donc c'était il y a 5 ans, enfin non, pardon, c'était plutôt il y a 3 ans, mais en fait, il n'y avait pas de méthode qui marchait bien, quoi. Il y avait des petits projets open source qui essaient de faire ça, mais en fait. Ça te donnait des graves de performance, mais en fait, tu vois, la performance, ça faisait vraiment des allers-retours c'était vraiment c'était pas utilisable et du coup il s'est dit bah tiens il y a peut-être moyen de faire quelque chose et du coup, un jour il a vu pour la petite histoire il a vu un tweet de Samuel Colvin qui est le fondateur de Pidentique qui est une Pidentique c'est une librairie qui fait de la data validation en Python qui est assez populaire très populaire, et aujourd'hui ils ont 500 millions de downloads par mois sur cette librairie en Python et du coup lui il fait une librairie open source et il avait exactement ce besoin enfin un jour il a fait un tweet pardon où il s'est dit, je suis en train de faire des modifications dans ma librairie qui est utilisée par des millions de personnes, j'aimerais bien avant de déployer une nouvelle version de ma librairie m'assurer que en fait je ne vais pas casser la performance et j'aimerais bien savoir ça dans ma scieille du coup Arthur il a vu ça il s'est dit ah, j'ai eu ce problème là je ne suis pas tout seul à avoir ce problème du coup je ne suis pas tout seul à avoir ce problème c'est un sujet intéressant, on se lance du coup il a commencé à faire le produit Samuel Colvin a commencé à l'utiliser sur Panantique le projet open source ça a pas mal pris, on a commencé à avoir pas mal d'utilisation dans l'open source et depuis, je l'ai rejoint et du coup ça fait maintenant 2 ans et demi.
Bruno:
J'ai eu l'occasion il y a fort longtemps de faire un podcast autour des Chromebooks, c'était une OP avec Google Chromebook, et j'avais appris à l'occasion que chez Chromebook ils ont les premières versions des ordinateurs Chromebook et qu'ils ont une de leurs règles c'est que quand ils font une nouvelle version de Chromebook il faut que l'OS mette au minimum autant de temps que les premières versions pour booter sur les anciennes machines au minimum ça peut pas aller plus au maximum pardon, au maximum autant de temps, que les premières versions sur les premières versions des machines parce.
Adrien:
Qu'ils se disent on peut pas faire quelque chose de moins bien.
Bruno:
Exactement mais tu vois chez eux ça nécessite qu'ils ont un banc de test, avec des machines du coup historiques où ils vont runner en fait dans ce contexte là est-ce que vous votre solution nécessite aussi d'avoir une entre guillemets une version de prod, équivalente sur lequel tu testes à chaque fois ta prod c'est un stress test du coup Fian d'une certaine manière alors.
Adrien:
Aujourd'hui la manoeuvre en Cospit ça marche donc Cospit le but c'est c'est de faire un dev tool qui soit facile à utiliser pour les devs pour te permettre de mesurer et d'optimiser ta performance avant la production.
Bruno:
Et donc aujourd'hui.
Adrien:
Le levier qu'on a le premier levier qu'on a et qu'on utilise ça va être de faire de rener des tests de performance dans ta CI, donc comme je disais tout à l'heure comme tu fais tourner aujourd'hui, à chaque fois que tu fais une pull request tu fais tourner des tests de non-régression, donc des tests unitaires. L'idée c'est d'avoir des tests de performance qu'on appelle des benchmarks qui sont, Toi, dans le code, quand tu les écris, c'est exactement... T'as l'impression d'écrire des tests unitaires, sauf que juste ta fonction, elle va prendre un certain temps à être exécutée, et c'est ça la métrique qu'on va utiliser. Et donc l'idée, c'est de la même manière que tu peux écrire des tests unitaires, tu écris des tests de... donc des benchmarks, des tests de performance, et ceux-là, ils tournent dans ta CI. Et l'idée, c'est que en termes d'environnement de production, donc tu dis des stress tests, tout ça, l'idée, c'est aujourd'hui, comment ça marche ? C'est que à partir du moment où tu es capable de faire... d'écrire ces fameux tests, de ces benchmarks nous on peut récupérer la métrique, donc c'est en quelque sorte pour répondre à ta question c'est à toi de créer cet environnement de renaître tes tests dans cet environnement et ensuite du coup de nous envoyer la métrique.
Bruno:
Ok donc c'est une mesure de c'est pas tant une mesure de la performance en prod mais c'est surtout voir une tendance d'évolution de ta performance versus d'ancienne version.
Adrien:
Ouais exactement et l'idée c'est c'est en fait de mettre de côté la prod pour l'instant et vraiment de se faire en sorte que la feedback loop de la performance elle soit la plus courte possible parce que dans le problème dont je te parlais tout à l'heure avec Arthur et les robots en fait c'est vrai pour tous les use case si c'est que une fois que ton code il est en prod que tu te rends compte qu'il y a un problème en fait tes utilisateurs ils sont pas contents parce que le robot il est rentré dedans ou alors ton site e-commerce la page elle met 3 secondes à se charger du coup tu perds 90% de ton funnel d'acquisition, donc les usateurs en pâtissent toi vu que c'est déjà en prod pour faire la remédiation, ça va être plus long parce que du coup si c'est déjà en prod ça veut dire que le problème il est déjà plus loin la personne qui a fait le code qui a régressé la performance est plus loin donc en gros l'idée c'est que en attendant la prod la feedback loop elle est trop longue et donc en la mettant dans la CI, au moment où tu crées le code avant qu'il soit déployé l'idée c'est d'aller plus vite, mais le trade-off c'est que du coup il faut essayer de répliquer cet environnement, de production pour essayer de faire des tests qui soient les plus pertinents possibles parce que comme tu l'as dit en intro c'est un grand sujet et donc aujourd'hui l'idée c'est, il faut savoir où mettre le curseur donc il faut savoir quoi tester, comment le tester, mais du coup si tu sais quoi tester comment le tester avec code speed du coup l'idée c'est que tu peux avoir ces métriques là dans ta CI et du coup à chaque fois que tu vas rajouter du code dans ta code base tu vas savoir quel va être l'impact sur ces différents points, ces différents tests que tu as mis en place.
Bruno:
D'autant qu'effectivement si tu te rends compte d'une perte de performance une fois que t'es en prod t'as entre guillemets aussi moins de temps pour le corriger parce.
Adrien:
Qu'en fait t'as le client qui tape par la porte donc t'es t'as tout perdu quoi mais ouais donc ça c'est au plus tu te rapproches en fait comment dire au plus tu te rapproches du dev donc au plus tu te rapproches du dev sur sa machine au plus tu t'assures que les feedback loops sont les plus petites et il y a le moins d'impact sur la production ouais.
Bruno:
Comment se... Je ne sais pas si... Il y a peut-être une intuition sur la réponse, mais la notion de la performance, parfois, elle n'est pas uniquement induite par le code. C'est-à-dire que parfois, tu peux rajouter du code qui ne va pas forcément impacter la performance. Mais en fait, si tu passes de 10 users à 1000 users simultanés, en fonction des goûts d'étranglement que tu peux avoir à certains endroits, comment est-ce que tu peux mesurer aussi ce genre d'éléments ?
Adrien:
Aujourd'hui, c'est un gros challenge. parce que typiquement l'exemple le plus parlant de ce que tu dis c'est typiquement sur les database en tant que webdev c'est.
Bruno:
Le goulot le plus.
Adrien:
Exercé tout webdev qui a déjà fait des applications prod avec un petit peu d'utilisateurs sur des bases de données un peu grosses il s'est rendu compte de ce problème là, dans ton espace de dev où là quand il y a quelques lignes dans ta DB tout se passe bien mais dès que tu passes sur ta DB de prod quand t'as des millions d'éléments dans ta DB si tu oublies des index, il y a plein de problèmes qui peuvent se lier à être à cause de ça, aujourd'hui c'est toujours un challenge parce que comme je te l'ai dit aujourd'hui il faut répliquer ton environnement de test du coup. Aujourd'hui c'est toujours un challenge donc si tu es capable de reproduire cet environnement de test avec des environnements qui sont isoprod ou peut-être pré-prod, ce genre de choses tu peux avoir des tests à cette charge là mais c'est assez dur à mettre en place, nous la solution qu'on a commencé à expérimenter ça va être en fait de typiquement pour le use case des bases de données ça va être de proposer une solution clé en main pour que si dans tes tests tu utilises une base de données, on est nous-mêmes un proxy qui automatiquement écoute toutes les requêtes que tu fais à ta DB et fait une requête en plus pour avoir le fameux explain plan, donc je crois que c'est le explain ça dépend si t'es en post-gray, en MongoDB suivant les différents engines de DB en gros, l'idée c'est que si tu as une query DB à ton engine de DB tu peux lui demander d'expliquer cette query et en fait il va te dire comment est-ce qu'il va l'exécuter s'il va utiliser un index ou quoi et du coup à partir de ces informations là tu peux extrapoler en te disant si cette chorie n'est pas optimisée alors du coup la performance sur une table avec des millions d'éléments tout ça elle va être pas bonne et donc on a commencé à expérimenter avec ça et l'idée c'est de, même si l'idée c'est que même si sur ta DB dans ton test tu n'as pas énormément de, enfin si c'est juste mesurer le temps on va pas se rendre compte du problème en ayant ces données là, nous-mêmes on les retraite et on te dit ben en fait attention là typiquement, sur cette pull request tu as rajouté cette query. Et enfin tu auras comment dire plutôt ce test par exemple si t'as mis un test sur ton endpoint t'as un endpoint sur ton API web, cet endpoint là il fait une nouvelle query sur un nouveau champ sauf qu'il n'utilise pas un index ben du coup on te dit attention t'as une nouvelle query qui n'utilise pas un index donc en prod ça va faire un scan sur une table et du coup si ta table elle a un million d'éléments ben ça va te prendre autant de temps donc c'est on essaie de trouver des moyens, lorsqu'on n'a pas un environnement d'exécution isoprod, c'est difficile, on essaie de trouver des moyens pour quand même avoir une donnée, pertinente dès la CIA.
Bruno:
Est-ce que ça veut dire que je sais de voir comment est-ce que vous pouvez exploiter ce fameux explain pour déterminer qu'il y a des éléments qui peuvent être manquants est-ce que du coup vous passez par une regex pour essayer d'identifier les éléments, qui peuvent être liés ou est-ce que tu passes par un LLM pour analyser ça ?
Adrien:
Alors, les formats des explains sont assez déterministes. Donc typiquement, le fait que ta query va utiliser un index ou pas, tu as l'information. Genre typiquement, si tel champ va faire que ta query n'utilise un index ou pas, tu peux avoir l'information. Donc il y a typiquement... Le use case le plus simple, ça va être les index. Et après, tu as aussi le nombre de queries. On n'y pense pas trop, mais si demain, tu modifies ton code et avant, tu fais une seule query, et tout d'un coup, tu as la fameuse n plus 1 qui arrive, parce que tu disais un ORM et que la manière dont ton ORM est fait s'il fait que tu vas faire, une query par item d'un arrêt ce genre de choses, l'idée c'est qu'on te le laisse on te le dise aussi, attention avant tu faisais 5 queries avec cet endpoint là aujourd'hui t'en fais 300 il y a ce genre de problème D'accord.
Bruno:
Donc vous mesurez aussi le nombre de queries qui est faite.
Adrien:
En fait l'idée c'est que, une fois que tu as ce proxy qui est en place tu peux avoir plein d'informations et donc tu vas avoir notamment les N plus 1 les index ce genre de choses.
Bruno:
Alors c'est intéressant parce qu'effectivement il y a peut-être une question que j'aurais peut-être dû poser au début quand on parle de performance on parle de quoi ? On parle uniquement de temps d'exécution on parle de consommation mémoire c'est ça aussi qui est je trouve un peu piégeux comme on dit dans le sujet de la performance c'est qu'en tant que dev on a tous un peu nos lubies, les trucs sur lesquels on va s'attacher, c'est quoi la performance avec Codev ?
Adrien:
Et même c'est quoi la performance bien sûr et c'est quoi la performance qui est importante aussi parce que et du coup je reviens peut-être c'est en fait la performance qui va être importante pour toi ça va dépendre de ton use case et donc l'idée c'est il faut aussi la ramener avec, pour ton entreprise pour ta boîte pour ton produit c'est quoi qui est important, et donc si tu fais un site e-commerce comme je disais tout à l'heure ce qui va t'interporter c'est que tes endpoints ils répondent vite parce que tu ne veux pas perdre tes utilisateurs. Donc là, typiquement, la métrique qui va t'intéresser, a priori, ça va être en premier lieu la vitesse d'exécution de ton code. Si tu fais de l'embarqué, donc tu fais des programmes qui vont tourner dans l'embarqué, là, la consommation de la mémoire, la taille de ton code, c'est des métriques qui vont être hyper importantes que tu vas commencer à regarder aussi parce que tu as des contraintes fortes au niveau de ton entourage. La performance ça peut être toutes les choses que tu as dit mais celle qui va être importante pour toi ça va vraiment dépendre de ton use case mais on va dire que la plupart du temps quand même la rapidité d'exécution de ton.
Bruno:
Code ça.
Adrien:
Va être ce que tu vas chercher parce qu'aujourd'hui la plupart du temps la rapidité de ton code va être un élément différenciant par rapport à tes.
Bruno:
Concurrents de ton space est-ce que ça veut dire qu'aujourd'hui avec votre librairie est-ce que je peux mesurer tous les indicateurs que je peux imaginer je sais pas si on peut imaginer un truc un peu un peu UBS que je sais pas par exemple ça peut être, le fait que je sais pas on veut pas des certains fichiers on veut pas que des fichiers qui dépassent un certain nombre de lignes de code ou à l'inverse on veut essayer d'avoir le minimum de fichiers à utiliser dans une exécution tu vois est-ce qu'on peut imaginer tous les types de maîtrise possibles ou est-ce que vous avez quand même déjà listé un certain nombre de...
Adrien:
Historiquement on a commencé on s'est vraiment focalisé sur la mesure de performance donc le temps d'exécution même si on pourra peut-être y revenir mais c'est il y a plusieurs manières de mesurer le temps et du coup nous on a deux manières on va dire de mesurer le temps et il y en a une où on mesure pas vraiment du temps mais ça devient du temps avec le CPU, mais donc ouais on s'est historiquement on s'est focalisé là-dessus mais on a de plus en plus de demandes pour faire exactement ce dont je viens de parler en fait le fait de pouvoir, mesurer des métriques du coup des métriques que ce soit la mémoire utilisée par certains bouts de code, la taille de ton binaire, ce genre de choses. C'est quelque chose que... Alors aujourd'hui, on peut complètement faire. On a tout ce qu'il faut dans notre produit pour le faire. Mais en fait, l'idée, c'est... Avant de se lancer là-dedans on veut être sûr d'avoir vraiment bien arrivé à nail down c'est quoi derrière au niveau produit qu'est-ce qu'on veut faire parce que on peut faire tout et n'importe quoi avec ça mais on veut s'assurer qu'on garde une bonne expérience utilisateur un bon truc donc, aujourd'hui ce serait possible de le faire mais on préfère attendre avant de se lancer là-dedans d'avoir un truc vraiment vraiment, qui apporte vraiment plus la valeur pour le produit qui soit pas juste tu peux balancer n'importe quelle métrique et après le produit, en fait il permet de faire trop de choses et du coup l'expérience elle est plus bonne.
Bruno:
Il y a peut-être un sujet aussi qui commence peut-être à apparaître de plus en plus, alors tu l'avais évoqué tout à l'heure un petit peu avec le CPU j'imagine que c'est effectivement le nombre d'opérations que ton CPU va générer c'est à dire que du coup tu peux aussi extrapoler la consommation de ton CPU parce que la consommation électrique aujourd'hui on a de plus en plus d'appareils qui fonctionnent sur batterie.
Adrien:
La moindre.
Bruno:
Énergie qui est consommée à.
Adrien:
La navale au moins ton, au plus ton code est rapide au moins il va consommer d'énergie C'est un énorme enjeu aujourd'hui avec les LLM, les agents.
Bruno:
Tu peux aussi considérer que si tu parallélises trop, ton code il est certes plus rapide mais en fait tu fais plus d'opérations par seconde au final et donc tu pourrais mesurer la charge du CPU.
Adrien:
C'est clairement une métrique qu'on pourrait avoir, c'est intéressant.
Bruno:
Il y avait une autre question qui m'était venue tout à l'heure, oui c'est sur cette mesure de la performance. Je disais que parfois, les devs, on a tendance à aller un peu loin dans la mesure de la performance, qu'on a parfois fait une certaine lubie, qui parfois, je trouve, va d'ailleurs à l'encontre de la lisibilité du code. C'est-à-dire que tu as des devs qui vont nous faire un truc hyper optimisé. Mais maintenant, quand tu l'ouvres, à part celui qui l'a écrit ou celui ou celle qui l'a écrit, le code était lisible pour le commande immortel. Et moi, il y a un exemple flagrant. Il y a un bel exemple que j'ai là-dessus. il y a quelques années, quand Facebook avait commencé à avoir leur propre data center ils en étaient arrivés jusqu'à réécrire leur firmware, leur disque dur qu'ils utilisaient, parce qu'en fait les quelques millisecondes de temps d'écriture et de lecture qu'ils pouvaient gagner à leur échelle ça représentait un truc colossal, mais tu vois on est sur un niveau de détail, qui au final n'intéresse que des gens comme Facebook, Google, enfin tu vois que les grands, est-ce que le sujet de performance c'est pas au final le luxe ou l'apanage, que des grands acteurs.
Adrien:
En fait c'est hyper intéressant parce qu'on pourrait se dire aller chercher la micro-optimisation il faut vraiment être à un niveau super élevé et là pour le coup je suis complètement d'accord avec toi ceux qui vont aller chercher les micro-secondes les nanosecondes, c'est des gens qui ont des besoins en performance, qui ont des workloads tellement énormes, où tu l'as dit une micro-seconde gagnée ça va représenter des milliers voire des millions de dollars de gains d'économie exact sur le data center tout ça et en plus en énergie ça va sauver de l'énergie aussi donc c'est pas mal mais pour le commun des mortels la micro seconde on s'en fiche un peu mais l'idée c'est en fait la performance elle est quand même importante parce que comme on l'a dit tout à l'heure. Peut-être qu'optimiser la performance à la millisecondition, ça ne va pas être hyper important, mais par contre, s'assurer que la performance, elle reste à un certain seuil et qu'elle ne se dégrade pas en plus, au-dessus d'un certain seuil, c'est ça qui va être hyper préventif. Tu l'as dit toi-même en intro avec le Chromebook. Ton exemple du Chromebook, c'était, en fait, ils avaient un bon test et ils voulaient s'assurer que la performance, elle restait au moins aussi bonne. Et du coup, l'idée, c'est que ce problème-là, l'importabilité des gens qui font des applications, en fait, ils l'ont aussi. Si ton utilisateur, il est habitué à ce que, en utilisant ton application, les choses, elles mettent un certain temps, si ça va aller plus vite, il va être très content, si ça va aller moins vite, a priori, il va pas être content, quoi. Si ça va aller de plus en plus lentement pour faire la même chose, il va pas vraiment comprendre, il va... Donc, du coup, la qualité de ton produit, elle va en pâtir, et il y a des gens où c'est même pas la qualité va en pâtir, c'est qu'en fait, bah, leurs utilisateurs vont juste partir et aller chez des concurrents, quoi. Donc, en gros, l'optimisation à la micro-seconde, je suis d'accord, c'est quelque chose qui peut être quelque chose d'assez niche, mais par contre, empêcher les régressions et s'assurer qu'on garde quelque chose de sain et de voir, d'avoir la visibilité sur la performance de son code, ça par contre, c'est quelque chose que tout le monde commence à faire et ça va être de plus en plus démocratisé.
Bruno:
Est-ce qu'il n'y a pas quand même un risque de... J'essaie de formuler ma question parce que, la perte de la performance dans un contexte lambda ou normal on va dire, c'est quelque chose de très incrémental. C'est-à-dire que tu vas faire une mise en prod qui va te faire perdre un petit peu de temps, puis un petit peu plus. Si tu regardes d'incrément en incrément, enfin de mise en prod en mise en prod, le delta n'est pas forcément hyper important. Le moment où tu commences à considérer que c'est trop que la perte est trop importante par rapport à ce que t'avais comme target, peut-être en fait que t'as déjà laissé passer trop de choses comment tu fais pour déterminer une traîne qui va dans le mauvais sens.
Adrien:
C'est un problème qu'on voit beaucoup c'est qu'en fait dans un projet où tout va bien, l'idée c'est que le truc le plus facile à éviter c'est les grosses marches où en gros tu fais une nouvelle tu rajoutes un petit peu un petit peu de code un nouveau bout de code dans ta code base et tout d'un coup tu te prends, ton code est deux fois plus lent trois fois plus lent c'est facile. Du coup l'idée c'est que tu veux éviter ça à tout prix du coup l'idée c'est qu'avec Speed le fait que dans ta CI on te dise bah tiens, là si tu merges ça tu vas perdre ça ça va durer deux fois plus longtemps tu le vois direct mais par contre tu l'as dit bah il y a les silent killers qui sont les choses qui arrivent très souvent c'est que au fur et à mesure que tu développes ton application, la plupart du temps tu vas rajouter du code quand tu rajoutes du code tu rajoutes des features, il y a de plus en plus de code d'exécuté, donc forcément, au plus il y a de features, au plus ton code il va mettre du temps exécuté, et du coup si tu regardes la courbe dans le temps de. D'un benchmark notamment tu vas voir la plupart du temps que petit à petit va monter et donc l'idée c'est déjà rien que le fait d'avoir la visibilité là dessus c'est déjà énorme rien que le fait de se rendre compte de se dire bah ok il ya six mois j'étais là aujourd'hui je suis là je suis passé par ces marches là il ya eu des marches vers le haut vers le bas tout ça rien que d'avoir ça ça permet de se rendre compte de bah de combien ça permet de se rendre compte de la vérité quoi et Et déjà, rien que le fait de se rendre compte, c'est déjà une énorme étape. Et donc l'idée, c'est qu'une fois qu'on a ça, on pourrait imaginer complètement un système où on dit, ok, t'es parti à 10 niveaux. T'étais à, je sais pas moi, 10 millisecondes pour ce code-là. Aujourd'hui, 6 mois plus tard, t'es à 100 millisecondes, t'as fait x10. Est-ce qu'il y a un problème ? Est-ce qu'il y a pas un problème ? C'est à toi de le décider. Mais l'idée, c'est que au moins, avec la visibilité, tu vas voir les trends. Et rien que le fait de voir les trends, ça va te permettre de confronter ton modèle mental de qu'est-ce que tu t'attendais à voir avec la réalité et de voir s'il y a un delta.
Bruno:
On évoquait tout à l'heure, donc t'as fait le compilé de l'épisode 328 je crois, avec Antoine, on parlait de refactoring en fait mon propos il est sur le fait que, tu peux en fait déceler trop tard que tu as.
Adrien:
Une trend.
Bruno:
Qui était sur la baisse ou sur l'augmentation en fonction du métrique que tu mesures bien évidemment et qu'en fait la correction te nécessite un travail, trop important que d'une certaine manière tu aurais détecté quoi qu'il arrive au bout d'un moment.
Adrien:
Ouais alors complètement et du coup l'idée c'est que une fois que tu arrives là dessus une fois que tu arrives là qu'est-ce que tu fais et donc l'idée c'est une des manières qu'on a de pallier à ça à Codespeed c'est que, de manière automatique à chaque fois que tu fais tes tests de performance de manière automatique on va te mettre un donné à disposition du profiling où en gros tu vas avoir ce qu'on appelle des flame graphs où en gros c'est un graph d'exécution de ton code où tu vas savoir exactement, dans ton code chacune des fonctions qui ont été appelées et chacune de ces fonctions, combien de temps elles ont mises et quelles fonctions elles-mêmes elles ont appelées et donc l'idée c'est, là dans le cas que tu as parlé, on est en mode ok la performance elle est devenue elle a régressé, je veux l'optimiser et du coup première chose quand je veux optimiser c'est de savoir qu'est-ce qui se passe dans ce bout de code et du coup avec le profile, je vais pouvoir voir le flame graph d'exécution de mon code et c'est un peu ce que je disais tout à l'heure, c'est en fait je vais confronter mon modèle mental moi quand je connais ma fonction, je connais ma code base je me dis ah bah voilà, j'ai un modèle mental de à quoi mon flame graph devrait ressembler parce que je sais que je devrais passer tel temps tant de temps dans cette fonction, tant de temps dans cette fonction, en fait en regardant le vrai flamegraph en me rendant compte de la taille des. De la taille des frames dans le flamegraph je vais pouvoir me dire bah en fait c'est pas bon typiquement je parlais de Samuel Colvin tout à l'heure, je crois que j'en parlais oui le créateur de Paris-Antique sur une de ses librairies, c'est justement en utilisant les flamegraph où bah pareil il a regardé le flamegraph en fait il a dit mais, ce span là c'était un span je crois que c'était ça faisait du parsing de JSON, en gros il parsait un JSON il s'est dit c'est pas censé durer 80% du temps et en fait en regardant l'implémentation il a trouvé il a vu qu'il y avait un problème dans la librairie de parsing de JSON et en fait en la fixant il a réduit le truc avant ça prenait 80% du temps et maintenant c'est un truc qu'il a réduit ce temps là et il a gagné 80% sur, 80% d'exécution sur un benchmark qui du coup derrière a des impacts sur l'intégrité de la librairie mais du coup c'est vraiment de se dire, avec la visibilité sur mon code je peux confronter mon modèle mental de à quoi je m'attends à ce que ça ressemble où est-ce que je suis censé passer du temps et se rend compte que en fait, tu vas voir qu'est-ce qui te coûte du temps et qu'est-ce que tu vas devoir optimiser.
Bruno:
C'est du coup une super source d'apprentissage pour tous les devs en fait tu parles effectivement de confronter ton modèle mental je pense que tu as aussi moyen de découvrir qu'il y a des trucs qui prennent beaucoup plus de temps que ce que t'imaginais, et en général c'est aussi comme ça qu'on apprend le fait que t'as certains tris, t'as certains t'as certaines fonctions qui fonctionnent d'une manière un peu particulière enfin tu vois c'est de la, finesse de grain, on est sur la bordure du trait comme on dit enfin l'épaisseur du trait mais c'est un je trouve que c'est un énorme apprentissage pour tous les devs quoi.
Adrien:
Ouais et puis nous avec CodeSpeed le nombre de pattern qu'on voit, les enseignements qu'on a appris moi j'ai, enfin personnellement j'étais pas un expert de performance avant de commencer CodeFit, pas du tout mais j'avais des petites idées à droite à gauche tout ça, mais en fait bah ouais le nombre de choses qu'on apprend c'est vraiment impressionnant et c'est comme tu le dis, c'est hyper important, même d'un point de vue d'une équipe et tout quand tu, que ce soit d'ailleurs une amélioration ou une régression, dans les deux sens, je veux dire, des apprens de ça dans les deux sens parce que tu vas faire une, pour request tu vas ajouter un bout de code qui a l'air complètement anodin et en fait ce bout de code là il va éclater complètement la performance du coup c'est un super apprentissage pour tout le monde n'utilisez pas ça, utilisez ça à la place attention ce genre de choses.
Bruno:
Qui dit une mesure de la performance veut dire forcément un outil de mesure, est-ce que du coup vous ajoutez les sondes partout à tous les côtés, est-ce que du coup ça a un impact sur le coût de ta CI de manière globale ?
Adrien:
Alors du coup vu qu'on utilise ce qu'on appelle des benchmarks ça n'a aucun impact sur le code en production donc tout ce qui est lié à code speed sur les tests de benchmark tout ça ça part pas en prod il y a aucun, aucune footprint il y a aucun bout de code qui se retrouve en prod déjà. Et après l'idée c'est ces tests de performance il faut quand même il faut les runner dans la CI pour avoir des métriques, donc il y a une footprint dans le sens où la plupart du temps ce que tu vas faire c'est que tu vas rajouter un job en plus si tu n'avais pas déjà un job qui faisait tourner des benchmarks l'idée c'est que tu rajoutes un job pour faire tourner ces benchmarks et du coup, c'est un truc que tu peux faire en parallèle de faire runner tes tests unitaire par exemple et donc oui bah il ya suivant le nombre de tests de performances que tu as suivant le temps qu'ils prennent jusqu'à la quantité de code qu'ils exécutent le temps qu'ils prennent ça va rajouter plus ou moins de temps et donc là c'est c'est aux utilisateurs ben un peu de fine-tune et de savoir qu'est ce qui est important de tester et à quel point est ce qu'ils ont envie de tester la quantité de choses qu'ils veulent tester. Et donc, juste pour terminer, comment ça s'intègre ? Donc, c'est la même manière que tu as dans la plupart des langages. Dans la plupart des langages, tu as des frameworks pour faire des tests unitaires. Dans la plupart des langages, il y a aussi des frameworks pour faire des tests de performance, donc des benchmarks. Et donc, l'idée, c'est que nous, on se plug directement avec les frameworks les plus populaires pour faire des tests de performance. Donc, en gros, si aujourd'hui, dans un langage que tu supportes, tu fais des tests de performance, nous on va supporter ce framework là donc pour utiliser CodeSpeed, il y a juste une sorte de compatibilité layer qui est un package où en fait on a la même API que le package qui fait des tests de performance la plupart du temps il n'y a quasiment pas de code à changer par rapport à utiliser le, framework de base et rajouter un job dans sa CI et c'est parti.
Bruno:
Quoi ok donc ça veut dire qu'aujourd'hui on peut l'utiliser avec n'importe quel type de langage enfin quasiment.
Adrien:
Qu'on supporte qu'on supporte Il faut qu'on supporte, ouais. Donc aujourd'hui, ouais, on supporte Co, Rust, JavaScript, TypeScript, Python, et C++.
Bruno:
Ok.
Adrien:
Et du coup, dans tous ces langages, on supporte les frameworks les plus populaires. Des fois c'est natif, des fois non, pour faire les benchmark.
Bruno:
Pourquoi pas PHP, qui est pourtant le... Alors je sais que c'est... La stat est biaisée, mais c'est le langage le plus présent sur Internet grâce à WordPress. Donc c'est certes biaisé parce que c'est WordPress, mais du coup il y a peut-être beaucoup de choses à tester sur la performance en presse.
Adrien:
Oui oui bien sûr bien sûr.
Bruno:
Php.net.net.
Adrien:
On parle beaucoup java ces langages qu'aujourd'hui on ne supporte pas j'étais donné les derniers gros langages qu'on ne supporte pas complètement la raison pour laquelle on n'est pas parti c'est qu'en fait on a eu moins de demandes de par comment est-ce qu'on a construit code speed comment ça s'est fait code speed, on fonctionne pas mal grâce à la distribution open source parce qu'en fait Codespeed c'est gratuit pour l'open source, complètement gratuit et donc l'idée c'est qu'en fait on a commencé à être utilisé par des projets, plus en plus populaires dans les communautés open source et aujourd'hui les besoins, ce qu'on a vu c'est plutôt fait du côté des langages que je t'ai cités.
Bruno:
Plutôt que ces.
Adrien:
Autres langages où on a un peu moins de demandes mais comme je te dis ça arrive et on va les supporter le.
Bruno:
Prochain sur.
Adrien:
La liste par exemple c'est Java.
Bruno:
Une autre complexité que je vois aussi c'est que encore plus dans votre cas, qui dit mesure surtout dans cette notion de mesure de performance quand tu veux voir un peu des tendances t'as quand même besoin d'une stabilité de ta capacité de mesure on sait que les environnements de CI, les environnements de test sont pas toujours les plus, disponibles, les plus constants en termes de performance est-ce que vous avez un moyen vous de pallier à cette irrégularité des tests ?
Adrien:
C'est littéralement c'est la première quand CodeSpeed a commencé c'était la première propulsion de valeur qui était qu'aujourd'hui de faire tourner des tests de performance dans ta CI tu pouvais le faire mais si tu le faisais sur ce qu'on appelle typiquement si tu es situé sur Github si tu fais ça sur les runners Github, qui sont dispo gratuits ou alors t'as un free tier qui est assez généreux mais en fait c'est des VM qui sont partagées donc en gros, si tu run le même test de performance sur deux tu fais deux jobs différents, ça va être deux machines différentes tu vas avoir des résultats qui n'ont rien à voir parce que la machine, il y a un moment il y a quelqu'un qui va miner les bitcoins dessus et l'autre moment tu seras tout seul dessus ton.
Bruno:
Exemple est un peu extrême.
Adrien:
Mais déjà même toi tu peux le tester sur ta machine tu fais des tests de performance quand il te reste 5% de batterie et que t'es sur batterie versus quand t'es sur secteur et que t'es à fond tu vas voir qu'il y a une sacrée différence de perf donc même sur ta machine ça peut être très différent donc clairement c'était un énorme problème et si la mesure n'est pas consistante on peut pas se permettre de te dire dans ta PR ah bah tiens la performance a régressé de 20% parce que ça se trouve c'est complètement du bruit donc tu l'as dit c'était un énorme problème à résoudre et du coup la manière qu'on a fait pour résoudre ce problème, parce qu'on voulait que tu puisses runner sur des runners GitHub normaux ça a été de ne pas mesurer du temps. Mais plutôt de simuler ce qui se passe de simuler un CPU donc on run ton code sur un CPU qui est simulé on run le code une seule fois et en fait on va aller compter les instructions CPU, les accès au cache du CPU et les accès mémoire et l'idée c'est qu'avec toutes ces données là en fait on a on va avoir une sorte de on va extrapoler un nombre d'instructions CPU et ce nombre d'instructions ça va être la, on retransforme ça en temps en mettant une fréquence de CPU un peu nominale, et en fait ça c'est une mesure qui va être déterministe parce que sauf si ton code n'est pas déterministe on pourra y revenir, il y a des langages qui sont plus ou moins déterministes, il y a des langages qui sont plus ou moins déterministes langages non compilés, langages interprétés comme Python et JavaScript ils sont moins déterministes mais mine de rien avec cette approche on a des résultats qui sont vachement stables tant que ton code ça reste du code qui est lié au CPU donc. Qui n'a pas de I.O., donc de file system, de call DB, tout ça, ton code, il est sur le CPU, avec cette approche-là, on a des mesures qui sont vraiment hyper stables, sur, quand on regarde sur des projets, donc sur les projets open source qui utilisent CodeSpeed, toute la donnée historique est disponible, et du coup, on a des projets, ça fait des années, enfin deux ans qu'ils nous utilisent, tu vois que en fait, t'as des lignes flat, quoi, parce que d'une paire à l'autre, ils n'ont pas changé le code, qui est touché de ces benchmarks-là, du coup, la performance elle est complètement stable quoi ce qui fait que, c'est que en ayant cette performance stable si tu ne changes pas ton code en ayant cette performance stable cette flatline c'est que grâce à ça qu'on peut se permettre si jamais il y a une step c'est que grâce à ça qu'on peut se permettre de dire bah tiens il y a une régression il y a une amélioration parce que sinon bah c'est du bruit quoi et donc c'est comme ça qu'on a commencé, pour des use case typiquement voilà donc du code CPU bound pour ces use case là ça marche très bien et ça te permet de faire runner ça sur des machines github qui sont gratuites donc c'est comme ça qu'on a fait. Le problème, c'est que si jamais tu as des use cases avec des accès au file system, des accès au réseau, donc typiquement, on en parlait beaucoup, les databases, tout ça, qui sont des sacrés use cases, là, on ne peut plus simuler le CPU. Et donc là, on a besoin de revenir sur une méthode plus traditionnelle de matchmaking qui est, on a un bout de code, une fonction, on va l'exécuter un certain nombre de fois et on va faire des petites stats dessus et on va mesurer le vrai temps. Et donc là pour faire ça nous le parti qu'on a pris c'est si on propose de faire ça sur GitHub les runners GitHub tu peux le faire mais du coup tu vas avoir une mesure qui va être complètement. Brutée tout ça et donc on te le dit tu peux utiliser Codefield comme ça mais on te dit là pour le coup on ne maîtrise pas l'environnement de l'exécution, ça te dépend quoi tu peux le faire mais voilà et du coup nous ce qu'on propose c'est qu'on a commencé à proposer en regardant ce qui se faisait parce que des gens le faisaient aussi mais déjà plutôt in-house c'est en fait d'utiliser des runners, per métal donc c'est des machines où il n'y a que ton code à toi qui tourne, c'est plus une VM dans une machine partagée, donc c'est une machine per métal il n'y a que toi dessus, cette machine en plus on l'a fine-tuné nous-mêmes, donc on a fait on a fine-tuné deux, trois petits trucs sur la machine pour s'assurer qu'on ait une performance encore plus stable, que si c'était une machine comme ça, et grâce à ça on a un article sur notre blog où on a fait des comparaisons justement, on run des tests de performance de projets open source bien connus on les run sur les runners GitHub et on les run sur nos runners à nous, et on regarde la variance de ces résultats il y a toujours de la variance on n'a pas arrivé à zéro parce qu'en même temps c'est juste pas possible, mais ce qui est intéressant c'est en fait. Typiquement sur GitHub il va y avoir 4 ou 5% de variances et en fait on a fait un petit calcul je ne me rappelle plus exactement mais en fait si tu as 4 ou 5% de variances ça fait que ton seuil de confiance, pour te dire qu'il y a une vraie régression et que ce n'est pas du bruit il est assez élevé, ça va être de l'ordre de plus ou moins 10% ce qui est assez élevé, du coup ça veut dire que, si tu as un résultat de... Si tu as une perte de 10% de...
Bruno:
Tu ne peux pas savoir si c'est du bruit ou pas.
Adrien:
Avec nos runners la variance elle baisse je sais plus exactement mais je crois qu'elle baisse aux alentours du pourcent voire un peu en dessous là le seuil de sûreté il passe à 3-4% donc ce qui fait le seuil donc ça veut dire que tu peux mettre un seuil, un seuil vachement plus bas et t'assurer que tout ce qui est en dessous ça peut être du bruit mais tout ce qui est au dessus là c'est un vrai impact dans ton code.
Bruno:
Tu parles effectivement des appels réseau c'est à dire que je vois effectivement une vraie, tu parlais notamment de tout ce cycle d'exécution, je me dis que dans un contexte monolithique c'est hyper utile, dans un contexte microservice ou distribué, ça va être un peu moins pertinent parce que du coup tes tests sont hyper morcelés, on sait en plus que quand t'as des systèmes où t'as trop de services en fait tu te rajoutes aussi une latence de réseau et donc potentiellement autant de goulots d'étranglement un peu partout, est-ce que vous avez du coup cette, gestion particulière ou est-ce que vous favorisez plutôt les monolithes versus...
Adrien:
Pour l'instant tout ce qui est latence, inter-service c'est pas quelque chose qu'on a regardé, les seuls services en quelque sorte qu'on a regardé je t'ai dit c'est les DB, donc on considère qu'on peut mettre, avec les proxys sur les DB on peut avoir des infos mais à partir du moment où c'est un call vraiment un call HTTP qui part là on... Mis à part mesurer le temps d'attente on a pas forcément plus d'insight que ça donc pour l'instant oui c'est quelque chose ça va plutôt marcher au sein d'un même service si jamais voilà tu fais des calls à ton file system DBDB tout ça tu vas avoir des choses intéressantes, à moins que tu aies une possibilité de t'assurer que les calls réseau que tu fais ils soient extrêmement précis ce qui je pense ne peut ce qui n'arrive jamais, tu vas forcément avoir de l'avance mais le fait est que suivant ton news case c'est quelque chose que tu peux accepter et parce que tu veux quand même pouvoir catcher, les plus 50% les plus 100% et donc tu vas quand même pouvoir mettre en vouloir mettre en place une telle solution mais aujourd'hui c'est un énorme problème, C'est clairement un problème où il y a des choses à faire, mais aujourd'hui, on n'a pas encore commencé à regarder à ce niveau-là.
Bruno:
Et est-ce qu'après en même temps, je réalise aussi en le posant, est-ce que ce n'est pas au final, entre guillemets, plus un problème hardware ? C'est-à-dire que tu as la tendance réseau, tu peux l'améliorer en faisant en sorte que tes machines aient plus de capacité de traitement de leurs Ayo. Enfin, je ne sais pas si...
Adrien:
Ouais, si tu en arrives à ce niveau-là, mais la plupart du temps, j'imagine que surtout quand tu fais des... Des microservices, tout ça, ça va être surtout la latence de tes services downstream, tout ça, plus que la capacité réseau.
Bruno:
Tu évoquais tout à l'heure les sujets non déterministiques, les langages non déterministiques, donc les langages effectivement non compilés, mais si on va même au-delà du encore plus loin dans le non déterministique, ce qui se développe de plus en plus, c'est l'usage de LLM et d'outils comme ça où effectivement tu vas ajouter un LLM quelque part dans ta stack qui a des temps de réponse qui est complètement fluctuante comment est-ce que, l'évolution globale du code et du métier même de production logicielle est un truc qui est en train de complètement shifter, est-ce que cette mesure de la performance est-ce qu'elle a encore du sens dans une époque aussi tumultueux.
Adrien:
Nous notre vision c'est que oui ça va être de plus en plus important, l'idée c'est que aujourd'hui quand tu fais quand tu fais une application un site e-commerce, une application, la performance l'impact de performance c'est des utilisateurs c'est des humains qui vont la ressentir donc c'est la vitesse de chargement d'une page sur ton téléphone sur ton desktop, tu tapes dans un input le temps que ça va mettre à te donner des inputs et du coup nous en tant qu'humains, si c'est des temps d'attente de l'ordre de centaines de millisecondes 400 millisecondes 500 millisecondes ça va, ça passe bien si par contre tu commences à faire des applications qui vont être utilisées par des LLM, des agents, là pour le coup eux, la capacité de le bottleneck eux c'est plutôt à quel point tu peux leur donner de l'information rapidement et ils peuvent ingérer des quantités d'informations beaucoup plus rapidement que des humains et donc des plus grandes quantités et plus rapidement et donc l'idée c'est que bah toutes nos applications qu'on est en train de faire au plus ça va au plus elles vont être amenées à être utilisées par des agents typiquement on le voit pas mal avec les mcp je t'ai fait plusieurs épisodes dernièrement là dessus c'est un truc qui prend pas mal et du coup mcp.
Bruno:
C'est une dinguerie je fais une n'appartait mais vraiment j'ai fait pas mal d'épisodes dessus je le dis à tous les devs c'est hyper simple, c'est-à-dire que techniquement on parle pas d'un truc hyper compliqué mais ça va, changer le truc, ça va changer le monde c'est un avis perso, mettez-vous tous à MCP c'est pas compliqué et je vous jure que sur un CV pour moi c'est game changer.
Adrien:
En gros, pour expliquer carrément ce point de vue là, c'est qu'en fait aujourd'hui, quand tu fais ton application tu fais ton API, et tu vas avoir plusieurs clients qui vont consommer ton API la plupart du temps ça va être ton site qui va consommer ton API tout ça mais tout ça c'est des humains qui s'utilisent l'idée c'est qu'avec le MCP, tu rends ton application disponible à des agents des agents des LLM et eux c'est ce que je disais tout à l'heure c'est eux ils peuvent récupérer de l'information très vite au plus ils récupèrent l'information vite au mieux c'est et ils peuvent récupérer des quantités astronomiques d'informations du coup, Si ton application, elle a vocation à être utilisée par des agents, ce qui a priori a un virage à ne pas rater, la performance, ça va être hyper important parce que, en fait, au plus ton application est performante, au plus l'agent, il va pouvoir l'utiliser de manière efficace et ça va être un facteur différenciant énorme par rapport à tes concurrents si toi, tu es capable de donner la même information ou... Plus rapidement que quoi parce que le LLM en fait il va pas juste passer du temps à juste attendre ton endpoint enfin le endpoint MCP il va pouvoir répondre direct à l'information que tu vas donner.
Bruno:
Alors ma question elle était plus sur le fait que de plus en plus aussi dans les dans les systèmes que nous on ship en tant que développeur et développeuse on intègre dans nos systèmes des LLM qui vont pour générer du code pas pour générer du code mais tu peux avoir, tu peux avoir dans ton code à un moment effectivement t'as un agent qui est appelé pour prendre une décision soit pour aller effectivement router sur un bout de code en spécifique, soit pour te générer un output qui sera utilisé par ton code encore ensuite derrière. Mais du coup ce LLM ou cette IA qui est au milieu de ton code, elle, elle a des temps de latence, enfin des temps de réponse qui peuvent énormément fluctuer en fait. Donc quand on est justement sur une notion de mesure de performance c'est un, c'est un comment dire, c'est un j'arrive pas à trouver le mot mais c'est un truc erratiques au final comme...
Adrien:
D'ailleurs on voit pas mal de boîtes qui sortent, qui investissent il y a pas mal de boîtes qui, se mettent sur le créneau de l'observabilité des agents pour justement répondre à ce besoin là, ce problème là parce que c'est un énorme problème tu l'as dit quand tu lances ton agent et en fait il fait 5 allers-retours au lieu d'en faire qu'un seul et du coup ça prend 20 secondes au lieu que ça aurait pu en prendre 3 donc clairement il y a pas mal de boîtes qui font des produits là dessus sur de l'observabilité sur tes agents, donc ouais c'est clairement un énorme sujet aujourd'hui nous chez Codespeed c'est pas un truc qu'on avec la manière qu'on a c'est pas un truc, qui serait facile à mettre en place dès aujourd'hui mais c'est un truc sur lequel on est en train de pas mal regarder mais ouais aujourd'hui la... L'accent est vachement mis sur l'observabilité en prod sur ces trucs là et d'essayer de ramener donc il y a un truc qui s'appelle les evals je sais pas si tu connais en gros c'est ce que sont les tests unitaires au code, normal les evals ça va être des sortes de scénarios et tu vas t'assurer que ton, agent il va répondre à ton besoin donc tu vas pouvoir l'évaluer comme ça, et l'idée c'est peut-être de commencer à mettre des sortes de barrières de performance là-dessus pour s'assurer que justement il ne fasse que deux allers-retours ou trois allers-retours plutôt que d'en faire cinq et que ça prenne 20 secondes au lieu de cinq. Donc je pense qu'on va aller vers ça, ouais.
Bruno:
Tu parlais de MCP aussi tout à l'heure. Je crois que l'épisode juste avant toi, c'est un épisode que j'ai fait avec ou l'épisode encore avant, c'est un épisode avec Marcel Wicke, qui est le VP Engineering de Figma. On n'en a pas parlé sur l'épisode mais du coup j'ai pu le voir après Figma ils ont sorti un serveur MCP et je trouve que l'idée est assez folle et peut-être que ça pourrait être utile pour vous, c'est en fait ils ont fait un serveur MCP l'idée c'est que quand t'as une boîte qui met tout son design system dans Figma quand tu vas après faire de la génération automatique que ce soit de code, ou d'autres templates de pages dans ton Figma et que tu peux le faire avec leur IA Figma Mec ou même ton cursor, ton codex ce que tu veux en fait ton cursor va pouvoir appeler le MCP, de ton design system pour être sûr du coup de générer du code qui correspond à ton design system et qui reprend tous tes composants et compagnie ce que je trouve assez ouf comme idée, qu'est-ce que ça veut dire que dans cette même mécanique là vous pourriez avoir un MCP que du coup tu pourrais connecter à ton cursor qui est capable du coup quand il génère du code d'automatiquement le tester, pour voir en fait du coup effectivement l'évolution de la performance et essayer de s'auto-corriger avant de te sortir un truc.
Adrien:
Bah écoute on est en train de le tester.
Bruno:
Ok c'est vrai ouais.
Adrien:
Ouais non c'est marrant que tu en parles parce que du coup on est en train de le tester on a on a on a fait du coup la brique qui nous permet de rener du code un peu de manière ad hoc comme ça et du coup là on est en train de faire des tests sur ce produit là justement qui permettrait d'avoir, d'exposer du coup les services de code speed d'avoir cette mesure qui soit très consistante, avec le profiling tout ça en tant que enfin via MCP.
Bruno:
Donc.
Adrien:
On est en train de complètement bosser là-dessus.
Bruno:
Canon ouais.
Adrien:
C'est trop marrant que tu.
Bruno:
Sortes le truc et tout ça donc comme quoi parfois j'ai les bonnes idées et.
Adrien:
Du coup c'est un truc qu'on est en train de sortir et du coup l'idée ce serait que en fait ton agent il peut il faut être grâce à ce MCP en fait il peut quand il te propose du code il va pouvoir avoir des insights sur la performance et voilà, L'idée c'est que les feedback loops de tiens, j'ai ce bout de code-là, c'est quoi le profiling, ce span-là dans mon profiling il prend 80% du temps alors qu'il va prendre moins, ça peut être fait carrément par ton agent automatiquement, c'est pour y tirer dessus tout ça. On est en train de pas mal tester tout ça, c'est assez grisant parce que ça peut aller très loin.
Bruno:
Est-ce que du coup tu partages ce propos que j'ai juste avant, dire à tous les devs d'aller bosser sur RMCP parce que c'est une vraie dinguerie ce qui est en train de se...
Adrien:
Ouais, c'est... Moi j'ai l'impression que c'est un peu un virage technologique. Il y a eu le... Je n'ai pas connu, mais apparemment le web c'était un peu... C'était un sacré virage quand c'est arrivé. J'ai l'impression que là c'est... Enfin, j'ai pas vécu cet autre virage, mais j'ai l'impression qu'on est sur un truc qui est vraiment d'une envergure assez énorme. Donc moi je dirais... Il faut pas non plus se dire, oh là là, il faut pas tomber dans le truc, oh là là, MCP c'est compliqué ou alors, c'est pas pour moi il faut pas que je regarde il faut aller commencer à mettre le doigt dedans parce qu'en fait tu l'as dit c'est pas si compliqué à partir du moment où tu as déjà fait des applications c'est pas si compliqué à voir un peu comment ça marche je pense qu'il faut aller mettre, tremper les doigts de pied dedans parce que c'est clairement un virage qu'il faut pas arrêter.
Bruno:
Je suis d'accord avec toi sur le fait que moi j'ai un peu connu le virage du web j'étais encore un peu jeune mais j'étais en fin de l'adolescence, quand le web a vraiment commencé à exploser j'ai bien connu du coup aussi l'arrivée du mobile pour moi c'est deux révolutions qui ont changé la manière dont les utilisateurs interagissent avec des marques des produits, des services, ce que tu veux et, pourtant MCP c'est sorti en janvier je crois au février c'est tout début de 2015 je.
Adrien:
Crois que le protocole vient d'avoir un an.
Bruno:
Ouais quelque chose Donc.
Adrien:
Le protocole vient d'avoir un an et du coup, ça a commencé à être vraiment, vraiment connu il y a un peu plus de six mois ou pas.
Bruno:
Et vu que c'est porté massivement par Anthropik et OpenAI, je pense vraiment qu'on est au début d'une nouvelle révolution en termes d'usage, de la manière dont les gens interagissent avec des marques, des produits et des services, qui est à l'échelle de ce que le web et le mobile ont pu apporter.
Adrien:
Oui, donc complètement, oui. Complètement, et c'est pour ça que c'est hyper important de bien comprendre c'est quoi les nouveaux use cases et ça va être quoi les nouveaux besoins, les nouveaux pain points qu'on va avoir à cause de... Enfin, grâce à des suites d'utiliser les MCP. Du coup, c'est pas mal ce qu'on fait à Cosby, je te disais. C'est vraiment le fait de se dire, OK, les usages vont changer. Du coup, c'est quoi les nouveaux pain points qui vont arriver ? Qu'est-ce qu'il va falloir résoudre ?
Bruno:
Écoute, canon. merci beaucoup en tout cas pour cette discussion adrien j'aurais deux dernières questions pour toi qui sont les questions rituel du podcast la première c'est est ce qu'il ya un contenu que tu souhaiterais partager avec l'ensemble des auditeuristes ouais.
Adrien:
Alors c'est une chaîne youtube ça s'appelle je crois que ça s'appelle code esthétique on mettra le lien mais c'est une chaîne youtube alors c'est en anglais mais c'est une chaîne youtube qui parle de principe de programmation et, Je trouve ça hyper intéressant parce que la forme de la vidéo, elle est excellente. Il y a des diagrammes, tout ça qui bouge. C'est des très belles vidéos à regarder qui parlent de programmation rentée, objets, premature optimization, je l'aime beaucoup celle-là d'ailleurs, de vidéos. Donc je recommande vraiment de regarder ces vidéos. Ça parle de concepts de programmation qu'on connaît plus ou moins. Et c'est très bien présenté. Dommage, il ne sort plus de vidéos, j'ai vu, mais c'est pas mal.
Bruno:
Si on parle effectivement d'esthétique du code je pense qu'il y a besoin que les vidéos soient léchées et je vois effectivement le lien entre l'esthétique et la performance on est quand même un peu sur des sujets un peu connexes, Et dernière question la plus importante de ce podcast, Adrien, est-ce que tu es plutôt espace ou tabulation ? Espace Merci beaucoup Adrien Merci à tous d'avoir suivi ce podcast J'espère qu'on vous a donné envie de vous intéresser un petit peu à la performance du code à mon avis vous y intéressez déjà parce que je sais qu'on est un peu tous, parfois on a des lubies comme ça on a envie que ça marche mieux que ça marche plus vite, que ce soit plus efficace plus pertinent, mais c'est toujours intéressant d'avoir les outils, donc n'hésitez pas à aller checker la librairie Codespeed. Pour vous donner les outils de le faire et puis aller checker le MCP et, renseignez-vous sur MCP, faites du MCP c'est un game changer c'est une révolution à ne pas manquer, je vous remercie aussi comme toujours de partager ce podcast autour de vous, n'hésitez pas à mettre un commentaire 5 étoiles ou un pouce en l'air en fonction de la plateforme sur laquelle vous êtes. Je vous remercie beaucoup, je vous souhaite une très bonne fin de semaine, je vous dis à la semaine prochaine, et d'ici là, codez bien !
