Contexte Engineering : Dresser ses agents IA

Bruno — Racontez une blague sans contexte et vous allez faire un bide. Expliquez-la pendant 10 minutes, vous allez aussi faire un bide. Le contexte, c'est un dosage presque impossible. Sans lui, on ne comprend rien. Avec trop, on est juste complètement perdu. Les cochers, eux, l'avaient aussi bien compris avant nous. Un cheval sans reine ne sait pas vraiment où aller. Mais un cheval sans œillères voit tout et peut potentiellement s'affoler. Un bon harnais ne montre pas tout. Il lui montre juste ce qu'il faut. Mais alors, le contexte, on l'écrit plutôt pour les humains ou pour les machines. Comment harnacher une codebase de 15 ans dans laquelle plus personne ne comprend rien ? Et surtout, quand une PR est rejetée, faut-il corriger le code ou envoyer l'agent en rééducation ? Pour répondre à ces questions de dressage, je ne reçois pas le Père Noël, mais il s'y connaît en attelage. Florian, bonjour.

Florian — Bonjour, j'ai trouvé ça très marrant.

Bruno — Alors Florian, est-ce que tu peux te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?

Florian — Oui, avec plaisir. Moi, je suis Florian Brugnot, geek et passionné depuis toujours. J'ai baigné très tôt dans la tech et donc tout naturellement, j'ai eu un cursus tradi d'ingé logiciel où j'ai fait mes armes en tant que dev, puis lead dev, puis EM, VP, CTO. Donc, une traque assez orientée management sur les dix premières années de ma carrière où j'étais plutôt celui qui devait être le bon sélectionneur. Donc garder un certain niveau pour arriver à aller chercher les bons talents, à les évaluer. Mais j'ai toujours aimé dire que j'étais expert en rien et que mon but, c'était justement d'aller choper les bons experts dans les différents postes sur lesquels je recrutais. Plutôt profil, bac, infra que front, etc. Même si maintenant, on touche à tout. Il y a quelques années comme beaucoup on va dire de profils alors senior avec des guillemets, j'ai eu envie de repartir à mes premiers amours la tech, le code et donc je suis passé d'un rôle de VP of engineering avec une trentaine de personnes dans mon scope à peu près à, du early stage où j'ai repris une vieille code base donc pas avec 15 ans mais avec quelques années on va dire fait de façon un peu yolo, et je suis revenu seul d'Ève en gros à mes premiers amours je me suis amusé, j'ai repris confiance en mes capacités techniques quand on ne pratique pas, on se dit qu'on les a perdus je dirais que c'est comme le vélo ça ne s'oublie pas mais il faut se remettre en selle quand même, Et là, ça fait à peu près un an, un an et demi que je me suis mis à fond sur l'IA générative. Pas juste dans l'usage, mais vraiment essayer de comprendre et essayer de communiquer. J'ai oublié de le préciser, mais j'ai navigué dans l'écosystème IA depuis 2017, 2018. J'ai travaillé dans le NLP, donc le traitement du langage, dans ce qu'on appelait le big data à l'époque, dans les mots un peu valise. Donc j'ai toujours gravité autour de ça échangé avec des data scientists, des machine learning engineers donc moi quand c'est arrivé la Gen AI forcément j'ai toujours été dans les profils excité early adopter ça m'a fait marrer. Et depuis cette année en gros ma bonne résolution de l'année c'était pas d'arrêter la bière ou de faire du sport c'est un vrai truc, et c'était de faire de l'open source et j'ai fait de l'open source et je suis arrivé très tôt sur un petit projet à l'époque qui s'appelle RTK qui a été lancé par Patrick que t'as reçu ici, où au début il disait tiens j'ai fait ça, ça a l'air cool et en gros il cherchait des contributeurs, je lui ai dit c'est génial, j'ai contribué assez fortement pendant, tout le premier quarter et après je suis plus passé sur un rôle d'évangélisateur et en fait ça m'a ouvert beaucoup de portes, ça m'a permis de voir les bons, les mauvais côtés de l'IA et tout ce que ça implique dont on va parler après et maintenant j'ai le plaisir depuis quelques mois, d'intervenir dans différents podcasts, émissions, conférences sur la partie sur laquelle j'ai le plus travaillé, donc initialement le contexte engineering donc j'ai beaucoup aimé ton intro parce qu'effectivement c'est clé et plus récemment sur un truc encore un peu plus spécialisé qui est le harness engineering où, je retrouve au final un rôle assez similaire à ce que j'avais quand j'étais, engineering manager où je devais donner le bon cadre à mes équipes, sauf que maintenant mes équipes sont plus humaines mais sont, des agents IA.

Bruno — Très concrètement comment est-ce qu'on pourrait faire la distinction entre le contexte engineering et le harness engineering.

Florian — Si on prenait une image un peu d'un entonnoir, je dirais que le contexte engineering est côté plus haut. Pour moi, c'est plus large. Déjà, dans la définition, le contexte engineering, il me semble que c'est Carpathie, si je ne dis pas de bêtises, qui avait dit que c'est l'art de placer la bonne donnée au bon endroit au bon moment. Donc ça fait écho à ce que tu disais, ni trop ni trop peu, donc il y a tout, un ensemble de concepts en fait qui viennent autour de ça parce que c'est large, et donc du coup plus bas le harness engineering pour moi est comme une sous-partie en fait du contexte engineering qui vise plus à aller, Assurer. La qualité et les systèmes qui vont permettre d'avoir confiance en ce qui est produit par l'IA, pour arriver à accélérer avec un niveau de qualité acceptable, un niveau de sécurité acceptable. Et c'est là où, en fait, après, le niveau du harnais va mettre la barre plus ou moins haute. J'ai envie de faire le parallèle avec des compétences qui étaient déjà dans le software engineering d'avant, qui étaient les design patterns, les principes solides, la clean archie, le TDD. Tout le monde l'utilise plus ou moins tout le monde met un certain nombre, de pratiques mais d'une équipe à l'autre dans une petite équipe qui doit aller très vite sur un produit pas très sensible à une grosse équipe qui bosse en fait avec que des profils seniors, il va y avoir différents niveaux. Donc voilà, pour moi le harness c'est un ensemble d'outils qui va arriver sur, plusieurs couches aussi, et ce qui est marrant c'est que c'est des termes qui sont un peu des mots-valises, on peut mettre beaucoup de choses, et ça évolue au fur et à mesure. Au début, quand on parlait de harness, on parlait de la couche, on va dire, locale pour le développeur, les skis, les hooks, ce genre de choses. Puis après, une fois que l'adoption a été faite, on voit que ça se déplace, donc l'équipe arrive à shipper, enfin chacun individuellement arrive à shipper plus vite. On part du coup sur des problématiques au niveau de la CI, au niveau de l'infra, nouveau goulot d'étranglement, et on voit que du coup, le truc se construit un peu brique par brique. Je pense qu'il n'y a pas encore une... Méthodologie claire sur ce qu'est le harnais, comment le faire je pense qu'il va y en avoir plusieurs et un peu des mouvements donc voilà.

Bruno — Parce que du coup pour toi toutes les tendances qu'on voit autour d'évolution, de la CI l'épisode de la semaine dernière alors que tu as pu écouter parce que je l'enregistrais hier mais qui sera diffusé la semaine dernière par rapport à la personne qui nous écoute on parle justement de l'évolution de la CI, sur toute cette conséquence on génère énormément de code, et qui bousculent un peu les CI. Toi, ce que tu vois dans cette évolution de CI, pour toi, ça fait aussi partie du concept de harnais au total, parce que ça permet au final de générer du code de meilleure qualité, c'est ça un peu l'idée ?

