Transcription

• Manu

  Bonjour et bienvenue dans le dernier clic, votre podcast tech, IA et no code. On se retrouve comme chaque semaine avec Lulu pour plonger dans les méandres de la technologie et essayer de clarifier un petit peu tout ça. Je vous préviens, on est un peu dissipé cette semaine, c'est la fin de journée, n'est-ce pas Lulu ?

• Lulu

  Oui, ça va, on va plonger dans les méandres de nos cerveaux aussi, je pense. J'espère qu'on trouvera des trucs intéressants.

• Manu

  Oui, ça devrait le faire. Peut-être un peu plus le bazar que d'habitude, il faut voir. En tout cas, on se retrouve cette semaine pour continuer un petit peu notre triptyque sur le développement. Si vous ne nous avez pas suivis, ou même si vous nous avez suivis pour vous remettre un petit peu tout en tête, Il y a deux semaines, dans un épisode Côté Outils, on avait commencé à vous présenter notre portail. Enfin, en tout cas, comment on avait créé et développé un petit peu justement notre portail qu'on utilise nous pour le podcast. Donc en gros, notre outil logiciel qui nous permet de gérer la diffusion d'un épisode, enfin la préparation d'un épisode jusqu'à sa diffusion. Et on avait parlé notamment du fait qu'on l'a développé, assisté par IA, donc en bytecoding. Et on voulait vous montrer un peu qu'il y avait plein d'étapes avant, qu'il y avait plein de choses à faire, en tout cas dans notre vision. Et voilà, que le bytecoding, c'était très puissant. Mais il fallait quand même se creuser un petit peu la tête pour essayer de faire des choses intéressantes et surtout viables pour de la production derrière, pour que ce soit utilisé par des gens par la suite au quotidien et qu'il n'y ait pas tout qui explose dans tous les sens ou pour que vous puissiez par la suite le faire évoluer votre logiciel. La semaine dernière, on a essayé de faire un petit peu...

• Lulu

  Un petit peu,

• Manu

  non. On a balancé un gros épisode par pain d'une heure 37, 37 ou 38, sur le développement logiciel. La bonne nouvelle, c'est que ça va nous permettre d'aller plus rapidement sur certains passages aujourd'hui et de ne pas toujours détailler. On y fera sûrement référence quand on abordera certains sujets et si vous voulez le détail des grandes étapes qu'il y a dans un développement d'application, de manière générale dans les boîtes. On vous renvoie à l'épisode de la semaine dernière, qui est relativement assez pertinent pour vous donner une bonne idée du sujet des différents points. Et aujourd'hui, on reprend la suite sur notre portail et nous, et on va essayer d'avancer, d'aller un petit peu plus loin sur les étapes d'après, pour vous faire un mini récap' très court de ce qu'on s'était dit l'autre fois. C'est que le portail, à la base, nous on l'a fait parce qu'on utilisait plein d'outils qui étaient un peu éclatés. Et du coup, on avait des infos un peu partout. On avait besoin de centraliser tout ça en un seul endroit pour pouvoir bosser. Et pour pouvoir justement organiser nos podcasts et les amener à bon port. Et aussi, par rapport aux différents outils qu'on avait, on ne pouvait pas avoir des invités directement qui arrivent, qui interagissaient avec nous. Ça aurait été vraiment compliqué.

• Lulu

  Déjà qu'entre nous deux, on se dit si on doit rajouter une tierce personne là-dedans, on ne va pas lui faire vivre ça.

• Manu

  C'est ça, c'est qu'il aurait fallu à chaque fois créer des trucs sur mesure pour chaque personne, en quelque sorte. Et faire comme malheureusement beaucoup de gens et beaucoup de boîtes font, de passer directement par du WhatsApp qui double avec du mail, qui triple avec du drive,

• Lulu

  qui enchaîne avec...

• Manu

  Ou les pages de la chaîne partagées. plein de... Mais quand bien, même dans la page de la chaîne, il n'y a pas forcément tout, parce que les gens n'ont pas forcément le réflexe de venir voir les commentaires, etc.

• Lulu

  C'est ça,

• Manu

  et on se dit,

• Lulu

  il y a des gens qui vont prendre le temps de venir discuter avec nous, donc c'est pour pas qu'on leur envole plus et que l'expérience soit aussi agréable que possible aussi.

• Manu

  Oui, ce qui nous a amenés à nous dire qu'on avait besoin d'un portail, d'un outil pour nous, donc vraiment un outil collaboratif pour gérer tout ça, pour permettre d'avoir aussi nos invités. Donc il y a deux semaines, on avait fait un petit récap de la différence entre un site web et une application. On était revenu sur le fait que le cœur d'une application et la base de tout, c'est de définir un besoin, de comprendre le problème de départ et de bien cadrer en fait pourquoi on va faire un programme s'il n'y a pas déjà des solutions qui existent et à quoi notre logiciel doit répondre vraiment à terme. on avait aussi parlé du coup du... PRD, notamment, ce qui est l'équivalent d'un cahier des charges fonctionnel, dans lequel on va mettre... concrètement de quoi on a besoin après pour développer notre application. Et voilà, on avait convenu du fait, enfin on vous avait raconté un petit peu qu'en fait, une fois qu'on avait tout ça, on avait fait plein d'infos, on avait déblayé un peu le terrain, on avait assez de choses pour s'attaquer au maquettage. Donc vraiment au moment où on va réaliser le premier jet au final de l'application, mais sur sa partie vraiment design et interface, donc de mettre toutes les pages et à quoi va ressembler l'application. Donc là, c'est là que Lulu intervenait. et justement nous parler de comment elle avait pensé la maquette, comment elle l'avait faite et comment elle l'avait aussi...

• Lulu

  J'avais attaqué un peu cette recherche-là pendant que tu révisais le PRD de ton côté. Et c'est pour ça qu'on va reprendre, on en était arrivé la dernière fois, la confrontation de la maquette avec le PRD, on va dire, mis à jour. Parce que là, je ne sais pas si, par exemple... Pour une prochaine application, vu que maintenant, tu as trouvé un autre process pour faire ton PRD, je pense que la maquette va quand même moins différer. Et la confrontation dont on va parler là juste après, elle ne sera peut-être pas aussi importante. Ou je ne sais pas comment tu le vois.

• Manu

  Ouais, alors, effectivement, là, en gros, le PRD, je l'avais fait avec une première méthode qui mélangeait la technique et le fonctionnel. Toi, tu t'étais basé là-dessus. tu as identifié des choses qui manquaient, tu les as rajoutées sur la maquette. Entre temps, moi j'ai repris du début en adaptant la méthode qui était dans le livre d'Alexis Kovalenko, le traité de vibe coding éclairé, et en remaniant un peu les différentes étapes à ma sauce. Et ce qui fait que quand tu m'as renvoyé la maquette, effectivement j'avais des choses qui différaient entre les deux, et notamment des choses en plus dans ta version. ou que je n'avais pas forcément pensé, ou que j'avais vu dans une deuxième version, et en fait, en les voyant à l'écran, je me suis tombé d'accord sur le fait que ce serait bien de les avoir dès le début. Il y avait quand même certaines choses que tu avais mises, je me suis dit, non, ça c'est quand même trop tôt, on le mettra plus tard. On va symboliser déjà notre... Quand on vous parle de V1 et V2, c'est vraiment la première version, l'essentiel de l'app. Et V2, c'est ce qui peut arriver dans un second temps et qui est moins critique pour les premières semaines ou les premiers mois d'utilisation. Et donc la confrontation, le principe c'est de se dire je vais prendre tout ce qu'il y a dans la maquette, je vais regarder ce que j'avais au départ, je vais faire le lien entre les deux, je vais voir ce qu'il y a en plus, ce que j'estime qu'on n'a pas besoin et on va démêler tout ça pour garder une version mise à jour du PRD et des User Stories qui reflète vraiment ce qu'on veut au niveau de l'application. Donc là effectivement c'était un cas où il y avait peut-être... plus de changements qu'il peut y avoir par la suite. Néanmoins, je pense que...

• Lulu

  au niveau fonctionnel aussi. Parce qu'il y avait des... Ça t'a rajouté un peu des user stories après, derrière ? Avec de nouvelles fonctionnalités ? Oui. Ok.

• Manu

  Oui. Toutes nouvelles fonctionnalités que j'ai ajoutées passent par des user stories supplémentaires.

• Lulu

  Et là, c'est vrai que quand j'avais regardé dans le repo, tu avais fait un skill exprès pour la confrontation.

• Manu

  Oui.

• Lulu

  Et ça, je ne sais pas, tu l'avais construit comment ? Tu étais parti avec le skill qui t'aide à construire les skills ou tu as fait autrement ? Je fais à ma méthode. Oui, ce n'était pas forcément dans le bouquin. C'était plus adapté à ce cas spécifique-là.

