Bruno:
Il paraît que depuis que l'homme tape du code, il cherche à en taper le moins souvent possible. On a tout essayé, le copier-coller depuis Stack Overflow, les snippets de code qu'on récupère à droite à gauche, des IDE turbo-vitaminés à l'autocomplition, et depuis peu, Copilot et compagnie. Et donc voilà, c'est il y a générative qui débarque sur le poste du dev. Mais quand on parle que 99% du code pourrait être bientôt sorti tout droit d'un LLM, ça secoue un peu comme si on avait soudainement troqué notre bonne vieille bicyclette contre un vélo électrique ça va plus vite mais faut encore pédaler quand même mais alors est-ce que l'IA transforme réellement notre métier et pas juste notre vitesse de tabulation qu'est-ce qui change entre jongler avec cursor, cloud code et compagnie et de déléguer vraiment à la fin du dev, et de déléguer vraiment du dev ou plutôt, de déléguer vraiment le travail du dev qui lit finalement sa doc à la main et surtout la nuit, est-ce que la nuit pendant qu'on dort disons j'ai mal écrit mon truc, et surtout la nuit pendant qu'on dort, est-ce que notre code va se refacto tout seul ? Pour répondre à ces questions de science-fiction, je ne reçois pas Al9000 mais il s'y connaît, en IA qui prennent le contrôle, Jocelyn, bonjour.
Jocelyn:
Bonjour Bruno, heureux d'être ici.
Bruno:
Alors Jocelyn, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Jocelyn:
Je pense qu'il y a beaucoup de personnes qui ne me connaissent pas, donc Je suis Jocelyn Intagpé, je suis père de deux enfants. Je bosse dans l'informatique depuis un peu plus de 15 ans. Et aujourd'hui, je suis Head of Engineering et Head of Architecture chez Mano Mano, après avoir fait ma carrière souvent dans le milieu financier et dans une grande ESN bien connue qui s'appelle Soprasteria.
Bruno:
Donc aujourd'hui, Mano Mano, tu peux nous décrire un peu la taille des équipes, l'environnement technologique dans lequel vous évoluez ?
Jocelyn:
Oui, bien sûr. Mano Mano, c'est une célèbre licorne française. On est un site d'e-commerce qui vend tout ce qui est home improvement. On est très connu pour nos pubs un peu décalés sur tout ce qui est bricolage. On est à peu près 600 employés et sur la partie tech, 200-250 personnes. Avec une organisation assez classique, des équipes produits, des équipes d'ingénieurs, des équipes plateformes, des équipes data. Et une organisation en train, donc on a trois ou quatre trains si on compte la plateforme. Et ensuite dans chaque train des feature team avec un PM, un engineering manager et 5-6 développeurs.
Bruno:
Donc là effectivement de manière très classique. La question qui nous intéresse effectivement aujourd'hui c'est comment est-ce que l'écriture du code se passe pour ces 250 personnes aujourd'hui chez Mano Mano ?
Jocelyn:
Elle est en train d'évoluer, comme dans beaucoup de boîtes. Donc, pour poser un peu le contexte, chez Manomano, on est dans une archi assez distribuée. Chaque équipe gère plusieurs dizaines de microservices. Donc, on a un peu plus de 400 microservices chez Manomano qui sont majoritairement écrits en Java. on va avoir un peu de go. Le front, c'est du classique TypeScript, React, Next.js. Et ensuite, les équipes data, elles bossent plus en Python. Et donc, en 2023, on a commencé à intégrer un outil que la plupart des devs, j'espère, connaissent, qui s'appelle GitHub Copilot. Donc on était quand même sur quelque chose qui apportait pas mal de valeur, à la fin de l'utilisation de Copilot on estimait qu'il écrivait entre 20 et 30% du code qu'on avait dans notre base de code donc c'est quand même un outil qu'on pouvait utiliser de manière assez significative mais bon ça reste un outil qui ne changeait pas fondamentalement le métier de développeur c'était comme si on avait une autocomplétion survitaminée Ça permettait également aux développeurs d'être plus focus parce qu'on ne quittait pas l'IDE pour aller se balader sur Google ou sur Stack Overflow. On pouvait poser les questions directement dans le chat sur l'IDE. Donc ça a quand même apporté pas mal d'avancées pour les développeurs, mais on ne pouvait pas parler de révolution. L'année dernière, on a vu de nouveaux outils arriver tels que Cursor et Winsurf. Donc déjà, on pouvait déléguer beaucoup plus à ces forks de VS Code qui étaient des IDE qu'on peut qualifier d'agentiques. Donc tout ça, ça a un peu plus changé le métier des développeurs. Donc nous ce que ça si je me place avec ma casquette de manager ce que ça a changé c'est qu'on s'est mis à gérer plein d'outils, donc on avait du monde qui était encore sur Copilot, des développeurs qui préféraient utiliser Cursor, des développeurs qui ne voulaient pas quitter le monde de JetBrains, donc qui utilisaient, JetBrains AI et on a commencé à avoir une nouvelle forme de demande qui était j'ai plus de crédit, il faut me redonner des crédits des missions, le manager qui gère les crédits donc on a commencé à avoir de plus en plus de développeurs qui étaient drogués au crédit IA, je tiens quand même à préciser que chez Mano Mano on a, essentiellement des seniors, il y a très peu de juniors on va dire que les développeurs qui ont moins de 5 ans d'expérience c'est extrêmement rare l'immense majorité des développeurs sont des développeurs seniors donc c'est pas des développeurs qui regardent ce que fait l'IA sans un regard critique c'est des développeurs qui maîtrisent bien leur base de code et qui comprennent à tout moment ce que fait l'IA, mais même ces développeurs seniors-là les utilisaient, massivement et arrivaient. Rapidement à ne plus avoir de crédit et donc là, sur 2026 on essaie d'accélérer encore plus, c'est-à-dire d'avoir des développeurs qui peuvent se concentrer sur les tâches à plus haute valeur ajoutée. Je disais qu'on a beaucoup de microservices, ça veut dire qu'on passe beaucoup de temps à définir des appels d'API, on passe beaucoup de temps à coder un client HTTP, un DTO pour se connecter à tel API on va passer du temps sur des tâches comme j'en sais rien rajouter des traductions dans une langue, changer un message sur un écran donc c'est des tâches qui n'ont pas énormément de valeur ajoutée donc là on essaie d'aller de plus en plus loin avec l'IA pour automatiser ces tâches là et l'année dernière on a vu un nouvel outil apparaître qui est Cloud Code donc aujourd'hui je vais parler beaucoup de Cloud Code parce que c'est ce qu'on utilise chez ManoMano, Mais il y a d'autres outils comme Gemini 3 Pro qui est également excellent. Mais oui, Cloud Code a un peu changé la manière dont on envisage le métier de développeur. Parce que Cloud Code, le développeur, il n'est plus forcément au co-monde. Le développeur peut être vu comme un orchestrateur qui a plusieurs terminaux ouverts avec des agents qui font des tâches pour lui. Une analogie que j'aime bien c'est de dire qu'avant avec Cursor ou avec Copilot c'était un peu quand je prends ma voiture et j'ai, le régulateur de vitesse adaptatif et CloudCode c'est un peu le taxi autonome je lui dis à l'endroit où je veux aller et il m'y amène.
Bruno:
Alors t'as déjà évoqué énormément de sujets t'as annoncé plein de plus donc il y a plein de sujets que j'ai envie de creuser, je me permets juste avant de commencer parce que tu précises effectivement qu'aujourd'hui tu vas parler surtout de cloud code donc j'en profite pour dire qu'on enregistre cet épisode le 20 janvier, je sais pas quand est-ce qu'il sera diffusé mais je sais encore moins quand est-ce que les gens vont l'écouter il se peut que des choses aient bougé dans l'actualité des LLM et des outils de production de code entre le moment d'enregistrer et le moment où vous écoutez ce podcast donc on va beaucoup parler de cloud code mais peut-être que d'ici quelques semaines peut-être qu'on a un nouvel acteur qui va popper et qui va encore plus faire bouger les lignes que cloud code, donc je vais revenir du coup sur justement cette notion d'outillage, aujourd'hui que t'as chez Mano Mano de ce que j'ai compris t'as une organisation avec des équipes qui sont très libres notamment de choisir leur techno parce que du coup c'est ce que je sais plus si tu l'as dit à ce micro là à l'épisode d'avant ou à un autre moment mais vous avez beaucoup de techno sur différents microservices, vous laissez les équipes choisir en fait sur quoi elles bossent est-ce que vous êtes aussi dans un mode de dire tu choisis le LLM que tu utilises, et même si tu en utilises un, ou est-ce qu'il y a des choses que vous essayez de standardiser entre toutes les équipes ?
Jocelyn:
Alors, on essaie de standardiser plein de choses, tout en laissant un maximum d'autonomie aux équipes. L'autonomie chez Mano-Mano, c'est vraiment quelque chose qui est très important pour avoir des équipes performantes. Donc, en termes de langage, on autorise deux langages principaux côté backend, qui est le Go et tout ce qui est autour de la JVM. en fait on autorise Java et Kotlin et. Pour les outils IA on va dire on en autorise trois principaux Cursor, avec JetBrains AI et CloudCode. Donc en fait, globalement, les développeurs vont souvent choisir un outil dans l'IDE qui peut être Cursor, s'ils sont plutôt VS Code, ou JetBrains AI s'ils sont plutôt dans le monde JetBrains. Et ensuite, ils vont avoir CloudCode pour tout ce qui est grosses tâches ou tâches en arrière-plan. Donc c'est la liberté qu'on laisse aux développeurs. Par contre, on a une équipe dédiée qui s'occupe de construire, c'est du jargon très Claude, qui va construire des skills pour Claude. Cette équipe dédiée va également construire plein de rules pour permettre aux agents de comprendre comment on code chez ManoMano j'en sais rien, comment on se connecte à la base de données, comment on crée un cache pour mon microservice comment on va envoyer des messages sur Kafka comment on va encoder ces messages via Avro donc il y a toute une, littérature qui est maintenue et écrite pour permettre aux agents de pas juste être un agent agnostique du contexte Mano-Mano, mais. Pour permettre à ces agents de comprendre comment on coachait Mano-Mano et d'être efficient comme un... D'avoir les connaissances d'un développeur sur le contexte Mano-Mano.
Bruno:
Donc en fait, c'est une... on pourrait presque dire, c'est de la configuration d'un outil pour que les devs soient le plus efficaces possible avec ces outils-là.
Jocelyn:
Tout à fait. En fait, c'est essayer d'avoir une... De prendre le savoir qu'il y a dans la tête des développeurs et d'essayer de le documenter pour que les agents soient capables de coder avec les bonnes pratiques qu'un développeur pourrait avoir et de comprendre quelles sont les spécificités Mano-Mano. Parce que comme dans toutes les boîtes il y a des spécificités Mano Mano il y a quelques outils internes qu'on utilise que chez Mano Mano, il y a des règles de nommage qui va y avoir, que chez Mano Mano et donc on essaie d'avoir cette automatisation là pour que quand on est quand le développeur est sur un nouveau projet il n'est pas à reconfigurer son agent ou à expliquer, dix fois à l'agent comment se connecter à tel fil de messages.
Bruno:
En fait, de la même manière que quand j'imagine une nouvelle personne qui rejoint l'équipe, tu lui apprends les règles de chez ManoMano, tu considères que ton cloud code en fait, c'est un nouveau développeur qu'il faut former et donc vous le formez à vos pratiques.
Jocelyn:
Tout à fait. Et peut-être que maintenant, s'il y avait quelqu'un qui rejoignait les équipes, on lui dirait va lire la documentation qu'on donne à cloud code. Peut-être qu'elle serait mieux menue et comment dire, plus...
Bruno:
Plus à jour.
Jocelyn:
Ouais, plus à jour et j'en perds mon latin mais plus facile à digérer que toute la doc-confluence qu'on a construite pendant des années.
Bruno:
Est-ce que vous imposez l'usage de ces outils-là ? Est-ce que vous traquez la quantité d'usage qui est fait ou du coup tu peux avoir des devs aujourd'hui qui continuent à faire du code à l'ancienne ?
Jocelyn:
J'ai des devs qui continuent à faire du code à l'ancienne. Est-ce que c'est une espèce en voie de disparition ? Je ne sais pas. Bon, j'ai mes convictions. Je pense que l'IA apporte trop de bénéfices pour qu'on puisse, à moyen terme ou à long terme, continuer à ignorer ces bénéfices-là. Mais c'est évident que dans toutes les boîtes et dans toutes les professions, il y a une sorte de résistance au changement j'aimais beaucoup ce que disait Quentin Adam dans l'épisode précédent où il disait que c'était quand même un comble ou l'hôpital qui se fout de la charité parce que pendant des années en tant que développeur on a, automatisé des choses donc on a défoncé en fait plein de boulots où on est arrivé on a dit en fait maintenant il y avait 10 personnes pour faire ça maintenant une personne ça suffit et quand les gens n'étaient pas contents Il expliquait qu'on disait « alors les mecs, la conduite du changement, c'est la marge du progrès, il faut changer ». Et aujourd'hui, on voit les mêmes réticences dans le monde des devs, où on se dit « mais non, j'ai quelque chose de particulier. Jamais une machine pourra remplacer mon art ou ma manière d'écrire ». Peut-être que jamais une machine pourra remplacer ta patte, ta manière de penser, d'écrire du code. Mais est-ce qu'une machine peut écrire du code qui marche bien en prod, qui est efficient et qui est moins cher à écrire ? J'ai quand même l'impression que c'est vrai. Je ne pense pas que les IA vont remplacer tous les devs, mais je pense qu'il y a des gains de productivité qui sont absolument incontestables aujourd'hui grâce à l'IA. Et qu'il va falloir s'y mettre un jour ou l'autre, mais on n'a pas ce besoin de forcer les gens. Honnêtement, je pense que quand on voit les gains qu'on arrive à faire, les développeurs vont y passer petit à petit. À un moment, de toute manière, ça ne sera plus possible de refuser ce changement.
Bruno:
Donc, vous avez outillé vos équipes depuis 2023, de ce que tu disais. Ça a été quoi la courbe d'adoption de ces outils là est-ce que c'est à chaque nouvel outil il y a un peu plus de monde qui arrive ou est-ce qu'il y a d'autres choses qui drive ça c'est quoi la quantité de gens qui l'utilisent aujourd'hui comment tu perçois ça.
Jocelyn:
À Copilot, ça a été très rapide parce que c'est super bien intégré dans les IDE. On a donné des licences, les gens installaient le plugin, ils avaient Copilot, mais ils l'utilisaient au début essentiellement pour de l'autocomplétion. Donc globalement, ils appuyaient sur Tab et à la place d'avoir juste le premier nom de méthode par ordre alphabétique qui s'affiche, Copilot comprenait un peu mieux le contexte et essayer d'auto-compléter la ligne ou la fonction de manière un peu plus efficace. Ensuite, ça a été assez brutal l'adoption, parce qu'un mois il n'y avait personne qui avait copilot, on a lancé un groupe pilote, on a vu que les retours des devs étaient super positifs, que les devs estimaient que ça leur faisait gagner du temps, que ça rendait leur boulot plus agréable, parce qu'ils restaient concentrés dans leur IDE, Ils n'avaient pas besoin d'aller se balader sur internet, chercher la doc avec tous les risques qui sont d'être déconcentrés par je ne sais quelle distraction en faisant ça. Donc ça, on va dire, améliorer l'hygiène de travail des développeurs, donc c'était vraiment un no-brainer pour nous d'adopter cette techno. On a vu des développeurs utiliser de plus en plus le chat parce que quand on a adopté Copilot, il n'y avait pas encore le chat dans l'IDE, donc être capable de parler à son IDE un peu comme on peut parler à ChatGPT. Donc quand ces fonctionnalités-là sont arrivées sur VS Code puis sur JetBrains, on a vu les développeurs utiliser ça de plus en plus. Mais cette partie-là a été, on va dire, un peu plus, graduel on a eu une adoption plus linéaire alors que le tab et l'autocomplétion de la ligne ou de la fonction ça a été absolument immédiat ça.
Bruno:
Et le cloud, tu estimes aujourd'hui que quasiment toute ton équipe l'utilise ? 50% l'utilisent ?
Jocelyn:
Ah non, c'est toute l'équipe. Copilot, c'était toute l'équipe. Aujourd'hui, on utilise beaucoup moins Copilot, mais Copilot, c'était absolument toute l'équipe. Et aujourd'hui, JetBrains AI, pour les gens qui ont JetBrains, c'est intégré à l'IDE. Donc, ils l'utilisent forcément. après c'est à quel point ils l'utilisent il y en a ils vont utiliser que l'autocomplétion, il y en a d'autres ils vont utiliser beaucoup le chat, il y en a d'autres ils vont utiliser l'agent que ça soit l'agent Claude ou l'agent, Juni qu'il y a dans JetBrains et oui une bonne partie du boulot c'est de. De remettre des crédits des choses comme ça parce qu'on a quand même une grosse consommation de crédits pareil sur, Cursor, c'est à peu près la même utilisation que celle de JetBrains et aujourd'hui on est en phase de scale-up progressif sur CloudCode parce qu'en fait pour automatiser des agents il faut arriver à leur donner toute cette connaissance, chose qu'on avait moins besoin de faire avec du Cursor ou du JetBrains AI, avec Cloud on veut aller vers des agents qui sont le plus autonome possible ou qui font des tâches de plus en plus de plus en plus compliquées et pour faire ces tâches là mais il faut leur, pas mal de choses et leur donner beaucoup de contexte donc c'est avoir des clouds .md ou agents .md qui sont vraiment bien faits avoir. Des répertoires dans lesquels cloud il est capable de trouver toute la documentation dont il a besoin, donc ça c'est des choses qu'on doit installer sur les postes quand le développeur il met à jour ses logiciels, on veut qu'il y ait toute cette documentation cloud qui soit mise à jour en même temps pour que Cloud puisse évoluer avec l'évolution de nos pratiques de dev ou l'évolution de nos ADR, tout ça donc là il y a plus d'outillage et pour l'adoption de Cloud Code de manière efficace les gens qui demandent des licences Cloud Code on leur donne des licences Cloud Code mais on essaie vraiment de prendre quelques équipes, donc on a 5 équipes on va dire témoins, sur lesquelles on essaie d'avoir un maximum de feedback sur l'industrie réalisation de bosser avec l'IA parce que quand on veut, au moment où on va vouloir avoir du cloud code sur l'ensemble de nos développeurs on veut pas qu'ils aient une expérience qui soit mitigée on veut vraiment qu'ils aient une super expérience dès le premier jour donc on a une phase de ramp-up progressif.
Bruno:
Donc là du coup sur l'intégration de cloud code avec ces agents qui du coup ont beaucoup plus d'autonomie sur la code base qu'avant, là du coup vous n'y allez qu'à de manière un peu précautionneuse, step by step, parce que c'est quand même un peu critique, on va dire, la code base.
Jocelyn:
C'est critique, on doit...
Bruno:
Mais vous voulez y aller, quoi ? Il n'y a pas de débat.
Jocelyn:
On veut y aller, c'est un objectif très clair, d'y aller au maximum dessus, mais on ne veut pas y aller de manière désorganisée. Un, il y a des enjeux légaux. Alors nous, on a fait le choix, alors, on a sur Cloud, on a du pay-as-you-go, donc on a des API qui, et les développeurs, paient à l'utilisation, mais on a aussi pas mal d'équipes qui sont sur des plans enterprise où on paie tous les mois un peu plus, enfin 150 dollars et le développeur peut utiliser le plan et donc il y a beaucoup, en équivalent de crédit API c'est quand même beaucoup plus que 150 dollars c'est aux alentours de 750-800 dollars d'équivalent de crédit API et, il y a des enjeux légaux sur ça donc la boîte qui fait Cloud c'est Anthropix, c'est une boîte américaine sur les plans. Qui ne sont pas des plans IPI Key, il y a une partie des données qui sont processées aux Etats-Unis donc on ne peut pas mettre n'importe quoi dans ces, enfin dans les données qu'on envoie et qui sont processées aux Etats-Unis donc il y a de la formation pour les développeurs, ensuite, typiquement on ne veut pas que Cloud il part des fichiers où il y a des mots de passe, où il y a des keys, des choses comme ça dans le monde des devs c'est souvent les fichiers dot, dot, on veut des fichiers comme ça donc il y a plein de règles de sécurité, ou de guardrails qu'on veut mettre sur les agents donc c'est des choses, qui prennent un peu de temps à construire et aussi on veut arriver en expliquant aux développeurs, regardez comment utiliser Cloud, de manière la plus efficace possible, c'est-à-dire avoir des listes de serveurs MCP qui fonctionnent bien, mettre en place des serveurs MCP si on a besoin sur la boîte. Donc pour être vraiment... Enfin, comment dire ? Pour avoir toutes les promesses de l'outil, il faut quand même un peu d'industrialisation même si je pense que pour plein de boîtes juste cloud code et des gens qui ont la volonté d'apprendre, ça permet de gagner pas mal de temps mais nous on veut vraiment offrir une très bonne expérience à nos équipes donc on fait un peu de travail préliminaire.
Bruno:
Tu parlais de ces services MCP, vous en avez beaucoup qui sont déjà connectés à vos à vos agents ?
Jocelyn:
Ouais, il y en a pas mal. Il y en a pas mal. On a pas mal de demandes de gens qui veulent en rajouter des nouveaux en permanence. C'est dur de balance, d'arriver à équilibrer entre en mettre trop et avoir un LLM qui est perdu, qui sait pas quoi appeler, quand appeler, et mettre les bons. On a beaucoup de Figma MCP, on a beaucoup de MCP, alors nous on est sur la stack Atlassian, donc on a beaucoup de MCP pour se connecter à Jira, pour se connecter. À Confluence on va avoir des MCP pour nous on est sur GitLab, donc pour se connecter à GitLab, aller voir l'Europo, faire certaines actions sur l'Europo GitLab je dois en oublier, deux que je veux mentionner qui sont quand même assez incroyables, le premier c'est Serena donc Serena MCP c'est un outil qui permet d'avoir de, qui permet à l'agent d'être plus efficace d'avoir de faire de la recherche sémantique sur le code il peut aussi utiliser, du LSP donc c'est vraiment quelque chose qui permet à l'agent d'être plus efficace, plus rapide et de consommer moins de tokens et pour nous c'est quelque chose qui marche plutôt pas mal et le second que je trouve magnifique, alors ça Merci. Plus ma casquette manager et qui. Qui touche un peu à tout mais c'est le MCP, Playwright donc ça permet vraiment de dire à l'agent maintenant tu vas aller tester directement sur l'UI en tant que manager ça me permet d'automatiser une panquée d'actions qui c'est assez magique qui va de l'upload de factures, de la réconciliation de factures de l'automatisation de l'acceptation des congés dans certains cas, ça permet vraiment d'automatiser plein de tâches sur le navigateur et c'est incroyable et pour les développeurs web je sais que c'est quelque chose qui est super, maintenant il y en a pas mal qui utilisent le MCP Chrome Dev Tools qui fait à peu près la même chose mais l'un ou l'autre c'est quand même des outils, que je trouve assez incroyables Tu.
Bruno:
T'évoquais justement quand on commençait à parler de MCP, le fait d'essayer de choisir les bons MCP, pas trop en rajouter. Tu nous as aussi vaguement parlé des skills qui sont disponibles dans Cloud. Comment est-ce que tu arrives à conjuguer ces deux éléments sans qu'ils se marchent l'un dans les pattes ?
Jocelyn:
Tout ce qu'on peut faire en skill, on le fait en skill. Ça coûte moins cher, c'est plus rapide. Même, par exemple...
Bruno:
Tu vois, le MCP a l'avantage d'être peut-être plus dynamique. Là où ton skill, tant que tu ne le mets pas à jour, il n'est pas à jour.
Jocelyn:
Tout à fait. Après, le MCP, quand c'est des outils du marché qui maintient le MCP, c'est top. Quand c'est nous qui devons maintenir le MCP, la partie dynamique devient toute relative. Donc des fois c'est plus facile d'uploader, enfin de maintenir un fichier .md et de dire maintenant à la place de faire ça tu le fais comme ça que d'aller sur un serveur, de mettre à jour une API, donc c'est enfin je dirais que le skill est même, plus facile à maintenir parce que c'est du texte on le voit, on le comprend et pour un humain il n'y a pas cette traduction c'est du langage naturel.
Bruno:
Alors oui mais juste parce que, Je pense qu'aujourd'hui, ces éléments sont facilement gérables par nous, êtres humains, parce qu'ils restent encore dans des tailles acceptables. Mais en fait, à mesure que le temps va passer, on va commencer à avoir des trucs qui sont de plus en plus volumineux. Et de la même manière que j'imagine que personne chez ManoMano ne connaît toute la codebase de ManoMano, parce qu'en fait, aucun humain n'est capable d'appréhender des codebases aussi importantes. Je pense qu'à un moment, on va avoir le même sujet sur nos paramétrages de nos LLM ou agents ou quoi que ce soit dans quelques années ou peut-être même mois, donc tu vois peut-être que le MCP te permet ça d'avoir quelque chose qui est, en fait plus appréhendable par l'humain parce qu'en fait il a un côté un peu générique on va dire.
Jocelyn:
Effectivement on a assez peu de recul sur ça et c'est assez dur de dire de quoi l'avenir sera fait, néanmoins c'est un avantage des codebase micro-services c'est que les développeurs ils ont besoin de connaître leurs services qui sont souvent plus petits dans lesquels les entrées et les sorties sont très bien connues, en général les services ils vont utiliser Postgres et Kafka ils ne vont pas utiliser 50 000 choses différentes donc on arrive quand même à avoir à, à bosser sur des ensembles pour lesquels la charge cognitive n'est pas, énorme par contre il y a des endroits où il va falloir du MCP typiquement maintenir toute la doc d'API via skills ou à la main c'est des choses qui ne sont pas possibles donc oui il va falloir du MCP pour avoir, l'auto-discovery. Des autres API qu'un microservice va devoir rappeler, et il va falloir du MCP pour alors j'ai pas mentionné, Context 7 qui est pas mal aussi pour voir la documentation c'est un MCP qui permet justement d'aller voir la documentation de différents de différents outils, et apprendre à la gente comment se connecter sur des outils qui ne connaissent pas qui ne connaissent pas forcément donc oui sur la partie dynamique je pense que le MCP ça fait totalement sens, après des skills c'est vraiment plus rapide et pour démarrer je pense que c'est vraiment super, et il y a même des choses qui typiquement j'en sais rien pour, GitHub on pourrait utiliser le MCP GitHub si on sait que les gens ont le GitHub CLI installé sur leur machine des fois c'est plus simple d'expliquer via skill comment utiliser le GitHub CLI, ça évite d'avoir des appels HTTP dans tous les sens et ça simplifie une partie du process.
Bruno:
Ok. Donc vous faites ça depuis un petit moment maintenant. C'est quoi pour toi les... Je sais pas si tu peux nous partager les erreurs que vous avez faites dans l'usage de tous ces utiles là mais c'est quoi pour toi les best practices que tu vois avec le recul alors.
Jocelyn:
J'en ai déjà évoqué quelques unes la plus évidente c'est avoir un Agence.md qui soit le plus à jour possible et qui vraiment explique à l'agence, comment il doit se comporter, je pense que c'est simple c'est standard et aujourd'hui il y a vraiment zéro raison de ne pas mettre ça en oeuvre si on veut utiliser des agents de manière efficace et j'ai quand même, je ne suis pas allé voir d'études sur le sujet mais je me rends compte que plus on cadre les agents et plus on les fait bosser dans un contexte et un écosystème qui est strict plus ils sont efficaces. Parce qu'il y a moins de manières de faire la même chose et je trouve que les agents donnent des meilleurs résultats donc avoir un agent pour MD c'est absolument essentiel, après essayer de lui donner un maximum de connaissances chez nous, chez Mano Mano on utilise comme dans beaucoup de boîtes des ADR pour tout ce qui est décision, arriver à donner ces décisions-là aux agents. On voudrait, alors ça on ne l'a pas encore, mais être capable d'avoir des agents qui sont capables de comprendre « Ok, je suis dans telle base de code qu'il y ait tel microservice. » L'avantage d'un microservice, les entrées sorties sont très claires et l'agent, je pensais à l'épisode de Quentin sur... Penny Lane, où il disait qu'ils avaient 35 000 fichiers en microservices, on est quand même sur des bases de code qui sont plus petites. Donc l'agent comprend plus facilement quel est le contexte du microservice. Mais des fois, on doit appeler d'autres microservices qui sont à l'extérieur. Mais comment l'agent, il sait, si je veux récupérer les données du client, quel est le microservice que je dois appeler ? Donc arriver à donner cette information-là à l'agent, c'est quelque chose, du moins dans les archis microservices, qu'il va falloir adresser. Aujourd'hui, on ne sait pas encore comment faire. Après, il ne faut pas faire confiance de manière aveugle, surtout en production, aux agents. Donc je sais que c'est très tentant de dire « Ok, j'auto-autorise toutes les commandes. Je conseille plus d'avoir des white list de commandes, autorisées, on sait qu'il peut faire du git commit mais peut-être pas du git push sans que je l'accepte par exemple et plein d'autres commandes qui peuvent être, sensibles, moi ça m'est déjà arrivé, d'être en auto-edit sur un projet perso et d'avoir un agent qui me supprime tous mes favoris Firefox parce que ils voulaient effacer du contexte et donc. Limiter les commandes autorisées, je pense que c'est absolument essentiel dans, on va dire dans les environnements de prod et les environnements critiques et, un point un peu controversé je suis persuadé que les agents sont plus efficaces sur les langages typés enfin c'est pas, je suis persuadé il y a des études sur le sujet il y a une étude qui est de Berkeley qui est sorti qui disait que, les agents étaient donc plus performants sur les langages typés parce que 94% des erreurs des agents c'était des erreurs qui étaient évitables s'il y avait une phase de compilation donc ça veut dire que quand on est dans un langage non typé il y a 94% des erreurs qui vont pas être catchées qui vont être catchées par une phase de test, ou alors directement au runtime Donc plus le langage est typé, mieux ça marche. Je me rends compte aussi que les agents adorent avoir des règles qui sont strictes. Typiquement tout ce qui est archi hexagonal, DDD, on peut se dire que c'est assez verbeux. Quand on écrit du code à la main, ça prend du temps de faire ses ports, ses adapteurs, ses value objects, etc. L'avantage pour un agent c'est que c'est des patterns d'archi qu'il maîtrise parfaitement qui lui donnent du cadre donc je trouve que tout ça c'est. Avoir des structures bien documentées et le plus strict possible c'est ce qui permet de, tirer parti au maximum des agents.
Bruno:
Canon quand je t'écoutais lister ses best practices, Je me suis fait une réflexion. Est-ce qu'au final, toutes ces recommandations que tu fais pour que ton agent soient efficaces, on ne pourrait pas les appliquer aussi à n'importe quel développeur ou développeuse ? Au final, parce que tu vois, un langage typé, c'est plus pratique pour tous les devs. Enfin, tu vois, on va pas se mentir. Le compilateur, il t'aide quand même énormément. Le fait d'avoir du contexte, le fait d'avoir de l'information disponible, le fait d'avoir pas non plus une liberté totale, mais d'avoir des règles précises sur comment est-ce qu'on crée du code, comment on écrit le code, comment on shippe le code, tout ça c'est aussi des choses qui rendent n'importe quel développeur meilleur est-ce que tu penses qu'il faut simplement peut-être juste considérer ces outils comme n'importe quel développeur et développeuse avec juste la différence et que ils tapent environ un million de fois plus vite que n'importe qui.
Jocelyn:
Oui et non difficile de, répondre, enfin je vois tellement de manières différentes de répondre à cette question, je pense cela dit qu'on pourra tous être d'accord pour dire que les développeurs ne sont pas connus pour être des personnes extrêmement dociles ils ont souvent des opinions assez arrêtées sur pas mal de sujets ce qui n'est pas forcément le cas des agents si je lui dis de coder de telle manière je ne vais pas rentrer dans un débat avec lui pour savoir si un langage typé ou pas typé c'est plus efficace il va accepter ce que je lui dis assez rapidement. Ensuite pour un développeur l'écriture du code c'est quand même une partie significative de son temps pour un agent cette partie là disparaît totalement pendant des années j'ai des collègues qui m'ont dit il faut que t'arrêtes de faire des langages typés, je dois avouer intellectuellement que j'ai toujours été très pro langage typé même si j'ai été pendant longtemps formateur javascript, j'ai trop souffert d'erreurs en production à cause des langages non typé, je me suis dit que c'était cool d'arrêter de faire des tests sur du typage et d'avoir, comme tu dis, un compilateur qui catch toutes ces erreurs mais il y a plein de gens qui sont persuadés que c'est incroyable de faire du, Python, qu'on s'embête pas si je parle correctement à faire des classes pour expliquer que le type de retour ça va être ça ou ça et l'avantage principal de faire du Python c'est qu'on écrit du code plus vite, il ne faut pas se mentir écrire du code. À un instant en Python ou dans un langage dans lequel il va falloir plus structurer les choses, ça va aller plus dur plus rapidement en Python par contre, en fait cet avantage disparaît totalement avec les LLM parce que le LLM, lui, il va aussi vite, comme tu le dis à écrire du Python ou du Rust, c'est juste que quand il va se planter en Rust, il va avoir un compilateur qui va lui dire instantanément, c'est pas nous qui allons devoir créer des tests derrière ou dire au LLM il faut que tu testes ça parce que vu que j'ai un typage faible, il y a tout un ensemble de garanties que je ne vais pas avoir le compilateur lui dit très bien et donc pour répondre à ta question, Oui, il y a tout un ensemble de ventes pratiques qui étaient applicables aux humains, qui peuvent s'appliquer au LLM également. C'est juste qu'il y a tout un ensemble de choses qui étaient importantes quand c'était des humains qui écrivaient du code, comme la syntaxe, la non-verbosité ou la verbosité dans le langage. Toutes ces considérations disparaissent avec les LLM. Il y a quand même des différences majeures.
Bruno:
Intéressant. Avant de parler effectivement de l'évolution de notre métier, il y a aussi des sujets qui reviennent souvent sur ces outils-là. C'est des aspects, on va dire, de sécurité. Je vais regrouper volontairement, c'est dommage que c'est un petit peu différent, mais on a deux aspects sur la sécurité. Quand on parle LLM, il y a dans un premier temps sur est-ce que ton LLM va être capable de générer du code qui est suffisamment safe et fonctionner et de ne pas t'ouvrir de backdoor ou de problèmes ou t'exposer à tout un type d'injection. Enfin bref, tu connais. Et l'autre côté, c'est aussi comment tu garantis la sécurité de ta code base en tant que telle quand tu as des agents qui évoluent de manière complètement libre dessus mais qui sont aussi en plus des agents américains donc potentiellement ton codi par ailleurs tu vois comment est-ce que tu, j'essayais de faire court parce que on a encore pas mal de sujets à évoquer mais tu vois cette notion de sécurité comment est-ce que toi tu la gères avec tous ces outils.
Jocelyn:
Alors aujourd'hui j'ai une conviction c'est que il doit toujours y avoir un human in the loop je sais pas comment le dire.
Bruno:
En français.
Jocelyn:
Donc il doit toujours y avoir un être humain qui regardent ce que fait l'agent. Je pense que c'est sur du code critique qui n'est pas d'époque. C'est totalement inconscient de faire confiance aveuglément à l'agent. Donc, dans tous les cas, le développeur, avant de comité, il doit regarder ce qu'a fait l'agent et normalement, il a itéré avec l'agent. Idéalement, je pense que c'est très efficace de commencer à écrire des tests d'ensuite avoir l'agent qui essaie de faire passer ces tests-là. Pareil, le TDD, c'était une pratique qui pouvait être à certains égards considérée comme lourde avec les agents. Je pense que c'est une pratique qui fait encore plus qu'avant sens. Avant de pousser du code via une merge request, l'humain doit regarder ce qui se passe et ensuite, de toute manière la merge request, elle doit être revue par les développeurs. Après en tant que manager, j'aimerais bien te dire, bien sûr, chez Mano Mano, tous mes développeurs, ils regardent les merge requests je sais qu'il va y avoir des petits malins ils vont dire à Claude, Claude regarde cette merge request là, tu peux me faire la revue et ensuite ils vont écrire les. Commentaires que Claude leur a donné mais si on veut être, sérieux aujourd'hui il doit y avoir absolument des phases de revue d'humains et des phases de revue même par des seniors. Le code devient de plus en plus complexe avec les bases de code qui grossissent et on peut pas faire confiance aux agents et tu me donnes une perche intéressante pour faire le parallèle entre le vibe coding et l'agentic coding moi je pense que le vibe coding c'est super bien pour faire des tests, explorer des idées pour faire un proto qui va être jetable des outils comme Lovable sont absolument incroyables après quand on bosse dans une boîte qui ship du code qui va impacter plusieurs. Centaines de milliers de clients, voire de millions de clients c'est pas du tout adapté, donc nous on est plus sur de l'agentic coding ou de l'I.I.A. Il y a assisted coding où on a l'I.A. Qui aide l'humain mais à toutes les parties du process, l'humain est celui qui pilote, qui décide et qui vérifie que niveau sécu ça va bien, par, Ce qu'on peut avoir, c'est des agents qui regardent en permanence les bases de code, et c'est ce qu'on a chez ManoMano, et des agents qui essaient eux-mêmes de détecter des failles de sécu, et on a eu des agents qui nous ont détecté des failles de sécu ou des mauvaises pratiques. Donc j'ai envie de dire que si on est sérieux en termes, on va dire, de pratique d'ingénierie, l'IA n'est pas censé apporter plus de failles de sécu. Encore une fois, il ne faut pas que l'humain se dédouane de son boulot et délègue tout à l'IA. Et même l'IA peut nous aider à aller plus loin en automatisant une partie du boulot qui est assez pénible et rébarbative.
Bruno:
Mais j'aime beaucoup ta phrase je la mettrais en quote, de l'épisode c'est qu'il faut pas que l'humain se dédouane de son rôle c'est vrai qu'on a encore notre valeur ajoutée mais c'est vrai qu'effectivement se pose en fait aujourd'hui la question de, mais même c'était le cas aussi sur les 40 années qui viennent de s'écouler, est-ce que notre valeur ajoutée elle était vraiment dans notre capacité à écrire du code ou à concevoir du code qui fonctionne et qui fonctionne dans le temps quoi.
Jocelyn:
Moi je suis un amoureux du beau code donc j'ai passé énormément de temps à étudier la syntaxe du code, à essayer de trouver la plus belle syntaxe pour faire quelque chose mais si je regarde honnête, je suis toujours un amoureux de ça et j'adore l'IA pour ça parce que justement ça me permet d'itérer pour savoir, disant ah ce bout de code est-ce que je pourrais pas trouver une manière qui soit un peu plus on va dire, pragmatique c'est pas le bon mot mais une manière qui soit un peu plus belle d'écrire ce code là j'en sais rien des fois c'est un peu plus fonctionnel à la place d'utiliser plus d'impératifs ou plus concis ou qui se comprennent mieux parce que des fois je trouve que le code que j'écris il est dur à comprendre, donc l'IA permet d'itérer sur ça, après on passait beaucoup de temps sur du sucre syntaxique et ça apportait pas vraiment de valeur, de valeur métier donc c'est vrai que l'IA ça nous enlève un peu ce petit truc là moi j'adorais en revue de code dire ah regarde là ces trois lignes de code que tu as fait t'as une fonction dans la standard libre qui te permet de l'écrire et tu vois, t'as plus besoin de tester ton code parce que t'as utilisé le code standard c'est super, bon ben avec l'IA on a moins cette partie là.
Bruno:
Après pour faire une analogie j'ai regardé il y a quelque temps un espèce de reportage on va dire sur l'histoire de l'IA dans les échecs, toute l'histoire de Deep Blue et autres et ce qui était intéressant, la conclusion c'était de se dire que aujourd'hui en fait les IA d'échecs sont absolument, imbattables par n'importe quel être humain ils sont à un niveau qui est juste colossal malgré tout on a encore des championnats d'échecs il y a encore des humains qui jouent aux échecs, il y a encore des gens qui font du beau jeu en échec, Le fait que les IA nous dépassent dans une capacité à faire des choses ne veut pas dire qu'on doit arrêter de le faire pour autant.
Jocelyn:
Oui, tout à fait. Je pense que j'ai vu le même reportage que toi et je crois qu'il y a de plus en plus de monde qui joue aux échecs, d'ailleurs. Et parce que maintenant, on peut aussi s'entraîner seul face à une IA qui peut s'adapter à notre niveau, qui peut nous apprendre des choses. Et je pense qu'en tant qu'être humain, on a tous un moment de réalisation que ce qu'on fait qu'on pensait artistique unique, la machine peut le faire il y a des professions, on va dire tous les métiers de l'industrie de l'agriculture qui l'ont compris il y a, des siècles voire quelques dizaines d'années, nous en tant que profession intellectuelle et développeur en particulier, on est en train de l'apprendre Moi typiquement je suis passionné de jeux vidéo et je jouais beaucoup à un jeu qui s'appelle Dota 2 Qui existe toujours, c'est lol pour les puristes on va dire. Et il y a quelques années une petite boîte qui n'était pas connue a commencé à faire des IA Pour essayer de battre des équipes professionnelles de Dota Cette boîte s'appelle OpenIA, donc ils ont commencé, moi j'ai connu OpenAI il y a 7-8 ans parce qu'ils essayaient de battre des joueurs professionnels à Dota et au début ça m'a fait doucement rire parce que en fait c'est un jeu, où c'est pas comme un plateau d'échecs ou un plateau de go où on voit en permanence ce qui se passe on voit qu'une petite partie de, l'échiquier à Dota il y a plein de choses qui se passent dans ce qu'on peut appeler du brouillard de guerre, donc que la machine ne peut pas analyser. Donc la machine ne voit pas l'ensemble et après il y a énormément de synchronisation entre plusieurs personnes, il y a des tactiques à mettre en place et je me disais jamais une IA, avoir de la puissance de calcul, ça ne sert à rien pour ce jeu-là. Il y a vraiment une particularité de l'être humain, une intuition, quelque chose des, que les machines sont vraiment pas prêtes. À avoir et en tout cas les machines mettront plusieurs dizaines voire vingtaine d'années pour nous battre et en fait pas du tout les machines ont battu les êtres humains très rapidement après il y a Starcraft 2 qui est tombé, et je crois que tout ça c'est arrivé après que AlphaGo est battue, alors je ne me souviens plus du nom du champion sud-coréen et je me disais non mais les jeux vidéo c'est encore plus complexe il y a encore plus d'inconnus et il y a des choses que Lya ne peut pas voir et elle n'arrivera jamais à raisonner de manière. Probabilistique sur ces choses là et un humain trouvera toujours une manière totalement débile de battre Lya et effectivement il y a des joueurs qui ont réussi à battre Desi avec des techniques avec lesquels ils n'auraient jamais battu un être humain mais très rapidement les IA se sont adaptés et aujourd'hui les IA sont absolument, absolument imbattables et ce moment de réalisation que, j'ai eu il y a quelques années je pense que il y a quelques-uns de nos collègues qui, sont en train de la voir ou qui ne veulent pas le voir et sur les jeux vidéo c'est quelque chose, qui a peu de conséquences c'est un passe-temps, c'est un hobby c'est pas très grave le métier qu'on fait, on était quand même dans une bulle dorée, en tant que développeur on était extrêmement bien payé on était beaucoup à avoir du télétravail, des conditions de travail qui étaient incroyables et là il y a un nouveau truc qui arrive et qui dit on va foutre un gros coup de pied dans toute cette fourmilière et on va voir ce qui va rester à la fin, ça fait peur on sait pas où ça va et donc il y en a qui ne veulent pas le voir je vous.
Bruno:
Mettrai en description cette vidéo, je crois que c'est une vidéo de Igo sur l'histoire de Deep Blue et qui évoque aussi un petit peu ce que tu évoques comme quoi Kasparov est le premier être humain à avoir eu ce sentiment de se dire en fait la machine est plus forte que moi, et de se faire remplacer, donc super vidéo je vous mets le lien en description pour du coup terminer justement sur ce sentiment de peut-être pas forcément de remplacement je sais pas si on peut aller jusque là, mais ça a été quoi l'impact de tous ces outils là sur le métier pour les devs seniors, experienced, juniors ou même prestats chez Manomano.
Jocelyn:
Je rebondis juste sur ce que tu viens de dire. Je trouve que les secondes où on voit Kasparov se lever fou furieux quand il perd la première fois contre Deep Blue, il y a un moment où l'être humain réalise qu'il y a quelque chose qui est unique, qui n'est pas si unique que ça. Pour revenir à ta question sur Mano Mano des prestats on en a très peu chez Mano Mano donc les impacts, ils sont assez durs à analyser mais je sais que t'as fait un épisode avec quelqu'un dont j'ai perdu le nom qui bosse au cercle qui explique très bien les impacts qui peut y avoir, sur les prestats sur les devs seniors, Je pense que c'est plus ou moins, je ne dirais pas les gagnants, mais leurs connaissances sont démultipliées par l'IA. Globalement, savoir comment architecturer une application, savoir quelles sont les erreurs à éviter quand on fait une application, comprendre le business de la boîte, savoir où on veut aller, quel style. D'organisation du code prendre en fonction du contexte c'est des savoirs qui sont démultipliés par l'IA parce que avant pour mettre, comment dire en action ces savoirs il fallait quand même passer pas mal de temps à écrire du code et là en fait l'IA permet de démultiplier on va dire que la partie laborieuse d'écriture du code où on écrivait, des DTO, des mappeurs, des classes qui n'avaient pas forcément, on va dire... Enfin, elles avaient une utilité architecturale, mais elles ne nous demandaient pas une concentration de dingue. En fait, l'IA permet d'aller à une vitesse inouïe sur ces tâches-là. Donc, je pense que le savoir des seniors est démultiplié par l'IA... Ceux pour lesquels je suis plus inquiet, c'est les juniors. Aujourd'hui, je n'aimerais pas être un junior parce que le marché du travail dans l'IT est devenu beaucoup plus compliqué pour les juniors et deux, parce qu'il va falloir une discipline de faire aux juniors pour acquérir les savoirs que nos seniors ont aujourd'hui. Nos seniors, ils ont été obligés de se coltiner la théorie sur comment fonctionne une machine, comment fonctionne un langage, pourquoi tel langage est pertinent dans tel cas, ils connaissent à peu près bien les standards libres de tous les langages, ils connaissent les patterns d'architecture, mais tout ça, ils ont été obligés de l'apprendre. Il n'y avait pas le choix et si on voulait être pertinent, on était obligé de passer par toutes ces phases d'apprentissage, toutes ces phases où on se plantait, on réessayait et là ça marchait. Enfin du moins ces phases de répétition où on ancrait ses connaissances. Aujourd'hui, un junior qui peut poser une question à Chad GPT et Chad GPT ou Claude ou Mistral lui donne la réponse, comment peut-il avoir la discipline de passer par toutes ces phases d'apprentissage qui font que les seniors ont tous ces savoirs qui sont pertinents dans le monde dans lequel on vit aujourd'hui ? Donc je trouve que pour les juniors, c'est extrêmement dur par rapport à ça. Et ensuite il y a un autre truc qui est dur c'est qu'aujourd'hui pour une boîte la plupart des boîtes sont des calculs économiques à assez court terme pour une boîte. Tellement plus efficace de recruter des seniors et de leur donner toutes les IA, tous les outils agentiques et d'avoir un senior qui va pouvoir bosser avec 3 cloud code en parallèle sur 3 bases de code et vu que c'est un senior, il a l'habitude de faire des codes review, de switcher de contexte, il va être capable d'orchestrer plusieurs agents en parallèle plutôt que de dire on va prendre ce même senior et on va lui coller un junior et il va faire monter le junior en compétences. Si on fait un calcul économique tout court-termiste, en fait, j'ai l'impression que l'équation est assez brutale pour le junior. Les boîtes ont tout intérêt à prendre des seniors et équiper des seniors. Et malheureusement, quand on regarde le marché de l'emploi américain, c'est ce qu'on semble voir. Comment dire ? Les boîtes ont continué à embaucher des seniors Par contre, depuis le pic de 2022, on a eu une chute des embauches de juniors de l'ordre de 20-30% et c'est encore plus fort sur les stagiaires. Donc il y a clairement un âge d'or qui est terminé au niveau du marché pour les juniors et ils vont avoir besoin d'avoir une discipline, plus grande pour apprendre les connaissances, que les seniors ont acquis et je dis que c'est ce que je dis c'est vrai à mon sens pour les juniors, les dev juniors mais c'est encore plus vrai pour les gens qui sont à l'école et les étudiants où en fait c'est tellement plus simple de demander à l'IA de faire, de répondre à la question plutôt que d'essayer, d'apprendre à répondre à cette question là, donc pour répondre à ta question je suis pas très, inquiet pour les seniors je suis assez inquiet pour les juniors.
Bruno:
Ce qui est d'autant plus problématique c'est que les seniors au bout d'un moment ils seront plus là et si on a pas fait progresser les juniors pour qu'ils deviennent seniors en fait on c'est aussi mon inquiétude en fait et en fait, forcément la réflexion mûrit à chaque invité que je reçois mais tu vois en écoutant ce que tu disais tu vois tu me disais il faut avoir une discipline de faire pour comprendre les choses et pas juste poser la question à Tchadp.t, on va être honnête, toi et moi on a beaucoup fait de copier-coller de code depuis Stack Overflow, c'est au final pas si loin de ce que pourraient faire les jeunes aujourd'hui et ça nous a pas empêché d'apprendre, et ce que j'avais aussi envie d'ajouter c'est que est-ce que la manière dont nous on a appris est forcément la manière dont les autres doivent apprendre. C'est une question que j'ai posée à pas mal d'invités récemment c'est vrai que nous on a beaucoup appris par l'erreur on a fait beaucoup de trucs qui ont planté en prod, qui ont causé des sueurs froides, des problèmes et autres. Ça nous a permis d'apprendre plein de choses. Tu nous as parlé des langages typés, où tu t'es confronté suffisamment aux problèmes des langages faiblement typés. Est-ce qu'apprendre par l'erreur, par l'échec, c'est vraiment la seule solution qui existe ? Et pour compléter là-dessus. Je me demande aussi si le problème qu'on n'a pas aujourd'hui, c'est qu'on est en train de mettre sur le côté des juniors, parce qu'effectivement, c'est difficile de les faire progresser vers le métier de senior dont on a besoin aujourd'hui. Mais est-ce que les seniors de demain sont les mêmes seniors que ceux d'aujourd'hui ? Parce qu'au final, est-ce qu'écrire du code... En fait, ce que je me dis de plus en plus, c'est que si on considérait le LLM comme un compilateur, parce qu'au final tu vois tous tes devs aujourd'hui qui font du Python du javascript, et autres, l'assembleur ils le connaissent pas, le langage machine encore moins, et en fait si tu considères l'LM comme un compilateur en fait tu peux dire qu'il faudrait que les juniors apprennent justement à maîtriser au maximum ces outils quitte à ne pas savoir ce qui se passe en dessous parce que c'est déjà le cas, nous aujourd'hui les développeurs on est très peu à vraiment maîtriser, moi pourtant qui ai reçu beaucoup de gens sur ce podcast je sais que je maîtrise pas tout ce qui se passe dans toutes les piles, tu vois ce que je veux dire le problème je pense c'est qu'on ne prépare pas tu parlais des jeunes qui sont en école aujourd'hui on ne prépare pas les jeunes d'aujourd'hui à être les seniors de demain.
Jocelyn:
Tout à fait. Alors, j'avais prévu de... Enfin, ça sera ma recommandation à la fin de l'épisode, mais je vais la spoiler dès maintenant. Il y a Micode, le présentateur de Underscore, qui a fait une vidéo que je trouve absolument excellente la semaine dernière, ou il y a deux semaines. Je crois que le titre de la vidéo c'est allons-nous tous devenir débiles ou pourquoi nous allons tous devenir débiles où il explique justement les mécanismes d'apprentissage du cerveau et c'est des choses qui sont assez bêtes et assez scientifiques mais globalement, il faut une phase de théorie il faut une phase de répétition et il faut une phase de récompense où on se plante, où on a un feedback positif ou négatif et ça c'est vrai dans le code mais c'est vrai dans tous les processus d'apprentissage de l'être humain. Et le problème, c'est qu'en fait, l'IA vient au milieu de tout ça et casse cette boucle d'apprentissage. Et change drastiquement la manière dont on peut acquérir du savoir. Et il y a un exemple qui est extrêmement connu, qui est celui des taxis londoniens, qui avaient une mémoire absolument incroyable et des capacités de raisonnement qui étaient incroyables parce qu'avant, ils devaient connaître quelques milliers de rues et en fonction de l'endroit où ils étaient, ils devaient comprendre quel était le chemin le plus court pour aller dans le point A.
Bruno:
En fonction de l'heure de la journée et de la semaine.
Jocelyn:
Tout à fait. Et en fait, on s'est rendu compte que quand le GPS est arrivé, il y a eu des pertes de capacités cognitives sur les taxis londoniens. Qui ont été absolument drastiques. Et aujourd'hui, il y a des études scientifiques qui montrent que quand on laisse des étudiants utiliser des LLM et on ne passe pas par cette phase d'apprentissage de la théorie, de répétition de la théorie et de feedback positif ou négatif en fonction de si on se plante ou si on réussit, on n'arrive pas à acquérir des connaissances. Donc pour nos juniors il est absolument. Qu'ils utilisent le LLM comme quelqu'un qui va les entraîner et pour moi c'est un peu la même j'ai envie de te faire la même réponse que celle que je t'ai faite pour, la sécurité, sur la sécurité il y a un an de ça on s'est tous vraiment on a tous vraiment rigolé quand il y a quelqu'un qui est pas dev qui est arrivé, qui a dit j'ai vibe codé une application, tous les devs vous êtes morts, regardez mon application, elle est déployée elle est en sas, elle marche trop bien évidemment il y a quelques devs qui étaient un peu on va dire, piqués au vif tout à fait par cette déclaration qu'ils sont allés faire du stress test sur l'application et qui ont réussi à hacker l'application, et il me semble que la personne qui avait été un peu trop assertive s'est retrouvée avec une facture AWS ou Google assez conséquente, donc sur la sécurité oui, si on utilise les LLM, on fait n'importe quoi ça nous explose à la gueule mais je pense que c'est exactement pareil pour l'apprentissage, il y a des choses qui marchent, il y a des bandes pratiques on a mis des. Millénaires à apprendre comment apprendre aux personnes, si au milieu on met un LLM et on délègue tout au LLM mais en fait on va avoir des choses qui vont nous péter à la gueule en termes en termes de connaissances donc les juniors doivent utiliser le LLM comme quelque chose qui leur apprend à faire des exercices qui leur permet de mettre en oeuvre des méthodes qui sont scientifiquement prouvées pour entraîner la mémoire etc. Si on utilise le LLM comme ça, c'est quelque chose qui va être incroyable en termes de connaissances, Comme pour la sécurité où on a le LLM qui peut scanner des bases de code et voir des problèmes. Par contre, j'ai peur que l'être humain est feignant par nature et les développeurs, je pense qu'on est tous des gros feignants par nature et c'est un des critères pour adorer ce boulot parce qu'on est capable d'automatiser des choses, donc de s'éviter pas mal d'efforts. J'ai peur qu'en tant que développeur et être humain plus généralement on choisisse le chemin de moindre effort court termiste qui nous envoie droit dans le mur.
Bruno:
Mais du coup tu penses pas que si on formait les jeunes, à utiliser l'LLM plutôt que de les former à ce que l'LLM sait faire et du coup ils utilisent l'LLM en mode raccourci, du coup en fait on pourrait entre guillemets créer un nouvel type de créateur d'application qui serait capable d'utiliser l'LLM correctement mais sans forcément savoir écrire du code ?
Jocelyn:
Je pense qu'il y en a qui vont utiliser les LLM de manière incroyable, ça peut être un outil d'égalité incroyable parce que n'importe qui a accès à un LLM qui fait à peu près la même chose, je dis n'importe qui, il y a quand même des limites, des plans qui coûtent assez cher, mais je pense que ça peut être un outil de diffusion de la connaissance qui est absolument incroyable. Mais je pense qu'il faut que tout le monde ait conscience de comment on apprend les choses, quels sont les processus métacognitifs qui sont à l'oeuvre et d'utiliser les LLM justement pour. Abonner si on si on le fait pas on va droit dans le mur et pour en revenir à ta question initiale parce que j'ai perdu un peu le fil, il y a un danger qui guette les boîtes qui font cette équation économique court termiste de ne pas recruter des juniors c'est que à un moment on va se retrouver les juniors d'aujourd'hui sont les seniors de demain, pas se permettre pendant de longues périodes d'arrêter de recruter, les juniors et je crois que c'est le CTO d'Amazon ou le nouveau patron d'Amazon qui n'est pas Jeff Bezos du moins quelqu'un, qui a pas mal de bouteilles chez Amazon qui disait que c'est le truc le plus con qu'il avait attendu des dix dernières années et je me souviens plus de la citation exacte mais il disait il nous faut absolument des juniors sinon on casse totalement la pyramide RH de la boîte donc c'est essentiel même si on se passe de toutes les considérations de est-ce qu'ils vont être économiquement plus efficients à court terme une boîte ne peut pas survivre sur le long terme sans recruter des juniors.
Bruno:
Un investissement sur la durée top, merci beaucoup Jocelyn pour tout ça, on termine par deux questions les questions héritées du podcast tu nous as déjà fait ta recommandation est-ce que tu en as une autre qui te vient que tu as envie de partager un film, une série, un livre que tu aimerais partager avec tout le monde ou est-ce qu'on reste sur la vidéo de mi-code ?
Jocelyn:
Excellente vidéo de mi-code sur l'IA je reste sur ça autre vidéo qui se regarde très bien sur l'IA et qui... Et qui est assez intéressante c'est un documentaire sur, D-Mind de Google, donc l'entité anglaise de Google qui a fait, AlphaGo des IA sur StarCraft et je crois que le titre de la vidéo qui est disponible gratuitement sur Youtube c'est The Thinking Game, et donc je pense que c'est quelque chose qui donne un peu d'espoir sur ce que l'IA pourrait apporter ok.
Bruno:
On mettra les liens bien évidemment en description, et pour terminer la question la plus importante de ce podcast Jocelyn, tu es plutôt espace ou tabulation ?
Jocelyn:
Plutôt tabulation, même si je sais que c'est un popular opinion très bien.
Bruno:
Merci beaucoup Jocelyn merci Bruno et merci à tous d'avoir suivi cet épisode je pense que je pense que ça nous a donné des super recommandations sur le bon usage de ces outils, la première étant que c'est indispensable de les utiliser aujourd'hui bien évidemment, que vous soyez senior ou que vous soyez junior donc n'hésitez pas à vous le réécouter on va essayer de faire des extraits pour que tous ces éléments de savoir soient aussi disponibles en mode nuggets et encore plus facilement digest, mais voilà c'est effectivement une révolution de notre métier qui est en train de changer de se transformer, le chemin l'arbre des possibles est infini c'est aussi une bonne nouvelle, ça nous permet de faire plein de choses ça permettra effectivement, comme le disait aussi Jocelyn, c'est une grand arme d'égalité qui permet de faire venir beaucoup de gens, nouveaux dans ce métier là donc c'est plutôt une bonne nouvelle. Donc voilà, on va suivre bien évidemment toutes ces évolutions je vous remercie beaucoup aussi de partager ce podcast autour de vous, n'hésitez pas à aller faire un tour sur le Tipeee pour aussi contribuer à ce podcast si vous souhaitez le soutenir comme toujours, merci à tous je vous souhaite une très bonne fin de semaine je vous dis à la semaine prochaine et d'ici là codez bien.