Florian — Ouais, parce qu'en fait, le harnais, il y a une couche, en gros, comme je disais, individuelle sur la machine du développeur, qui permet en fait, si on le fait en très rapide, d'envoyer, du coup, dans GitHub, dans GitLab, d'envoyer un code qui est censé respecter un certain niveau de qualité qui a été défini par l'équipe, mais une fois que ça arrive justement là-dedans, on arrive sur tous les concepts de continuous integration, ce genre de choses où il y a d'autres verrous, il y a d'autres vérifications qui se font, que ce soit au niveau des tests, et maintenant au niveau du contexte, au niveau en fait, du travail qui a été fait par le reste de l'équipe, donc ouais, ça se déporte, vraiment assez fort, et pour moi il y a une partie du harness, du coup, qui est un peu mon terrain de jeu en ce moment, qui est au niveau justement de la CI, mais qui consomme beaucoup de ressources, qui tournent beaucoup parce qu'on veut faire ceinture, bretelles, parachute pour être sûr qu'il n'y ait pas de bêtises. Ça consomme du coup des ressources au sens VM, des workers. Ça coûte de l'argent. Ça fait exploser les coûts. Il y a des nouvelles problématiques, de nouveaux contextes et sécurité parce qu'on fait transiter de la donnée qui ne transitaient pas forcément avant. Donc, il faut faire attention à ça. On envoie des volumes qui sont juste phénoménaux. Il faut imaginer que le... Modulo la taille des équipes mais on fait entre x2 et x10 je dirais que plus c'est gros moins ce facteur est exponentiel plus une équipe est petite, plus on produit et là en gros dans ma boîte actuelle méthode Aristote, on est deux devs de métier plus trois products qui maintenant sont des product builders, je pense qu'on en voit. Plusieurs milliers de pull requests en quelques mois donc les volumes, donc en gros on met à mal la partie qui est sur ACI, des DevOps, comme on dit, des FCCOPS, comme le sujet dont on parlait avant. Ça génère plein de nouvelles problématiques, dont une qui est assez forte, qui est le coût financier, qui peut vite devenir assez peu maîtrisable. En général, c'est une fois qu'on se prend la première grosse facture, comme à l'époque, les gars qui sont pris les premières factures à WS, une fois qu'ils avaient un peu trop joué avec des Lambdas, on dit « Wow, on va faire attention ».

Bruno — Pour revenir sur la notion de harnais j'ai vu passer un truc l'autre jour je trouvais l'idée intéressante, quelqu'un qui disait que de son point de vue, parce qu'encore une fois tu l'as dit c'est des mots qui bougent chacun a posé la définition, la poussière n'est pas encore posée mais qui disait que le harnais c'est toute la partie déterministe que t'as notamment dans ton cloud code, donc là on revient sur cette notion très locale que t'évoquais avant mais je trouvais ça intéressant, de de dire qu'en fait effectivement ce qui est ce qui permet à cloud code d'être aussi efficace c'est pas tant le llm, c'est surtout l'ensemble des outils très déterministique qu'on a autour donc des linter un ensemble d'outils pour aller je passe qu'elle est répertoire choisir comment tu tu découpes tes fichiers ce genre de choses, qui permettent de donner du bon contexte, c'est ça du coup au final au LLM ?

Florian — Du bon contexte, des contrôles, des verrous, effectivement, quand on parle de harnais aussi, Cloud Code est un harnais, Codex est un harnais, Pi, enfin après je ne vais pas tous les citer, il y en a énormément, on voit bien qu'il y a différentes visions, différents mouvements, mais qui en plus ressemblent visiblement après aux organisations, et c'est là où on voit qu'on essaye tous de construire... Et effectivement, le harnais, c'est toute l'espèce de grosse boîte à outils qui va venir graviter autour du modèle, autour, du LLM, qui est qu'une partie et un des trucs clés qu'il faut vraiment, enfin, que j'essaye de faire comprendre, c'est, OK, on a des modèles qui sont de plus en plus puissants, qui captent sans qu'on leur donne, enfin, on va dire, ils comprennent de mieux en mieux, ils sont efficaces, mais il vaut mieux un très bon harnais et un modèle plus low cost ou plus basique qu'un très bon modèle, sont harnais à date, en octobre 2026, peut-être qu'on voit bien que les modèles, ça va à une vitesse assez folle et on a besoin de moins en moins sécuriser avant de donner des règles pour la concision, on mettait des verrous dans tous les sens pour limiter justement le contexte blot, ce genre de choses. Et effectivement, les harnais locaux, il y a toute la partie pour le rendre, efficace et pertinent vis-à-vis de la stack. Donc là, le harnais peut être aussi adapté pour qu'ils répondent bien à une problématique. Est-ce qu'on fait du front, du back ? Est-ce qu'on fait du bas niveau, du haut niveau ? Est-ce qu'on fait du mobile ? Après, le harnais, pour moi, il doit s'adapter, comme je disais, à l'organisation et donc à la personne qui l'utilise. Je n'ai pas le même harnais à proprement parler pour un de mes stagiaires produits que pour un dev senior, que moi qui suis plutôt dev back, que pour mon collègue qui est dev front. En gros, c'est là où on a aussi une notion de « on va adapter. La tâche qu'on est en train de faire, à la personne qui est en train de piloter ». Et c'est là qu'on revient justement sur cette idée de contexte. Le harnais va pouvoir en fait générer dynamiquement un contexte adapté au pilote et à la tâche en cours.

Bruno — Ok. J'ai reçu récemment je sais pas si l'épisode est sorti il n'est pas encore sorti, j'ai reçu il n'y a pas très longtemps Quentin de Théodaux, qui travaille sur la practice de refactoring de code, donc ils prennent que du code legacy, qu'ils réécrivent dans un nouveau langage ils ont une practice qui est, qui est full AI c'est à dire qu'il n'y a aucune ligne de code qui est tapée par le moins d'être humain, et je trouvais qu'ils avaient une manière intéressante d'onborder les devs dans l'équipe, c'est que chaque dev en fait, commence son travail par recoder son propre cloud code. Donc, il fait son propre harnais et il recrée son propre outil. Est ce que ça te semble devenir un peu une nécessité dans notre métier? Parce que ça a un moyen peut être pour des plus jeunes de effectivement faire du dev. Je pense que c'est un super moyen de comprendre que, comme tu le disais, l'intérêt, la performance de cloud code, c'est pas que cloud, c'est aussi cloud code, tout ce qu'il y a, tout ce qu'il y a autour et de comprendre cette notion de harnais.

Florian — Pour moi, c'est essentiel parce qu'en plus, pour faire un bon harnais, il faut avoir des compétences quand même en software engineering. Et c'est là entre utiliser un harnais, l'exploiter, un non-tech, un moldu comme j'ai souvent un peu arrivé à y arriver. Mais par contre, pour créer ce harnais, c'est vachement pertinent leur approche parce que du coup, là, il faut comprendre ce à quoi il faut faire attention. En fait, pour surveiller quelque chose, par définition, il faut savoir quoi surveiller. Il faut comprendre et pour mettre des verrous il faut savoir ce qu'on veut verrouiller donc en gros c'est assez smart je trouve comme approche ce qui fait qu'après en gros quand on a regardé en fait sous le capot, on sait mieux mais comme un super mécano ce qu'il va falloir bidouiller ça fait un petit bruit machin qui me plaît pas allez un coup drill-en et ça va partir donc j'aime beaucoup, c'est un sujet en plus que j'ai évoqué du coup, avec Marek de chez Théodaux récemment également, ouais il y a un gros sujet et, je pense que c'est quand on parlait justement des juniors et de l'apprentissage dans le résumé de l'épisode précédent. On n'apprend plus les mêmes choses, on n'apprend plus de la même façon, donc là effectivement est-ce qu'on va apprendre à produire du code en typescript, admettons, en faisant du TDD et telle ou telle bonne pratique non, maintenant on va apprendre à, créer le harnais qui va lui produire du code de qualité donc en fait on step up en fait on remonte d'un niveau, donc je pense que je leur repiquerai l'idée honnêtement c'est assez malin.