• Manu

  De toute façon, même ce qui était dans le bouquin d'Alexis sur l'e-logique, en gros, à chaque fois que je fais un skill, je reprends la méthode que je veux déployer. Je la détaille. J'itère avec l'IA pour la clarifier et qu'on voit un peu où est-ce qu'il y a des manques et où est-ce qu'il y a trop de choses et qu'on en fasse quelque chose de cohérent. Et après, le skill d'anthropique. Pour rappel, les skills, c'est les compétences que vous pouvez mettre en place dans l'IA, qui sont des méthodes ou des process que vous pouvez intégrer à votre IA pour qu'elle déroule votre façon de bosser, globalement. Et donc, il y a un skill, il y a une compétence qui est disponible dans le cloud qui permet de créer ces fameux skills. d'une manière structurée avec plusieurs choses, parce qu'en fait, l'avantage des skills et des compétences, c'est qu'on peut les exporter pour les passer au point. Et aussi qu'on peut les construire de différentes manières, avec des références, pour en faire des choses plus ou moins détaillées, plus ou moins complexes, avec plus ou moins d'étapes. Et en fait, non, la confrontation, je me suis posé sur les méthodes, en me disant, je veux qu'on reprenne tel point par rapport au PRD, je veux qu'on challenge ça par rapport à la maquette, que tu identifies ces différents points. En fait, ce que je n'ai pas challengé dans la confrontation, c'est la partie design. Parce que la partie design, même le responsive et même des choses comme ça, le PRD n'est pas là pour ça. Il n'est là vraiment que pour la partie fonctionnelle. et dire qu'on a besoin que l'application permette de faire tout ça. Mais quant à savoir si la maquette est parfaitement adaptée au mobile, quant à savoir si elle répond bien à toutes les normes d'accessibilité, quant à savoir si ce bouton en Ausha droite ne serait pas le mieux en bas à gauche, on s'en fout. Ce n'est pas à ce moment-là qu'on va l'ajuster. Et donc j'ai construit mon skill pour qu'il a identifié tous les points qui sont importants pour moi et qu'on voit ce qui doit être ajusté et adapté. et ajouté et vu que j'ai fait mon skill, je savais que sur la prochaine maquette que j'aurais à récupérer avant le dev, je vais la confronter dans tous les cas. Ah oui,

• Lulu

  oui, complètement.

• Manu

  Parce que maintenant que j'ai l'outil, au final, même s'il y a peu de choses à retoucher, il y en aura probablement quand même quelques... Enfin, il y a souvent moins des petits détails et des petites choses à remanier et c'est juste que ça ira beaucoup plus vite. Mais... En tout cas, à partir de là, en sortant de la confrontation, j'avais mes documents fonctionnels qui étaient tous à jour, prêts, raccords avec la maquette en termes de ce qu'on voulait.

• Lulu

  C'est vrai que moi, ce que j'avais bien aimé, parce que j'avais lu justement ce document de confrontation, et là, ce qui était bien, c'est que chaque élément qui différait entre la maquette et le PRD, c'est toi qui l'as arbitré. c'est toi qui as choisi oui, non, et c'est pas au regard du projet, Claude a choisi si ça partait en V1, V2, ou si c'était pas pertinent, ou qu'il fallait mieux garder la version maquette. Après, il y avait quand même de l'argumentation au regard du projet, mais tu avais quand même cette main où c'est toi qui décidais si on l'intégrait maintenant, si on l'intégrait pas, si ça restait au backlog pour la V2.

• Manu

  Oui, ça, comment... On l'avait déjà dit dans les précédents épisodes, mais surtout celui où on vous a parlé de notre application. L'intérêt de l'IA, c'est qu'elle l'exécute pour vous, mais ça reste à vous de piloter, d'avoir la stratégie et la logique. Et quand vous ne comprenez pas des choses qu'elle vous raconte, vous demandez de clarifier, de détailler, d'expliquer. Mais ça peut arriver de laisser des choix à l'IA parce que sur le moment, on est fatigué, on ne comprend pas trop. vas-y parce que là j'ai pas trop suivi, fais-le à ta sauce. Et qu'on se rend compte plus tard en fait qu'on n'aurait pas dû, parce que le choix qu'elle a fait ne correspond pas à ce qu'on voulait, et qu'on s'en rend compte un peu plus tard et que du coup c'est galère et ça oblige à changer des choses et à se prendre un peu la tête parce que ce qui nous aurait pris une minute à la base à juste demander une explication plus claire et à choisir en étant plus conscient de la décision se traduit par beaucoup plus de temps à la fin. à la fin parce que ça a des implications techniques entre temps il y a des choses qui ont été développées et c'est exactement ce qu'on vous disait dans l'épisode dernier plus tard vous allez prendre conscience d'un problème et d'un besoin et de devoir le corriger, enfin plus tard non, c'est un cycle de développement d'applications, plus ça va vous coûter du temps,

• Lulu

  de l'énergie et des galères pour un résultat qui sera potentiellement moins bon parce qu'il y aura des compromis à faire quand même que si ça avait été pensé au départ ouais

• Manu

  Et selon les cas, vous allez pouvoir faire mieux ou des fois être bloqué. C'est ce qu'on avait aussi évoqué en parlant de dette technique. Vous pouvez vous retrouver bloqué si vous avez fait une succession de mauvais choix ou de choix trop rapides pour aller vite à un objectif sans penser à ce qui pouvait arriver plus tard et qu'au moment où vous voulez aller plus loin, vous êtes obligé de casser tout un bout de votre application pour le reprendre de zéro. Et ça, c'est le bazar. Mais voilà, en tout cas, ça nous amène à la partie d'après, qui est le choix d'architecture. On s'en va le passer un peu rapidement, mais en fait, l'objet de cette étape-là, ça va être de définir exactement ce qu'on veut, techniquement parlant, pour développer notre application. C'est-à-dire, qu'est-ce qu'on veut pour le front-end ? Pour rappel, le front-end, c'est la partie interface. où est-ce qu'on va mettre le code qui va gérer ça et qu'est-ce qu'on va utiliser comme langage de programmation dessus c'est là où on va définir aussi le schéma de la base de données, donc se dire ok on va utiliser tel backend, pour rappel le backend c'est votre arrière boutique c'est là où vous avez la logique d'une application, où on va gérer les utilisateurs, on va gérer l'information comment c'est enregistré, comment c'est stocké on va avoir aussi toutes les règles qui vont se déclencher l'homme. vraiment quand vous allez travailler, de dire quand j'appuie sur un bouton il se passe plein de choses, mais en fait il se passe plein de choses parce que derrière c'est côté back-end. Donc ça là vous allez choisir en fait vraiment les technologies, les mots... les outils, les logiques, les langages que vous allez mettre en place et aussi comment vous allez penser la sécurité, par exemple. En fonction de tel ou tel backend, ça va être un choix stratégique ou pas. En fonction de où vous allez héberger aussi votre application, au niveau de la sécurité, ça va avoir plus ou moins d'incidence. À cet endroit-là, on ne va pas anticiper et planifier tout le... le code de l'application, ce n'est pas du tout l'objet. C'est juste de mettre, de définir tout le cadre technique sur lequel on va s'appuyer et sur lequel on va travailler.

• Lulu

  Parce que les migrations, c'est galère, Frédéric.

• Manu

  Oui, ça dépend. Ça dépend à quel moment on est amené à faire une migration. Ça dépend. Et oui, effectivement, on parlera à la fin de... Peut-être pas aujourd'hui, ça dépendra. Mais on parlera de migration, effectivement. Parce que justement, j'ai fait un choix d'architecture sur du Supabase, qui est un outil très connu et très adapté pour le vibe coding, pour héberger les données et pour gérer tout ça. Et qui marche très bien dans la version que j'utilise aujourd'hui, qui est en cloud, mais qui est un outil américain, mais qui est aussi open source et donc qui permet de l'héberger sur ses propres serveurs où on veut et comme on veut. Et ce back-end, justement, là, je suis en train de commencer une migration pour essayer de l'amener sur une version hébergée, auto-hébergée. Je reviendrai plus tard dans le détail du pourquoi, comment, et du fait que ce n'est pas moi directement qui vais gérer l'infrastructure de ça. Je veux rester quand même sur quelque chose d'encadré. Mais le choix d'architecture, ça fait aussi partie des choses, des moments où vous allez vous... poser la question de est-ce que j'utilise quelque chose d'accessible comme du lovable ou comme des outils comme ça qui sont plus simples à prendre en main est ce que vous allez être dans du vibe coding on va dire plus avancé ou vous allez vraiment du coup gérer enfin gérer vous appuyez sur des outils d'infrastructures un front end un back end mais sur lesquels vous allez devoir quand même gérer beaucoup plus de choses à la main connaissance de cause en tout cas et sachant qu'il ya un autre niveau encore au dessus c'est les comme dire c'est les développeurs et développeuses qui vont créer eux mêmes leur backend et construire la base de données et tout gérer eux mêmes mais n'allez pas là dessus si on n'est pas déjà développeurs développeuses l'avantagent des outils entre deux comme du super base comme du xano comme du bah du coup il y a corvex aussi corvex il est plus ceux d'avant mais vous avez quelques outils comme ça qui vous permettent encore en tant que personnes un peu techniques mais pas complètement développeurs et qui enfin voilà vous pouvez comprendre de la pro de la programmation visuelle et vous êtes en mesure d'interagir et de savoir ce qui se passe et de vous former sur des outils comme ça en fait l'avantagé que ces outils là ils vont vous apporter une couche de sécurité supplémentaire ils vont héberger vos données ils vont mettre en place des sauvegardes automatiques tous les jours ils vont vous mettre énormément de facilité pour vous donner un cadre alors ça n'empêche pas de faire des bêtises au niveau de la sécurité Puisque derrière, c'est vous qui faites le code. Donc, si vous faites des trous dans le code, ils ne vont pas garantir ça. Mais en revanche, le serveur tourne chez eux, il est protégé déjà de base de pleine manière, il a des soccards. C'est quand même des assistances et des choses comme ça qui sont très importantes et très utiles. Et voilà, tout ça pour dire que le choix d'architecture, il se fait à ce moment-là.

• Lulu

  Oui, vraiment, avant de commencer à... coder, c'est pas au fil de l'eau où on va dire tiens, de quoi je vais avoir besoin même de voir en termes de compatibilité entre les différents architectures qu'on va choisir. Parce que par défaut, si on se lance dans du code, Claude il va faire un fichier JS et après il y a la question qui arrive, c'est quoi ton back-end ? Ça tourne sur mon PC.

