Bruno:
Yves TTD, vous le savez, c'est un podcast de devs. On y parle de devs, entre devs, avec des devs, pour des devs. Nous sommes entre nous pour parler de nos sujets. Mais comme je le dis souvent, ce qui fait la différence avec un bon ou une bonne développeuse et avec les autres, c'est avant tout la capacité à s'intéresser à autre chose que sa stack quotidienne. Cela nous permet de choisir le bon outil pour tacler le bon problème. C'est ce qui fait que je suis un des rares devs qui défend avec passion le no-code et le low-code. Et donc il est plus que temps d'évoquer enfin cette nouvelle tendance, le Vibe Coding. Mais alors le Vibe Coding est-il l'avenir de notre métier ou une évolution des no-codeurs ? Si c'est en forgeant qu'on devient forgeron, peut-on devenir codeur sans coder ? Et surtout est-ce que demain les PM pousseront leur propre release directement en prod pendant que les devs iront vendre chez le client ? Pour répondre à ces questions de forge je ne reçois ni Harold ni Golford mais il s'est martelé du code. Pierre, bonjour.
Pierre:
Salut Bruno.
Bruno:
Alors Pierre, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Pierre:
Oui, bien sûr. Je m'appelle Pierre. Je travaille chez Exa. Exa, on est une plateforme pour entrepreneurs et particulièrement, moi je travaille dans la partie Startup Studio. Et donc ce que je fais, c'est que je travaille avec un partenaire pour trouver des idées de start-up. Une fois qu'on trouve une startup qui nous plaît et à laquelle on croit, on trouve un CEO, un CTO et on s'associe tous les trois pour amener cette boîte-là jusqu'au CID, donc la première levée de fonds. Donc ça veut dire signer les premiers clients, concevoir le produit, le monter et prouver le potentiel de ce marché-là.
Bruno:
Ok. Et donc en fait, tu crées une boîte tous les six mois ?
Pierre:
Je crée deux, trois boîtes par an, donc une boîte tous les six mois.
Bruno:
Canon, c'est une super expérience. Mais donc, es-tu dev ou n'es-tu pas dev ?
Pierre:
Donc je ne l'ai pas précisé, je t'ai entendu en intro dire un podcast où je reçois des devs pour parler à des devs, je ne suis pas dev.
Bruno:
Mais alors du coup, qu'est-ce que tu fais ici ? Pourquoi venir sur ce podcast alors que tu n'es pas dev ?
Pierre:
Parce que tu m'as invité.
Bruno:
Bonjour. Exactement, c'est vrai.
Pierre:
Pourquoi je viens là ? Je pense que j'imagine qu'on a... T'as parlé un peu de vibe coding, alors t'as dit le vibe coding pour les non devs, on pourra en reparler, est-ce que le vibe coding c'est vraiment codé en n'étant pas un dev, mais pourquoi je suis là ? Parce que moi je me suis beaucoup intéressé à ce sujet là, et notamment je m'en suis servi pour construire la première version de certains des produits de nos boîtes.
Bruno:
C'est quoi les outils principaux que tu utilises curseur cloud je me permets aussi une précision parce que dans ce monde là les choses évoluent très vite nous sommes aujourd'hui le 30 janvier au moment où on enregistre cet épisode il devrait donc être diffusé dans quelques semaines potentiellement des choses ont déjà changé tout aura bougé au moment où ce sera diffusé mais comme en plus avec le podcast les gens peuvent l'écouter, de manière assez prolongée dans le temps il faut juste sur ces sujets là il faut temporaliser de manière assez forte donc qu'est-ce que tu dis ? Donc tu as dit cursor et cloud code cursor, cloud et cursor, ce que je trouve intéressant en fait dans ton approche et c'est aussi pour ça que je voulais qu'on puisse en parler c'est que, dans le vibe coding quand on entend parler de gens qui sont pas issus du métier de développeur ou de développeuse et qui utilisent ces outils là souvent on va plus entendre parler, alors potentiellement de chat GPT mais surtout des outils comme Lovable comme Webflow qui permettent effectivement à des gens qui ne sont pas du tout tech de construire assez rapidement des interfaces, donc là pour moi ça a effectivement c'est des outils qui sont vraiment destinés au grand public, là ce qui est intéressant c'est que toi tu utilises Cursor qui est un IDE avant tout qui est un éditeur de code et CloudCode qui est un outil destiné, principalement aux développeurs mais ce que je trouve vraiment intéressant c'est que justement ces outils puissent enfin être pris en main par des gens qui n'ont pas, le prisme de formation purement d'oeuvre qu'est-ce qui t'a amené toi à te dire je vais utiliser ces outils là alors que c'est pas mon métier.
Pierre:
Qu'est-ce qui m'a amené à me dire ça franchement je suis pas posé la question de c'est pas mon métier alors déjà une précision, moi j'ai fait une école d'ingé, 90% de la promo est devenue dev en sortant quoi, je pense que moi je suis le 10% restant, qui n'est pas devenu dev qui voulait pas devenir dev et qui était très très nul en dev à l'époque donc quand même je découvrais pas non plus que c'était qu'un IDE j'avais déjà codé avant, jamais professionnellement mais tu vois j'avais fait mes petits projets, j'avais fait mon app Android, quand j'étais en école pour les projets d'école etc donc moi c'était pas, tu vois j'ai pas eu une barrière psychologique à me dire mon dieu je vais ouvrir un IDE qu'est-ce que c'est, et pourquoi j'utilisais ça bah tout bêtement j'avais testé Lovable avant et V0 et je trouvais qu'aucun des deux fonctionnait assez bien pour ce que je voulais faire, et c'est toujours le cas aujourd'hui même s'ils ont plein de évidemment plein de vertus c'est une première raison deuxième raison c'est hyper difficile d'être dans mon secteur où on monte des boîtes AI native donc le coeur du produit le coeur du business est basé sur l'AI sans soi-même entendre parler de cloud tous les jours et sans devoir tester, et en plus de ça la plupart des boîtes enfin les dernières boîtes que j'ai montées étaient à chaque fois ce qu'on appelle les agents et donc encore une fois tu peux pas aujourd'hui bosser sur un agent sans avoir testé Cloud Code ou le Cursor Agent sur le côté quoi ok.
Bruno:
Sur ces usages-là, il y a encore beaucoup de débats dans la communauté des développeurs et développeuses sur l'utilité réelle, la pérennité ou la qualité de ce qui est produit. Comment est-ce que toi, tu perçois ces débats ou ces avis-là qu'il peut y avoir sur le code généré ?
Pierre:
Tu as dit utilité, pérennité, qualité. Moi, il n'y a qu'une seule chose qui m'intéresse dans ce que je fais, c'est l'utilité. La périté je me pose pas la question en fait c'est une question qu'on se posait tu vois moi j'ai démarré chez Exa il y a 4 ans et donc nous notre principe encore une fois je rappelle, moi on a une idée de boîte avec le partenaire, et on trouve, généralement c'est un CEO qui arrive en premier parce que c'est lui qui va porter le projet et qui va porter la boîte et ensuite on trouve un CTO, trouver un CTO ça peut prendre 3 mois, au démarrage d'Exa on se disait jamais on écrit une ligne de code avant d'avoir trouvé le CTO parce que le CTO la première chose qu'il fait quand il arrive c'est qu'il jette tout à la poubelle et il recommence et ils recommencent et ça prend du temps et puis on a perdu un peu l'effet d'apprentissage de l'archi etc. Aujourd'hui avec l'AI ça va tellement vite de coder qu'en fait ils peuvent tout jeter à la poubelle c'est pas grave, ils reconstruiront en 3 jours quoi, tout va vraiment très vite, les CTO chez Exa avec qui tu bosses c'est des gens qui disent non mais en fait si dans 6 mois je jette toute mon app iOS à la poubelle, c'est pas grave si j'ai appris quelque chose et si j'ai fait avancer la boîte. Donc la question de la pérennité et de la qualité elle se pose pas en tout cas la pérennité se pose pas pour moi la question de la qualité c'est un autre sujet parce que la qualité ça touche en partie à est-ce que ça marche, et encore une fois bon il y a différents niveaux moi mon niveau de qualité idéal c'est ça fonctionne c'est à peu près sécurisé et ça s'arrête là.
Bruno:
Peut-être pour essayer de préciser ton propos parce que, comment dire il y a pas mal d'éléments qui se bousculent alors déjà j'ai tendance à dire que, en général quand je parle de sujet texte j'ai tendance à dire qu'écrire du code qui fonctionne c'est relativement facile écrire du code qui fonctionne pendant longtemps c'est pas la même limonade c'est là où t'as besoin d'une véritable expertise, toi de ce que tu dis en fait c'est que le sujet de pérennité c'est pas ton sujet, mais ce que je veux juste préciser c'est que, Pour toi, c'est que tu n'approches pas les choses en te disant de toute façon, avec le Vibe Coding, on fait du code qui est jetable. Ce que tu dis, en fait, c'est que le code, aujourd'hui, il peut s'écrire tellement vite qu'en fait, ce n'est plus un problème de se dire qu'on peut le jeter.
Pierre:
Ouais, et même, enfin, c'est parce que je parlais de mon cas spécifiquement et de la merde dont je m'en sers et donc peut-être qu'on peut parler de ça plus en détail pour recontextualiser un peu ce que je disais. Parce qu'effectivement, je ne dis pas que du code généré par l'EI est forcément de mauvaise qualité.
Bruno:
Forcément jetable. Il faut qu'on sait que ce soit jetable.
Pierre:
Attention je n'ai pas dit ça c'est juste que dans mon contexte à moi et la manière dont je m'en sers c'est soit pour valider une idée de boîte un proto et signer les premiers clients et c'est à ça que ça nous a servi ces 6 derniers mois, soit pour un petit outil interne pour moi pour un usage presque perso et donc dans ce cadre là moi ce qui compte le plus pour moi dans le cadre d'un proto que je vois un client c'est d'essayer de faire avancer la boîte faire avancer la boîte c'est soit valider l'idée et il n'y a pas de meilleure validation que de faire le premier MRR, de faire le premier revenu et c'est ce qu'on a fait avec ce projet là en l'occurrence, et le deuxième c'est d'apprendre et en fait il n'y a pas de meilleur moyen, d'apprendre sur le produit et sur ce qu'on doit construire qu'en le construisant en le testant, en l'ayant dans les mains et en s'en servant en condition réelle quoi, donc voilà pourquoi moi j'ai ce point de vue là sur la qualité, c'est parce que tu me demandes on parle souvent de ces trois aspects on parle souvent de ces trois aspects du code, bon il n'y en a qu'un seul qui m'importe en l'occurrence c'est est-ce que ça marche quoi, mais effectivement chez Exa je pense qu'il n'y a pas un seul CTO aujourd'hui qui ne vibecode pas, c'est pour ça que je te disais tu présentes le vibecoding comme permettre à des non-dev de développer. Pas tout à fait je pense que c'est pour ça qu'on en parle beaucoup, qu'on en entend beaucoup parler, mais moi la plupart de mes sources sur X qui m'apprennent des trucs sur le sujet c'est pas des non-dev, c'est des CTO ou des techs qui s'en servent, des devs et chez Exa il n'y a pas un seul, CTO qui ne vibe-code pas, directement, si tu leur parles je pense qu'ils disent qu'ils passent 80% de leur temps à planifier et ils ont juste un IDE sur le côté pour monitorer ce qui se passe, auditer et ils écrivent de temps en temps une ligne ou deux.
Bruno:
Pour corriger un peu mais c'est vrai que toi au final tu es de formation ingénieur mais tu n'es pas devenu dev quand je me suis dit des camarades dans ce que tu disais tout à l'heure, et en fait j'ai repris plaisir à coder quand j'ai commencé à utiliser quand j'ai commencé à utiliser Cursor notamment parce que moi ce que j'ai réalisé c'est que moi ça fait 30 ans que j'ai commencé à écrire des lignes de code, et qu'en fait aujourd'hui quand quelqu'un vient me voir et me dit Bruno j'ai besoin de créer, d'un outil qui permet de gérer des factures en fait moi très vite dans ma tête j'ai toute l'architecture de l'outil en quelques heures ou quelques jours je vois à peu près tout ce qu'il y a à faire mais le problème c'est que ça me prend quelques heures ou quelques jours de penser à tout, mais en fait après aller devoir écrire toutes les lignes de code pour te faire ton baller plate ton framework, tes contrats en fait ça te prend des mois, moi j'avais une vraie frustration de me dire c'est bon en fait tout est là mais maintenant il faut juste que je me coltine d'aller taper sur des boutons pendant 6 mois pour créer un truc avec Cursor en fait effectivement tu t'expliques un peu ce que tu veux faire et ton truc il se génère extrêmement rapidement, Est-ce qu'au final toi c'était pas cette même frustration Que t'avais en sortant d'école Et que.
Pierre:
C'est le même soulagement Le même soulagement Le soulagement je sens ta frustration, Non non bien sûr c'est la même chose Moi je suis allé en école l'anger Je pense que ça faisait rire tout le même camarade de promo Quand je suis allé dans la filière informatique Parce que mes pires notes étaient en info Moi j'étais fort en physique etc Pas en informatique quoi Vraiment quand je dis que j'étais mauvais j'étais mauvais, Et en école l'anger Moi j'avais des bonnes notes en algo Et sur les cours théoriques tu vois de problèmes de logique mais tout ce qui était pratique les TD tu vois j'étais dans une école on faisait beaucoup de projets etc bon moi j'ai un peu freeridé quoi j'étais vraiment plus mauvais et pourquoi ? Parce que vraiment moi j'ai encore une sueur froide quand je me revois ouvrir Eclipse et voir toutes ces petites lignes rouges là qui s'affichent en bas et je me disais ok mais en fait je peux même pas démarrer là je peux même pas commencer et c'est vraiment ce qui m'en est fou et donc effectivement moi je le vis comme ça je le vois comme ça, et bon je suis un peu au sommet de la pyramide de Linkranger ce truc là mais tu vois quand je démarre je me sens super puissant j'en me sens très rare, d'être surhumain et c'est bien je trouve que c'est intéressant ce que tu dis c'est bien que tu te trouves toi dans cette catégorie là parce qu'il y a quand même une autre catégorie de dev moi que j'entends qui trouve de la frustration là-dedans parce qu'ils aiment bien justement ce côté intellectuel de casser des bloqueurs.
Bruno:
Petit à petit oui mais tu vois qu'au final tu peux retrouver aussi avec du cloud code ou du code source en fait il va te, il va te sortir une pâle enquête code tout un baller plate notamment en fait qui est une partie intéressante quand il faut, quand il faut intégrer pour la 72ème fois l'API de Facebook ou je ne sais quoi en fait c'est quand même pas hyper intéressant à faire ça au moins c'est torché et après tu peux aller faire de l'orfèvrerie, sur les quelques éléments qui restent c'est.
Pierre:
Vrai bien sûr c'est comme ça qu'il faut retrouver de la satisfaction dans ce que tu fais si c'est ça que t'aimes bien.
Bruno:
Si c'est ça que t'aimes.
Pierre:
Bien c'est résoudre ces petits problèmes.
Bruno:
Comment est-ce que toi tu perçois voire peut-être même expliques la frustration des devs face à ce code généré parce que.
Pierre:
Mais est-ce qu'ils sont frustrés ?
Bruno:
C'est toi qui me le dis oui enfin tu vois il y a quand même une, En fait pour rajouter au débat en fait donc moi j'ai commencé à coder dans les années 90 au siècle dernier et à l'époque déjà on avait des outils il y avait Frontpage notamment qui était un outil de Microsoft qui te permettait de générer des pages HTML et déjà à l'époque les devs te disaient en fait le truc c'est ton code il est dégueulasse c'est trop lourd c'est pas comme ça qu'il faut faire donc c'est pas comme ça qu'on fait des sites web. Pourquoi est-ce que la génération de code, quels que soient les outils utilisés depuis des décennies et des décennies, on trouve que ce n'est pas au niveau attendu de ce que nous, on ferait en tant qu'être humain ?
Pierre:
Écoute, je pense qu'on est un peu dans le sociologique, là. Je pense que le métier de dev, c'est un métier d'expert. Et donc, je pense que quand on est dev aujourd'hui, tu vas me dire ce que toi, tu en penses plutôt. Je t'expose ma théorie, mon petit analyse de comptoir, et c'est toi qui me dis ce que tu en penses. Je pense que quand on est dev, c'est qu'on aime bien le fait que ce soit technique et qu'il y ait une expertise. On aime bien le fait que ce soit pointu, on aime bien le fait de découvrir de nouvelles technologies, découvrir des nouveaux langages, découvrir des nouvelles difficultés. Et quand il y a quelque chose qui vient perturber un peu ce monde de difficultés, en rendant plus facile certaines choses, je pense qu'on voit un peu son univers se rétracter un tout petit peu. Mais la réalité des choses, c'est que, tu parles, par exemple, de front page, mais à chaque fois, il y avait toujours de la place pour l'expertise. Et je pense que 100% des devs qui ont râlé sur chacune de ces changements se sont retrouvés à prendre ce changement-là. Et par exemple, ce que tu dis sur le vibe coding, je faisais un peu innocent en disant « Mais les devs, ne me rendent pas le vibe coding ? » Le vibe coding, c'était présenté au début. C'est un de la jacquart partie qui a labellisé le terme vibe coding dans un post que vous pourrez aller voir, vous même sur X mais le vibe coding il y a un côté un peu rien que le nom vibe coding qui moi me file un peu des boutons quoi. Qui veut sonner cool le vibe coding a beaucoup été décrit sur X et beaucoup, la plupart des gens qui en ont parlé sont des gens comme moi qui ont sorti des protos qui ont sorti des trucs et qui étaient tellement mais tellement, impressionnés et renversés de voir ce qu'ils arrivaient à sortir que sur X bon évidemment ils partent en. Ils sont évidemment très très fiers et ravis et donc ils en parlent beaucoup et ils en parlent beaucoup comme le monde va changer avec des prédictions en disant ça y est le dev c'est terminé, moi je vais faire mon propre sas tout seul regardez je l'ai déjà fait d'ailleurs sur X, c'est pas je vais le faire je l'ai déjà fait évidemment, et ça c'est exaspérant mais encore une fois aujourd'hui moi ce que je vois le plus dans le... Enfin il y avait toujours cette blague ah et t'as commis tes variables d'environnement moi ce que je suis le plus sur X en ce moment c'est des, techs et donc vraiment des experts des dev experts qui perfectionnent le webcoding et par exemple tu parlais du tail web coding pour sortir du boilerplate ils s'en servent pas comme ça, aujourd'hui ce qu'ils font c'est qu'ils passent alors il y a plein d'outils pour faire ça et on peut en parler un petit peu je suis pas la meilleure personne moi je suis encore un bébé sur ce genre de sujet. Quand je te disais que les sitios passent 80% de leur temps chez Exa dans la planification c'est parce qu'en fait ils ont créé, la galaxy outil l'architecture qui leur permet de faire ça et donc ce qu'ils font c'est qu'ils planifient donc c'est pas juste qu'ils expliquent dans les grandes lignes ce qu'ils veulent faire ils planifient la feature ils se posent toutes les questions que se pose un archi un dev, tu vois si vous faites du scrum dans un refinement en disant mon dieu comment faire cette partie là et ce service etc, et ensuite ils appuient sur un bouton, ils lancent et ils lancent cloud code en récursif, jusqu'à ce qu'ils arrivent à valider ces tests et donc parfois ils attendent 30 minutes sur ce cloud code là pour qu'il ait fini sa mission mais ils lancent un deuxième, un troisième, un quatrième, un cinquième le PC commence à chauffer et puis après ils reviennent voir et ils reset ils check qui a réussi quoi est-ce qu'il faut débloquer ou rebloquer et ils relancent la machine quoi donc le vibe coding pour moi c'est il y a eu une phase un peu adolescente, exaspérante, de non-développeurs qui un peu comme à l'époque du no code disent ça y est c'est la mort du sas moi aussi je vais faire mon sas et je vais être tout seul je vais faire un milliard mais aujourd'hui moi ce que je vois le plus sur X en ce moment, encore une fois je parle de X parce que c'est là qu'il y a la source d'infos, sur X aujourd'hui c'est pas des solopreneurs et des indie hackers, qui en parlent, c'est des experts c'est des lèvres.
Bruno:
Je suis quand même je suis complètement aligné avec ton analyse, je pense que effectivement il y a un démultiplicateur de ce que l'outil apporte je pense qu'effectivement il y a, terme n'est peut-être pas adapté, parce qu'effectivement il y a cette notion de bricolage on a l'impression que c'est un truc qui est fait par la vibe, un peu effet de mode, tendance et effectivement, quand t'es expert d'un sujet, tu vois d'un mauvais oeil quelqu'un qui bricole un truc dans son coin et qui n'est pas en mesure de le faire avec la même, précision ou la même perfection que toi mais qui va placer mais qui te donne l'impression qui place son résultat au même niveau que ce que toi tu produis Exactement.
Pierre:
Tu as bien dit et d'ailleurs tu vois par exemple faisons un pareil avec la Star Academy la Star Academy, pourquoi tous les musiciens pro, moi je fais beaucoup de musique la plupart des musiciens qui veulent en faire leur métier ce qu'ils détestent de la Star Academy c'est que ça donne l'impression qu'en 3 mois tu serais une star, ils détestent ça, ils disent mais moi j'ai fait 30 ans de conservatoire je suis à fond, je fais ça toute la journée c'est 12h par jour et la Star Academy ils te font croire qu'en 3 mois c'est bon, tu peux devenir une star Et t'as raison, c'est sans doute cet effet là L'impression.
Bruno:
Que les gens prennent un raccourci.
Pierre:
C'est même pas raccourci C'est que En mettant au même niveau ce qu'ils font Ils dévaluent ce que toi tu fais parce que ce qu'ils mettent au même niveau N'est pas au même niveau Mais encore une fois, je parlais de Dunning-Kruger C'est exactement la même chose C'est pas leur faute, ils savent pas de quoi ils parlent Quand ils disent qu'ils font Des trucs aussi bien que ferait un dev.
Bruno:
Alors donc du coup sur le comment dire ce que t'évoques c'est qu'effectivement, Claude Code alors moi je commence à utiliser Claude Code de manière effectivement assez intensive je suis assez fasciné en fait par effectivement cette capacité, de lui donner tant de choses à faire et en fait tu vas te faire un café tu vas limite regarder un film ou juste dormir et tu arrives le matin et la quantité de choses qui est faite est juste hallucinante, et ce que je trouve un petit peu, comment dire, ce que je trouve un peu perturbant, c'est que moi, pendant longtemps, sur ce podcast notamment, ce que j'expliquais, c'est que le dev n'est pas un métier solitaire. Il y a cette image du dev qui est seul face à son ordinateur. Alors qu'en fait, on a un métier qui est beaucoup dans l'échange, dans le partage, dans la discussion, dans la réflexion, et qu'on ne passe pas tant que ça seul face à son ordinateur à écrire des lignes de code. Et au final, aujourd'hui, avec un clôt de code, t'as l'impression que tu peux, de multiplier en fait tes agents qui tournent sur ton truc et qu'effectivement tu peux au final faire des choses tout seul, face à ton écran donc tu vois qu'il y a quand même un parfois tu peux avoir l'impression que c'est un changement de paradigme, pour au final arriver vraiment à un métier très solitaire.
Pierre:
C'est bon moi j'avais jamais envisagé comme ça tu vois pour moi c'était j'aurais même plutôt dit bah du coup toi tu vas te faire un café pendant qu'il tourne on va parler à ton voisin quoi mais non c'est marrant que tu imagines comme un métier solitaire pourquoi tu penses que ça te rend plus solitaire Claude Code.
Bruno:
Bah parce que comme tu peux en fait parce que ce qui génère beaucoup de discussions dans les communautés tech bah c'est des choix d'implémentation des choix d'architecture mais ça ça reste, bah je le vois moins justement comme en fait tu peux déléguer beaucoup de choses à la manière dont Claude fait les choses est-ce que.
Pierre:
Ce que tu délègues c'est les choix justement alors c'est marrant que tu parles de ça est-ce que ce que tu délègues c'est les choix d'archi d'implémentation ou est-ce que c'est le micro de la ligne de code ? Et est-ce que les conversions que tu as avec la communauté, c'est sur le micro de la ligne de code ou c'est sur l'archi et l'implem ?
Bruno:
Pour pinailler sur les termes, moi aujourd'hui, dans mon usage que ce soit de cursor ou de cloud, je reste aux manettes sur les choix d'architecture, les choix d'implem, comment est-ce qu'on utilise d'implémenter telle fonction, ou telle manière de coder les trucs ? C'est de moins en moins mon débat.
Pierre:
Ce qui crée de la conversation avec d'autres devs, c'est vrai, je te pose action, parce que moi je ne connais pas ça, mais vous parliez du coup de ce détail micro des choix d'implantation de la ligne c'est ça entre vous ou de l'archi et de l'ingénierie.
Bruno:
Les deux pour le coup.
Pierre:
Ça ne la retire pas cette partie moi ce que j'ai l'impression c'est que au final, peut-être que tu ne parleras plus du détail même si je pense que si parce que tu te dis ah c'est bizarre il n'a pas réussi à faire ça, pourquoi mais il y a un truc mais tu vas te retrouver à faire beaucoup plus donc plus de questions d'ingénierie donc plus de sujets de conversation avec tes pairs et tout à l'heure on parlait de, le mot ingénierie là bah tu vois mon petit wow effect, quand j'ai ouvert Cursor tu sais tu me disais t'aimes pas la ligne de code ça le wow effect c'est que quand j'étais devant mon cursor et que je faisais mes plans et mes specs etc en me disant c'est bon je vais le lancer et tout ça ce que j'ai adoré c'est que je faisais ce que moi j'aime bien qui est l'ingénierie qui est de penser au système et à l'archie à ce qu'on est en train de construire et je faisais pas le détail de l'artisanat qui est très bien aussi mais qui moi m'intéressait pas et Cloud Code pour moi il te supprime pas du tout, c'est pas le même challenge en temps actuel ça te supprime certaines problématiques peut-être mais ça en fait naître d'autres et tu passeras plus de temps à te poser des questions je pense sur de l'archi et faire plus de sujets, différents à la suite en parallèle et donc si ce qui compte pour toi c'est le nombre de conversions que tu peux avoir des faits de conversions que tu peux avoir avec tes pairs t'en auras plus c'est juste que tu vas parler de plein de projets différents au lieu d'un seul projet peut-être.
Bruno:
Et puis tu as.
Pierre:
Je vois vraiment pas ce truc peut-être parce que je suis pas dev mais je vois vraiment pas ce truc de est-ce que dev c'est un métier solitaire ou pas et est-ce que cloud code ça te rend plus solitaire ?
Bruno:
En fait là où je suis d'accord c'est que ça te permet effectivement de te consacrer à des sujets qui sont on peut dire au final plus high level t'es effectivement sur des sujets d'architecture et pas d'aller te, te soucier de la moindre ligne de code ou tout ce genre de choses j'aimais bien ce que tu disais tout à l'heure sur le fait que, on peut plus facilement considérer le code comme étant quelque chose de jetable parce qu'en fait on peut le réécrire beaucoup plus rapidement tu vas vite mais, tu vois une idée qui pop qui est peut-être aussi ajoutée au débat c'est que, dans le monde du dev on a ce qu'on appelle les codes reviews je pense que tu connais un sujet qui revient souvent c'est que, notamment au niveau des plus jeunes dans ce métier là quand ils prennent une code review en général ils le vivent mal parce que t'as un attachement très fort j'ai présenté.
Pierre:
Les specs et je me suis fait découper par la squad.
Bruno:
Donc tu vois en fait dans ces codes reviews souvent les plus jeunes, on voit qu'ils ont un attachement à leur code et en fait on essaye de leur apprendre avec l'expérience qu'en fait il faut que tu te détaches de ton code qu'en fait ton code c'est pas toi et que quand on critique le code en fait c'est pas toi en tant qu'individu qu'on critique c'est juste le... Et je pense qu'effectivement ces outils là te permettent en fait de plus facilement te détacher du code mais on a un enseignement aujourd'hui, enfin tu prends les plus jeunes je pense qu'on a une manière d'apprendre la construction d'applications je fais exprès de prendre ça, qui est très orientée justement sur cette importance de cette orfèvrerie, de la ligne de code qui fonctionne, de la petite erreur que tu arrives à corriger qui te débloque tout un truc derrière, qui fait qu'on est encore trop attaché à la valeur de cette ligne de code.
Pierre:
Ouais ouais ça je te enfin, encore une fois t'es mieux placé pour parler de ça mais il y a un truc qui m'intéresse dans ce que tu dis qui est les jeunes leur favori l'apprentissage par la code review par je vois comment ça fonctionne et là dessus je me pose beaucoup de questions et j'ai pas de réponse mais je me demande vraiment à quoi ça ressemble, tu vois le monde de demain dans un monde où en fait il y a potentiellement besoin de moins de juniors parce que le travail simple un dev expérimenté il le fait encore plus rapidement, et dans un monde où comme on passe moins de temps à en gros visser des boulons et faire la ligne de code et plus de temps sur l'archi est-ce qu'on perd un niveau de réflexion une façon de penser le code et de le comprendre qui fait que tu vois il y a une espèce de déperdition et que le dev senior lui il perd rien parce qu'il l'a déjà appris mais que ceux qui ont besoin de l'apprendre ne l'apprendront pas et tu parles de code review tu connais Code Rabbit ? Non Cernan c'est une startup qui cartonne en ce moment et qui fait des code review automatisés ok donc tu vois je te disais ça rend pas plus solitaire etc peut-être que si en fait parce que tu vois ce que fait CodeRabit c'est que tu fais une PR hop l'agent il arrive il te fait sa code review et le but de ça c'est évidemment que, bon je pense qu'eux ils le marketent en disant comme ça la personne qui vient faire la code review le travail est pré-mâché elle perd moins de temps etc mais la finalité c'est de closer la boucle et de faire en sorte qu'il n'y ait pas un humain qui doit faire la code review.
Bruno:
Je pense qu'effectivement on va s'éloigner de plus en plus.
Pierre:
De la.
Bruno:
Notion de code si on fait une analogie avec l'historique de l'informatique jusque là.
Pierre:
Oui on est remonté c'est.
Bruno:
Un chemin naturel moi ce que je dis de plus en plus c'est qu'à un moment on va considérer les LLM, en tout cas ces outils de génération de code, comme on considère aujourd'hui les compilateurs aujourd'hui quand t'écris du code en C et que tu le passes après dans ton compilateur, personne va aller relire le binaire pour s'assurer que le compilateur il a bien compilé comme il faut parce qu'en fait on peut critiquer les compilateurs de C, de RUD, tout ce que tu veux mais en fait personne va aller relire le code binaire qui est généré derrière.
Pierre:
Bah ouais c'est un bon point et du coup est-ce que t'as besoin de comprendre comment ça marche pour le construire quoi tu vois Est-ce que t'as besoin de comprendre comment ça marche en dessous de ton app pour pouvoir imaginer ton app et la décrire ? C'est vrai qu'a priori, peut-être pas.
Bruno:
Il y a certains cas, j'allais dire beaucoup, mais je pense qu'il y a certains cas où tu as besoin de savoir comment ça fonctionne en dessous. Parce qu'en fait, forcément, tu as des contextes où tu as des contraintes particulières qui font que tu as besoin de bien maîtriser ce qui se passe en dessous, mais dans la majorité des cas, c'est pas le cas. Et je me souviens, j'avais reçu il y a quelques temps le fondateur de Webflow, que tu connais, qui est un Français, qui était passé à ce micro et qui avait eu un propos je pense qui est un peu qui est réfléchi, qui est marketé, qui est volontairement provocateur mais qui est, je trouve très juste il disait en fait, Webflow est plus proche du javascript que le javascript n'est proche du CPU c'est à dire que tu as tellement de couches entre le CPU et javascript, que en fait les gens aujourd'hui quand tu es développeur javascript t'es très loin du hardware en fait donc la maîtrise de qu'est-ce qui se passe en dessous est pas tant que ça nécessaire et tu.
Pierre:
Donnes un peu la réponse à ta question de de qu'est-ce qui se passe les devs aiment pas le webcoding, comment ça va se passer pour la suite t'as déjà ta réponse je pense que tout le monde fait du javascript aujourd'hui, personne dit ah mon dieu non, l'assembleur c'était mieux.
Bruno:
Est-ce que du coup cette approche où tu vas créer une boîte où tu vas du coup déjà commencer à itérer sur un produit, généré avec du curseur ou du cloud code que tu vas après passer à un CTO, est-ce que du coup maintenant dans votre recherche de CTO ça vous arrive de recevoir des personnes qui vous disent ah non non t'as commencé avec ça moi je touche pas à ça machin ou est-ce que du coup tu vas chercher des gens qui ont cette approche là est-ce que ça se reprend dans les mêmes pratiques derrière non.
Pierre:
On rencontre que des CTO qui disent ah vous avez déjà des clients tu vois donc la question se pose pas et de toute manière enfin ce qui sous-tend ta question c'est qu'est-ce que ça devient ce code là ce projet et à quoi ça nous a servi dans la boîte et comment il survit bon bah à quoi ça nous sert encore une fois, il y a un premier aspect de validation et qui est c'est grâce à ça enfin, Je pense que si parmi ceux qui t'écoutent, certains ont déjà monté des boîtes, peut-être pas parce que c'est, tu me disais 98% de devs, mais bon les 2% qui sont pas les devs et qui essaient de monter des boîtes, si j'ai pas de siti au début, ma validation j'essaie de la faire avec un slide deck et d'aller vendre, on faisait des pirouettes avec des figmas et des vidéos de figmas animés pour faire une démo, enfin moi je l'ai fait ça, de faire du montage vidéo pour faire une démo, évidemment on disait pas que le produit était prêt, mais c'est une manière de faire sentir ton produit et de le montrer. Moi aujourd'hui si t'es un peu ingé faut quand même pas non plus dire que la barre est si basse que ça il faut quand même être un petit peu ingé et avoir ce résumé en système pour pouvoir sortir une app avec le code de cursor on verra dans un mois et demi ça dépend si tu veux.
Bruno:
Effectivement faire juste une démo je pense que tu peux être non dev si effectivement tu veux commencer à.
Pierre:
Avoir une approche.
Bruno:
Un peu production ready t'as la nécessité d'avoir cette.
Pierre:
Ouais je sais pas franchement tout dépend des encore une fois tout dépend de ton projet mais c'est vrai tout dépend du projet mais je pense que la barre est quand même pas aussi basse que ce qu'on aime se le raconter aujourd'hui. Mais tout ça pour dire que nous ce que ça nous a rapporté c'est que on a eu nos conversations avec des clients type CAC 40 tu vois on a fait nos premières missions avec eux on a fait du MRR avec eux donc du revenu quoi, ils nous ont payé pour ce qu'on faisait, et après faut pas minimiser non plus, moi j'ai passé des heures sur ce truc là j'ai appris plein de trucs et je passerai moins de temps la prochaine fois, mais c'était pas non plus un claquement de doigts tu vois, il y avait une réflexion donc déjà il y a un sujet de validation Le deuxième truc c'est quand tu montes une start-up c'est un jeu d'apprentissage en fait Toi ce que tu veux faire c'est apprendre plus vite que les autres et c'est tout En fait ça s'arrête là, tu veux apprendre plus vite que les autres sur tous les sujets, il n'y a pas de meilleur moyen d'apprendre sur ton business et ta boîte qu'en construisant quelque chose et en essayant de le vendre parce que tu vas apprendre si ça plaît aux gens et puis en construisant tu vas te poser toutes les bonnes questions donc en l'occurrence le projet dont je parle c'est, c'est en gros faire un AI interviewer qu'on envoie un lien à des consommateurs donc vous et moi, dans votre canapé, vous nous ouvrez et vous êtes en interview avec une AI qui vous pose des questions sur un sujet par exemple est-ce que vous avez bien ce nouveau shampoing L'Oréal et hop on parle de ce shampoing L'Oréal et on récupère, toute cette interview vidéo et on l'analyse derrière. Ça il y a plein de questions qui se posent là dedans, ok mais du coup à quoi ça ressemble une interview avec une AI qu'est-ce qu'il faut faire pour que le consommateur il soit honnête pour éviter les biais, pour que l'AI quand elle pose ses questions de follow up et qu'elle creuse les sujets pour, en faire de l'apprentissage, qu'est-ce qu'il faut faire pour que cette AI pose des bonnes questions, qu'est-ce que c'est que la méthodo ? C'est quoi la méthodo du consumer research aujourd'hui ? est-ce qu'il faut être drivé par des questions hyper strictes ou au contraire être hyper exploratoire et ouvert ? Tu vois toutes ces questions là tu peux évidemment te les poser sur un papier en chambre et c'est ce que je faisais moi avant, mais tu vas évidemment 100 fois plus vite, tu te poses 100 fois plus de questions et les bonnes questions si t'es en train de construire de tester et avec un peu de chance comme nous si t'es en train de t'en servir avec des clients Et ça, ça n'a pas de prix. Et donc à la question de qu'est-ce qui reste à l'issue du projet, tout ce qu'on a appris, l'argent sur le compte en banque, la validation et sur le code, je pense qu'il a, intérieurement j'espère qu'il a jeté quasiment 100% mais je crois que j'avais jeté un coup d'œil et il a gardé quand même une partie qui est en gros toute la logique business product qui était à l'intérieur de savoir quand est-ce que je fais une relance comment je structure l'interview, le data model, la base de données je pense que c'est la même.
Bruno:
Tous les fondamentaux.
Pierre:
D'archi product sont restés quoi.
Bruno:
Et sur le alors peut-être que le track record est encore trop frais pour avoir cette info là mais est-ce que du coup, ces code base sont reprises et retravaillées toujours en utilisant majoritairement du cloud code ou du cloud server et autres ou est-ce que du coup c'est repris et réécrit à la main non.
Pierre:
Non non, donc le site en communication c'est Camille qui bosse avec moi, il utilise cloud code, codex et je ne sais pas combien d'agents qu'il met ensemble pour le faire et non non non non il réécrit pas à la main pas du tout, vraiment l'exemple de l'ordinateur qui chauffe trop c'est un vrai exemple, il a changé d'ordi parce que son ordinateur chauffait trop il y avait un ordinateur trop petit, après je dis pas qu'il écrit pas de code à la main mais une grosse partie de son temps c'est de se dire ok, c'est de la planification, de l'archi et de lancer des agents et le fait est qu'en une semaine il sort ce que moi je me rappelle on sortait en un mois quand on était en début de carrière avec quelle pérennité et quelle qualité l'avenir nous le dira.
Bruno:
La question aussi qui fait peur en tout cas dans notre communauté c'est est-ce que tu penses que ces outils là sur ton expérience de création d'entreprise sur 4 ans est-ce que c'est un moyen de faire avec moins de monde, ou est-ce que ça permet juste à tout le monde de faire plus vite ça alors Kepa !
Pierre:
C'est un moyen de faire avec moins de monde mais c'est aussi un moyen de faire plus vite et donc enfin, j'essaie de faire une réponse courte à la place d'une réponse longue mais en gros oui c'est un moyen de faire avec moins de monde parce qu'en fait une seule personne va plus vite donc on arrive plus vite à la validation et donc nous par exemple les dynamiques de boîte ont un peu changé parce que quand t'es dans une phase hyper exploratoire, donc enfin vraiment on démarre évidemment on a l'idée qui est précise mais c'est très très différent dans une scale up et de travailler sur une feature qu'on va ajouter que de sortir une boîte de terre et là il y a un énorme. Énorme prime à être peu nombreux, parce que ça veut dire moins d'overhead organisational au-dessus, tu vois, on a moins de meetings parce qu'en fait on est que 3 ou 4, donc tout va plus vite au démarge donc c'est sûr que nous c'est un impact, et moi quand je l'ai marié chez Exa, on avait toujours un CEO, un CTO, un ou deux devs, voilà, maintenant la team, moi j'ai l'impression que c'est plutôt un CEO, un CTO, et en fonction des projets entre un mois et trois mois après, il y a un autre dev qui vient pour aider parce que bon bah là on a commencé à valider les trucs et on se dit ok on est assez précis sur ce qu'on veut construire, il faut qu'on aille plus vite, on en prend à nouveau. Donc c'est sûr qu'il y a un facteur de faire plus avec moins. Par contre, dans un contexte un peu plus loin, nous on finit quand même par recruter un dev en plus parce qu'on a besoin d'aller plus vite. Ça c'est un autre truc. Et l'autre point, c'est qu'on vit quand même... Donc la question sous-jacente c'est est-ce que le dev c'est un métier fini, est-ce qu'on continue à recruter ou pas ? Moi je connais pas de boîte, j'ai jamais poussé dans une boîte où la deadline de la roadmap était tenue. Où il fallait pas prioriser hyper fort sur la roadmap et où les CEOs disaient à la fin de son quarter ou à la fin de l'année à la fête du nouvel an les gars c'est super l'année prochaine on fait plus rien.
Bruno:
On a fini ça ça n'arrive pas c'est.
Pierre:
Bon on a terminé à tort ou à raison mais ça ça n'existe pas donc est-ce qu'il y aura plus de dev demain non pas du tout pas du tout.
Bruno:
Mais je pense même en fait qu'on va que là on va connaître une période un petit peu, difficile de transition du métier tu vas t'évoquer le cas des juniors on sait pas trop comment est-ce que, mais je pense que le problème qu'on a c'est que on forme les juniors d'aujourd'hui à devenir les seniors qu'on avait hier alors que les seniors dont on a besoin demain, c'est pas tout à fait le même métier que les seniors d'aujourd'hui donc faudrait former les juniors de demain mais du coup un métier qui est pas encore qui est pas encore clair mais tu vois je pense que du coup en fait on va là on est dans une part un petit peu étrange, et qu'en fait, il y a plein de gens qui vont arriver avec des nouveaux produits, des nouveaux services, des nouveaux usages qu'on n'avait jamais pensé à créer avant, soit parce qu'on ne savait pas le faire, soit parce qu'on n'avait pas les moyens soit parce qu'on est trop dans notre, c'est ce qu'on disait un peu sur le compilé juste avant, on est trop dans notre approche on est trop dans la solution et pas dans la résolution du problème, en tant que tech, on se dit en fait, nous on sait faire ça, Et que du coup, on va rentrer dans une période où il y a plein de trucs qui vont popper de tous les côtés, qui vont faire qu'on va repartir dans une situation où en fait le besoin en créateur d'application, je change le terme volontairement, parce que ça ne sera plus du codeur en tant que tel, va ré-exploser et va redevenir un marché du travail avec une pénurie de talent versus la demande nécessaire.
Pierre:
Donc ce que tu dis, c'est on va pouvoir construire plus. Donc on va construire des choses pour lesquelles on n'avait pas le budget de construire avant. Entre autres et on va aussi déconstruire des choses qui ne servent à rien c'est ça ?
Bruno:
Comme on le fait aujourd'hui au final c'est qu'aujourd'hui il y a quand même des moyens qui sont assez importants dans certains contextes que finalement il y a des choses qui prennent du temps à faire parfois on fait des choses qui ne servent à rien ça arrive c'est pas pour autant que ça peut générer des choses, que ce soit purement financier et autres mais ça arrive de faire des choses qui ne servent à rien.
Pierre:
Alors tu parlais d'utilité, pérennité, qualité il y a quand même une grande mouvance aujourd'hui dans ce qui est de la tech sur l'AI, j'essaie de me rappeler du terme et il faudrait que tu cherches à côté c'est impossible en prononcer mais je crois que c'est slope copain slope apocalypse entre comme ça le copain x qui est en gros ça va être l'apocalypse tech parce que on va sortir que du code de mauvaise qualité qui est pas pérenne et qui en plus ne sert à rien quoi tu vois et qui fait un peu à écho de l'internet que vous l'intérêt est rempli de zombies quoi je crois que sur internet il ya plus du fin il ya moins de cette heure humain ça.
Bruno:
C'est surtout l'impression que effectivement en fait on génère de plus en plus.
Pierre:
De contenu.
Bruno:
De manière automatisée, le problème c'est que le contenu produit sur internet est utilisé pour entraîner l'ensemble des modèles donc en fait on a un moment où ça va tourner dans une espèce de vide et que ça va commencer à Et.
Pierre:
Moi j'ai aussi vu repris sur le code en fait, sur le fait que du coup on va générer des apps qui ne servent à rien, qui sont pleines de code qui est de mauvaise qualité et qui n'est pas pérenne comme tu le disais, il y en a d'autres qui disent que ça n'arrivera pas parce que tu vois le... Le gars qui a créé Cloudbot Cloudbot c'est le nouvel agent vraiment à la mode, on en parlait sur X je pense le week-end dernier ou le week-end d'avant encore, je crois que lui il dit l'inverse il se dit de toute façon les modèles vont tellement vite et sont tellement plus smart que la courbe d'adoption n'est pas assez rapide, pour que le modèle soit pour qu'on ait cette espèce de l'apocalypse du code de WSKT il faudrait que la courbe d'adoption soit hyper rapide et que tout le monde utilise les modèles maintenant et lui ce qu'il dit c'est qu'en fait la courbe d'option elle est pas assez raide par contre la progression des modèles est suffisant raide pour que le jour où ça se croise, évidemment on fera des trucs qui servent à rien mais la mauvaise qualité il y croit pas trop bon lui il est un peu partisan aussi parce qu'il est évidemment à fond là dedans et il joue son business là dessus mais, moi j'ai pas d'avis ce dont je suis sûr c'est que des choses qui servent à rien on a déjà sorti plein et on va continuer à en sortir et on en sortira encore plus, est-ce que c'est grave est-ce que c'est un problème, bah évidemment il y a le sujet un peu politique sociétale et écologique de se dire est-ce qu'on a raison de produire plus ? Est-ce qu'on a raison dans un monde capitaliste et de choix avec la recroissance ? Si je laisse ces sujets là de côté, de toute façon, le marché, il rééquilibre. C'est-à-dire qu'un truc qui ne sert à rien, il n'est pas utilisé. Et puis tant pis, il est en 5 coins, il n'est pas utilisé.
Bruno:
Je suis d'accord. Moi, je suis assez aligné avec le fait que la quantité de codes produits aujourd'hui n'est pas suffisamment importante pour arriver à cette notion de slope-apocalypse. Je serais juste... Moi, je tends à être mitigé sur les gens qui disent que les modèles vont évoluer tellement rapidement que les sujets de qualité vont se résoudre. Parce que tu vois je crois que c'était la semaine dernière Elon Musk qui sur une scène a évoqué, a dit que pour lui dans 5 ans, une IA sera plus intelligente que l'être humain et que dans 30 ans une IA sera plus intelligente que tous les humains collectivement mais.
Pierre:
Il a raison bien sûr on peut mesurer tous les humains collectivement et.
Bruno:
L'intelligence public il y a 10 ans ou 15 ans Elon Musk il disait que dans 6 mois on aurait les voitures autonomes en fait le dernier kilomètre et hyper compliqué. Et moi j'ai reçu beaucoup de gens qui font de l'IA à ce micro qui me disaient qu'en fait les GI, qui est un peu l'espèce de truc optimal. Sera peut-être une possibilité ça c'est difficile de dire si ce sera le cas ou pas le cas en revanche ce qu'ils disent tous c'est que, le deep learning les réseaux de neurones tels qu'on les construit aujourd'hui ne seront pas une solution c'est à dire qu'en fait il y a un moment ça a plafonné et ce sera pas capable d'arriver à une sorte généraliste donc tu vois le fait de dire en fait les modèles ils évoluent tellement rapidement je pense que assez vite on va arriver à une espèce de plateau qui fera que, on va pas résoudre tous les problèmes j'ironisais.
Pierre:
Sur Elon Musk.
Bruno:
Tout à l'heure c'était.
Pierre:
Pas sérieux tu peux pas écouter Elon Musk, Sam Hattman il faut les écouter évidemment mais ils sont tous partisans encore une fois ils ont un truc à vendre, après évidemment en vrai moi j'en sais rien est-ce que ce sera l'année prochaine, ce sera dans 10 ans moi je parlais pas sur l'année prochaine pour ce dont tu parles les AI qui est plus intelligente que tous les humains qu'est-ce que c'est être intelligent et qu'est-ce que c'est qu'elle est sur les humains, moi je sais pas trop ce dont on parlait par contre c'est la capacité à créer du code du coup utile, pérenne de qualité, ce qui est pas tout à fait la même chose c'est pas de la super intelligence de sortir ce code là, moi j'ai quand même l'impression qu'entre le moment où je m'y suis mis tu vois en avril, mai en gros le moment où j'ai commencé vraiment à mettre les mains dedans et à m'en servir avril, mai dernier et aujourd'hui, ça a juste plus rien à voir je pense qu'au delà de juste le modèle qui est plus intelligent, et c'est le cas Quand tu regardes les vrais experts, pas moi, mais ceux qui s'en servent de manière hyper extensive, ils le voient, ils sont capables d'argumenter, ça se mesure. Au-delà de ça, il y a tout ce qu'ils ont construit autour, le harness. Donc, tu sais, Claude, tu as les modèles, évidemment, tu as les outils et tu as ce qui s'appelle le harness autour, qui est un peu le harness qui tient le modèle et tous ces outils et tous ces sub-adgets, etc. pour faire que Claude Code marche. Et les progrès que tu vois là dessus sont hyper rapides et l'une des raisons pour lesquelles c'est aussi rapide c'est que le code c'est un jeu parfait pour les AI c'est à dire que eDogFood à mort, ceux qui créent CloudCode ne codent qu'avec CloudCode donc forcément ils le font progresser pour leur usage qui est le même usage que le reste des gens qui codent, le code c'est trop bien pour les AI parce que ça se valide donc en fait c'est facile de dire ça marche ou ça marche pas donc c'est facile d'entraîner un modèle dessus c'est facile de faire en sorte de construire toutes les features tu vois tous les à côté tous les harness ce qui fait qu'à la fin ton modèle, même en étant pas dix fois plus intelligent il est dix fois meilleur parce qu'on a fait la boucle enfin on a fait la structure les outils l'archi qui fait qu'il est meilleur parce que c'est facile de me dire qu'il est le meilleur, donc est-ce que ça arrivera dans un mois, dans six mois, dans un an, dans deux ans moi pour ces raisons là je suis plutôt optimiste et je pense que ça arrive plus vite que ce que toi t'as l'air de penser est-ce que je me mouillerais à dire une date aujourd'hui tout de suite ?
Bruno:
Non de toute façon c'est compliqué de faire la boule de cristal sur ce sujet là pour terminer ça fait quand même un moment que tu utilises ces outils là, qu'est-ce que tu aurais comme conseil à nous donner sur un bon usage d'un cloud code ?
Pierre:
Voilà. Aller sur X et se renseigner. C'est vrai que, à mon grand désarroi, c'est vrai que tout se passe. Un conseil, qui s'adresse à qui ? Quelqu'un qui n'a jamais essayé ?
Bruno:
Oui, à des devs qui sont soit sceptiques, soit qui ont testé mais qui ont été déçus parce que peut-être qu'ils l'ont pas forcément utilisé comme il faut. C'est quoi pour toi les conseils ?
Pierre:
C'est le même conseil que n'importe qui qui est sceptique face à l'AI. L'AI, déjà c'est super mal nommé, à l'intelligence artificielle est-ce que c'est vraiment intelligent ou est-ce que c'est juste de la compétence mais en tout cas quand on entend l'intelligence artificielle ma mère et je pense que les gens qui sont sceptiques avec Cloud Code c'est la même chose, pardon maman ils s'imaginent quelque chose de bien au-delà de ce qu'ils expériencent quand ils le vivent tu vois parce qu'il y a des gens qui disent partout sur internet que ça change la société que c'est l'avenir qu'il faut mettre des milliards dedans etc, moi personnellement je pense que c'est vrai je le constate mais le problème quand on dit ça c'est que du coup quand la personne se retrouve devant ChatGPT ou devant CloudCode et essaye de faire quelque chose et que ça marche pas ou que ChatGPT dit qu'il y a deux R à Strawberry ou une bêtise comme ça il dit bah mince il est bête, parce qu'en fait il s'imaginait la super intelligence tu vois dans ton pariateur il s'imaginait un truc incroyable, et donc le premier truc c'est de pas le regarder par rapport à ses attentes c'est à dire pas se dire moi je m'attendais à ce que ça fasse ça mais plutôt le regarder à la progression que ça offre, par rapport à si ça n'était pas là c'est à dire que si j'utilise CloudCode pour produire du code Bien sûr qu'il va sortir un truc 100 fois trop verbeux Si vous lui demandez sort moi un sas tout de suite Et que vous l'encadrez pas Mais dites vous bien que Enfin il y a 3 ans on parlait pas à une machine Autrement qu'avec du code hyper structuré Là c'est de l'anglais quoi C'est déjà incroyable, Il sort du code Personne savait écrire du code automatiquement Avant lui il sait quoi. Donc ça c'est un premier truc, de placer la barre au bon niveau parce que c'est en la plaçant trop haute qu'on se dit ça sert à rien et qu'on essaie pas qu'on arrête. Le deuxième truc c'est qu'il faut itérer en fait. Il y a une intuition à se créer de savoir de quoi le modèle est capable, de quoi l'outil est capable, comment je fais pour m'en servir, comment je fais pour y aller. Donc faut pas s'arrêter évidemment au premier, faut continuer à essayer. Moi mon conseil sur Cloud Code mais c'est pareil que tout le reste c'est en fait faut essayer de tout faire avec. Parce que le meilleur moyen d'apprendre vite à quoi ça sert c'est de tout essayer. Donc il faut essayer de tout faire avec, et le troisième qui est un peu plus terre à terre, un peu plus actionnable mais qui est, bon j'espère que j'enfonce une porte ouverte un peu, c'est de se dire en fait, ce qu'il faut c'est donner des instructions qui sont claires, donner des instructions qui sont claires, ça prend du temps et en fait c'est passer du temps à planifier à se dire ok ma feature, voilà à quoi doit ressembler voilà les endpoints dont je vais avoir besoin, la base de l'aide derrière doit être structurée comme ça et passer ce temps là à itérer, moi la première fois que j'utilise le cursor j'ai rien sorti, la dixième fois si j'ai sorti quelque chose c'est parce qu'en fait j'ai passé, beaucoup de temps à itérer avec lui sans faire du code pour qu'ils me sortent un markdown avec à la fin donc j'avais des markdown de spec et tout que je fais avec lui pour à la fin faire un plan d'implémentation et littéralement c'est un markdown avec avec des cases à cocher de tâches à faire et je faisais faire tâche par tâche quoi et c'est le truc qu'ils ont implémenté maintenant de mode plan de cloud code c'est ni plus ni moins que ça c'est juste qu'il se fait un markdown dans un coin de l'ordinateur qui cache et il vous dit j'avais bien réfléchi voilà ce que je veux faire quoi donc le conseil avec soi-même c'est ça c'est de se dire. Il faut passer du temps à planifier et il faut être critique sur « Ok, il m'a donné un mauvais résultat. Est-ce que c'est parce qu'il est nul ? » ou « Est-ce que c'est parce que si je lui avais donné plus de précision, il aurait été meilleur ?
Bruno:
» Notamment, il y a depuis quelques mois, je crois, sur le code, on a les skills. On parlait des notions de qualité de code. Ça aussi, c'est un moyen de rassurer peut-être les devs sur la qualité du code qui est produit et que tu peux lui apporter justement cette capacité à faire ce que tu veux.
Pierre:
Et c'est le secret, en fait. Quand je parle des CTO qui laissent Claude tourne des 30 minutes et qu'il revient de voir après ce qu'il se passe ou deux heures En fait c'est ce qu'ils font C'est pour ça que On parlait du code de qualité, mauvaise qualité, est-ce qu'ils vont sortir du code PN ou pas Eux ils sortent du code PN mais parce qu'ils s'en servent, Comme moi je m'en sers Mais à un niveau qui est bien plus élevé Parce qu'ils savent coder en fait Et donc ils savent lui donner les bonnes instructions Et donc tu parles des skills ? Tu vois, le repo d'un sitio chez nous maintenant, c'est un point cloud dans lequel il a des instructions spécifiques sur l'archi du projet, des guidelines sur comment on code le front, des guidelines sur comment on code le back, des skills spécifiques pour faire l'immigration de DB, tu vois. C'est tout ça. Et donc, c'est parce qu'il y a tout cet encadrement autour qu'à la fin, ils peuvent le faire tourner tout seul et avoir un bon résultat.
Bruno:
Je suis en train de regarder c'est l'épisode juste avant toi de la semaine dernière pour les gens qui nous écoutent, où j'ai découvert que chez Mano Mano ils ont une équipe de DevEx, de Developer Experience ça c'est des équipes moi c'est un sujet que je trouve top depuis.
Pierre:
Des années donc.
Bruno:
Des gens qui sont vraiment là pour faire en sorte que les dev aient les meilleurs outils dans le meilleur contexte pour travailler et chez Mano Mano en fait ils ont une équipe de DevEx qui.
Pierre:
S'occupe de maintenir les skills le cloud comme.
Bruno:
Ça tous les devs qui utilisent cloud.
Pierre:
Ils l'utilisent.
Bruno:
De la même façon ils produisent du code de manière unifiée du coup t'as 200 personnes qui utilisent cloud de la même manière qui produisent du code de la même manière et donc forcément t'as ce fameux aspect qualitatif et pérenne dans le temps du coup.
Pierre:
Toutes les boîtes aujourd'hui en gros tous les sitios aujourd'hui qui utilisent de l'AI et c'est quand même un gros pourcentage ils se posent cette question là ils se disent ok mes choix technologiques je vais les faire en fonction du modèle parce que si le modèle il maîtrise bien ma techno bah ma boîte elle va aller 100 fois plus vite ils se disent comment je fais pour organiser mon équipe, pour qu'ils puissent bosser ensemble avec les mêmes standards moi j'ai mes best practices comment je les implémente et les skills viennent de là et en fait comment on réglait ça au début donc. Encore une fois moi je suis pas dev moi j'avais des rules dans le curseur pour lui expliquer mon niveau et lui dire moi ça m'intéresse d'apprendre donc tu m'expliques au fur et à mesure ce que tu fais comme ça j'apprends et donc c'est comme ça que j'apprenais, Quand Cursor n'avait pas bien utilisé PyTest et qu'il faisait toujours la même erreur et que je me rendais compte que c'était la même erreur, même si je ne la comprenais pas forcément, je faisais l'effort d'aller la comprendre, de me lui faire expliquer. Je lui faisais un guide dans un markdown comment utiliser PyTest. Et du coup, après, à chaque fois que je voulais lui refaire des tests, je lui dis, by the way, n'oublie pas d'aller lire le guide. Et c'est là que tu vois aussi que... Mais c'est ça qui est génial. Plus vous avez utilisé ce genre d'outils, vous avez trouvé ça super parce qu'en fait, en s'en servant, pour contourner toutes les limitations, on crée nos propres astuces notre propre manière de faire et ce que je fais tout le monde le faisait enfin c'est pas du tout original et on se rend compte que en fait les créateurs du modèle les créateurs de cloud de l'outil de cloud code, ils réutilisent les skills c'est ni plus ni moins que ce que je viens de décrire moi j'avais mon guideline sur comment il s'est pas le test j'avais mon script pour tous les faire tourner dans le bon ordre parce que je savais pas le faire autrement donc je lui avais fait écrire un script j'ai dit ok il marche je le garde et à chaque fois que j'avais besoin de faire tourner mes tests, je lui disais va chercher dans ce dossier là dans la doc comment faire des tests et comment les faire tourner les skills c'est ça et donc les ouais ouais comme tu dis, tu vois il y a Mano Mano je sais que Alan c'est exactement la même chose Alan ils vont jusqu'à faire en sorte que des designers puissent faire des PR parce qu'ils ont mis souvent une guideline autour pour que des designers puissent faire des PR et c'est un peu c'est le sens c'est le sens de l'histoire.
Bruno:
Donc tu penses qu'à terme dans les squads où on a plusieurs compétences des gens produits des gens côté UI côté data et autres que la notion de production de code ne sera plus réservé que aux...
Pierre:
Ouais mais c'est déjà le cas. Alors à une échelle qui est ridicule par rapport à ce que c'est que le marché du dev et la production de code mais bien sûr, bien sûr.
Bruno:
Top, merci beaucoup Pierre pour cette discussion. 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 que tu souhaiterais partager avec l'ensemble des auditeuristes ?
Pierre:
Ouais ouais, alors je me suis un peu creusé la tête parce que du coup j'ai cherché j'ai le vous pari d'un dessin animé que j'aimais bien puis je me suis dit bon quand même je vais essayer de trouver un truc en rapport avec le sujet, et un article que je peux vous recommander alors je crois que ça s'appelle highagency.com, donc highagency.com et c'est un article qui a parlé sur, les internets ces deux dernières années avec l'arrivée de l'AI et qui parle du concept de l'agency évidemment comme tous les articles un peu sur ces sujets là il fait 10 pages il ne pourra en faire qu'une seule mais c'est un concept qui est suffisant abstrait pour être, un très bon conseil qui ne vieillira pas premier truc et qui s'applique bien à toutes les discussions qu'on a eues sur l'AI qu'est-ce que ça veut dire pour moi qu'est-ce que ça veut dire pour la suite et moi en tant que personne qu'est-ce que je devrais faire pour en tirer le maximum quoi.
Bruno:
On mettra le lien bien évidemment en description pour que les gens le retrouvent facilement. Je suis preneur quand même du dessin animé que tu voulais recommander.
Pierre:
Le produit qui m'était venu en tête, c'était Samuel. J'avais bien aimé.
Bruno:
Ok, effectivement, c'est un super truc. On mettra le lien aussi vers Samuel. Et dernière question qui est la plus importante de ce podcast. Est-ce que tu es plutôt espace ou tabulation ?
Pierre:
Alors évidemment, je savais que la question venait. Je me suis mis un malin plaisir à ne pas me renseigner sur ce que c'était. Je ne comprends pas la question. Ok, donc moi, ce serait peut-être plutôt Claude, tu vois.
Bruno:
D'accord.
Pierre:
Mais Space or Tab, non, je ne sais pas du tout pourquoi tu me poses cette question.
Bruno:
Très bien, bah écoute ça me va aussi je pense que ça montre aussi l'avenir de ce que Doské est réellement le codage l'appauvrissement intellectuel.
Pierre:
Plus personne ne sait utiliser un IDEO c'est ça.
Bruno:
Bah écoute top, merci beaucoup Pierre pour cette conversation merci à toi et merci à tous d'avoir suivi cet épisode voilà je pense que, si vous êtes développeur ou développeuse et que vous n'utilisez pas encore Cloud ou d'autres, on a parlé de Cloud mais il y en a bien évidemment plein d'autres qui existent l'idée c'est pas de dire que Cloud est forcément. Le top du top en termes de génération de code mais que déjà il faut en utiliser un, il faut le maîtriser il faut le tester, il faut itérer comme disait effectivement Pierre je pense que c'est primordial, on a un métier qui est en train de changer et je pense qu'il faut s'embarquer dedans parce que ça nous permet de faire des choses qui sont réellement folles, et de vraiment s'éclater et de s'intéresser à des sujets un peu plus. High level comme on dit, un peu plus d'orientation, d'architecture et ça a quand même aussi pas mal beaucoup de valeur, donc je vous remercie aussi de partager ce podcast autour de vous. Je vous souhaite une très bonne fin de semaine. Je vous dis à la semaine prochaine. Et d'ici là, codez bien.