Bruno — J'ai plusieurs questions j'essaie de les faire dans un ordre qui soit on va commencer sur, Si on considère que le harnais c'est un outil pour permettre aux développeurs ou à la développeuse de générer du code qui soit pertinent dans le contexte dans lequel il est, historiquement dans les équipes tech on avait des équipes de développeurs experience qui étaient là justement pour mettre à disposition les bons outils, s'assurer que tout le monde soit dans la meilleure condition pour travailler. Est-ce que tu crois que dans un contexte où ces outils deviennent de plus en plus critiques et ceux qui génèrent réellement le code, est-ce que ça veut dire qu'on va avoir des équipes de Devex qui vont devenir énormes parce que ce sera le principal métier quasiment, enfin purement technique ce sera eux les plombiers on va dire, de ça ou est-ce que à l'inverse c'est des équipes qui vont disparaître parce qu'en fait ça va être une compétence en fait portée par tout le monde de gérer eux-mêmes ça.

Florian — C'est une bonne question j'ai plein d'idées attends je fais le tri un peu dans ma tête parce que sinon ça va partir dans tous les sens En gros, effectivement, ça fait sens quand on parle d'équipe de Devix, je pense notamment aux équipes de Platform Engineering aussi, qui n'est pas si ancienne, on dit historiquement, mais pas tant que ça, en vrai, ça va vite. Moi, je pense qu'effectivement, alors est-ce que ça va être des équipes énormes et tout ? Je ne sais pas. Je pense par contre que ça va être des équipes où on va mettre des équipes. Vrais experts, très très forts. Et pas forcément que des experts en harnais, qu'il a une compétence à part entière, comme on apprend à faire de l'infra. Là, on va mettre des experts au sens métier, mais métier tech. On va mettre des experts en TDD, on va mettre des experts en Rust, si jamais il y a en gros l'équivalent des leads ou des staffs engineers. Enfin je pense qu'en fait ces équipes vont interagir avec les profils vraiment très très très très forts parce que en gros, là où les staffings avant venaient regarder les codes review, venaient vérifier le code qui était produit par les humains maintenant ils vont venir en fait verrouiller le harnais donc en fait si les équipes vont être très grosses je sais pas mais elles vont devenir clés. Et c'est déjà le cas je pense que ça va accélérer Après, il faudra qu'il y ait des gens qui soient garants en fait si on veut accélérer très vite et aussi répartir les practices En fait ça va dépendre encore une fois de la taille des organisations Dans une petite boîte en rally stage comme je suis Non en fait c'est porté par plus ou moins tout le monde, les profils tech Même si dans les faits moi mon rôle a déjà évolué donc je suis rentré j'étais le seul dev, Donc au début, j'étais un dev qui produisait avec de l'IA. Puis après, il y a un des product qui m'a dit, mais en fait, il y a plein de trucs où je perds du temps à te les expliquer. Donne-moi les clés de la voiture. Donc là, c'est là où mon harnais à moi est devenu le harnais de l'équipe qu'on a fait. Il a appris à comprendre le harnais, même s'il ne contribuait pas sur le harnais directement, vu que lui, ce n'est pas un tech de métier. Lui, en gros, à la limite, parce que dans le harnais, c'est là où ça peut être discutable. Mais pour moi, il y a une couche contexte et donc métier. Et donc qui est très lié en fait à l'entreprise où lui du coup contribue au harnais, sur la partie être sûr que l'IA part pas en freestyle sur des concepts business, métiers qui pour le coup peuvent encore causer beaucoup plus de dégâts qu'un, bug technique. Et après on a avancé comme ça et moi mon rôle maintenant c'est je suis quasiment... 75% de mon temps sur le harnais, donc en fait dans les faits, dans une petite équipe où on est 4-5 à la tech, il y a déjà 20% de l'équipe qui maintenant est dédiée à ça, parce qu'il faut que ça évolue très très vite, et en fait c'est, un truc un peu vivant, en fait c'est pas juste on fait un one shot et voilà, et le harnais non, il évolue tout le temps il évolue avec là où les applications, il évolue avec les arrivées dans l'équipe, il évolue avec les problématiques de coût, de sécurité. Donc je pense qu'il va falloir qu'il y ait des champions, diffusés dans les équipes qui soient formées et à un certain niveau d'entreprise, du coup il y aura une, voire des équipes dédiées, où il y aura des spécialistes auxquels je vais plus moi, enfin, mon profil en gros spécialiste sur comment on fait un harnais, qu'est-ce qui est possible qu'est-ce qu'on vient mettre dedans, comment en gros on vient faire en sorte que l'IA, via plein d'outils respectent les règles qu'on lui donne et il y aura des gens qui par contre sont très compétents sur les règles à donner, mais je vois même aussi comme je disais du coup, pas que des experts techniques, même des experts métiers donc potentiellement des products ou des designers s'il y a un moment, enfin il y a des apps qui sont très importants qui vont travailler du coup avec ces équipes là, parce que, un exemple le design, c'est un truc où on voit que, le front au sens vraiment l'interface, pas le code mais le fait de respecter un design système pour moi c'est pas encore tout à fait craqué ou en gros moi en tout cas j'ai pas encore tout à fait craqué le truc avec mon équipe. Donc là je pense qu'il y a un immense terrain de jeu aussi pour faire en sorte que, le harnais mette les bons verrous pour éviter qu'on se retrouve avec une application qui va grossir trop vite où on se rend compte où le designer va se rendre compte que le truc est parti totalement YOLO en fait et ça respecte pas du tout son design système.

Bruno — Donc toi ce que tu vois c'est plutôt le... On va dire les équipes d'architectes ou le conseil des sages, selon les boîtes, chacun l'appelle un peu comme il veut, mais on a toujours effectivement, cette équipe avec des staffs, les top experts. Tu vois plus cette entité-là fusionner avec une notion de devex et de rajouter aussi une compétence métier pour être une espèce, de métabuilder, c'est-à-dire qu'on ne construit pas le code, mais on construit ce qui permet de construire le code.