• Manu

  Mais ça c'est un bon point. justement, et Kata peut d'ailleurs parler de tes apps, parce qu'au moment du choix d'architecture, on n'est pas obligé d'aller sur du Superbase ou sur des outils comme ça en ligne pour que tout le monde y accède et tout. Tout dépend de votre app, en fait. Si ça correspond à un besoin juste pour vous au quotidien qui n'implique pas d'accès à Internet ou qui peut tourner que sur votre machine ou qui peut avoir besoin d'accès à Internet, etc. En tout cas, qui est que pour vous. vous pouvez faire des choses qui sont vachement plus douces, on va dire, moins dangereuses. Ça,

• Lulu

  mais par défaut, Claude, il ne va pas proposer, même selon l'application, parce que l'application à laquelle je pense, le but, c'était potentiellement de la... rattaché au portail, mais il n'y a pas eu ce questionnement de sur quel backend on part. Quand on lui demande c'est quoi le backend après pas mal d'itérations, c'est parfait cette question tombe à pic. Justement, il y a un fichier JS.

• Manu

  C'est ça, j'ai un fichier, tu appelles dedans, j'ai tout foutu en vrac, et puis débrouille-toi. Et voilà, ça, ça passe sur un besoin, sur un usage, tout seul sur son ordi ou tout seul à aller justement faire des manips qui ne sont pas sensibles, qui ne sont pas graves, où vous n'avez pas forcément de données, quand même, il n'y a pas besoin de sauvegarde, il n'y a pas besoin de choses critiques. Il y a plein de cas, en fait, où ça ira très bien, tout simplement. D'ailleurs, c'est comme l'application dont tu nous avais parlé il y a un moment.

• Lulu

  Ah, de convertisseur ?

• Manu

  Ouais.

• Lulu

  Oui, ça, c'était local. Et je n'avais pas besoin de plus. Mais ça, je le savais. Mais là, par exemple, l'éditeur pour générer les caroussels ou tout visuel lié au podcast à partir de la transcription d'un épisode, moi, dans l'idée, c'était de le faire pour gagner du temps, moi, sur mon PC. Et après, c'est de se dire... Ah, mais ça serait quand même vachement bien que si on appuie sur un bouton dans le portail, ça le fasse automatiquement. Et que je n'ai pas besoin d'avoir mon PC allumé pour le faire et que ça ne dépende pas que de moi non plus. Et pourquoi pas que les invités, quand ils viennent sur le portail, puissent aussi générer les visuels pour communiquer sur l'épisode dans lequel ils ont été invités. Et là, je sais que le projet, je le vois plus comme un prototype parce que ça sera impossible de revenir au départ pour le refaire proprement. partir presque de zéro dans ce cas-là. En tout cas, je pense. Ça sera mieux.

• Manu

  Le backend, c'est sûr. Sur le frontend, non. Ça permettra de garder déjà toute l'interface, toute la partie visuelle, toute la logique. Mais oui, ce sera un proto. De là, on va pouvoir en déduire les fonctionnalités dont on a besoin. Le cycle dont on a parlé jusqu'à présent, on va le refaire, mais en ayant déjà la Mac à ta disposition parce qu'en fait, tu auras conceptualisé et itéré et développé. ce que tu voulais en termes de besoins, en termes de tout ça, tu l'as fait directement en codant.

• Lulu

  Oui, et puis en soi, ça marche sur mon PC. Je pense que je vais l'utiliser au début, moi de mon côté, pour l'affiner et qu'on puisse vraiment, quand on va commencer le vrai développement, pas vraiment notre faux et de vrai développement, mais quand ça sera en vue de l'intégrer au portail ou pour utilisation à plusieurs personnes, ça sera de... vraiment prendre en compte tout ça mais d'arriver avec quelque chose où je ne vais pas me dire ah bah tiens c'est vrai que ça serait mieux comme ça ou alors c'est vrai que des contrôles Z c'est pratique. Je ne sais pas comment ça va être fait en back-end, ça va être marrant.

• Manu

  Il ne faut pas me laisser développer. Ça dépendra si ton contrôle Z a besoin qu'il affecte les autres ou pas. Aujourd'hui tu ne l'as que en front de toute façon, ce qui ne te concerne que toi.

• Lulu

  Je pense que ça peut suffire. Après, dans l'idée, ça serait même de presque plus avoir d'interface. Là, je m'en sers pour moi itérer et voir, mais d'arriver au maximum avec une automatisation et utiliser l'IA le moins possible. Mais là, pour la partie itération, c'est bien, mais après, d'arriver sur quelque chose de très déterministe, qui vient juste remplir des cases sur mon image. Il n'y a pas besoin de régénérer, d'utiliser de l'IA. et déjà le... En soi, le petit logiciel que j'ai fait, c'était pour ne pas avoir à utiliser de l'IA à chaque fois, pour refaire des visuels qui partagent un même template. Et là, ça peut déjà presque tourner sans l'IA et c'est trop, trop cool.

• Manu

  Oui, parce que pour... Je j'en vois un peu. En gros, typiquement, quand on parle de template, on parle de modèle. Donc là, pour le coup, un modèle visuel. Donc, comme un... Un peu comme les images que vous avez quand on diffuse les épisodes du podcast que vous pouvez avoir sur YouTube ou sur votre lecteur de podcast. Et Lulu avait fait un carousel notamment sur LinkedIn justement avec plusieurs images, avec du texte, le carousel était très joli, avec plein de diapos différentes et des approches différentes. Et là le concept est temps de se dire, par exemple dans un outil comme Katva, j'ai ce modèle-là qui est disponible, mais je vais aller modifier à la mano chaque bout. changer du texte ou éventuellement choisir plutôt tel ou tel visuel ou tel ou tel effet. Et là, c'est qu'en gros, tu t'es fabriqué toi-même ta collection de modèles. Enfin, tu les as récupérés depuis Canva pour les mettre comme ça là-dedans.

• Lulu

  Ah, j'ai pas utilisé du tout Canva. pour le carousel.

• Manu

  Oui, mais tu les avais créés avec quoi ? Avec Cloud Design ? Oui.

• Lulu

  D'accord. Enfin, à partir d'un spi, de trucs que j'avais presque dessinés à la main. C'était de me dire, tiens, je suis repartie pas mal du proto que j'avais fait pour le site web et presque utiliser différentes parties du site web, mais transformé en carousel pour avoir une certaine cohérence pour quand on fera le site web. Mais c'était dans Cloud Design. et ça avait été une purge pour avoir un PDF. Je me dis, OK, pour la première fois, pour faire mes itérations, pour me dire, tiens, là, j'ai effectivement trois transcriptions d'épisodes parce qu'en plus, on en a annoncé trois d'un coup. De me dire, là, j'aurais un bon panel de possibilités. Mais il y a des moments où j'aurais envie de changer le fond et je veux pouvoir l'éditer à la main parce que là, c'est trop coûteux en énergie, en token. Enfin, juste... pour changer et je me suis dit là je sais j'ai un exemple, à partir de cet exemple je vais générer différents templates et l'idée c'est de les modifier directement et de pourquoi pas avoir un format JSON à partir de la transcription d'un épisode et de se dire tiens pour telle citation c'est tel slide qui correspondra le mieux donc on remplit enfin voilà c'est... C'est un peu l'idée pour le moment.

• Manu

  Pour finir sur la représentation visuelle que vous pouvez vous en faire, c'est de vous dire que vous avez plusieurs choix de diapos. Vous en choisissez une et après, vous avez juste des petites flèches qui vont vous permettre de cliquer pour changer d'une variante à l'autre, pour changer des logos, des bouts, des emplacements, changer de la couleur, changer de la profondeur.

• Lulu

  Mais vraiment personnaliser pour le dernier clic.

• Manu

  Et comme ça,

• Lulu

  relâcher les couleurs. Et ce que j'aime bien, c'est que là, je sais que j'ai que ce qu'il me faut. Parce que sinon, dans Canva, on peut perdre énormément de temps à essayer plein de trucs. Là, au moins, ça me permet de me concentrer plus sur le contenu et de me dire OK, la mise en forme, elle est bien. Je l'ai déjà testée, je l'aime bien. Je peux changer quand même un peu mon fond, mais c'est quand même trois fonds parmi celles que j'avais itérées sur le site web. Donc, ça permet de rester un peu focus.

• Manu

  Oui, en fait tu as fait ton propre outil no-code, donc vraiment ton propre outil de programmation visuelle, parce qu'à la fin tu ne fais qu'agencer et gérer justement des... Parce que tu peux rajouter des blocs, tu peux rajouter... J'ai vu que tu avais des ajouts de...

• Lulu

  Et ça tourne sur le PC en local, tout seul, il n'y a pas besoin d'aller en ligne, machin, enfin voilà, là je peux le faire tout seul, c'est trop bien !

• Manu

  Oui, tu as ton propre outil sur mesure... Oui,

• Lulu

  c'est trop bien !

• Manu

  Mais bon, tu veux quand même le brancher au...

• Lulu

  Je me suis dit, ça serait cool quand même.

• Manu

  Tu veux quand même le brancher au bout du monde. Oui, parce que tout à l'heure, tu parlais de JSON. Pour celles et ceux qui n'ont pas en tête, en gros, c'est ce qui va nous permettre après d'exporter des informations ou d'alimenter justement ce petit moteur de template de manière automatisée, de manière programmatique. Donc, ce soit avec des automatisations ou avec du code, de se dire, ben voilà, là on a... on peut lui envoyer les infos qui arrivent typiquement, par exemple pour les citations, c'est de se dire, on a un transcript de nous qu'on récupère déjà dans la plateforme, et on va demander à une toute petite IA d'aller identifier les citations les plus intéressantes pour un invité ou une invitée, et après la personne pourra choisir parmi les différentes citations celle qu'elle veut garder pour mettre sur un des templates disponibles, et elle pourra mettre sa photo. quand tu voulais mettre ça. Oui,