Florian — Et qui vont en gros il y a plein d'enjeux là dedans déjà il y a des nouveaux rôles, on voit il y a le chief AI officer qui arrive et qui n'est pas juste de la tech des fois c'est même des profils non tech parce qu'on parle de strat, on parle de transfo on parle d'un impact presque encore plus humain ou en tout cas la partie la plus complexe à gérer, la partie humaine plus que la partie technique, on parle de harness engineer je ne sais plus qui a inventé le terme qu'il a sorti il y a quelques mois, pendant un moment, il y a très longtemps, on parlait de prompt engineer, donc on voit qu'il y a des nouveaux rôles, des nouvelles spécialisations c'est comme quand on dit DevOps à la base c'est un mouvement, DevOps c'est plutôt une culture et après dedans il y a SRE, il y a différents pans métiers donc je pense qu'il va y avoir des profils simplement qui vont se spécialiser. Et Je pense que c'est on va avoir en fait effectivement des gens qui vont devoir être au service, des équipes et rester à jour parce qu'il y a un gros enjeu qui est quand même clé c'est, au delà du FOMO parce que pour l'ego moi c'est un symptôme un syndrome que j'ai vraiment le FOMO la peur de louper un truc quand j'entends un copain qui me parle d'un truc que j'avais pas dans le viseur je suis dégoûté en mode comment ça se fait que je le sais pas et, il va falloir suivre parce qu'en fait les avancées sont telles que si un truc bouge pas pendant quelques semaines c'est, Je ne sais pas, ça peut être, si on n'a pas fait attention, typiquement, donc là on est en octobre 2026, il y a Opus 5.5 qui est arrivé, Sony 5.5, qui ont plié le game, enfin là ils sont revenus très fort dans la course, bah si, pour une raison X ou Y, je ne vois pas comment, pourquoi, mais admettons que, les harnais étaient verrouillés sur une ancienne version de Cloud, parce qu'on peut le faire, on peut verrouiller, moi j'avais verrouillé en Opus 4.6 ou 4.7, je ne sais plus, parce qu'il y a peut-être bien la 4.7 ou la 4.8 qui n'était pas ouf, bah en fait c'est quelques semaines après où j'ai tilté en fait que merde il y a un truc qui me va pas je vois que tout le monde dit qu'ils sont contents et tout et je vois que je ressentais pas. La même chose bah ça c'est une erreur et donc du coup il va falloir qu'il y ait quelqu'un aussi qui suive et qui mette à jour et qui aille pousser dans les équipes et pour le coup c'est là où les équipes qui buildent le produit vraiment vendu par la boîte et tout, il faut leur retirer cette charge il faut qu'ils suivent mais c'est comme à l'époque ils pouvaient pas tout suivre le dernier framework que j'y ai, c'est tout, rester à la page donc il faut des gens qui viennent les nourrir mais avec. Comment dire, un prisme assez propre en gros, venir leur faire un digest en gros, de tout ce qui passe et en gros ça veut dire qu'il y a des gens qui vont devoir tout ingérer pour venir recracher entre guillemets de façon ciblée pour éviter, de flouder, de défocus en fait les équipes ça c'est un des points que je retiens d'un ancien manager à moi qui a dit tu fais plein de veilles c'est génial mais ne défocus pas tes équipes ouais.

Bruno — Comme tu disais tout à l'heure que toi, tu inclues aussi toutes les évolutions qu'on voit sur la CI dans cette notion de harness engineering. On évoque effectivement tous ces outils qui permettent de générer du code proprement. Forcément, tu as évoqué, tu as fait une analogie tout à l'heure avec le monde de l'automobile. Tu as dit que les gens du produit t'ont demandé, file-moi les clés de la voiture. Tout ça, ça nous fait quand même penser au concept d'usine logicielle, mais au sens très strict du terme. c'est-à-dire que tu as une usine, donc nous on construit une usine qui va pouvoir en fait générer du code derrière. Est-ce que ça veut dire que toi tu vois, le harness engineering devenir l'avenir du software engineering ? C'est-à-dire qu'en fait notre métier ne va être que de créer une factory capable de générer du code, et que du coup on ne verra plus jamais le code et qu'on va très très peu, voire quasiment plus écrire le code qui sera en production, mais uniquement s'occuper de produire l'outil qui sera capable de générer du code comme on aimerait qu'il soit généré.

Florian — Encore une fois, bonne question. Effectivement, l'usinage antique, Software Factories, ça fait partie des sujets chauds du moment. Et le cas là, on en reparlera peut-être après, mais aussi après le Greenfield, le Brownfield, donc la notion de faire du neuf ou faire de la rénovation, qui sont deux façons de travailler. Donc déjà là, on voit déjà des pistes où il y a quand même des façons entre faire du neuf from scratch, construire une maison neuve, on va faire l'analogie ici avec le bâtiment, et faire une rénovation. C'est des compétences, des entreprises différentes. Donc il y a quand même, en gros, déjà deux pans qui se distinguent. Je pense qu'effectivement. Beaucoup d'ingénieurs de software engineer vont, à mon sens, bifurquer vers la construction de ces usines logicielles au sens large. Donc ça englobe énormément de choses mais devenir développeur du coup d'outils ce qui ne veut pas dire qu'il va juste y avoir je ne sais pas comment dire trois méga entreprises dans le monde qui vont faire trois usines de logiciel mais je pense que chacun va construire son usine, en interne en l'adaptant etc. En se nourrissant de l'open source aussi qui est un des gros sujets en ce moment, je pense qu'il y aura toujours par contre aussi des gens qui vont bifurquer beaucoup plus proche du métier ça fait quand même quelques années qu'on parle de product engineer, le dev n'est pas un pisseur de code mais il doit comprendre le métier et je pense que ça va faire d'autant plus sens maintenant où en gros il y avait un peu, des gens un peu au centre qui n'avaient pas vraiment choisi leur camp qui ne sont ni experts, ni managers ni en gros très intéressés par le product, effectivement il va y avoir moins de place pour eux, il va falloir choisir à un moment soit tendre vers l'expertise et, j'aimais bien l'analogie de la plomberie que tu as glissé, dans cette question ou celle d'avant parce que c'est très marrant parce que j'ai demandé à l'IA d'analyser, les profils de mon équipe en fonction des commits et de comment on travaille sur... Et l'IA, pour moi, a utilisé le terme plombier, justement, en fait, avec les pipelines, la série, juste. Donc, c'est assez fun. On est vraiment là-dedans. Et après, au niveau du code, on parlait de... Est-ce qu'on va voir, du coup, le code ? Est-ce qu'on va toucher, déjà ? Tous les gens les plus avancés dans l'IA que je croise actuellement, n'écrivent plus de code. Ou très très peu, au sens où, donc là moi mon univers il est très typescript web, enfin assez classique, sans furiture entre guillemets j'en connais peu qui écrivent encore du code, si ce n'est parce que des fois il faut rester pragmatique pour aller faire une correction, un truc comme ça, des fois plutôt que le dire à l'IA de le faire, enfin il faut aussi ou pour le kiff, en gros ça marche aussi, il y a un extrême où on parle du fait que les langages vont peut-être disparaître, le langage de programmation à la base c'était une interface justement pour comprendre, pour que l'humain puisse, comprendre, exécuter et c'est là où il y a eu plein de façons de faire avec par exemple Windef qui avait eu le parti pris on va faire en français, on va faire un truc assez, comment dire, fermé, un écosystème maîtrisé et tout, où il y a eu des partis pris mais là en fait on arrive où il y aura peut-être une sorte de métalangage qui va peut-être être comme du pseudo code donc on va peut-être avoir des nouveaux langages Qui vont apparaître A mon sens, Mais qu'au final très très vite Qui va partir en prod Pour ainsi dire je n'en sais rien Ce sera du binaire Ça sera du... Enfin... Donc, je pense qu'il faut s'attendre à avoir des gros changements. Et on voit aussi qu'écrire, par exemple, un langage, c'était un truc de fou. C'était des pontes de la tech qui le faisaient. Maintenant, on voit qu'il y a des étudiants qui réécrivent un langage pour une thèse ou pour un stage. Je crois qu'il y a un gars qui s'est tapé le délire de recoder. TypeScript en Rust en quelques jours. Il y a des chercheurs qui réécrivent, etc. donc ça se trouve sinon c'est peut-être même encore pire c'est peut-être qu'il y aura une sorte de langage machine et que les organisations vont créer non pas un logiciel mais un langage, propre à leur business.

Bruno — À leur.

Florian — Produit à leur métier, voilà je me suis un peu éparpillé.

Bruno — Mais je trouve ça ultra excitant mais alors après j'avais déjà évoqué effectivement quelques fois à ce micro le fait que potentiellement demain on aura plus de langage C de langage javascript et autres mais peut-être qu'on n'aura que du français ou de l'anglais, ou la langue naturelle des gens, ce à quoi beaucoup de gens bien plus brillants que moi me répondent que, ce qui est difficilement atteignable dans cet élément là c'est que, en tout cas dans ce qu'on imagine aujourd'hui un programme pour tourner a besoin d'un côté très déterministe et qu'un langage parlé, usité par les humains n'a pas se déterminé, c'est-à-dire qu'un mot en fonction des gens n'aura pas forcément le même sens, en fonction du contexte dans lequel il est il n'aura pas forcément le même sens, là où dans un langage si effectivement tu avais des instructions qui n'ont pas le même sens en fonction, de qui il fait appel c'est un petit peu compliqué et que donc on aura quoi qu'il arrive des langages peut-être des langages qui seront moins compréhensibles par les humains parce que ce sera, une manière de faire et je m'étais intéressé du coup à un moment il y a, J'ai découvert, grâce à une de mes belles filles, j'ai oublié le terme, mais en philosophie, ils utilisent une codification spécifique pour la logique. Qui est en fait très proche de certaines représentations, enfin écritures mathématiques, enfin qu'on retrouve en mathématiques, mais qui est du coup un moyen de décrire la logique et la conséquence des actions, et que ça pourrait du coup potentiellement être une manière demain de se dire, que t'as un langage qui est plus riche qu'un langage informatique tel qu'on pourrait l'avoir aujourd'hui.

Florian — En plus ça me fait penser à un truc par rapport quand on disait effectivement au sens des mots et pour le coup à la beauté de la langue en gros que ce soit le français ou d'autres etc et pour le coup je travaille dans une head tech avec des vrais passionnés de la langue française, les mots ont un sens ou plusieurs significations et, donc du coup il y a l'interprétation là on ne veut pas d'interprétation justement et c'est, je crois que tu as évoqué le mot déterministe tout à l'heure et je suis passé à côté, qui est un des gros sujets autour justement, du problème avec l'IA, c'est que justement quand on lui dit un mot, on veut qu'elle applique ce qu'on lui demande, on veut rendre ça le plus déterministe possible, est-ce qu'on va partir sur un aspect plus scientifique, est-ce qu'on va revenir aussi sur, au niveau du langage qui pourrait être utilisé je pense à des vieux langages comme, le prologue avec très orienté mathématique, avec des prédicats ce genre de choses, il y a peut-être aussi un moment où ça va partir plus, peut-être plus hardcore, entre guillemets plus complexe au final où on va revenir à des choses où on va se rapprocher du coup de l'algorithmie, de la machine, de la statistique, des maths vu qu'en plus concrètement si on se la fait très facile, c'est des maths c'est des maths l'LM, Est-ce qu'il y aura aussi des langages pour créer, la dimension AI et après pour la dimension métier ? Je pense qu'honnêtement, on va avoir plein d'initiatives, ça va partir dans tous les sens, il y a des choses qui vont marcher, qui vont exploser, qui vont reprendre, donc. C'est pas fermé. Ouais. Je sais pas, je suis mitigé, je pense que c'est toujours pareil, ça va dépendre un peu autour, des goûts et des couleurs, de la façon dont on aime travailler, est-ce qu'on aime quand c'est verbeux, est-ce qu'on aime quand ça l'est pas, est-ce qu'on veut en écrire le moins possible, ou est-ce qu'au contraire on veut un truc bien indenté, bien... Moi, j'avoue que, étant donné que je vois de moins en moins le code, qu'on soit clair, je ne suis peut-être pas le mieux placé, étant donné que de toute façon, comme je vous disais au début, mon égo n'est pas dans le code. Pour moi, en gros, je n'estime pas être un artiste du code, etc. Pour moi, c'est juste un outil pour faire du business.

Bruno — Donc bon alors justement c'est parfait transition pour ma question suivante, qui est volontairement un peu un peu polémique c'est un peu le sujet polémique je trouve en ce moment dans notre métier de dev, quand tu nous décris le harnais tu nous explique que le harnais il est là pour, fiabiliser notre capacité à produire du code est ce que donc pour toi l'idée du harnais c'est de faire en sorte qu'on ait plus besoin de relire le code et qu'en fait on puisse demander à cloud code, de générer du code et de le pousser en prod directement parce qu'on sait qu'on n'a pas besoin de le relire.

Florian — Je sais que c'est un sujet clivant. J'ai découvert récemment mes premiers haters suite à un podcast. Moi, j'ai un parti pris qui est le mien, auquel on adhère ou on n'adhère pas, mais clairement, moi, mon objectif et c'est là où, pour le coup, c'est presque plus ma casquette 2M, un CTO, manager qui prend le truc, c'est on va vers l'efficience, le but c'est de faire du business, il faut que ça soit rentable. Donc oui, le harness à vocation, à assurer un niveau de qualité tech et métier, acceptable, c'est là où pragmatique, au bout d'un moment, j'ai vu des devs faire des choses merveilleuses techniquement mais ça servait à rien, on arrivait avec des devs seniors on défonçait tout, on refaisait un fichier en mode ou alors sortir une usine à gaz pour dire un, Excel ou un Google Sheet ça suffisait donc je pense qu'il y a cet aspect. Qu'il faut garder en tête mais oui, moi Moi, à l'heure actuelle, on pousse du code en prod que je ne relis pas parce que je déporte mon attention. Mais attention qu'on soit clair, je n'ai pas fait ça day one. Ça fait 18 mois en gros que je pense le sujet, que j'ai fait des centaines d'allers-retours, que j'ai fait des bêtises plus ou moins graves. J'envoie pas des fusées avec mon application, etc. On bosse pas dans le médical. Donc, en gros, encore une fois, c'est là où le cerveau humain sert. Il faut être pragmatique. Quand ça touche au système de paiement, je suis vigilant. Je regarde encore. Pas surtout. L'intégration, globalement, la partie un peu plus front-end et tout. C'est pas que je m'en fous. Déjà, j'ai moins d'affinité. Comme je disais, je suis plus au bac. Mais parce qu'en gros, c'est pas grave. Il y a un formulaire qui bug ou un truc comme ça. Bam, on va le corriger parce qu'on fait du web, parce qu'on peut déployer très vite. Si c'était du mobile et qu'il y avait plusieurs jours avant d'être accepté sur eStore ça change, si on avait des millions d'utilisateurs ça change donc encore une fois il faut toujours garder avec un oeil, ça dépend du contexte, ce fameux contexte qu'on avait déjà en fait, qu'on générait déjà mais j'ai vu des gens qui disaient mais jamais en gros je ne laisse partir du code en production sans l'avoir relu, en fait c'est un manque à mon sens de confiance dans ce qui a été produit mais donc du coup ça veut dire que on n'a pas confiance globalement dans ce qui est produit, il y a des devs qui ont confiance sur leur code, j'ai vu des devs me dire si tu trouves un bug je te paye l'apéro, en gros ils étaient tellement fiers, bah en fait moi au bout d'un moment c'est presque, ouais je déportais ça dans mon harnais, si mon harnais laisse passer une merde, franchement je te paye l'apéro alors en vrai, il n'y a encore rien de sec il y a encore plein de choses à apprendre ça va tellement vite et ça demande des compétences aussi comme on disait une expertise il faudrait que j'embarque des devs bien plus compétents que moi pour faire un harnais encore plus encore plus solide mais au quotidien nous on envoie, des dizaines de pull requests qui sont produits par des non tech qui comprennent pas forcément. La partie tech de ce qui a été produit qui comprennent très bien. Le métier que j'ai pas relu. Moi dans mes pratiques où là pour le coup quand c'est moi qui code sur du métier on fait appel à moi plutôt sur les features je sais pas justement plutôt sensibles où il y a du gros bag ce genre de choses je... Faire extrêmement attention dans la conception, dans l'équivalent du tableau blanc, le système design, dans les patterns, ce genre de choses. Je vais surveiller l'architecture, je vais regarder l'arborescence de fichiers, je vais. Faire attention à quelques trucs. Mais par contre, à aucun moment maintenant, sauf si c'est vraiment encore un truc où je suis en stress ou parce que c'est un nouveau ou un junior ou un truc comme ça, je ne descends au niveau l'onglet en gros dans GitHub qui permet d'aller voir en fait le diff sur les fichiers je n'y vais plus, je n'y vais plus et je pense que, de toute façon si le harnais est assez bien fait avec beaucoup de règles qui impliquent des délais des coûts enfin plein de choses, en fait n'importe quelle équipe qui fait un logiciel de façon encore une fois tradie, en gros un truc commun du web un truc une application pas de la R&D un truc que l'IA sur lequel elle n'aurait pas été entraînée. Mais à partir du moment où peu importe le langage. Peu importe le langage dans les stacks on va dire classiques c'est là où il y a un gros sujet sur le très gros legacy, je pense qu'en fait les devs devraient accepter à envoyer en prod sans regarder et s'ils le font pas encore c'est juste qu'en fait ils ont pas encore assez travaillé le harnais. Donc si je vais titiller leur ego et là je vais me faire des ennemis c'est qu'ils ont pas encore assez bien travaillé en fait et que pour plein de raisons. Ils ont pas le temps il y a plein de devs qui sont sous l'eau, ils doivent shipper de la feature donc en gros ils sont bloqués on leur a pas donné les moyens financiers et le temps de se pencher dessus, soit ils le font pas parce qu'en fait ils disent que ça va pas marcher donc pour moi c'est un manque de connaissance, soit c'est parce qu'ils ont peur et en fait ils font du la rétention en fait ils bloquent parce qu'ils se sentent menacés c'est pas une bonne raison non plus jusque là j'ai eu aucune discussion où en gros il y avait un argument qui était on va dire, vraiment valable enfin valable à chaque fois c'est le contexte le truc le plus récurrent c'est j'ai pas le temps je suis pris dans ok donc ça c'est factuel le le.