• Lulu

  pour modifier aussi avec l'effet un peu du automne, aussi en magenta. Donc là, c'est un autre outil qui va arriver peut-être.

• Manu

  Oui, tu vas te calmer sur les outils. Petit à petit, parce qu'on est déjà deux à rajouter avec tes histoires. Celui-là, je ne sais plus ce que c'est l'autre, mais il y en a deux.

• Lulu

  Oui, si je t'ai fait une démo juste avant. Pour modifier les couleurs des images, enfin, de trucs.

• Manu

  C'était un autre ça ? Je mélange les deux.

• Lulu

  Oui, c'était un autre encore. Pour modifier les images en mode peinture plus ancienne et les raconter dans la couleur.

• Manu

  Oui, celui-là, il est plus pour créer des images dans la palette graphique, des assets, qui pourront servir après à l'autre générateur de templates.

• Lulu

  C'est ça, ou pour mettre sur le site internet. Si on met les portraits, ça serait avec ce duotone des couleurs du dernier clic.

• Manu

  Et voilà, je ne vais pas, pour chaque invité, le faire à la main. Et je me dis, ça peut être cool qu'eux puissent mettre leurs photos. Il y a un détourage aussi automatique. Et puis, ça met directement les bonnes couleurs. Et après, ils peuvent avoir leurs petites citations. C'est prêt à publier. C'est cool. Et voilà, un jour.

• Lulu

  Oui, un jour. On va déjà migrer le Superbase là. Et faire l'API.

• Manu

  Et après...

• Lulu

  L'API... Oui, bon ça l'est On a déjà identifié, mais oui. Alors, on enchaîne. Après tout ça, on a fait un petit détour en parlant d'architecture. On est parti sur un peu tout ça. L'étape d'après, très simple, c'est que je fais un audit avant le développement. Le principe de l'audit, sur le portail du dernier clic, j'avais fait cinq passes de relecture. Alors, pas que tout seul, avec l'IAV aussi. Là, normalement, j'ai calibré le skid pour descendre à trois passes la prochaine fois. Mais en fait, l'idée de cette étape-là, c'est de reprendre tous les documents qui sont déjà prêts, donc le PRD, les user stories, et aussi les autres documents qui ont été déjà identifiés. Enfin, parce que, bref. Allez écouter l'autre épisode, on ne va pas tous le refaire maintenant. Mais de se dire, ok, maintenant qu'on a travaillé là-dessus, il y a probablement, vu que ça fait pas mal de matière, si l'application est un peu solide, il commence à y avoir déjà un... un certain nombre de choses. Il y a probablement des détails, des choses qui ont pu échapper à la vigilance et notamment à travers la confrontation aussi, parce qu'entre-temps, il y a eu le passage maquette. Et donc l'audit avant le développement, il sert à ça, à aller relire tout, identifier où est-ce qu'il y a des incohérences, à trancher sur ces incohérences pour dire, dans tel document, on dit que la personne doit pouvoir faire ça au moment de la diffusion d'un épisode. Mais dans l'autre document, on dit que l'invité, il ne peut pas interagir sur la jaquette de fin, par exemple. Et là, pareil, on va trancher à nouveau. On va reprendre les décisions et on va revalider. Et le but, c'est qu'à la fin de cette phase, tout soit cohérent, que tous les documents soient cohérents, qu'il n'y ait pas de trou, qu'il n'y ait pas un réglage A qui devient un truc B à un autre endroit, alors que c'était censé être logique. d'avoir quelque chose de sain et de pré-odave globalement. Il reste un petit truc quand même avant d'attaquer le développement, c'est le cahier de recettes. Le cahier de recettes, on en avait déjà parlé aussi. L'idée étant de se dire, chaque fois qu'on a identifié quelque chose qui doit être dans l'application, on fait un scénario de test en face et le cahier de recettes, ça va être en gros un cahier qui va recenser de manière détaillée tous les tests à faire, tous les scénarios de tests à faire. par rapport à toutes les user stories, etc. Et voilà, je crois que sur les étapes, avant le développement, on n'est pas mal. Ça ne nous aura pris qu'un épisode et demi, trois quarts. Voilà. Donc maintenant, vous êtes prêts à développer ? C'est formidable.

• Manu

  Enfin.

• Lulu

  Enfin.

• Manu

  On est loin du... Fade up qui... Voilà, le mini prompt. Il s'en est passé des choses, quand même.

• Lulu

  Toujours pareil, ça dépend de ce qu'on veut faire. Parce que toi, sur les apps dont on parlait, il y en a normalement une ou deux, celle que tu as utilisée en local sur les templates, tu es partie de l'idée du concept et tu as créé un peu en même temps.

• Manu

  Oui, complètement. Et je me dis, mais ça aurait été trop lourd de passer par toutes ces étapes-là pour faire, parce que je voulais juste voir. Et avoir un petit truc, même en local sur mon PC, qui me permettrait déjà de... Enfin, pas forcément d'automatiser, mais de voir les choses qui se répètent et de pouvoir au moins gérer ces parties-là. Et après, c'est quand je vois les possibilités, c'est le côté visuel qui me plaît bien. Et je pense que je n'aurais pas du tout été jusque-là si j'avais dû me poser sur des specs, sur le PRD et tout ça. C'est plus j'ai une idée, je l'attente. En plus, ça me sert parce que j'identifie un besoin et on verra après si ça vaut le coup de l'amener plus loin ou pas. Mais déjà, en l'état, je peux m'en servir et c'est cool. Il n'y a pas forcément besoin de partir dans de l'over-engineering non plus parce que ça, c'est un autre piège. Et voilà, si c'est fait pour tourner sur mon PC, non, ce n'est pas forcément nécessaire. C'est les différentes catégories qu'on avait évoquées dans tous les cas.

• Lulu

  Oui, parce que même si tu ne les as pas formalisés, que tu n'as pas fait le PRD et tout, tu étais quand même passé par toutes les phases de se dire « Ok, j'ai besoin de ça, j'ai identifié que j'avais… » Tu avais quand même un certain nombre de choses en tête avant de t'attaquer au dev. Et tu avais déjà identifié que de toute façon, là, ce que tu allais faire, c'était que pour toi, en local, sur ton poste, sans conséquence de base. Oui,

• Manu

  c'est vrai que je suis arrivée avec mon modèle de carousel aussi, parce que sinon, s'il avait fallu que je développe et qu'en même temps, je réfléchisse au design, ça n'aurait pas été possible. C'est pour ça que je me dis, on va déjà travailler sur le matériau qui doit sortir. Et à partir de là, je sais ce que j'ai en entrée, je sais ce que je veux en sortie. Et je fais la machine au milieu.

• Lulu

  Mais par contre, ça, ça va très bien justement tant que tu l'as fait pour toi. Mais au moment où on va basculer ça pour l'intégrer au portail...

• Manu

  Ah oui, là, je sais que c'est autre chose.

• Lulu

  Je vais le repasser par toutes les étapes qu'on a dites, même si ce sera... Du coup, il y a des étapes qui vont aller très vite, puisque justement, on aura un vrai prototype déjà de base. et qu'il y a des choses d'architecture, par exemple, qui sont déjà faites, parce que le portail existe déjà. Il y a déjà des fonctionnalités qui sont déjà en place pour la partie gestion des droits utilisateurs et tout. Mais du coup, je vais quand même devoir passer par ces étapes pour l'intégrer à l'existant, pour que ce soit cohérent avec ce qu'on a en place au niveau des invités, au niveau de nos autres fonctionnalités et nos autres besoins.

• Manu

  Mais oui, c'est vrai que c'est plus pertinent de pousser ce proto, limite de moins l'utiliser, un petit peu, sur quelques épisodes, lorsqu'il peut être ajusté. Et les étapes après iront d'autant plus vite et le développement sera d'autant plus précis et pertinent parce que j'aurais modifié des trucs en local sur ma machine, sur mon petit proto, et de me dire, finalement, ça, je n'en ai pas besoin. Là, le but, ça va être aussi de la simplifier au maximum pour garder que ce que j'utilise dans l'outil.

• Lulu

  Complètement. Et donc, si vous n'êtes pas dans le cadre, justement, d'une app en local à tester pour vous et à itérer, à garder... Parce que voilà, comme on disait, ton app à toi en l'état, elle ne serait pas basculable directement. Par exemple, pour le backend, il y a tout à faire, il y a tout à construire. Si on voulait y mettre des utilisateurs dessus, sur le front, du coup, il tourne chez toi parce qu'il est dans ton navigateur. Mais pareil, si on voulait proposer à des gens, il faudrait l'héberger, il faudrait le mettre en œuvre. Et là aussi, il peut y avoir des choses côté sécurité à mettre en place. Mais du coup, quand vous en arrivez là... dans le cadre de l'application un peu plus costaud orientée production pour plusieurs personnes on attaque le développement je veux bien d'ailleurs que tu nous dises toi un peu comment tu comment tu décrirais le vibe coding dans le sens tu vois les mécanismes quand tu vas justement coder,

• Manu

  comment ça se passe comment est-ce que moi je développe quand je me dis, tiens, je veux me faire un petit outil. Je pense que je passe par toutes les phases-là, mais un peu en express. Me dire... Non, oui,

• Lulu

  je ne parlais pas des phases avant, mais vraiment là, quand tu es dans... Ça y est, tu ouvres... Dans le flot. Claude Cote, pardon. Tu sais ce que tu as, et que ce soit tes petites appels ou quoi. Le moment où vraiment tu vas dire à Claude, OK, voilà, développe-moi ça, c'est parti. Comment tu le...

• Manu

  C'est plus ou moins ça.

• Lulu

  Oui. Mais tu les mets quoi dans ton prompt de départ, dans tes consignes de départ ? Comment tu les gères ?