Bruno — Le seul contexte où je suis aligné avec toi, je pense que les gens qui écoutent ce podcast le savent. Je pense que si on doit réduire un peu la chose à son essentiel, c'est que quand tu fais un site web ou un SaaS ou un truc, effectivement comme tu le dis, je n'ai pas, envie de dire simple au sens, pas compliqué, mais simple au sens qu'il y a déjà des millions qui existent, ça a été fait et refait. En fait que tu choisisses quand tu confies une tâche à un développeur ou à une développeuse que machin choisisse tel mode d'implémentation et que machin choisisse tel mode d'implémentation, ça change pas grand chose en fait ton input et ton output correspondent à ce que t'as demandé, l'implème a peu de valeur et je pense que c'est là où tu peux dire je peux laisser moi l'élève faire, parce que c'est comme si je le confiais, à machin ou à machine ça reste pareil en revanche il y a des contextes où le choix d'implémentation a une conséquence qui peut être plus ou moins délétère. En général, de manière assez naturelle, on imagine des contextes notamment embarqués. Effectivement, quand tu as un système qui a un tout petit processeur, qui a très peu de mémoire et compagnie, là, il faut que tu aies un niveau de granularité et de finesse où tu ne vas pas laisser ton LLM faire tout seul. Tu as besoin de relire, de t'assurer, d'avoir toute une chaîne qui soit propre.

Florian — Et derrière, si c'est embarqué, que c'est produit, que c'est dans des voitures, qu'il y a de la sécurité. Donc là, je rejoins, et c'est encore une fois, c'est pour ça, mais pour moi, ce n'est pas la masse globale des développeurs bossent sur des problématiques. Alors, je veux dire triviale, qu'on soit clair, techniquement, l'enjeu est dans le métier. Mais quand on fait un SaaS, B2B, B2C, une marketplace, une app mobile, globalement, en général, il n'y a pas de sujet. Effectivement, le dev qui va bosser sur un système de computer vision ou sur des machines pour faire des opérations ou des trucs comme ça, là, c'est différent, effectivement. Et c'est un monde en plus que je ne maîtrise pas donc sur lequel je ne m'avancerai pas mais encore que je pense que si le harnais ne remplace pas totalement, il va, à minima être un très bon assistant. Je pense qu'on en est quand même là, je ne vois pas un endroit où à minima l'IA peut être un très très bon assistant pour le pilote.

Bruno — Et après la méthodologie ou l'approche que tu décris paraît aussi relativement sainte et que tu l'as bien dit, ça fait 18 mois que tu bosses là-dessus, que tu n'as pas fait du jour au lendemain, allez go, on ne relit plus aucun code, c'est juste que tu choisis des périmètres qui sont suffisamment safe, qui ne sont pas critiques, et on laisse petit à petit de l'autonomie. Là, de ce que tu semblais dire, même si ça fait 18 mois, il y a encore des contextes où tu vas acheter un œil pour t'assurer de machin et compagnie. Donc, ça reste quand même une... En fait, c'est comme si tu avais coaché une jeune IA qui arrive ne sachant rien, et petit à petit, tu lui apprends, et petit à petit, tu lui laisses de l'autonomie, parce qu'en fait, elle a acquis ta confiance.

Florian — Oui, clairement, et j'ai déjà entendu, je ne sais plus qui a dit ça, que le harness était le reflet de l'expertise de son maître, de celui. Ça, je veux bien le croire et je suis sûr que un développeur extrêmement bon en TypeScript ou en, enfin, peu importe la techno ou un truc comme ça, viendrait sur ma stack, il améliorerait évidemment mon harnais. C'est évident parce que du coup, c'est un sachant qui a déjà fait, qui trouverait. Donc, en gros, étant donné, comme je disais, je ne suis pas un expert, ça veut dire que mon harnais plafonne mon niveau d'expertise ou alors après, il y a aussi un autre point qu'il faut prendre en compte, c'est toute la donnée qui est disponible, qu'on peut, enfin, qu'on peut récupérer mais il y a des périodes où en fait on voit dans les commits etc, j'ai des pics où c'était 100% de ma bande passante, 100% de mes commits étaient de la config, du test and learn et c'est là où après ça recoupe avec beaucoup d'autres choses, la data qui devient maintenant très importante on peut traiter en plus des beaucoup plus gros volumes, ça consomme du token sauf si après on part sur des trucs un peu plus on va dire, traditionnels du classifier, il y a Jev qui a fait beaucoup de bruit en ce moment. Moi, j'essaye de tout tracer. Donc, on est dans la partie... Comme ce que j'ai fait avec mes devs à l'époque, des logs, de l'observabilité. De la reproduction de scénarios, des playbooks pour arriver à voir un endroit si on arrive à reproduire un échec. Pour moi, il y a une vraie expertise, métier, technique dans le harnais où il faut y aller, pratiquer, rejouer. En fait ça prend vraiment du temps quand même à le faire correctement, je pense à un exemple tout bête là on a un débat très concret avec Medev en ce moment, c'est est-ce qu'il vaut mieux donc on a le même harnais qui marche déjà assez bien est-ce qu'il, vaut mieux avoir plusieurs licences codex par exemple parce qu'en fait on tape que sur du très bon très gros modèle par exemple Astra X-Rai, je dis n'importe quoi, versus être plus raisonnable et aiguillé sur le bon niveau de modèles et là c'était par rapport à l'efficience temps-coût. En fait, on utilise un très gros modèle avec un gros niveau de thinking, c'est plus lent sur la machine factuellement. Ça a plus de probabilité de one-shot, un truc qu'à ligne, qui va partir, du coup. Dans la CI. Versus si on fait un plus petit modèle, un plus petit niveau de thinking, on va faire plus d'allers-retours. Donc, on va avoir plus de besoin d'attention, être plus souvent interrompu. Par contre, ça va plus vite. Par contre, du coup, après, quand ça part en CI, cette fameuse CI, si, il y a des allers-retours. Parce que les bots de review vont remonter des bugs parce que les trucs classiques du sonar cube les linter vont remonter des erreurs et bon tout ça pour arriver à le mesurer j'ai fait avec des outils comme Git.ai et ce genre de choses, on injecte un maximum de contexte pour savoir s'il y a un commit s'il y a un truc, en gros je veux arriver à dire si tel commit, à tel moment qui avait introduit une erreur, quel modèle, il a utilisé quel niveau de thinking dans quelle session, quel contexte il avait, quel skill, quel agent, pour vraiment en fait arriver justement à avoir une chaîne de traçabilité, pour arriver à un moment à reproduire potentiellement ce système et factuellement après, c'est là où on est presque dans un data science, arriver à dire, bah non, on a fait un benchmark, on a refait dix fois le truc, bah on arrive, on garantit qu'il vaut mieux faire tel truc pour, la vitesse opérationnelle, quand on prend le temps de cerveau humain plus la vitesse après les temps d'attente de CI et les coûts, donc ouais non j'incite vraiment sur ce truc du il faut vraiment savoir quoi suivre et avoir un maximum de données justement pour arriver en fait à faire le feedback loop ou le loop engineering ok.