• Manu

  Alors là, par exemple, le carou, c'était un petit peu plus complexe parce qu'en plus, j'ai envoyé de Cloud Design vers Cloud Code le projet. Même ça, il avait quand même le HTML et tout, donc il pouvait travailler là-dessus. Sinon, plus petit projet, je vais rapidement décrire mon problème, dire j'ai ça, je veux ça. notamment là pour l'éditeur d'images j'ai mis, alors ça c'est l'image que j'ai en entrée, ça c'est celle que j'ai travaillée à la main en sortie, j'ai modifié ça j'aimerais bien un outil qui me permette de jouer sur ces paramètres là et tout ça,

• Lulu

  et fait et après quand tu fais ça, tu le laisses en roue libre en automatique ou tu acceptes j'accepte manuellement

• Manu

  quand même. Les actions qu'il fait. Je ne suis pas passée en full auto.

• Lulu

  Alors, sachant qu'il y a deux stades de route. Il y a le automatique où il s'arrête pour les choix importants ou destructifs ou dangereux. Et il y a le full auto, j'ai envie de dire défaut, tu vois, parce que jamais je ne ferai un truc pareil. Et d'ailleurs, on entend de temps en temps, et là, depuis que le dernier GPT, le 5.6, s'est sorti, on a eu deux... Deux grosses histoires, il y en a eu plusieurs, mais il y en a eu deux grosses histoires justement d'IA qui font Nawak quand elles sont même en mode les plus intelligents et en mode complètement automatique. Il y en a une qui avait littéralement écrasé tout le contenu du PC d'un temps.

• Manu

  Oui, c'est Alexis qui en a parlé dans sa dernière note vocale, c'est ça ?

• Lulu

  Oui, du coup, ils ont été un peu relayés. Pas que lui,

• Manu

  mais oui.

• Lulu

  Les deux techs étaient assez... C'était deux pointures, tu vois, un peu. Mais même comme ça, en fait, ils font confiance à l'Ika, ils mettent en ultra et ils mettent en full automatique. En full automatique, en gros, il y a... même si c'est dangereux, même si c'est destructif, mais machin, c'est littéralement le mode outrepasser les permissions et s'arrêter que quand la terre brûle.

• Manu

  C'est plus ou moins ce qui se passe en soi là pour l'instant, même sans passer en mode auto, mais on ne va pas revenir là-dessus.

• Lulu

  En tout cas, voilà, les accidents que vous entendez sur des bases de production qui ont été écrasées, sur des informations qui ont été perdues. Alors ça peut arriver même sur des modes de réglage inférieurs, et même en automatique pas destructif, des fois elle peut se rater en faisant des mauvaises manips, ou créer des failles de sécurité, ou faire des choses comme ça. Mais le mode à fond, sincèrement, il est complètement déconseillé, parce que c'est dans ces moments-là où, si vous n'êtes pas vigilant en permanence, mais normalement si vous mettez ce mode-là, c'est que vous n'êtes pas vigilant en permanence, qu'elle est en mesure de détruire des informations, et que si vous n'avez pas... mis en oeuvre ce qu'il fallait pour avoir des sauvegardes et que vous n'êtes pas en mesure techniquement de rattraper le coup, des fois c'est perdu, perdu. Et donc, entre le auto et le mode que tu as là où tu acceptes chaque action, il y a quand même un mode qui permet de planifier aussi.

• Manu

  Oui, oui.

• Lulu

  Et sachant qu'après, tu n'es pas obligé de rester sur le mode planification parce qu'en fait, en auto, si tu te prépares tes propres skills de logique de développement, tu peux lui instaurer des méthodes de travail où elle va systématiquement lire, prendre connaissance de telle ou telle information, le fameux hardé dont on parle de temps en temps. On est pour dire très simplement, vous renseignez si jamais vous êtes sur du white coding, mais ça va être un peu le cadre global que vous allez donner à votre IA et qui va définir autant le contexte que les garde-fous, les limites, le cadre vraiment de ce qu'elle peut aller lire, comment elle doit le lire, et qu'est-ce qu'elle peut faire, et jusqu'où. Et donc, on peut mettre en place, même dans des modes automatiques, un système de routine et de méthode et de process. Typiquement, tu vois, je n'utilise plus le mode plan depuis le moment. Et parce qu'en fait, elle m'en fait systématiquement un dans le cadre de mon mode auto et dans le cadre de... J'ai un skill, en fait, pour qu'elle suive toujours un process pour chaque PR. Les PR, c'est pareil. Vous irez écouter l'épisode d'avant sur les pull requests. On explique.

• Manu

  Non, mais après, moi, quand c'est de la... petite application comme ça, je me... Je veux assez vite arriver à quelque chose que je peux... Un proto dans lequel je peux un peu bouger. Et presque après, là, je vais itérer par rapport à ça. Donc là, je pense qu'on est plus dans du vrai vibe coding. De se dire, bon, bah, j'ai un truc visuel. Je dis, ah bah non, ça, je l'imaginais pas comme ça. Ou alors ça, ça m'embête quand j'essaye d'utiliser et d'itérer comme ça, quand c'est vraiment du petit projet et que... Ouais, juste voir si c'est... faisable et que ça vaut le coup d'aller plus loin, de prendre plus de temps. Sinon, pour des plus grosses... Enfin, j'ai aussi une autre idée d'application et là, j'en suis plus à définir les specs et tout ça, mais là, j'utilise vraiment des skills que j'ai... On en a déjà parlé. Enfin, voilà, que j'ai pas encore éprouvés et qui bougeront au fur et à mesure de comment je vais développer. Mais là, pour l'instant, je me concentre plus sur le design maquettage. Donc, partie code, c'est plus j'ai ça en entrée, je veux ça en sortie. C'est un peu quoi le meilleur moyen et le plus efficace pour convertir ce que j'ai en entrée pour avoir ce résultat-là en sortie.

• Lulu

  Ok. Oui, parce que tu crées ton homme vraiment au fil de l'eau. Et du coup, pour faire un peu le parallèle avec justement le cheminement qu'on a fait vraiment pour la partie portail et le fait d'avoir... séparer tous les documents. Ça fait que quand on arrive au dev, on a une logique qui est différente. À travers justement le PRAD et tout, en fait, on avait déjà identifié des lots. Donc à chaque lot correspondait un ensemble de fonctionnalités qui correspondaient à un certain nombre de choses qu'on devait pouvoir faire dans l'application. Par exemple, il y avait un lot qui était sur l'authentification, donc le fait de pouvoir se connecter, modifier son mot de passe, de déconnecter, de recevoir des mails en cas de pépin, tout ça. Il y avait un lot qui allait être le fait de pouvoir... créer un épisode et de le gérer donc avec différentes étapes avec le fait de pouvoir mettre une trame etc il y avait un autre lot qui allait être sur le fait d'ajouter des ressources enfin bon il va y avoir plein de lots comme ça qu'on va qu'on va découper. Et ce qui fait, quand on arrive au moment de développement, on va dire, enfin, il y a un truc avant l'histoire du lot, ça va être de mettre en place l'architecture technique réellement. Donc au début, on va initialiser le cœur de l'infrastructure, on va dire ça comme ça, et on va commencer déjà par dire bon, ok, là, j'ai mon dossier de travail, mon repo, dedans, j'ai déjà mis ça et ça, maintenant... tu vas m'installer tous les langages qu'on a dit, toutes les bibliothèques dont on a besoin, tu vas organiser les dossiers, les documentations, répartir vraiment, créer tout le squelette organisationnel de notre code et de nos documents. On commence par faire ça, on valide, et après justement on attaque le développement des lots. Et après, dans le développement de chaque lot, on va aller, ça il y a plein de techniques qui vont varier. entre ceux qui vont aller découper à chaque user story pour en faire une pull request, donc vraiment un truc versionné, cadré, etc. qui va être défini. Il y en a qui vont faire plusieurs choses comme ça en une seule session. Il y en a qui vont prendre un gros modèle et faire bosser les petits modèles. Il y en a qui vont bosser qu'avec les gros modèles. Enfin bon, plein de choses, et c'est pas l'objet là de... Encore une fois... plein de sujets, et notamment aller voir du côté du table d'Alexico Valenco, il y a plein de ressources là-dessus. Mais ce qu'il faut garder en tête, c'est que la logique qu'a décrit Lulu, vous allez la voir de manière plus structurée quand on a déjà tout le cadre, mais ça va être de dire au début, en fait, ok, on va attaquer le développement du premier lot, tu t'appuies sur tous les documents qu'on a déjà à disposition, et à partir de là, il va faire un plan d'implémentation et au moment où il va faire le plan, il va aussi identifier tous les points qui ne sont pas clairs et sur lesquels il faut trancher. De là, on va répondre aux questions, on va dire voilà, je veux ci, ça, ça, comme ça. Et quand on ne sait pas, on lui demande de clarifier les différents points. Et après, il va dérouler son plan d'implémentation. Et c'est là qu'il est très important de garder ça à l'œil. Parce qu'en fait, juste l'essayer à tourner et partir faire autre chose, ou en lancer plein en même temps et la laisser se débrouiller, c'est le meilleur moyen de se retrouver avec des gros pépins, des petits ou des gros pépins. Parce qu'en fait, Lya, elle va essayer d'atteindre son objectif et de suivre son plan d'implémentation jusqu'au bout. Et quand il y a un truc qui ne se passe pas bien, elle va improviser. Mais si vous ne lisez pas ce qu'elle fait, vous ne verrez pas les moments où elle a improvisé et qu'elle a pris des décisions que vous ne vouliez pas, ou qu'elle a eu la flemme d'aller au bout de certaines choses, et voilà, qu'elle va acter littéralement, elle va prendre des décisions pour vous et se dire « Non, mais en fait, j'ai jugé ça superflu. » « Non, ça, ce n'était pas vous. » « Non, ça, en termes de sécurité, on verra plus tard. » Et vous aurez systématiquement des choses comme ça, et même en suivant, et où il faut la reprendre. Et Claude, pourquoi tu n'as pas voulu finir la fonctionnalité ? Et ça, pourquoi tu as eu la flemme de mettre la sécurité ? Et ça, pourquoi tu l'as fait de telle manière ? Et ça, pourquoi ces trois points, tu ne les as pas traités alors qu'ils étaient dans le plan et que ça s'est bien passé, donc tu aurais dû aller au bout du truc. Et voilà, en fait, vous allez avoir plein de cas comme ça. Et ça,

• Manu

  c'est inhérent à la technologie. Ça, on peut renvoyer à l'épisode où... décrit vraiment le fonctionnement des LLM, des grands modèles de langage. Vu que c'est génératif, on peut mettre autant de garde-fous qu'on veut, il y a toujours un risque. Ce n'est pas déterministe. On renvoie à l'épisode qui explique tout ça et de comprendre comment la techno marche, ça montre qu'on ne peut pas juste faire confiance à 100% des choix qui vont être faits. Et il y a plein de choses qui vont passer à la trappe. Et encore une fois, on va rajouter des fonctionnalités, on va continuer le développement. Puis, il y a un moment, ça ne marchera pas. Ou mal. Ou alors, il y aura des fuites de données. Et ça vient d'où ?

• Lulu

  D'où le fait que, bon voilà, dans votre déroulé, dans les plans à chaque fois qu'il faut, il y a ça. Et moi, ce que je vous recommande très, très, très, très, très, très, très, très, très vivant, dès le début, même sur des petits projets, c'est de mettre des tests là-dedans. Et les tests... On a détaillé dans l'épisode précédent un peu les différents types de tests que vous pouvez avoir. Mais là, pour les résumer rapidement, on va voir les tests unitaires. On va vraiment tester chaque pièce, chaque bout de code, une fois qu'il est fait et qu'il doit accomplir tel résultat de transformer A vers B. On met un petit bout de code qui va vérifier que, oui, quand on fait ça, ça transforme bien A vers B. Et on va voir des tests de sécurité. Par exemple, si vous utilisez du Super Bay, c'est des tests sur la planète dits de RLS, qui vont être là pour s'assurer que les règles de sécurité sont bien appliquées et qu'un invité ne peut pas avoir les mêmes droits qu'un administrateur. qu'une personne ne peut pas voir le contenu ou le profil d'une autre personne, qu'elle ne peut pas aller modifier le mail de quelqu'un d'autre, ce genre de choses qui est hyper important, parce qu'en fait c'est de là que peuvent naître des gros pépins de sécurité, de failles de sécurité, de perte de données, de vol de données, de choses qui vous mettent bien dans le côté. Vous allez voir les tests dits end-to-end, de bout en bout, donc là c'est vraiment les tests... d'interface en fait, où il y a des outils qui sont là pour reproduire un comportement d'utilisateur humain en train d'aller cliquer, de faire des actions, et de voir si ça fait le résultat prévu ou pas.

• Manu

  Tu utilises quoi d'ailleurs comme outil qui est assez connu ?

• Lulu

  Playright, je ne crois jamais le dire correctement, mais voilà, un outil qui marche très bien.

• Manu

  Oui.

• Lulu

  Enfin, alors... Si vous développez avec, je vous recommande très très vivement, je ne sais plus si c'est un skill officiel ou pas, je ne crois pas, mais mon cloud galérait beaucoup à rédiger les tests de justement end-to-end. Et en fait, j'avais plus de bugs sur la rédaction des tests que de bugs de logiciels. Mais vraiment, beaucoup plus. Parce qu'après, c'est un peu sensible en fait, la partie interface, forcément. Déjà en temps normal, même des équipes QA, ce n'est pas forcément la tâche la plus évidente d'aller coder ces parties-là. Mais du coup, pour l'IA, ça est encore moins clair, on va dire. Et en plus, en fonction des bouts d'interface et des choses qui sont cachées derrière, du coup, il y a des bonnes pratiques, il y a des techniques, il y a des choses à avoir en tête. Et notamment le fait que, par exemple, quand il va cliquer sur un bouton, en fait, ça va déclencher une action. Et s'il programme le deuxième clic trop tôt, du coup, ça crée un bug dans le scénario, parce qu'en fait, juste l'action n'a pas eu le temps de se dérouler en entier. par exemple cliquer sur un menu déroulant et que la partie suivante du test soit de cliquer dans le deuxième objet du menu déroulant, en fait, s'il n'a pas eu le temps de s'ouvrir, du coup, parce qu'il y a une animation, par exemple, comme ça, du coup, ça crée un bug. En fait, c'est juste un bug de test. Le comportement côté code, il va bien. Et donc ça, si vous utilisez du playwright, il y a des skills très bien. Il faudrait que je regarde, ça fait un moment que je l'ai mis. Je sais que moi, le fait d'utiliser un skid justement qui était renommé côté communauté, je ne sais plus s'il était officiel ou pas, m'a radicalement changé la rédaction des tests.

• Manu

  C'est intéressant ça. Je ne suis pas encore allée jusqu'à ce stade de développement vu qu'apparemment, il y a déjà cet autre côté maquette et prototypage. Mais je pense qu'on pourra mettre ça dans la description parce que ça peut intéresser. les personnes qui nous écoutent.

• Lulu

  Oui, et d'ailleurs, de la même manière, si vous utilisez des outils, enfin de plus en plus aujourd'hui, les outils officiels, par exemple, Supabase vous propose des skills officiels qui permettent du coup à l'IA d'aller, en gros, de savoir déjà un peu, d'aller consulter la documentation au bon endroit, de savoir un petit peu ce qu'elle peut faire ou pas dans l'application, d'avoir des logiques sur les trucs qu'elle peut interagir, il y a des bonnes pratiques. Enfin, voilà, c'est vraiment un atout. Sur les outils que vous utilisez pour développer, ou les outils que vous utilisez tous les jours, on va avoir des skills officiels et hyper pertinents. Et voilà, juste pour terminer sur cette partie-là des tests, mais du coup, un des garde-fous possibles pour vous assurer que l'IA ne fait pas n'importe quoi, c'est de mettre en place tous ces tests-là à chaque développement de fonctionnalité. Et parce que du coup, après avoir codé, elle va mettre ces tests-là et elle va les vérifier. Et c'est là où elle se rend compte quand il y a des... bug soit du scénario de test, mais aussi quand il y a des bugs tout court. Parce qu'en fait, si un test ne marche pas, il faut bien voir pourquoi il ne marche pas. Et ça permet de déceler des choses que vous auriez pu déceler vous en testant à la main et en cassant le truc, mais du coup qu'il aurait fallu remonter à l'IA. Alors que si vous le faites en automatique sur le moment, en tout cas, je ne pense pas parce qu'il y a des tests automatiques que vous n'allez avoir aucun bug et tout va bien se passer. Mais en tout cas, ça en couvre déjà une immense quantité. Et pour vous donner juste une échelle du nombre de tests qu'on a aujourd'hui, Je vous donnais les chiffres sur la version 1 du portail et ensuite sur la version 2. Pas aujourd'hui, parce que là, on arrive sur la fin de cet épisode et on vous racontera la suite la semaine prochaine. Pour la V1, c'était à mi-juin. Ça devait faire un mois qu'on avait l'application en prod, un truc comme ça.

• Manu

  À peu près, oui.

• Lulu

  Je crois que je l'ai sortie en mi-mai. Moi, je pensais mimer qu'elle était en ligne complètement.

• Manu

  Oui, mais moi, je continuais de bosser sur une version de test. Tu ne m'avais pas filé la bonne URL.

• Lulu

  Non, tu étais sur la bonne version, tu n'étais juste pas sur le bon... Oui, tu avais presque tout de bon, en fait, globalement. C'est juste que l'URL que tu avais ne passait pas par les bons droits à certains endroits. Mais tu avais déjà la version...

• Manu

  Oui, Mais il y a des trucs que je ne pouvais pas faire.

• Lulu

  Oui, mais effectivement, il y avait des trucs de sécurité que je n'avais pas mis sur notre environnement. Parce qu'en gros, on avait... C'était une version de prod, mais temporaire, qui n'était pas branchée sur notre domaine, qui n'était pas avec la bonne URL, etc., mais qui nous permettait de voir l'évolution au début. Vu qu'il n'y avait que nous deux, je pouvais avoir une version de prod qui était disponible pour Lulu. Moi, j'avais de toute façon des versions avant. C'est juste un mot sur les environnements de preview. On a parlé encore une fois la semaine dernière des environnements de test. Allez écouter l'épisode, on raconte tout ça. Mais du coup, dans mon cas, ce que je fais, c'est que j'ai un environnement... de preview, parce que Supabase permet d'avoir ce qu'on appelle des branches. Donc en gros, quand je code, au moment où le code est prêt, il va, ce qu'on appelle provisionner une branche, donc en gros il va créer un environnement provisoire et de test avec le moteur de Supabase, sur lequel on va pouvoir tester ce qui vient d'être fait, et c'est un environnement qui est comme celui de production. L'intérêt justement d'avoir cet environnement de preview, c'est qu'il est en ligne, il est avec les mêmes paramétrages et tout. Il n'y a pas les données à proprement parler, mais toutes les règles, toute la configuration, tout ça de notre production, c'est répliqué. Et sauf que ça dure le temps que la branche est active, donc on va faire le développement, on va faire tous les tests, et une fois que notre fameuse pull request à notre PR est terminée, tout ça, ça se ferme, la branche est supprimée, et basta, on n'en a plus besoin. Mais au moins, tous les tests, tout ce qu'on a fait pour casser et pour vérifier l'interface et tout. C'est fait sur un environnement comme ça, dit de preview. Donc qui correspond à un environnement de pré-production, en quelque sorte. Et pourquoi je disais tout ça ? Je ne sais plus.