Bruno — Est-ce que ça veut dire qu'aujourd'hui, quand tu détectes, on va dire, un bug en prod ou qu'il y a un souci en prod, est-ce que ça veut dire que tu vas avant tout essayer de corriger ton usine logicielle, tes différents harnais, et après de demander à ton système de corriger le bug en prod, de manière à ce que ce bug ne repasse plus ? Ou est-ce que tu commences d'abord par corriger le problème avant de corriger ce qui a causé le problème ?

Florian — Je vois la question. Globalement, déjà, il faut faire les deux. De toute évidence, il ne faut pas s'en tenir à juste corriger le bug en lui-même, et pas le harnais, parce que sinon, il y a des chances qu'il se reproduise. Après, c'est là où, encore une fois, ça dépend. Quand c'est en staging en gros en environnement où c'est pas grave, harnais je commence par le harnais, je lui dis en gros ça a merdé à tel endroit pourquoi, comment, quel skill on doit modifier, est-ce qu'on rajoute un hook un process même de débugage et j'ai des skills qui permettent de faire ça d'aller remonter à arriver à comprendre très souvent, contexte de toute façon il n'y a pas, ah bah le contexte, était blot était trop rempli, il y avait trop d'informations donc il a manqué un truc et c'est le fameux là où il dit ah oui tu as raison les champignons n'étaient pas comestibles donc ça faut faire gaffe après en prod. Déjà c'est fou à dire mais on a pas, Tant que ça, des incidents, malgré le fait qu'on y va quand même, pour ainsi dire, en YOLO mode, on a assez peu de trucs critiques qui passent parce qu'on a tellement de checks dans tous les sens qu'en gros, ça pète avant, globalement. Si c'était le cas, c'est arrivé quand même. Non, là, je corrige. Et encore, si c'est vraiment ultra bidon, je sais exactement où c'est, je corrige moi-même. C'est là où, à la limite, je vais faire du code. Enfin, je vais coder. Sinon, je fais la correction. Mais pareil je fais tout tracer donc j'ai pareil j'ai des mécanismes qui font que globalement dès qu'il y a eu un bug dès qu'il fait une correction il va loguer ça et après je vais avoir une sorte de un peu c'est pas un garbage collector mais un truc qui va venir en fait récupérer retraité. Retraité en masse après je dirais que par contre je ne si vraiment je poussais le truc à l'extrême que j'avais le temps c'est en fait c'est donc c'est on corrige le harnais on lui fait limite rejouer l'intégralité, de l'implémentation et pas juste la correction, parce que si on lui dit ça marche pas et qu'il corrige, ok, mais on lui dit ça marche pas il y a une erreur comme, je sais pas, je pense à mes enfants qui apprennent, à écrire en ce moment, il y a une faute d'orthographe oui, mais si on lui dit factuellement il y a une faute d'orthographe dans ce mot là, il va plus la trouver que si je lui fais réécrire toute la phrase pour voir, donc si on voulait vraiment bien faire les choses et c'est là où il faut avoir, des sortes de tests unitaires de harnais en quelque sorte où on lui fait rejouer un scénario on lui fait refaire un mini projet, pour voir si les niveaux de qualité augmentent. Et là où pour le niveau de qualité, en plus, ce n'est pas ce qu'on fait dire, ce qu'on veut aux chiffres. C'est là où après, il faut se baser sur des outils assez classiques, SonarCube, Code Climate, ce genre de choses, où en gros, juste on va mesurer avec des métriques, on va dire statiques pour le coup, et des terministes plus traditionnels.

Bruno — Ok, canon. Pour terminer, parce qu'il y a un... Il y a des propos que j'entends de plus en plus et qui tendent, j'avoue, de plus en plus à m'énerver un peu. C'est sur l'évolution des LLM et l'augmentation de leur capacité. Là, de ce que tu nous as expliqué, le harnais est surtout là pour cadrer ton LLM, t'assurer qu'ils partent complètement dans les choux. Mais tu nous as dit aussi que quand tu fais appel à un Astra 6 ou à un Opus 5.5, tu as plus de chances qu'ils te one-shotent le truc que des modèles plus petits. Est-ce que ça veut dire que là on est dans une phase où on ajoute de plus en plus d'outils sur nos harnais mais qu'il y a un moment on va en fait, retirer de plus en plus d'outils parce qu'en fait nos LLM seront capables de faire sans qu'on ait besoin de les maîtriser.

Florian — Oui et non, en fait je dirais que alors oui, je crois je pense que les modèles vont arriver à un niveau tel de performance d'efficience que, dans les grandes lignes il y a des choses effectivement où on va dégraisser un moment les harnais où on avait remis des verrous dans tous les sens de là à ce que le harnais complet disparaisse je pense pas parce que comme je disais peut-être sur des trucs techniques mais il y aura toujours des trucs métiers que là en gros bah enfin au bout d'un moment surtout quand on innove on est une boîte tech qui fait un nouveau truc un produit par définition il le connait pas ce produit donc il y aura toujours ce côté là après il y a un enjeu aussi, c'est là où enfin plus grave mais économique écologique, parce que en gros ces fameux gros modèles ça consomme du token donc ça consomme. Du mégawatt, du gigawatt donc de l'énergie, donc ça a un impact sur l'environnement ça a un impact financier de toute évidence on le voit en plus la tendance est plutôt où, Les modèles sont plus efficients, donc consomment à priori moins de tokens, mais du coup, ils réduisent les abonnements. Typiquement, là, il y a OpenAI qui a dit, votre licence 20X, en gros, ne va plus faire que la moitié. Mais en fait, comme le modèle est carrément bon, en gros, ils essayent de faire passer la pilule en disant, en fait, c'est pareil. Mais donc, factuellement, augmentation des coûts. Donc, je pense que ça va être un jeu d'équilibriste de justement, je pense que le vrai talent, si je puis dire, le vrai talent, et c'est là la vraie plus-value des très bons Técosses, va être d'en faire bien, très bien, avec le plus petit modèle possible, et c'est là où effectivement je pense qu'on va voir la différence entre. La production de masse, où il faut y aller où là si on veut pas s'embêter, ouais on pourra partir avec des très gros modèles, on est prêt à payer, c'est un calcul de toute façon c'est, une approche qui sera pragmatique, et par contre les vrais, les durs entre guillemets, eux ils vont réussir à faire tourner justement un haut niveau de qualité avec un modèle qui va être plus petit, qui va coûter moins cher, qui va être potentiellement open source, qui va consommer moins d'énergie et ça aura aussi un impact vertueux encore une fois il y a des gros sujets autour des, data centers, le campus IA ce genre de choses, on voit bien que au bout d'un moment, si c'est pas la puissance de calcul qui met la limite, ça va être la nature. Donc ça peut pas scaler indéfiniment et je pense que c'est là où, Je tends la perche aussi à ceux qui ont un égo dans le code, déportez votre égo dans ces trucs-là, de péter, le truc qui fait qu'on va réussir à faire avec un Luna ou des modèles équivalents, peut-être plus petits, plus experts sur un métier. Parce qu'à l'heure actuelle, il faut imaginer, opus astra, en fait, ça c'est tout. Il faut imaginer, ça a la connaissance du monde, ça c'est tout. Et moi, en fait, quand je suis en train de développer un truc en tailwind, c'est vraiment important qu'il ait des connaissances en médecine, en cancérologie, ce genre de choses. Ben non, donc en fait, au bout d'un moment, ça sera peut-être justement d'arriver à redispatcher et utiliser vraiment une spécialisation, un expert, en fait, avec un plus petit truc. Là, ça me dépasse. Là, c'est un métier à part. Là, on est dans les machine learning engineers dans des gens qui sont bien plus compétents que moi que peut-être dans le meilleur des cas j'encadrerai et j'épaulerai mais c'est certainement pas moi qui vais craquer ça.

Bruno — Ça rejoint en fait l'architecture choisie par Mistral le large cadre qu'ils ont annoncé cette semaine, encore une fois je vous rappelle qu'on enregistre, on est début octobre, il a justement cette mécanique là d'experts ils ont je crois je sais plus combien d'experts qui sont dans leur LLM. Du coup, l'avantage, c'est que quand tu fais de l'inférence, tu ne passes pas à travers tous les nœuds du modèle, donc ça te coûte aussi moins cher en token. Et j'ai découvert, ce qui est assez intéressant, c'est que les experts ne sont pas répartis par domaine de compétences. Tu n'as pas un expert d'astronomie, tu n'as pas un expert du code, il n'y a pas un expert de la médecine. Parce qu'en fait, c'est au moment de l'entraînement où le modèle choisit comment est-ce que les expertises sont réparties. Et tu as plus des expertises qui sont autour de la manière d'écrire. Et donc, tu vois, le fait, d'indenter ou pas, de faire des gros paragraphes ou pas, ce genre de choses, on va plus les retrouver sur ces niveaux d'expertise. Donc tu peux avoir de la médecine autant que du code autant que de l'astronomie dans un même expert parce qu'en fait c'est plus une manière d'écrire qu'autre chose c'est.

Florian — Là où je m'avancerai pas et encore une fois c'est moi je suis déjà plus dans la, consommation de toute façon de tout ça et c'est là où encore, on parlait de métier software engineer, il y a quand même là du coup aussi une partie qui va partir vers ça où il y a des compétences quand même assez poussées, assez avancées. Mais pour moi ouais il y a des gros travails, j'aime bien ce que l'approche de Mistral au bout d'un moment de toute façon il faut être différenciant là en gros il y a une course par les deux mastodons, par OpenAI et Anthropic, on voit bien avec des niveaux aussi il y a un rapport, qui est sorti sur la partie financière où en gros concrètement on parle d'endettement en centaines de milliards en milliers de milliards, enfin, c'est démentiel on peut pas rivaliser, à date avec ça en France en Europe donc il faut trouver des approches différentes et intelligentes et pour moi le vrai talent du coup il se retrouve plus, là dedans avec le fait d'arriver à faire des choses, efficace avec encore une fois on pourrait faire par rapport à l'automobile, il peut y avoir l'ultra luxe etc mais au bout d'un moment monsieur tout le monde dans sa vie de tous les jours il a pas besoin forcément de l'ultra luxe sauf s'il a envie de se faire plaisir, qui peut se faire plaisir mais c'est d'arriver à un truc, assez terre à terre donc ouais moi j'ai hâte de suivre et j'avoue que, j'espère dans les semaines, mois, à venir échanger justement avec des gens très compétents sur ces sujets donc je tends la perche si dans les auditeurs il y en a, moi je rêverais de prendre un cours, je viens en stage entre guillemets, où je partage d'autres connaissances, mais c'est un monde sur lequel, où là je me sens pas assez taillé et légitime, donc j'adorerais prendre une masterclass en fait sur ça.

Bruno — Ok, écoute l'invitation est lancée, si quelqu'un veut se porter volontaire il saura où te contacter merci beaucoup Florian pour cette conversation avec plaisir. J'aurais deux dernières questions pour toi qui sont les questions rituelles du podcast la première c'est est-ce qu'il y a un contenu ou plusieurs que tu souhaiterais partager avec l'ensemble des auditeuristes.

Florian — C'est là où on a le droit de faire un peu de pub pour soi-même.

Bruno — Et aussi autre chose.

Florian — Honnêtement je vais faire de la pub pour un contenu c'est sur mon guide qui est historiquement CloudCode donc sur cc.brugnot.com, qui est en train de partir sur un truc plus large que juste CloudCode qui est juste en fait un prisme de lecture j'encourage à aller là-dessus parce que je m'embête à le faire donc ça fait toujours plaisir d'avoir des retours et donc d'aller voir potentiellement sur mon profil GitHub, de contribuer. En fait, j'ai plein d'idées, pas forcément le temps de tout faire. Là, je t'envoie la perche aussi, surtout à des profils juniors qui sont un peu en galère pour rentrer sur le marché du travail qui a changé. Donc, en gros, c'est n'hésitez pas si vous n'avez pas les idées. Moi, j'en ai plein. En gros, on peut collaborer. Et après, un autre contenu pour lequel je vais faire un big up, c'est RTK, qui est aussi un projet qui m'a permis a priori, d'être ici en train de discuter avec toi. Donc, sur le projet, il y a plein de belles choses qui arrivent. Il y a une équipe très très compétente qui a sorti une version pro donc aussi à les regarder parce que ça répond à d'autres problématiques que le RTK open source et sur la partie open source il y a Adrien, qui est un jeune très talentueux qui, m'a dit qu'il avait une idée qui pour moi va plier le game en fait sur la version 1.0 sur ce qui arrive donc suivez de près parce qu'il y a peut-être les Frenchies qui vont revenir là dans le jeu un peu plus fort encore canon.

Bruno — Et enfin, pour terminer, la question la plus importante de ce podcast. Florian, est-ce que tu es plutôt espace ou tabulation ?

Florian — Espace.

Bruno — Très bien. Merci beaucoup, Florian.

Florian — Avec plaisir, merci.

Bruno — Et merci à tous d'avoir suivi cet épisode. Voilà, ça fait partie de nos nouveaux métiers, ce Harness Engineering. Je pense qu'effectivement, l'approche qu'on avait vue avec Théodot il y a quelques semaines, où chaque développeur et développeuse devrait créer son propre harnais, je pense que c'est un bon moyen de comprendre aussi tout ce que fait Claude. Et je pense que pour toutes les personnes qui disent que le problème du LLM c'est qu'il n'est pas déterministe justement profitez-en, ajoutez lui une palanquée d'outils déterministes Florian nous a donné plein d'idées sur comment faire ça bien. Donc faites-le, faites-vous plaisir le métier change et donc tout est possible 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.