• Manu

  Parce que je devais être sur une version comme ça ?

• Lulu

  Ouais, non, c'est qu'en fait, moi j'avais ces environnements de preview pour faire mon paramétrage, mais du coup je t'envoyais en production, vu qu'il n'y avait que nous deux.

• Manu

  Oui, puis tu voulais montrer. Enfin, moi, je voulais voir aussi ce que ça donnait.

• Lulu

  Petit à petit, même quand ce n'était pas forcément tout terminé. Essayons de te connecter.

• Manu

  Ça marche. Ah non, ça n'avait pas marché parce qu'il y avait des astérisques dedans et tu m'avais envoyé le mot de passe par Discord et ça l'avait mis en italique. Ça ne marchait pas et on ne comprenait pas. Enfin voilà, des fois, c'est des trucs vraiment bêtes.

• Lulu

  Oui, parce que pareil, je t'avais filé de... C'était quoi ? Oui, parce que tu avais déjà ton mot de passe qui ne marchait pas. Et je te l'avais donné par Proton, parce que Proton a un truc de gestionnaire de mots de passe qui permet de partager ses mots de passe. Je l'avais filé à Lulu, et même comme ça, ça ne marchait pas. Je me suis dit, mais ce n'est pas normal. Et c'est parce qu'en fait, quand tu avais fait ta copie déjà, il y avait eu un pareil, ton Mac, je ne sais plus ce qu'il avait fait. Tu t'es fait manger une... Non, c'est Discord. C'est

• Manu

  Discord, en fait, qui... Oui, mais Discord,

• Lulu

  c'était... après parce que je ne t'avais pas d'abord filé par Proton ou j'ai fait l'inverse.

• Manu

  Non, tu as fait l'inverse, tu me l'avais envoyé comme ça sur Discord. Oui,

• Lulu

  c'était le tout premier. Je t'avais dit tiens, tu te prends et tu te modifies. Et comment je pouvais me connecter avec ? Parce que justement, je l'avais vérifié. Je me disais mais ça marche chez moi, ça ne marche pas chez elle. Bon, j'ai accusé Mac comme toujours parce que de toute façon, je déteste les produits d'Apple. Mais non, c'était la faute à Discord qui t'avait mangé les astérisques. Et c'est vrai que là, du coup, j'avais utilisé le gestionnaire de mot de passe pour te filer proprement, même s'il n'allait servir qu'une seule fois. Et tu t'étais rendu compte de ça.

• Manu

  Oui, mais après, quand j'étais sur la mauvaise... Enfin, mauvais environnement, c'est ça. Là, tu m'as accusé aussi. Le problème, il est entre le PC et la chaise. Non, j'ai jamais eu la bonne URL.

• Lulu

  Oui, mais tu aurais pu l'inventer. Pour la déduire. Alors, du coup, tu n'étais pas sur l'environnement prévu. Tu étais vraiment sur la production, mais avec notre ancienne adresse, en gros. Et quand j'ai fait la bascule vers nous, vers ledernierclic.fr, j'ai fait un changement là-dessus. Mais il y avait côté sécurité des choses que je n'allais pas basculer parce que l'ancienne URL était amenée à disparaître au bout de quelques jours. Et j'avais prévu de te donner la bonne adresse. Je ne sais pas pourquoi je ne te l'ai jamais donnée. Jusqu'au moment où tu me disais « mais pourquoi il y a des trucs qui ne marchent pas pour moi ? »

• Manu

  Pourquoi la trame ne se sauvegarde pas chez moi ? Et c'est là que tu m'avais filé, parce que c'est là que j'ai appris à faire des tickets à peu près potables pour que tu puisses comprendre au-delà de « ça ne marche pas » . C'était quoi que tu m'avais donné comme outil ?

• Lulu

  La petite fraise, mais je ne me rappelle jamais du nom.

• Manu

  J'ai dû me le marquer en favori,

• Lulu

  je crois. Alors, attends, c'est... En fait, vous avez un petit outil pour faire des petites vidéos. Jam, qui est un logo, un icône de petites fraises, qui est très chouette pour les développeurs, parce qu'en fait, il vous fait une vidéo de capture d'écran, mais il enregistre aussi ce qui se passe dans le navigateur. Donc, en gros, la partie console où il y a des logs et des trucs écrits comme ça pour les gens qui se cassent la tête sur du dev. Et c'est hyper pratique. parce que ça permet, nous, derrière, de voir la vidéo et d'avoir toutes les infos du navigateur en temps réel et de voir pendant la vidéo, si ça casse à 3 minutes, de voir l'erreur qu'il y a à ce moment-là, même si la personne ne l'avait pas mis à l'écran.

• Manu

  Et même pour l'IA, c'est pertinent aussi parce que ça lui donne tout de suite plus de... ça permet de tout de suite cibler aussi le problème.

• Lulu

  Alors, oui, l'IA ne va pas lire la vidéo, mais par contre...

• Manu

  C'est tout dans une seule vidéo ? Je ne l'ai pas encore essayé. En mauvais élève.

• Lulu

  C'est tout dans une seule vidéo, mais par contre... comme il y a la console, ça permet de récupérer les vrais messages d'erreur dans la console et de les donner à lire.

• Manu

  Oui, c'était plus ça en termes de contexte où c'est tout de suite plus pertinent que... Enfin, c'est toujours pertinent de décrire le problème avec le comportement normalement qui est attendu. Mais en plus d'avoir les messages d'erreur, ça permet de faire des correctifs plus chirurgicaux.

• Lulu

  Oui, ça permet surtout de beaucoup aider à identifier de liens de problème.

• Manu

  Et économiser des tokens.

• Lulu

  Oui, aussi. Mais bon, voilà pour la digression. Et juste pour terminer sur ces histoires de tests, du coup, à mi-juin, on avait déjà une V1 qui avait été relativement, qui avait été bien stabilisée, enfin, stabilisée. C'était stable dès le départ, mais on avait plein de petits couacs qui n'avaient pas été corrigés. Et voilà, corrigés un peu au fil du temps. Et donc, on avait 470 tests unitaires, 205 tests de sécurité. 230 tests d'interface d'embout. Il y avait aussi... Je ne les compte pas parce que ces tests côté infra, ils ne sont pas dans les tests automatisés. Mais en gros, il y avait à peu près 905 tests automatisés. Et aujourd'hui, sur la V2, on est à 1410 tests automatisés. Vous vous doutez bien qu'en temps normal, chaque fois que je fais une fonctionnalité ou un correctif, je ne vais pas me cogner 1410 tests à la mano. Donc, c'est hyper important et hyper... utile de mettre en place ce type de système. Encore une fois, ça ne protège pas tout, ça ne couvre pas tout. Mais ça vous fait...

• Manu

  En termes d'ordre de grandeur, c'est surtout les tests de sécurité, le bout en bout, qui ont doublé. Les tests unitaires, oui, ça a un petit peu augmenté aussi, mais c'est surtout ceux-là.

• Lulu

  Oui, mais ça, c'est très spécifique à notre contexte parce qu'on l'expliquera dans le prochain épisode. Aujourd'hui, entre les deux écarts, c'est entre la version 1 et la version 2. Et dans la version 2, on a rajouté un certain nombre de fonctionnalités qui sont très orientées utilisateurs et qui ont rajouté du coup des tests qui sont liés à ça. En fonction de ce que vous allez faire, vous aurez plus ou moins de tests. Mais c'est plus pour vous donner l'ampleur que sur un portail collaboratif qui n'est pas utilisé par des milliers d'utilisateurs, mais juste à nous deux chaque semaine et après à des invités petit à petit, ça représente déjà tout ça d'avoir un... une configuration de test typée production. Et voilà. Sachant qu'après, j'ai un petit travers aussi. Enfin, travers, je ne sais pas si c'est un travers, mais j'ai un parti pris en tout cas sur tout ce que je développe. Je pars toujours du principe que je le fais... Enfin, je bosse comme si je bossais en équipe et comme si je bossais dans un contexte de boîte. Donc ça, c'est un peu le vestige aussi d'avoir été product owner, responsable produit justement quand j'étais chez Cobble avec des collègues devs. Et que du coup, c'est important d'avoir, enfin mes yeux, de se dire, ben voilà, on va travailler sur tel sujet, on va créer une PR pour ce sujet-là, on va le documenter, on va justement s'assurer qu'il y a un suivi, on va mettre en place des tests, etc. pour que n'importe qui, en fait, puisse venir relire le code, relire les documentations, comprendre ce qui se passe, comprendre ce qui est fait, puisse prendre le relais, et aussi, ben voilà, si dans six mois, en fait, quelqu'un doit reprendre... Le travail va maintenant sur mon application. Je m'occupe juste de le faire, tout simplement. Et du coup, il y a des moments où j'en fais probablement trop. Potentiellement trop, parce que je mets en place un cadre vraiment type entreprise et taf en équipe, alors que le portail, je l'ai développé tout seul, donc il n'y avait pas forcément besoin de mettre autant de choses. Mais à mon sens, ça fait partie des enjeux quand on veut faire des applications de production. qui sont là pour durer, qui sont là pour être repris, qui sont là pour être maintenus, qui sont là pour être évolués. et qui implique des gens. Puisque là, ce n'est pas juste moi tout seul, ce n'est pas juste Lulu et moi, même si aujourd'hui, on n'a pas eu encore d'invités, enfin, si on a eu des invités, mais qui ne sont pas encore allés sur le portail, et ça va arriver là, ça m'en choupe peu. Mais derrière, chaque fois que vous avez des gens qui vont utiliser votre application, il y a des données à eux qui circulent. Il y a au moins leur mail, il y a au moins leur... Un mot de passe qu'ils vont peut-être utiliser ailleurs, il peut y avoir justement, en empruntant, il peut y avoir des données personnelles selon les cas, selon ce que vous avez dans les infos de profil et ce genre de choses. Il peut y avoir des fichiers qu'ils vont déposer qui sont plus ou moins confidentiels ou plus ou moins à eux, qui ne doivent pas fuiter, même si ce n'est pas des données sensibles, ce genre de choses. Et voilà, on peut, entendu de nombreuses fois, le raisonnement de se dire de toute façon, notamment vis-à-vis par exemple des... innombrables fuites de données qu'il y a sur les outils de l'État. De toute façon, mes données, elles ont déjà fuité par le permis. C'est l'ANTS ?

• Manu

  L'ANTS.

• Lulu

  Du coup, de toute façon, tous les deux moyens. Et de se dire, de toute façon, c'est peine perdue, ce n'est pas la peine de s'y mettre. Mais je suis pas d'accord avec ça. En fait, ce n'est pas parce qu'il y a des ratés dans les boîtes et parce qu'il y a... plein d'endroits où ils ne mettent pas les moyens qu'il faudrait. Et quand bien même, des fois, il y a les moyens qui sont mis en œuvre, mais ça n'empêche pas qu'il puisse y avoir des volets à donner. Sur pas mal de gros outils, quand même, on va se dire qu'ils ne font pas d'efforts. Parce que, par exemple, la NTS, c'était vraiment, vraiment, vraiment, vraiment une faille à la con. On était sur des trucs rudimentaires de cybersécurité qui n'ont pas été mis en place.

• Manu

  Après, c'est d'autant plus important que maintenant, il y a aussi l'IA pour attaquer. Là, voilà, en termes de défense, alors oui, on peut se dire que t'en fais trop, machin, mais je pense qu'il n'y a jamais trop de ce côté-là parce qu'il y a les mêmes outils en face. Et il faudrait d'autant plus rajouter de la sécurité, au moins jusqu'à tout ce qu'on peut. C'est comme se dire, bah oui, mais de toute façon, on a déjà toutes mes données, donc je peux les donner à toutes les boîtes. toutes les données de mon entreprise à l'IA et tout ça, parce que de toute façon, ils ont déjà tout. C'est un peu plus nuancé aussi.

• Lulu

  Quand bien même, à titre personnel, on renonce à ces données. Quand on financierait ces données, on parle de ce principe-là et on estime que s'en fout, c'est trop tard et c'est pas la peine de s'en occuper. Bah juste, c'est pas valable pour les gens avec qui vous bossez, en fait. C'est vrai,

• Manu

  puis c'est pas légal, de toute façon. Avec la RGPD, il y a quand même des choses à mettre en place.

• Lulu

  Oui, en partie. Mais pas que. La RGPD va sur d'autres sujets aussi, sur le fait de récupérer ses données, d'avoir le droit de suppression, d'avoir des droits comme ça. Mais on pourrait très bien mettre en place des fonctionnalités qui sont typées RGPD, justement pour l'export de données et tout, et avoir un code qui est une passoire et qui permet de rentrer par n'importe où. mais juste respecter les données des gens respecter les gens tout pour et ne traitez pas leurs données comme les vôtres en fait, faites mieux pour eux et pour elles et oui, aujourd'hui avec l'IA de toute façon aucune boîte n'est inviolable aucun système de sécurité, de cybersécurité ne peut pas être brisé il y a toujours des failles, il y a toujours des trucs mais tout ce que vous pourrez faire pour éviter que ça arrive, en fait, ce sera de près. L'idée, c'est quand même qu'il n'y ait pas le premier clampin venu qui puisse voler les données de vos utilisateurs. On a, ça me semble, le minimum de faire au mieux, même si ce n'est pas parfait, même si de base, vous n'êtes pas expert en sécurité, enfin, en cyber-sécurité, et qu'il y a des choses auxquelles vous n'allez pas penser, mais justement, on a l'IA pour nous aider à mettre en place des choses. Essayons d'en mettre le plus possible.

• Manu

  C'est notre responsabilité. On a des données qui ne nous appartiennent pas et quand on sait la valeur des données aujourd'hui, on ne peut pas choisir pour les autres.

• Lulu

  C'est ça. Voilà pour aujourd'hui. La bonne nouvelle, c'est que notre prochain épisode, ce sera un peu plus doux, un peu plus light. Il nous reste quelques petits sujets à aborder, mais un peu moins coton, un peu moins technique, on va dire ça comme ça. Et j'espère déjà que ça vous aura plu. parler la suite de ce déroulé, des différentes étapes, toujours pour développer, en tout cas pour comment nous on a développé notre portail et notre application, les étapes par lesquelles on est passé. Donc si vous avez écouté notre épisode la semaine dernière, vous avez vu que le cheminement, on le suit, on adapte à notre sauce dans les différents points. Et dans les prochaines fois, on parlera davantage de ce qu'on a décidé de mettre dans notre version 1, puis dans comment on a fait évoluer notre application. Parce qu'en fait, c'est un gros enjeu des applications, le moment où elle est vivante, utilisée, et comment on l'améliore et on la fait évoluer pour nos besoins, avec la partie support, avec les tickets de bug, avec les demandes d'évolution, avec tous ces petits trucs tout mignons là. C'est vrai que Lulu se fait une... Ça me donne à cœur joie de temps en temps. « Eh si, et ça, et ça, ce serait bien aussi. »

• Manu

  « Mais ça ne marche pas sur Safari. »

• Lulu

  Ouais, et surtout arrêtez d'utiliser des Mac. « Oui,

• Manu

  ça ne marche pas sur l'iPhone. »

• Lulu

  C'est horrible quand on est sur du Windows et du Linux et qu'en face, il y a quelqu'un qui utilise du Mac et de l'iPhone et qu'il y a des bugs qui n'existent que chez Mac et iPhone à cause de... On va rentrer dans le détail technique maintenant, mais ils ont des trucs à aveu chez Apple qui font qu'il y a des bugs. que chez eux et que du coup, pour les vérifier, d'ailleurs, dans ton dernier bug, tu ne m'as pas dit si t'es corrigé au dernier bug sur iPhone, mais normalement, c'est censé être bon parce que justement, j'ai été harceler Claude pour qu'il me mette en place un environnement de test et de debug spécifique Apple. Enfin, c'est intéressant à marcher.

• Manu

  Après, ça permet au moins de tester différents supports. C'est accessible. Ça permet de tester, parce que peut-être que les gens qu'on va interviewer ont aussi des iPhones ou des Macs. Si tu veux bien les laisser au micro, venir au micro quand même.

• Lulu

  Non, mais je pense que le matériel Apple devait être interdit par la loi. Mais bon, effectivement, en attendant, on fera avec. Et en tout cas, ça revient aussi sur le fait que c'est important de tester et de revenir. et de partir du principe que ce n'est pas parce que ça marche sur votre matos que ça marchera chez les copains et les copines but it works on my machine mais voilà on parlera de ça les prochaines fois et en fait plutôt de la vie d'une application une fois qu'elle est en production et comment on la fait évoluer on l'entretient et après des choix aussi qu'on a fait nous sur la partie technique enfin pas technique mais vis-à-vis de l'IA on va dire et vers où on va et c'est pour ça qu'on a évoqué un petit peu tout à l'heure le Le côté Supabase open source, on verra comment ça se passe. Si ça se passe bien, si ça se passe pas bien. Mais voilà.

• Manu

  La suite au prochain épisode.

• Lulu

  Ouais.

• Manu

  On fait une petite entorse, parce qu'on arrive déjà bientôt à la fin de la saison 1. Et ça vient de les vacances. Voilà, c'est ça. Donc ça sera pas un épisode thématique la prochaine fois. Après, même si là, honnêtement, on est presque dans une thématique quand même mélangée un peu. Oui,

• Lulu

  mais en fait, qu'est-ce qu'on veut chez notre podcast ?

• Manu

  Voilà, c'est ça. Et de toute façon, il y aura des super interviews aussi qui vont arriver, du contenu trop trop cool, courant août, et plein de surprises même après pour la rentrée.

• Lulu

  Oui, d'ailleurs, on vous l'annonce un petit peu, en août, du coup, le dernier clic sera en vacances, mais vous aurez quand même du contenu qui arrivera chaque vendredi, qui sera plus doux, enfin plus doux, moins long, surtout ça. On ne prendrait plus des parpaings d'1h37 comme ça, sans avoir à demander un par surprise. Et on se retrouvera à la rentrée après pour des épisodes longs à nouveau. Il y aura peut-être un épisode long pendant les vacances, on va dire, un cours en août. Mais voilà, on ira se reposer, mais on vous laisse quand même de quoi suivre un petit peu la tech. Et puis de toute façon, vous serez en vacances aussi. Donc, tes petits épisodes, ça vous fera du bien aussi. Merci à tous et à toutes de nous avoir écoutés. Lulu, est-ce que tu as un petit mot de la fin ? On est bon ?

• Manu

  Là, ça me semble bien. On avait dit 45 minutes.

• Lulu

  Ouais, c'est...

• Manu

  C'est... On va essayer.

• Lulu

  Ouais, mais on a fait plus gros. Le prochain, il fera 45 minutes, peut-être.

• Manu

  Peut-être.

• Lulu

  Peut-être. Merci Lulu de m'avoir accompagné sur cet épisode. Bonne journée ou bonne fin de journée, selon quand vous nous écouterez. Et on se retrouve la semaine prochaine.

• Manu

  Salut !