Transcription

• Speaker #0

  Bonjour et bienvenue dans Le Dernier Clic, votre podcast tech, IA et no-code. On se retrouve comme chaque semaine avec Lulu. Comment tu vas Lulu ?

• Speaker #1

  Ça va bien. Je comprends que tu étais fatiguée mais on va se faire un bon...

• Speaker #0

  Petit épisode de fin de saison, plus ou moins. Et du coup, aussi un petit épisode qui va venir conclure notre... Je ne sais pas, j'ai envie de dire un peu notre mois thématique sur le développement logiciel, en quelque sorte. On n'a pas fait exactement tout le mois, mais voilà. Si vous avez suivi les derniers épisodes, on avait fait un épisode où on parlait de notre portail qu'on utilise, nous, pour gérer les épisodes du dernier clic. On a fait un autre épisode ensuite, vraiment, pour parler du développement... logiciels de manière un peu plus générale et comment ça se passe dans les boîtes. Et la semaine dernière, on a fait la suite de notre épisode sur le portail. Parce qu'on avait beaucoup de choses à vous dire. Et je crois que c'est notre première fois avec un épisode en trois parties.

• Speaker #1

  Oui, oui. Après, on n'a pas non plus des cents et des milles côté épisode, mais il fallait que ça arrive de toute façon à un moment.

• Speaker #0

  Oui, oui. Là, ce sera... notre 19ème épisode que vous écoutez en ce moment. Et... On va faire un récap très rapide de ce qui s'est passé dans les deux derniers épisodes sur le sujet. Mais en gros, on vous avait expliqué un petit peu pourquoi on avait décidé de faire un portail pour gérer nos épisodes, parce qu'avant on avait plein de... toutes les infos éclatées à travers différents outils, etc. On avait parlé de la différence entre un site web et une application. On avait parlé aussi de comment on avait défini notre besoin et comment on s'en avait mis dedans, comment s'était passée aussi la partie cadrage produit, un peu le déroulé de la méthode. On a parlé de maquettage et de design. Et dans le dernier épisode, on a parlé du développement, je veux dire en lui-même, sans rentrer trop dans le détail des techniques de chacun. Parce qu'après, dans le webcoding, il y a plein de manières de faire. mais en tout cas on a essayé de vous expliquer un petit peu comment ça se passait avec deux approches soit celle où on était sur tous les documents qui sont prêts on est sur de l'application qui est destinée à être utilisée avec des gens donc qui est très cadrée très balisée, on a plein de ressources on a plein de choses et quand on attaque le dev, en fait l'IA elle va s'appuyer là-dessus pour nous dessiner un plan à chaque fois de chaque bout de l'application et on va la guider là-dedans et on va lui dire On va l'aider à trancher les décisions et elle va faire la partie exécution, globalement. Et l'autre approche, qui était plutôt orientée sur les applications qu'on peut faire, lui avait détaillé deux applications la dernière fois, justement, qu'elle utilise après elle, pour la partie design, notamment.

• Speaker #1

  Et la dernière fois, j'y ai repensé après. Tu m'avais parlé d'une autre application que j'avais faite et où je n'avais pas de back-end et que c'était un peu problématique. C'était l'appli que j'avais faite pour préparer l'épisode sur le cycle de développement logiciel.

• Speaker #0

  Ah oui, je l'avais oublié.

• Speaker #1

  Oui, moi aussi.

• Speaker #0

  Ce problématique n'est pas tellement à l'usage, c'était juste pour conserver les infos. Pour vous donner un peu le cadre, il y a un moment où j'avais eu un gros week-end et quelques jours de repos avec l'ordi pas dispo, etc. pour préparer un épisode. Je ne sais plus quel c'était.

• Speaker #1

  C'est un cycle de développement logiciel et tu n'étais pas convaincu par le fait qu'on arriverait à le tenir en un épisode. Alors, on l'a tenu en un épisode d'1h37, mais c'est un seul épisode.

• Speaker #0

  Oui, effectivement. Mais bon, c'est un sujet qui pourrait faire 10, 20, 30 épisodes. C'est un peu un sujet sans fin qu'on a tenté de condenser, de vous en faire quelque chose de synthétique et de digeste, même si on peut quand même enquiller les 1h37, mais ça reste une version très résumée. pour vous aider à y voir clair. Et si vous n'avez pas encore écouté, je vous invite à revenir sur l'épisode il y a deux semaines pour ça. Et donc là-dessus, vu qu'en termes de préparation, j'avais un timing un peu serré cette semaine-là, Lulu avait décidé de me préparer plus qu'une trame, c'était à la fois et la trame, et le contenu, et plein de choses qui allaient guider la réflexion et la manière dont on allait dérouler l'épisode et ce qu'on allait mettre dedans. Et pour ça, elle m'a fait un genre de... Ce n'est pas un mini site web, c'était une mini application ludique. Enfin, on va dire ça comme ça. Un site un peu ludique. J'avais des mini-jeux et tout dedans à passer. Je sais qu'il y a un Jenga que j'ai toujours pas compris, que j'ai pas réussi. Mais après, j'avais d'autres trucs que j'ai réussi, que j'avais eu tout bon, avec des points à relier, des questionnaires. Il y avait un questionnaire de vitesse aussi. Et ouais, c'était très chouette. Au final, ça avait très, très bien marché. Et avec un déroulement, justement, par chapitre, avec un système de progression qui me permettait d'avancer en gros dans la préparation de l'épisode et de voir un peu les sujets de manière interactive. et d'ailleurs c'est vrai que on parle pas assez mais aujourd'hui ça fait partie des usages qui peuvent être pertinents et intéressants avec le vibe coding d'aller sur quelque chose de plus pédagogique de plus orienté sur de la formation ou des contenus de formation et au lieu que ce soit des supports soit purement texte, soit purement powerpoint ou des choses comme ça d'avoir un espèce d'hybride en fait où dedans du coup ça fait des... comme un site web interactif mais avec des mini-jeux, avec des choses et Il y a d'autres outils, d'autres formations qui proposent des choses un peu comme ça. Mais ça permet de le faire sur un sujet de votre choix, d'aller cadrer le balisé. Et là, j'avais effectivement émis la seule réserve de ne pas avoir de back-end puisque du coup, j'avais pu le faire sur le téléphone, mais je ne pouvais pas transférer tout ce que l'application me générait parce qu'en fait, elle me construisait une trame sur mesure en fonction de ce que je répondais. Et c'était bloqué dans mon téléphone, je ne pouvais pas le renvoyer. Là où un back-end aurait permis de l'avoir en cloud, de l'avoir retrouvé sur téléphone, sa progression du PC et vice-versa, là où c'était bloqué que dans mon navigateur, enfin, sur le téléphone. Mais bon, à l'usage, tu avais pu exporter différemment la trame, donc ça n'a pas été gênant.

• Speaker #1

  Oui, on pouvait la copier-coller, mais là, c'était plus dans l'idée que... Là, c'était vraiment pensé pour le mobile et puis de... Pas avoir non plus de back-end pour se souvenir, ah bah tiens, tel IP a été jusqu'à tel endroit. Donc c'est sûr, ça a dû bouffer un peu de cash. Mais voilà, le but, c'était que ça soit utilisable. Mais c'est vrai que ça peut aussi poser problème si on veut la mettre en accès, comment dire, si on veut la rendre accessible, pourquoi pas, dans les ressources, quand on aura notre site Internet un jour. Ça pourrait être sympa, mais du coup, pour modifier, c'est sûr que ça serait mieux d'avoir un back-end et tout ça. Donc ça pourra être un chantier au milieu de tous les autres.

• Speaker #0

  Oui, ou alors on le laissera comme ça et on partira du principe que les gens auront le déroulé une fois et ce sera dans leur navigateur et ce n'est pas grave, ça marche aussi.

• Speaker #1

  Oui, mais plutôt que de jamais l'avoir,

• Speaker #0

  ça serait mieux. Oui. Et plutôt que de monter aussi une usine à gaz, juste pour ça, pour pouvoir aller enregistrer l'approbation de tous les gens, on n'en est pas en... C'est pas quelque chose qui a vocation à avoir un espace membre juste pour cette appli, donc il y aura peut-être un espace membre plus tard sur d'autres sujets du dernier clic.

• Speaker #1

  Sinon, c'est comme dans certains jeux vidéo, quand t'avances, tu débloques certains codes et pour reprendre ta progression, tu dois rentrer un code.

• Speaker #0

  Ah oui, à l'ancienne.

• Speaker #1

  C'est... ouais.

• Speaker #0

  On pourrait. Oui, mais... Du coup, t'as des niveaux standards, t'avais pas forcément ta progression avec tes choix, tu vois. de ta réussite au jeu. Mais on digresse.

• Speaker #1

  Il y a différents codes selon ce qui a été répondu et tout ça.

• Speaker #0

  Tu pars trop loin, Lul. En tout cas, dans le dernier épisode, on vous présentait aussi justement cette approche qui était aussi de faire du vibe coding quand on sait que c'est dans un usage perso qui est contenu et qui est juste pour soi, sur sa machine et qui n'a aucun enjeu de web, de sécurité. Non, pas vraiment. Au final, sur les mêmes usages que tu nous avais présentés. Voilà. On peut aussi construire une petite application pour soi au fil de l'eau directement avec l'IA en décodant. Ce qui implique quand même, même si il n'y a pas toutes les étapes de PRD, de cadrage projet et de tout ce qu'on a évoqué par rapport à une application de production, qui impliquait quand même d'avoir conscientisé quand même le besoin, l'approche qu'on veut avoir. Même quand tu avais itéré Lulu et que tu avais déroulé tes apps et créé petit à petit, tu avais déjà une assez bonne... idée de là où tu voulais aller quand même.

• Speaker #1

  Oui, et puis le but, c'est d'avoir quelque chose de visuel tout de suite pour itérer dessus. C'était marrant parce qu'après notre épisode, j'ai fait la commande Insights dans Cloud Code. C'était assez marrant. Il faudrait que je la retrouve parce que c'était... C'était sympa. Ça m'a dit que je partais dans tous les sens, mais bon. Ah non, pas que je partais dans tous les sens. Comment dire ? Qu'est-ce qui m'avait sorti ? Il y avait effectivement plein de projets et que le but, c'était de tout de suite aller vers quelque chose de visuel, mais après d'itérer quand même sur quelque chose de visuel et de consolider toute la partie utilisation et les différents... Comment dire ? Vraiment plus une approche no code. C'est un petit peu marrant de passer par l'IA pour faire ça et tout ça, parce que là, il n'y a pas vraiment besoin de glisser les composants, mais ça m'aide beaucoup. de passer comme ça et que je ne fais pas forcément de specs au départ, mais en même temps, je n'ai pas attaqué de giga gros projets non plus. Ça, il y en a toujours un qui est encore pour du design qui est en stand-by et que j'aimerais bien reprendre quand même, qu'on va voir. Mais la commande, si jamais la commande insights est très pertinente, donc c'est slash insights avec un S et ça va aller un peu analyser les dernières conversations qu'on a eues dans Cloud Code. et voir ce qui a marché, ce qui a moins bien marché, ce qu'on peut faire à partir de ça. Donc, je ne sais pas si toi, récemment, tu en as refait une ou pas.

• Speaker #0

  J'en ai refait deux ou trois. Effectivement, alors, il remonte à, je ne sais plus combien, une dizaine de conversations d'arrière. Il reprend. Donc, selon votre usage de Cloud Code, ça représentera plus ou moins de projets ou de fonctionnalités, de choses. mais... Alors, il ne va pas analyser la qualité du code qui est fait ou les failles de sécurité ou ce genre de choses. C'est vraiment un rapport de vos échanges avec Claude, de comment vous bossez avec lui. Et à côté de ça, il identifie aussi ce qui marche et ce qui ne marche pas et là où Claude se rate globalement. Et c'est très utile parce que derrière, il va proposer des pistes d'amélioration et de changement sur la méthode de travail. pour mettre en place, par exemple, des skills adaptés à la manière dont vous bossez, ou alors, justement, de la documentation supplémentaire dans les clouds.md. Ça rentre un peu dans la technique du vibe coding, mais en gros, ce qu'il faut en retenir, c'est qu'il va vous faire un rapport détaillé de ce qui va, ce qui ne va pas, et comment vous pourriez améliorer les choses pour que ce soit plus fluide. Et à partir de là, vous pouvez ensuite remettre ce rapport justement à Cloud pour... discuter avec lui de ce qui vous semble pertinent et de mettre en place des choses. Et moi, je l'avais fait après la V1 et ça m'a permis de mettre en place des skills, donc des compétences pour l'IA vraiment adaptées à la manière dont je déroule mes fonctionnalités, de tout ce que j'attends à l'intérieur. Et même chose après sur la partie relecture, les fameuses reviews. Et je l'avais refait un peu plus tard, au bout d'un mois, pendant que je travaillais sur la V2. Et là, il m'a fait d'autres rapports. Parce qu'en fait, l'intérêt c'est quand même d'aller sur de l'évolution et de l'amélioration continue et de faire un point idéalement peut-être pas toutes les semaines mais en tout cas un peu régulièrement sur ok comment je bosse avec Claude en ce moment et où est-ce qu'il galère et typiquement j'avais identifié aussi à travers ça, il m'avait remonté qu'il y avait des points très bêtes d'infrastructure de ma machine sur lesquels Claude se ratait tout le temps, sur du PowerShell sur des commandes ou des chemins qui se rataient tout le temps et qu'en fait j'avais pas Je l'avais vu à chaque fois, mais je n'avais jamais pris peine de le mentionner quelque part ou de le mettre dans le process du skill ou ce genre de choses, parce qu'à chaque fois, il retombait sur ses pattes. Mais en fait, toutes ces petites frictions où il se rate et qu'il retombe sur ses pattes, ça reste des tokens qui sont consommés, ça reste du coup de la mémoire qui est consommée pour rien au niveau du contexte, ça reste des choses qu'on peut traiter différemment. Donc Insight, je valide, je trouve ça très utile aussi.

• Speaker #1

  Là, je l'ai retrouvé, ce qui fonctionne. Travailler sur une gamme inhabituellement large en créant des outils interactifs tels que des éditeurs de carousels et des moodboards, en automatisant la segmentation des paroles de karaoké. Coucou Mathieu, qui est venu ce week-end avec qui on s'est amusé. En vrai, c'est super comme problématique. Mais voilà, c'est ce genre de choses larges sur lesquelles on peut aller. Et qu'est-ce que c'est ? enfin C'est marrant parce que vous y tirez en boucle conversationnelle serrée plutôt que d'écrire des spécifications initiales détaillées. Ça vous fixe un objectif clair. Faites confiance à Claude pour le construire et l'auto-vérifier puis éterrez à travers de nombreux cycles de raffinement rapide. Ouais, tout ce qu'on a dit qu'il ne fallait pas forcément faire pour des apps un peu plus sérieuses. Mais moi, j'y vais plus en mode photo et je me dis que si... En fait, c'est presque pour... affiner mes futurs specs si l'application vaut le coup d'être développée à une échelle beaucoup plus importante. Moi, je ne sais pas, j'ai besoin de jouer avec un prototype. pour me dire, ah bah tiens, ça finalement, dans ma tête, ça semblait bien, c'est comme ça que j'imaginais faire utiliser telle fonctionnalité, et au final, en l'utilisant, je me rends compte que ce n'est pas ce qu'il faudrait. Donc je vais y tirer sur ce prototype, et moi ça m'aide à avancer dans ma réflexion, à mieux décrire mes besoins, et au final, même pour le dernier clic, c'est ce que j'ai fait avec la maquette. La première maquette sur laquelle j'ai un peu itéré, elle ressemblait... pas du tout à la maquette qui a été confrontée avec le PRD. Il y a eu énormément d'itérations et même moi, je m'amusais à faire le parcours et dire, tiens, j'arrive là. Un épisode, même ça permet aussi de l'avoir en parallèle et de se dire, ok, là, on produit un épisode comme on fait d'habitude, c'est quoi le process qu'on a ? Quelles informations on va tout le temps chercher ? Donc, c'est se dire... ah bah tiens, cette information-là, il faut qu'elle soit facilement trouvable dans la fiche épisode. Donc voilà, moi en tout cas, j'ai besoin de cette partie-là, mais je sais très bien que si je dois aller développer plus pour avoir un back-end et pas juste l'utiliser sur ma machine, là je vais repartir de spec, sans forcément décrire ma maquette, mais ma maquette aura aidé à mieux définir mes besoins et que ça soit plus mature.

• Speaker #0

  J'entends complètement pour la partie... maquettage, d'ailleurs un designer comme ça travaille avec du filmaste et aussi des phases, des étapes par lesquelles on doit passer. Après, même pour de l'usage perso, je suis quand même un peu mitigé sur cette approche. Enfin, je comprends la partie visuelle et après d'y terrer dessus. Mais à mon sens, ça reste pas frugal non plus. Et sans aller jusqu'à des... des PRD, tout le déroulé des specs qu'on a fait qui peut être très lourd. Je maintiens que plus c'est déjà clair avant, et du coup plus on a déjà posé ça sur papier, sur écrit, sur dessin, sur Figma, sur Canva, sur ce que tu veux, mais plus tu as déjà de pistes et de choses en tête sur comment tu veux répondre à ton besoin, même si effectivement il y a des parties de l'itération au niveau design que tu dois ajuster qu'une fois que tu l'as. Tant que tu ne l'as pas matérialisé, il y a des choses que tu ne peux pas t'en rendre compte. Tu ne peux pas voir à quel point c'est bloquant. Donc ça, j'entends complètement. Mais je maintiens que plus tu as fait du taf en amont, moins tu crames de diya.

• Speaker #1

  Ah oui, oui. Et puis dans tous les cas, ce que j'ai fait, c'était en ayant déjà itéré sur le process en lui-même. Donc après, c'est presque plus que la partie visuelle qui va se mettre par-dessus. Mais par exemple, le template de Carousel, il y avait un gigafrolon dehors. Désolée, ça m'a fait peur. Ok, ça peut être aussi gros que ça. Oui, donc l'éditeur de Carousel, je sais déjà les paramètres qui doivent varier et tout ça. Donc ça, je le décris quand même. J'ai quand même un document en amont. avant d'aller itérer sur le prototype. Mais c'est vrai que je ne vais pas passer à me demander quel backend je vais utiliser. Mais bon, ça, c'était plus dans l'épisode de la semaine dernière où, en gros, je dis que j'ai ça en entrée. Je le modifie de telle manière pour arriver à ça.

• Speaker #0

  Je suis d'accord, mais je ne disais pas... Même si tu n'as pas besoin de backend, tu vois. Pour moi, c'était plus logique de se dire, dans tous les cas, plus tu as réfléchi à ton problème, mieux c'est, tu vois, même avec ton approche.

• Speaker #1

  Non, non, complètement. Après, j'ai aussi ce truc de... Je pense que même dans la communauté no-code, de ce que j'ai pu voir, il y a pas mal de gens qui sont comme ça, c'est d'avoir une idée et de parfois trop vouloir la préparer et après, ça reste dans un coin et ça n'avance pas forcément. Alors que là, il y a ce petit truc de se dire « Ah bah tiens, j'ai quand même quelque chose qui est utilisable » , parce que là, en soi, je n'aurais même plus besoin d'itérer dessus. C'est un peu de trouver l'entre-deux et de tout de suite savoir que les projets-là ne sont pas voués à grandir plus en l'état et qu'il faudra les refaire si on veut aller plus loin. Mais je pense que, comme je disais, l'éditeur de Carousel va manger moins de tokens que si à chaque fois j'essayais de repartir de zéro dans Cloud Design. D'ailleurs, l'interface de Cloud Design, c'est vraiment affreux. Je ne sais pas ce qu'ils ont fait. Je sais pas.

• Speaker #0

  Je te rejoins complètement. Je n'avais pas touché à Cloud Design depuis qu'ils l'avaient refondu. Enfin, qu'ils avaient rajouté des fonctionnalités et tout. Et pour l'avoir utilisé la semaine dernière, c'est un enfer. Ah, c'est une purge. J'avoue que ça m'a quand même beaucoup choqué parce que d'habitude, les produits cloud sont relativement bien pensés et assez ergonomiques. Ce n'est pas forcément parfait, mais en tout cas, ça reste assez intuitif pour s'y retrouver assez rapidement. Même un cloud code est très chouette et tout. Le lab de bureau a toujours été plutôt bien. Même sa déclinaison web. Alors là, cloud design, ni à... Si vous faites de l'UXUI, faites tout sauf ça, s'il vous plaît. C'est affreux. Autant, il y a des choses... Si tu vas sélectionner, par exemple, le truc de commentaire ou quoi, si tu vas sélectionner directement dans la maquette, il y a des petits trucs comme ça, ok. C'est le principal. Ce que tu vois à l'écran, il est parti d'aller modifier. Et encore que je dis ça, même la consultation, avant, c'était assez facile d'aller naviguer entre les différents fichiers. Maintenant, c'est encore moins lisible parce que du coup, ils te tronquent les noms parce que tu as un truc... Ouais.

• Speaker #1

  Voilà. Et en plus, ça consomme à fond les tokens. Franchement, moi, ça me fait... Là, je commence à me dire ouais, en fait, non, je vais utiliser peut-être Open Design et voir après pour itérer et puis ensuite aller dans Figma ou une solution open source autre que Figma. commencer à regarder ça. Donc ça, ça fera peut-être partie d'un futur épisode, on verra. Mes essais de l'été.

• Speaker #0

  Après, il y a quand même à préciser que dans Cloud Design, vous pouvez aussi changer de modèle. Donc n'hésitez pas à utiliser Sonnet parce que sur du design, la majorité des choses, il les fait très bien. Vous ayez un besoin très spécifique sur lequel Sonnet galère. Typiquement sur les exports, il y a des trucs d'export qui marchent moyen. Mais... Sinon, privilégiez Sonnet, parce que sur du Opus, ça consomme plus que du code. Je ne sais pas comment ils ont fait. Et voilà. Et pourquoi on est parti là-dessus ? Juste pour revenir sur ce que tu disais, notamment que l'app de Carousel, elle va coûter de toute façon beaucoup moins de tokens à la fin que d'utiliser Cloud Design toutes les semaines pour refaire des nouvelles versions itérations. Complètement d'accord là-dessus. Et j'entends aussi le fait que vouloir faire tellement de specs ou de se projeter dans les préparatifs, il y a quand même plein de cas où tu finis par ne pas faire l'app parce que tu lâches avant, parce que tu ne l'as pas sous les yeux, ça ne devient pas concret et du coup, ça reste de l'anticipation. Mais à la mer, ce n'est pas parce qu'on a du vibe coding qu'il faut tout faire, tu vois. Et là, les usages que tu as cités sont très bien parce que c'est des besoins concrets qu'on a aujourd'hui pour le podcast et des choses que tu dois déjà faire aujourd'hui à la mano et qui prennent du temps et qui sont galères. Du coup, tu réponds à des vrais besoins métiers, tu vois. Mais des parties de galère que tu avais déjà dans les choses qu'on fait au quotidien avant d'aller en faire des apps. Et même comme ça, il y a toujours la logique de se dire est-ce qu'il y a déjà un outil open source, notamment, qui existe avant de s'en servir ? Parce que ça ne sert à rien de réinventer la roue en permanence. Et le sujet dont on avait déjà parlé aussi avec la dictée vocale, qui était de se dire, bah oui, on peut... coder son propre outil de dictée vocale aujourd'hui, mais en vrai, il y en a plein sur le marché, avec des aspects différents, des fonctionnalités différentes, des interfaces différentes, etc. C'est quand même assez dommage de ne pas s'en servir, de ne pas regarder déjà ce qui répond et d'aller sur le développement seulement quand on a rien qui répond à nos besoins. Ou qu'on a un truc spécifique qui n'ira pas et quand même, sur des outils open source, on peut aussi les prendre, les forquer pour ensuite en faire une version avec à nous, perso, ça reste une possibilité aussi. Donc voilà. Désolé, on part un peu dans tous les sens aujourd'hui. Mais c'est un peu notre point de vue sur les différentes applications et les différentes façons de vibecoder. On ne voulait pas non plus... Déjà, le LUMO, on n'a pas les mêmes manières de bosser sur du vibecoding. On n'allait pas inventer une version unifiée qui ne correspondrait pas à la de nous deux. Et en plus, à travers tout ce qu'on vous a dit, ce qu'il y a bien à comprendre, c'est que ça dépend de l'usage et du besoin. Si vous allez sur une application qui est vraiment destinée à être mise en production avec plein de gens, prenez le temps, cassez-vous la tête, et voilà, il y aura plein de choses à faire, plein de boulots en plus sur les préparatifs, sur le cadrage, sur les tests, sur tout ça. Mais c'est important parce que vous allez bosser avec des gens et que ça permet de vous assurer que les données ne vont pas fuiter, que ça va tourner, que ça va pas... C'est un outil que vous allez développer et il faut que l'outil marche. Basta.

• Speaker #1

  Et que les gens vont utiliser aussi, tout simplement. Parce que c'est bien beau de le développer si personne ne l'utilise parce qu'on ne s'est pas assez posé de questions sur les besoins, les problématiques rencontrées, le parcours. utilisateurs, oui, on aura développé quelque chose, mais ça sera aussi des tokens cramés pour rien. Et ça, ou même en développement traditionnel, c'est de l'argent foutu en l'air, du temps aussi, pour rien, des équipes qui taffent sur des projets qui ne seront pas utilisés derrière, il faut vraiment prendre le temps de se poser ces questions et c'est, peu importe le projet qu'on fait ou l'énergie. qu'on va mettre dans quelque chose, c'est de se demander est-ce qu'il y a vraiment besoin déjà ? Est-ce qu'il y a des choses qui existent ? On a juste pas mal formulé le problème. Est-ce que c'est vraiment un problème ?

• Speaker #0

  C'est ça, c'est qu'on a un travers aussi sur l'approche de se dire on va faire dans l'ordre de cadrage projet, de définir toutes les étapes de PRD et tout. C'est typiquement le cahier des charges fonctionnelles qui a été fait sans prendre en compte la vie et la réalité des principaux personnes, métiers qui vont se servir de l'app. Ça c'est un cas typique. Vous allez discuter avec n'importe quelle agence qui fait du développement ou une boîte qui fait des solutions logicielles pour d'autres boîtes. Toutes vous diront qu'elles ont déjà reçu des cahiers des charges, qu'elles ont développé ça et que ça répondait juste pas du tout à ce que les gens utilisaient et avaient besoin réellement dans la boîte. Et d'ailleurs, c'était une des raisons aussi pour lesquelles le no-code était chouette là-dessus. C'était le fait d'avoir vite quelque chose à mettre dans les mains des gens permettait de se rendre compte rapidement quand ça partait dans une bonne ou une mauvaise direction. Mais ouais, je vais maintenant rappeler ça, c'est que il y a le pendant de faire de la préparation, mais sans avoir pris les bonnes infos, et du coup on se retrouve à développer une app qui va prendre plus de temps et qui sera juste pas du tout adaptée. Et pour illustrer ça, on peut vous présenter un petit peu ce qu'on a mis, nous, dans nos deux... déjà dans notre V1 de l'application. Donc un peu ce qu'on s'est dit, je sais pas si je vais vous présenter un petit peu justement les gros trucs qu'on a décidé de se mettre... qu'on avait jugé important et nécessaire pour notre première version du porté.

• Speaker #1

  C'est vrai que toi, tu avais déjà fait dans le PRD une V1 où moi, après, j'étais arrivée avec ma maquette en disant, ça serait bien qu'on Et puis, te dire, bon, il faut réussir à se demander qu'est-ce qui va être pertinent pour la V1. Donc, le but d'une V1, c'est d'avoir une application qu'on peut utiliser, qu'on peut faire notre process de bout en bout, à savoir... construire les épisodes de podcast de l'idée jusqu'à la diffusion. C'était un petit peu ça. Et puis de se dire, OK, il faut qu'on ait un socle pour une app fonctionnelle et le reste, ça sera de la V2. Et au moins d'avancer jusque là. Donc là, on avait forcément la partie, vraiment les fondations, c'est de savoir, les gens, ils doivent pouvoir se connecter, que ce soit les producteurs ou les invités. la partie authentification, donc invitation par lien, mot de passe. Après, ça va être aussi toute la... Une fois qu'on se connecte, on va arriver sur le tableau de bord et on va avoir après sur le côté, la sidebar pour naviguer. Et là, c'est bon, sur la partie là. Je ne sais pas si tu as...

• Speaker #0

  Déjà, non, mais c'est ça, c'est que le début, en gros, on a fonctionné par l'eau.

• Speaker #1

  Oui.

• Speaker #0

  et on l'a fait par l'importance de fonctionnement et de ce qu'on avait besoin de faire nous directement aussi. Et les fondations, c'était vraiment ce que vient de dire Lulu. Donc à savoir le fait de juste pouvoir se connecter et déjà, enfin, juste naviguer dans l'app, on ne pouvait rien y faire d'autre entre guillemets de se connecter, mais la première étape, c'est d'avoir un système d'authentification qui gère les gens avec les mots de passe qui vont bien, avec la sécurité qui va bien. Vous receviez votre mail d'invitation quand vous êtes invité et que si vous souhaitez changer votre... de pas de pas ce que vous puissiez le faire. Vraiment les basiques. Mais en fait, les basiques, c'est déjà une étape.

• Speaker #1

  C'est de poser vraiment le squelette. C'est là-dessus que tout va reposer et qu'on va mettre après des couches petit à petit. Et ensuite, le deuxième lot, c'était tout le cycle de vie des épisodes. C'était un peu le point de départ de la création du podcast. Donc là, c'était de se demander par quelles étapes on passe quand on produit un épisode. On va avoir l'idée, la validation de l'idée. Après, on va avoir différentes tâches aussi. Une tâche, c'est quoi ? C'est qu'on peut l'ajouter, on peut la cocher, après on peut les filtrer. On va avoir des templates de tâches aussi. Et la génération de... Ouais, donc template de tâches, on avait défini, on avait listé un peu toutes les tâches. Et ce template de tâches, cette liste de tâches, quand on crée un nouvel épisode, automatiquement, ça se met dans l'épisode.

• Speaker #0

  Donc ça, c'est vrai que c'est sympa de ne pas avoir à refaire à chaque fois. Ça, c'est une bonne pratique qu'on voit aussi pas mal dans le no-code et que c'est souvent ce qui est demandé de la part des personnes qui utilisent ce type de système. Oui,

• Speaker #1

  c'est ça, parce qu'en fait, les étapes correspondent en gros au cycle de vie de notre épisode, entre le moment où on a l'idée de le faire et après, le cadrage qu'on va faire sur l'idée qu'on va mettre dedans, le moment où on va le préparer pour qu'il rentre en production. Après, on va l'enregistrer. Et ensuite, il va y avoir des parties un peu, voilà, tout ce qui est montage, récupération de transcripts, etc. Et ensuite, après, toute la préparation, en fait, des éléments qui vont servir à le mettre à la diffusion. Mais du coup, le point de départ de ça, c'était justement ces étapes-là et les tâches qu'il y a à chaque étape. Le template, comme l'a dit Lu, c'est tout simplement parce qu'en fait, quand on fait un épisode, même si le contenu va changer, de la trame et de choses comme ça, mais en fait, les tâches à faire, ça semble toujours les mêmes. Et je pense que vous connaissez près de tout. Tout ça dans vos métiers, vous avez des sujets, des chantiers pour lesquels les étapes sont toujours les mêmes. Le détail va changer en fonction du client, en fonction du jour, en fonction du sujet. Mais le process reste le même. Et donc ça, c'était vraiment la base qu'on a étoffée petit à petit. Ce que tu appelais de tâches, par exemple, n'était pas forcément nécessaire. On aurait pu se contenter de faire des tâches à la main. Mais vu qu'on en avait déjà identifié et qu'il revenait tout le temps, c'est dommage de ne pas en profiter. et qu'on a complété du coup avec le lot d'après qui était la partie notes et sources donc vraiment rentrer dans le coeur de contenu en fait de l'épisode et de ce qu'on va y mettre donc vraiment là quand on... petit bruit de moto en arrière fond je sais pas si vous l'entendrez mais quelqu'un qui s'amuse mais en fait pour chaque épisode nous on va préparer déjà toute une trame, une bibliographie et se partager des sources et voilà se renseigner après, aller creuser certains sujets. D'ailleurs, parmi les sources que vous avez aujourd'hui dans les épisodes, dans les descriptifs d'épisodes, peu importe la plateforme que vous utilisez, ça vient directement de ce que nous, on a rajouté comme bibliographie dans la plateforme et qui va être réutilisé au moment de la diffusion qu'on peut récupérer.

• Speaker #0

  Oui, on peut sélectionner les sources qu'on va vouloir mettre en description parce qu'on les trouve vraiment pertinentes. C'est vrai que c'est assez pratique de se dire bon, là, on a... Notre écran, quand on prépare la trame, et la trame, elle est préparée à partir d'une certaine bibliographie. Et cette biblio, au moment de la diffusion, quand on va faire la description de l'épisode et qu'il va falloir mettre les sources, c'est bien de ne pas avoir à repasser à la partie préparation de l'épisode où on a notre trame et la biblio. Donc, c'est pour éviter les allers-retours. Donc, ça arrive directement sur le bon écran.

• Speaker #1

  C'est ça. Et après, on y a mis la partie diffusion.

• Speaker #0

  Je ne sais pas si tu veux reparler un peu de ta... Parce qu'au début, on se disait, la partie édition de la trame, c'est un joli bloc quand même dans le portail.

• Speaker #1

  Oui, qui a un peu évolué. Parce qu'en fait, on a un éditeur qui nous permet de rédiger notre trame. Et comme on avait l'habitude avant d'écrire ça dans Fibery, puis dans Anytype, on vous... renvoie aux épisodes précédents si vous voulez en savoir plus sur ces outils, mais en gros, ce sont des outils qui fonctionnent comme du Notion pour la partie écriture. Vraiment, vous avez une page blanche et vous appuyez sur votre slash et il va vous permettre de mettre en forme, de mettre des titres, des listes à points, des surlignés, du gras, du machin, très facilement. Donc ça, c'est fluide. C'est vrai que Lulu et moi, on utilisait du Notion depuis quelques années avant de le lâcher ces derniers mois. Et du coup, quand on a pris l'habitude de ce type d'éditeur, c'est compliqué de revenir en arrière. Et là, par défaut, au début, j'avais fait une première éditeur enrichie qui permettait de gérer déjà quelques points, mais qui ressemblait à un éditeur de mail, avec les barres au-dessus, là, où on peut mettre en l'air et tout. Donc, chose typiquement archaïque. Alors, c'était fonctionnel, mais ça m'a très vite gonflé. Et donc, j'ai voulu en faire un éditeur à la Notion. Et alors au début, juste pour pouvoir gérer les titres et les listes à points, et puis petit à petit, en fait, on rajoute des trucs pour que ça puisse se gérer aussi, notamment la copie directe depuis un in-type. Mais dans les copies directes qu'on avait, des fois, on avait des tableaux. Au début, ça ne marchait pas. Donc il a fallu gérer ces points-là. Et après, aussi gérer la partie collaborative, c'est-à-dire que lui et moi, on pouvait être amenés à travailler en même temps sur la trame. Et donc ça, il fallait aussi pouvoir gérer l'enregistrement en temps réel, etc. Sur lequel j'ai itéré, j'ai fait plusieurs approches différentes. Là, on en a une qui est un peu... pas qu'il y ait mieux. Et bon, en fait, tout ça pour dire que juste certaines parties de votre application peuvent exiger plus de boulot parce que ça va faire partie des choses un peu au centre de la préparation d'épisodes. Et le jour où on enregistre, systématiquement, on se retrouve les deux devant la trame et à potentiellement faire des modifs en même temps dessus. C'est là qu'on avait eu des petits crocs. Et puis juste que ce soit fluide, parce que les éditeurs, façon mail, moi je n'en peux plus. et quand on s'habitue à certains outils un peu plus modernes, on a envie de mettre ça aussi dans ce qu'on utilise nous et dans ce qu'on développe nous.

• Speaker #0

  Oui, c'est vrai que ça posait pas mal de questions parce que moi je disais, ça serait bien d'avoir un mini curseur pour voir où est-ce que la personne avec qui on bosse allait en ce moment sur le... Et au final, après on s'est dit, non mais en fait c'est pas nécessaire. Mais après c'est de gérer aussi toute la partie versionnage. Est-ce qu'on bosse en même temps sur la trame ? S'il y en a un qui supprime, comment ça se passe ? Donc ça, c'est aussi des règles...

• Speaker #1

  Ça, c'est arrivé plus tard. C'est arrivé dans la V2. Au début, on n'avait pas de version. C'est d'ailleurs un des quoi qu'on avait eu une fois. Sur une version que j'avais eue, je ne sais plus comment c'était débrouillé, mais qu'on avait tous les deux la page ouverte, mais chez toi, tu n'avais pas rafraîchi ton cache de navigateur ou je ne sais pas quoi. C'est ta version à toi qui a pris le pas et qui a été enregistrée en dernier et qui a supprimé la version où moi j'avais commenté des choses. C'est à partir de ce moment-là où j'ai dit non mais là c'est plus possible, on va mettre du versionning et on va mettre un truc dynamique différent. Et quand on parle de versionning, c'est en gros de se dire régulièrement en fait, les choses qui sont dans la plateforme, et notamment là sur la trame, sont enregistrées et on peut revenir à une version précédente. Même chose comme ce que vous avez dans un Google Doc, dans un document Word, en collaboratif, ce que vous avez sur du Notion, et que quand le collègue vient et vous a supprimé tout un pan et qu'il ne s'en est pas rendu compte, Vous arrivez, vous récupérez votre bout de document, mais vous passez par l'historique pour revenir sur une version précédente. Nous, on a ça dans notre app maintenant. Mais ça, on l'a fait dans un second temps. Au début, l'idée, c'était vraiment de pouvoir bosser à deux. Et après, on a été... Parce que bon, on va peut-être passer rapidement un peu sur d'autres lots, mais en gros, il y avait donc la partie diffusion qui était là pour vraiment y mettre tout le contenu qu'on envoie après sur Ausha, qui est notre plateforme de diffusion. Donc les visuels, le résumé. Les liens, tous ces trucs-là. Et les fichiers audio, typiquement. Sinon, notre podcast, je ne l'entendrai jamais. On avait mis aussi la partie invitées, même si elle ne servait pas encore à ce moment-là. Parce que l'enjeu de base de l'application, c'était quand même de se dire à tout moment qu'on peut recevoir quelqu'un dessus et que ça se passe bien. On s'était mis un petit calendrier qui était assez simpliste. On s'était mis aussi des ressources globales, c'est-à-dire des choses que... Comme des éléments de notre charte graphique, par exemple, ou quelques documentations et deux, trois... Les liens vers les outils qu'on utilise aussi. Enfin voilà, quelques éléments qu'on a au commun qui ne sont pas propres à un épisode, mais qu'on peut retrouver partout. Et avec ça, ma foi, on arrivait déjà à bosser bien sur le podcast. Mieux qu'avant.

• Speaker #0

  Donc a priori, c'est que c'était une métrique qui fait que c'était réussi.

• Speaker #1

  Ouais. Bah typiquement, ce qui aurait pu... On aurait pu être de trop, entre guillemets, sur cette première version. C'était la partie invité, tant que nous, on bossait à deux. Mais la V1, elle était aussi là pour ça, pour permettre la bascule. Donc, c'est là, c'est autre chose. Et après, on avait des détails. C'est-à-dire que oui, on a un peu, par exemple, le modèle de tâche, on l'a mis dès le départ, on n'en a pas forcément besoin. Mais c'était quand même bien mieux de l'avoir direct pour qu'à chaque nouvel épisode, on ait toutes nos tâches qui soient prêtes. Et pouvoir l'administrer, parce que ça, typiquement, tu vois, moi, je m'en suis servi au début. Il y a des tâches que j'avais mises, que j'ai virées, que j'ai réorganisées. et que si je n'avais pas eu le truc mal... Enfin, l'interface pour le faire, il aurait fallu que je le fasse côté base de données et code et ça aurait été galère pour pas grand-chose.

• Speaker #0

  Ça, puis ça permet de voir aussi à l'usage ce qui marche, ce qui ne marche pas et de ne pas prendre un peu de mauvaises habitudes dès le départ si on sait que c'est comme ça qu'on travaille. Et même toute la partie gestion d'invité, ça fait aussi commencer à gérer les parties droits dès le départ, enfin, sur la première version de l'application. vu que c'est quand même destiné à ça même si on ne s'en sert pas dès le départ c'est bien de l'inclure dès le début aussi et de penser même soi-même en tant qu'invité, de se dire ok, moi ça me semble évident cette interface mais comment est-ce que ça sera et de commencer même à prendre un peu des notes sur le côté, de faire des tickets dans Anytype avant d'avoir un vrai système de tickets

• Speaker #1

  Oui, et ça ça a été d'ailleurs la bascule c'est qu'à un moment on s'est dit bon c'est chouette maintenant on va améliorer tout ça et on va en faire une deuxième version. Entre temps, sur la V1, il y a déjà eu des tickets de support, comme faisait Lulu. ou des choses que moi je remarquais aussi, en me disant, en fait, ce truc-là, on pourrait le retravailler un peu, cet élément, on va le déplacer un peu, ou cet élément visuel n'est pas terrible, ou alors, ah non, là, il y a un petit bug que je n'avais pas vu et que je n'avais pas remarqué, qu'on va corriger. Et en fait, on avait déjà ces petits points-là que je corrigeais petit à petit, mais sans que ce soit des ajouts de grosses fonctionnalités.

• Speaker #0

  Le responsive sur mobile.

• Speaker #1

  Le responsive sur mobile, effectivement, qui n'était pas... Je veux dire qu'il n'était pas top au début, qu'il n'était pas... Il n'était pas. Il était à moitié. Ce qui donnait l'impression qu'il n'y était pas, c'est que la partie navbar et un autre truc qui était central ne l'étaient pas. Du coup, on a l'impression que tout était cassé, alors qu'en fait, c'était juste cette barre de navigation. Une fois que Edge l'ait fait, le reste, ça a été déjà pas trop mal. Mais oui, il n'était pas notre première version responsive, c'était inutilisable sur mobile, il a fallu l'ajuster.

• Speaker #0

  Vraiment en situation de secours, pourquoi pas, ça se gérait. Mais c'est vrai que la navbar prenait une grosse place. Et même après, vu que tu as fait en sorte qu'on puisse la rétracter sur mobile, je me suis dit pourquoi pas aussi sur la version PC. Parce que ça sera plus sympa si on veut vraiment voir qu'un seul épisode, si on veut voir la trame, juste la trame. C'est des petites itérations et ça, sur le coup, c'est là où ça ne vaut pas forcément le coup d'aller dans ce niveau de détail au moment des specs. Parce qu'il y a toujours, dans tous les cas, des choses où on va se rendre compte à l'utilisation.

• Speaker #1

  Clairement, clairement, clairement. Mais une fois qu'on a eu ça et qu'on a fait une version plus propre de notre V1 et qu'on a corrigé un petit peu les différents points, on s'est dit bon, ok, on va briller maintenant sur une... version 2 et on va y rajouter ce qui nous manque pour que ce soit une app vraiment chouette et de bout en bout et en fait qui a un peu tous les éléments qu'on gère encore un petit peu à côté. Donc on a amélioré plein de choses qui étaient déjà là, notamment sur les sources et sur la gestion des multifichiers, du calendrier. Ça a été plein de compléments en fait sur des choses qui étaient existantes. Après on a rajouté toute la partie commentaires et notifications parce qu'au début on n'avait pas ça dans l'app. Donc, on traitait encore par Anytype ou par Discord pour certains points.

• Speaker #0

  Oui, puis on se disait que la trame enrichie serait suffisante. Est-ce qu'on allait écrire plus ou moins dedans ? Est-ce qu'une partie commentaire allait être vraiment pertinente ? Au final, il s'est avéré que oui. Mais c'était plus en me disant, tiens, s'il y a un invité qui vient, et ça a soulevé différentes nouvelles features, de se dire, s'il vient et qu'il a envie de laisser un commentaire, par exemple, sur... je ne sais pas, l'épisode qu'il veut écouter. D'ailleurs, ça aussi, le lecteur de l'épisode directement intégré pour voir les fichiers directement sans avoir à les télécharger pour les ouvrir après sur son PC. Ça, c'est plein de petits trucs de confort où nous, bon, ce n'était pas vraiment bloquant, mais on se dit, s'il y a quelqu'un qui vient, qui veut checker vite fait si l'épisode, c'est bon de son côté, si les visuels, c'est aussi bon, qu'il puisse mettre un commentaire et qu'il puisse aussi voir directement les fichiers sans avoir à les télécharger.

• Speaker #1

  Oui, c'est vrai qu'au final, je ne l'avais pas mis au début. Et quand tu m'as fait la réflexion, je t'ai dit « Ouais, bon, on s'en fout un peu » . Et en vrai, je m'en suis servi plein de fois après, justement pour lire les PDF. Parce que les textes bruts, on les avait déjà dans l'application à travers l'éditeur. Mais effectivement, tout ce qui était PDF, tout ce qui était images, tout ce qui était même les audios, il fallait toujours les télécharger pour les écouter, enfin pour les consulter sur son poste. Parce que maintenant, on a des lecteurs qui sont dynamiques à l'intérieur, qui permettent de voir tout ça. Et c'est vrai qu'à l'usage, ça marche bien.

• Speaker #0

  Au final, même sur les sources et tout ça, je m'en sers. Même pour reparcourir vite fait et de ne pas avoir à télécharger, même sur mobile, c'est super pratique.

• Speaker #1

  C'est ça. Pareil, moi, c'est aussi beaucoup sur les sources que ça me sert. En me disant, ça paraît de quoi déjà ce document ? Est-ce qu'on le garde ? Est-ce qu'on ne le garde pas ? Ou il y avait un bout que je voulais revoir ? Et voilà, donc ça, c'était très cool. Après, on a fait quoi ? On a complété aussi la partie invité. pour la rendre, maintenant qu'on avait un peu toutes les autres briques, il y a eu des choses où je me suis dit ça, ça ne va pas être cohérent, il faut qu'ils puissent y avoir accès, leur page profite, il faut qu'elle soit remaniée un peu. Voilà, on a travaillé un peu ça. Et aussi, oui, si, important, et que je t'avais dit avant, c'est que du coup, j'ai intégré tout un système de ticketing dans le... Enfin, un système simple pour faire des tickets, mais les personnes, que ce soit Lulu, les invités, peuvent... créer des tickets de support directement et déposer des captures d'écran ou une vidéo ou tout ça pour me montrer qu'il y a un bug ou il y a ça où je n'ai pas accès. Ou alors, ce serait bien qu'on ait ça dans la plateforme. Et voilà, on s'en est servi.

• Speaker #0

  Et en plus, ça prend le dernier lien avant d'aller sur la partie support. Donc, ça peut le remplir directement. Ça, c'est cool aussi.

• Speaker #1

  Avec un système de statut, de notice, qu'il a fallu aussi un petit peu calibrer, parce qu'au début, ça avait soit pas de notif, soit des notifs tout le temps. Il y a eu toute une partie de taf, justement, sur la partie résilience des données. Donc, le fait de mettre en place... résilience des données versionning, c'est-à-dire que maintenant dans l'application, on a la trame avec différentes versions, mais on a aussi les autres éléments, s'il y a quelque chose qui est supprimé, en fait il n'est pas réellement supprimé, il part en archive et on est les seuls avec Lulu en tant qu'administrateur de l'espace à pouvoir supprimer définitivement ou alors restaurer ces éléments. Et ça s'applique à tous les éléments qui sont dans la plateforme, que ce soit des tâches, que ce soit des documents qui sont supprimés, que ce soit des... Les commentaires ne sont pas supprimables, mais ils peuvent être archivés. Il y a l'ensemble de ces choses-là qui sont comme dans une application normale en production où ça doit disparaître de l'interface, mais ça reste stocké au moins pendant un temps en base de données si on a besoin d'y revenir, si ça a été une mauvaise manipulation et tout ça, avec aussi un traçage de qui a fait quoi et la sécurité de se dire que les gens ont le droit de faire telle ou telle action et de voir qui a suivi. Et on s'est fait aussi une page d'administration qui nous permet de gérer tous les comptes depuis un endroit, qui nous permet d'avoir accès à des logs, à la corbeille, à la restauration, un journal tout-dit. Enfin voilà, globalement sur notre V2. Là, aujourd'hui, on fera une vidéo, un peu de présentation si jamais vous voulez venir voir le portail. Plutôt à la rentrée parce que là, on part en vacances à la fin de semaine et c'est pas dans les sujets prio d'avant-vacances. mais en tout cas pour la rentrée on vous mettra à disposition un petit peu ça pour que vous puissiez voir à quoi ressemble notre portail qu'on utilise tout le temps et en plus d'ici là il aura été mis aussi dans la main de plusieurs personnes qui vont les voir en avant-première oui et d'où remonter des bugs qu'on a jamais eu tous les deux et que je sais pas forcément des petits quacks qu'on a pas vu passer même si aujourd'hui l'AP sécurisé a été bien je pense qu'on a vu l'essentiel des petits pépins mais bon quand t'as des personnes extérieures qui arrivent dessus, forcément des cas que t'as pas anticipé ou que t'as pas vu qui surviendront mais on vous montrera ça et en tout cas moi j'en suis très content moi aussi,

• Speaker #0

  j'en attendais je me dis c'est sûr qu'on aurait pu le faire en no code mais en même temps là c'est tellement fluide avec vraiment nos process et c'est trop trop bien à utiliser il n'y a presque pas de point de friction c'est plus de me dire ah bah tiens qu'est-ce qu'on pourrait rajouter pour rendre encore le truc mieux en tout cas je pense qu'il n'y a pas de soucis à se faire, j'ai plein d'idées à rajouter dessus et voilà

• Speaker #1

  Oui parce que en gros la version 2 elle est plus ou moins finie, il y a une chose qu'on avait décidé avec Lulus c'était de voir si justement ça valait le coup côté UX et UI design interface et après la partie aussi plus suivie et plus jolie, s'il y avait des choses à améliorer et ajuster un peu, notamment sur notre page tableau de bord qui aujourd'hui est fonctionnelle, mais qui pourrait probablement être un peu plus jolie.

• Speaker #0

  Oui,

• Speaker #1

  Et voilà, tu as déjà identifié des pistes dessus. Mais aujourd'hui, en fait, tout est... En vrai, tout est fluide et fonctionnel de bout en bout. C'est juste qu'il y a une ou deux pages où on se dit, ouais, on pourrait avoir quelque chose de plus quali. C'est la seule chose qui manque pour NV2. Et en vrai, les prochaines versions... On sait déjà que ce sera plutôt le fait d'intégrer des fonctionnalités que tu avais évoquées, notamment pour la gestion des templates. En gros, ça prend les applications que tu as faites aujourd'hui sur ton poste en perso, d'en faire des versions utilisables dans notre portail pour que ça puisse nous servir pour nous ou pour nos invités. Comme tu l'évoquais, justement, le fait qu'ils puissent se faire un visuel aux couleurs du dernier clic en déposant leurs photos et leur logo, par exemple, des choses comme ça. Voilà, mais en fait... Vraiment, à part là, justement, design, les prochaines versions, ce sera ça.

• Speaker #0

  On avait pensé, effectivement, on a les épisodes et projets par... Enfin, un épisode est un projet avec les tâches et les différentes étapes. Sauf qu'il y a d'autres projets hors épisode qui vont potentiellement se rajouter au dernier clic. Donc, il faudrait quelque chose, un peu événement à suivre ou gestion de projet, mais qui ne sont pas des épisodes et qui vont arriver. Mais ça, on l'a mis un peu en stand-by parce que tu avais plus de deux minutes sur GitHub.

• Speaker #1

  Oui, alors ça c'était...

• Speaker #0

  Et ça c'est vrai que ça, je ne sais pas si tu veux prendre vite fait le temps de l'expliquer, parce que moi ça me semble encore un petit peu obscur, enfin pas obscur, mais il faut en prendre compte aussi.

• Speaker #1

  En très court, mais en fait ça dépend. Ça dépend vraiment de comment tu gères tes tests et ce que tu mets dedans. Mais en gros, quand on vous déploie avec GitHub, donc je ne vais pas réexpliquer tout GitHub et tout, enfin vous avez, voilà, on a fait un épisode sur le développement logiciel, on en parle, mais en gros quand on le... code est prêt et qu'on l'envoie en production, vraiment, il va y avoir des étapes qui vont passer de test et après de déploiement. Et en fait, par défaut, sur GitHub, notre outil sert pour le versionning et pour l'hébergement du code. C'est lui qui va se charger de ces parties déploiement et d'envoyer vers le front, vers Cloudflare, les différents éléments, afin d'exécuter certains tests. et justement de faire le relais vers le front et de faire transiter le code après l'avoir testé. Et donc par défaut, GitHub en gratuit ou même l'abonnement payant à 4 euros vous donne accès à un certain nombre de minutes par mois où ce qu'on appelle la CI, les GitHub Action, où en gros vous allez avoir du temps de traitement qui est disponible pour faire ces tests, pour faire des déploiements vers différents environnements, etc. Et en fait... J'avais mis beaucoup trop de tests en production, globalement, et j'avais mis trop de tests complets pendant un temps, même sur mes branches de déploiement, etc. Et ce qui fait que chaque fois que je déployais une nouvelle fonctionnalité, j'allais consommer des minutes de test pendant beaucoup trop longtemps. Donc en fait, mon app était très sécurisée et très bien testée à chaque fois, mais la contrepartie, c'est que du coup, ça l'était trop et que ça me pénalisait. C'est quelque chose qui n'est pas forcément nécessaire quand on travaille directement. Notre premier environnement de travail, il est ce qu'on appelle en local, donc il est sur notre machine. Parce que tout ça, on n'a pas besoin de passer par GitHub et de consommer de ce temps-là quand on le fait de cette manière. Et moi, j'en consommais parce que j'utilisais les branches de Superbase. Donc j'utilisais un environnement qui était déjà en ligne et qui était déjà comme la production. Du coup, tous les tests que je faisais... enfin pas tous mais quasiment tous les tests que je faisais du coup étaient réalisés sur cette branche donc réalisés en ligne et donc passés par des protocoles sécurisés et par mon GitHub. Il y a aussi une raison là-dessus c'est que du coup j'avais un certain nombre d'informations secrètes des mots de passe, des accès, des choses comme ça qui sont stockés dans un truc exprès sur le GitHub ce qui fait que mon cloud ne les connaît pas, ses infos il n'y a pas accès, il va Euh... brancher en gros le code vers certaines variables pour qu'au moment où les tests se déroulent, ce soit GitHub qui les alimente et après GitHub qui déroule les tests avec des moteurs dédiés qui sont là juste pour ça. Et c'est ça qui consomme du temps. Est-ce que c'est déjà plus clair ? Oui,

• Speaker #0

  c'est bon, je l'ai un petit peu mieux. Et là, maintenant, il y a pas mal de tests que tu as passés en local ou tu as revu un petit peu.

• Speaker #1

  Avant de passer en local... J'ai juste mieux pensé, mieux hiérarchisé et mieux géré mes tests. C'est-à-dire que j'avais des tests qui étaient complets, que je n'avais absolument pas besoin de faire à chaque fois. Donc, je les ai mis en déclenchement manuel que de temps en temps. J'avais des tests aussi également pour valider notamment l'envoi d'email et des choses comme ça, même chose en fait que j'ai réduit à l'essentiel. En fait, le principe, c'est de se dire quand on fait les tests en production, à chaque fois, il faut qu'il y ait des tests essentiels pour s'assurer qu'on n'a pas cassé de bloc majeur. Donc, au moins que la partie authentification fonctionne encore, au moins que l'envoi de mail fonctionne encore, tu vois, une petite sélection qui, elle, doit être faite à chaque fois. Et après, les tests complets, normalement, tu dois les avoir tous faits avant la production. Et une fois de temps en temps, tu peux te permettre de les faire aussi une fois en production, pour t'assurer, une fois de temps en temps, que, ok, tu as tout qui va bien. Les fameux tests automatisés dont on a tant parlé, d'ailleurs, sur les précédents épisodes. Et le truc, c'est que moi, même quand j'étais sur un environnement de preview, donc un environnement de pré-production, ça me consommait du temps comme si j'étais en production, puisque je passais par GitHub et tout ça avec Supabase. Mais là, effectivement, ça va beaucoup changer. C'est en train de beaucoup changer puisque je bascule. Je suis sur le point de migrer notre Supabase de sa version cloud qui est hébergée chez Supabase. sur un serveur Europe, je ne sais plus, je crois que je l'ai mis à Paris, vers une version auto-hébergée, hébergée par Elestio, on vous mettra le lien, qui est une boîte... qui fait de l'infra, ou globalement, enfin d'accord, je dis de l'infra, qui est là en gros pour gérer des serveurs et qui va vous mettre à disposition, par exemple, un Supabase déjà bien paramétré sur une machine de votre choix. Vous l'hébergez sur un serveur allemand, sur un serveur français, sur ce que vous voulez, et eux, ils font office de prestataire informatique qui vous paramètre du coup tout ça. L'objectif étant que qu'on puisse, avec le LULU, basculer vraiment sur une version open source. de Supabase donc vraiment sans être en permanence en fait en ligne chez Supabase qui reste un acteur eux ils sont quoi ils ont deux sièges sociaux je crois aux Etats-Unis à Singapour mais bref du coup ils sont soumis au cloud act et déjà parlé plein de fois dans le dernier clic on essaie de sortir autant que possible des outils américains pour aller vers davantage d'outils européens et là en gros le moteur qui permet de garder les informations de notre portail faire ça me permettra de l'avoir donc là dans un premier temps sur un serveur allemand mais du coup LSTO dont je viens de vous parler est une boîte aussi européenne donc en gros j'aurai un prestataire informatique européen qui me gère l'infrastructure et dessus je peux y mettre mon code et ma publie, enfin toute ma base de données tout mon super base et le gérer comme ça et donc là c'est l'objet d'avant les vacances, la migration complète de notre portail et en passant comme ça en fait tous les tests je vais les faire sur un environnement comme j'avais jusqu'à présent de preview ça, ça n'est pas disponible dans les versions en dehors du cloud de Superbase. Donc, je vais basculer tous ces tests-là en local et en faisant ça, effectivement, je n'ai plus à consommer de temps d'action. Donc, en fait, en basculant de cette manière, GitHub va juste maintenant me servir vraiment d'endroit de stockage de code global. Et après, je vais mettre en place des process différents pour... Enfin, très différents de ce qu'on a aujourd'hui. pour faire tous les tests et après envoyer le code qui va bien, que ce soit sur notre serveur et après sur Platflair également. Sur Platflair, ça va rester un peu comme avant, entre guillemets. Est-ce que c'est plus clair pour toi ? Est-ce que tu as d'autres questions sur ça ?

• Speaker #0

  Peut-être juste préciser pourquoi tu veux passer par l'Est I.O. et pas juste prendre un serveur toi et auto-héberger dessus. Parce qu'ils permettent des... Un peu plus de facilité côté DevOps. Alors,

• Speaker #1

  c'est plus que de la facilité, parce qu'en fait, eux, ils te gèrent vraiment paramétrage, installation, des backups automatiques, des mises à jour automatiques si tu le veux. L'environnement, il est parfaitement configuré de base. Il y a un support. Alors, tu as plusieurs niveaux de support. Tu peux payer pour des... Si tu as une application, par exemple, avec beaucoup d'utilisateurs, tu peux payer un... Je crois que le niveau de support, il est à 50 balles par mois. Et du coup, dès que tu as un pépin, tu peux les solliciter. Après, tu vas mettre du paramétrage que tu vas faire dans ta config. C'est-à-dire qu'ils te mettent un environnement qui est prêt à l'emploi. Et ton SuperBase a déjà installé tout ça, mais tu peux aller modifier les différents réglages, les différentes options. Tu peux te faire ta configuration à ta sauce, mais en cas de pépin, en gros, ils sont là. Tu peux les solliciter et tu peux aussi faire évoluer ton serveur vers des serveurs plus puissants, des machines plus puissantes. Parce qu'en fait, que ce soit Supabase ou d'autres, c'est le cas avec pas mal d'outils no-code, en tout cas avec des outils comme Supabase. D'un point de vue tarifaire, c'est très intéressant sur les petites infras au début, puisque en gros, par exemple chez Supabase, vous allez payer 25 balles pour votre abonnement pro qui fait aussi des sauvegards, qui donne un que ça, plein de choses, et vous allez en gros rajouter, au minimum c'est 10 balles par projet que vous allez faire derrière. Et ensuite vous pouvez payer un peu plus cher pour augmenter les ressources. quand vous commencez à payer plus cher chez Supabay ça va vite très haut et très fort par rapport aux ressources qui vous sont disponibles. Chez Elest ça vous coûtera quand même nettement plus cher que si vous prenez directement votre serveur chez OVH ou chez Scalway ou chez un hébergeur comme ça mais en fait si vous prenez directement chez OVH vous êtes responsable de absolument tout dessus et en cas de paypal vous vous démerdez Euh... Et l'Est, moi je voulais aller dessus. Alors je verrais, peut-être que ça ne va pas bien se passer. Si, je sais qu'eux ils bossent bien parce que j'avais eu pendant un temps du N8N dessus. Pareil, que je n'avais pas envie d'héberger moi-même sur du Hostinger et de faire attention à la sécurité, sauvegarde et des choses comme ça. Et en plus j'avais eu des pépins dessus de mise à jour, mais du coup c'est eux qui me l'avaient débloqué à chaque fois. Et tu vois, les deux ou trois fois où j'ai eu besoin d'eux, je frappais à eux et en une heure c'était bouclé. Alors ils m'avaient répondu, traité le problème et re-répondu. Et je... voilà. en gros pas du tout envie de faire moi-même la partie développement opération ce qu'on appelle DevOps donc vraiment de gérer l'infrastructure des serveurs parce que c'est un boulot à part entière et qu'il y a plein de choses donc

• Speaker #0

  Dans le vibe coding un peu avancé, c'est une chose de faire des passerelles, de faire des ponts, de travailler, d'aller toucher à 2-3 variables d'environnement à des endroits, mettre un petit peu la main dans le technique, comprendre les grandes lignes de ce qui se passe. Et c'en est une autre de gérer toute une infra correctement de bout en bout et d'être alerte sur les différents sujets. Et là, je sais que j'ai un prestataire qui me fait ça. Si à un moment, je me sens dépassé ou qu'il y a des galères et que j'ai vraiment besoin d'un BIC, il t'a payé un peu plus de support pendant un temps, c'est jouable. Et pardon, du coup, je me rends compte que j'ai fait une digression, je n'ai pas fini tout à l'heure. Ce que j'étais en train de dire sur la partie plus chère, tout ça, c'est que du coup, chez Lest, si vous montez de serveurs en capacité et en puissance, ça vous coûtera quand même beaucoup moins cher à ressources équivalentes que chez du Superbase en cloud, par exemple. Mais ça me coûtera quand même beaucoup plus cher que si vous les vergiez vous-même directement, enfin, vous le managez vous-même sur du VH. Mais voilà, tout ça pour dire que le DevOps, je n'ai pas envie d'en faire, sauf truc indispensable que je n'ai pas le choix dans le cadre du développement. Et au moins, Eleste, si ça se passe bien et qu'avec Superbase sur le vibe coding, ça se passe bien, ça me permettrait de mettre mes différents projets là-bas à chaque fois et de donner le choix aussi aux clients avec lesquels je bosse d'ailleurs dire, ben voilà, soit on met chez Superbase et bon, c'est fiable, ça tient, c'est gros, mais c'est ricain. Soit on a du Superbase dans sa version open source qui va me rendre la tâche plus difficile pour bosser. Ça, par contre, c'est une réalité. Voilà. Il y a plein de choses qui sont moins pratiques. c'est logique mais au moins qui me permet de rester dans un contexte complètement européen les deux points qui viendront après pour ne plus avoir d'US au milieu ce sera justement de ne plus utiliser Cloud Code pour ne plus être sur de l'IA américaine et idéalement aussi de ne plus avoir la partie interface le front-end hébergé chez Cloudflare mais là où il y a quand même toujours un petit pépin, c'est que même si je sors de Cloudflare, la majorité des gens utilisent quand même Cloudflare pour la partie sécurité des fronts, enfin du front, parce qu'ils ont des proxys, ils ont plein de trucs qui sont bien pour la sécurité et pour protéger des attaques et tout, et je pense que du coup, ça, je le garderai quand même au final, cette partie-là, ou un bout de cette partie-là. Pardon, je vais me monologuer pendant je sais pas combien de temps, mais...

• Speaker #1

  Non, ça va, c'est intéressant. Enfin, ça donne un peu des retours d'expérience aussi, et ça c'est... pas forcément trop de choses qu'on voit. Donc c'est pour ça, même si les personnes qui nous écoutent ont des questions, il ne faut pas hésiter à venir demander pour clarifier des choses et on pourra répondre aux épisodes d'après. Et c'est vrai que là, il y avait toute la partie événements, et puis on s'est dit, ça on le met pour après, parce qu'on s'est dit, ça serait bien d'avoir quand même une API pour faire des automatisations et le brancher à N8N. Ça c'est aussi la... prochain gros chantier, mais tu voulais déjà avoir migré avant de créer l'API parce que ça aurait été refaire une deuxième fois le travail.

• Speaker #0

  Oui, effectivement. On verra, de toute façon, je vais avoir pendant un mois les deux qui cohabitent. Pas exactement, puisque la partie cloud qu'on a aujourd'hui sera débranchée, mais l'infra existera encore. Et voilà, et d'ici un mois, de voir est-ce que ça se passe bien du coup avec notre nouveau back-end. Est-ce qu'on n'est pas embêté ? Est-ce que je peux développer sans souci ? Est-ce que du coup, on peut naviguer sans souci ? Est-ce que nos invités ont eu des soucis ou pas à l'utilisation ? Si tout va bien, on restera dessus, mais le cas échéant, on reviendra. Et justement, avant d'aller faire effectivement du développement supplémentaire sur mesure pour nous, les automatisations, parce que un des enjeux, c'est de fluidifier, d'automatiser une... une partie de toutes les tâches sur lesquelles on n'a pas de valeur, nous, aujourd'hui. Donc, de déplacer des fichiers, de récupérer ce qui sort du montage pour le mettre à tel endroit, de mettre un visuel sur YouTube, un visuel sur Ausha, toutes ces choses-là, qu'on les a en automatique, pour se garder que les tâches intéressantes. Et donc, pour ça, on va se faire des connecteurs, enfin des connecteurs, ouais, on va se faire une partie API. pour les connexions qui soient spécifiques à ce qu'on a dans notre portail. Le but étant, en gros, qu'à partir du moment où on a enregistré, nous, notre épisode, je récupère les deux fichiers audio qui correspondent à nos pistes audio, ou alors plus s'il y a des invités, mais je récupère les pistes audio de là où on a enregistré. Et en gros, je les mets sur une page de notre portail avec le titre de l'épisode. Et à partir de là, il nous fait... Il nous remplit tout le portail sur l'épisode, globalement. à part le visuel LinkedIn et le post LinkedIn parce que ça, on les fait à la mano, nous. Et ils nous préparent tout le brouillon de chez Ausha. Donc ça, j'ai déjà identifié de quoi j'ai besoin et toutes les étapes et tout, mais voilà, ça a impliqué un peu de développement et je voulais qu'on ait migré avant pour tenir compte des contraintes qu'on a aussi dans la version qui n'est pas en cloud.

• Speaker #1

  C'est vrai que là, ça offre des beaux sujets côté outils. dire comment on aura réfléchi nos automatisations pour essayer d'utiliser aussi le moins d'IA possible ou utiliser l'IA locale. Donc là, ça va être encore des beaux cas d'usage, des beaux chantiers qui vont arriver. Ça va être cool.

• Speaker #0

  Alors là, sur notre première version, ce ne sera pas de l'IA locale, mais ce sera de l'IA en tout cas européenne. J'ose espérer, normalement, à part peut-être pour un point, ça devrait être de l'IA aussi des modèles pas trop costauds.

• Speaker #1

  Je pense même à la partie transcription. Ça, c'est des choses qui tournent. très très bien sur le local mais à voir comment est-ce qu'on...

• Speaker #0

  Pour l'instant la transcription avec Auphonic elle est déjà intégrée c'est du Whisper et du coup ils le font chez OpenAI mais c'est intégré dans le montage donc après on pourrait le faire nous mais en fait ça rajouterait un truc qui est intégré théoriquement dans le premier traitement sur un contenu qui n'est pas confidentiel donc on n'aurait pas forcément de valeur à l'externaliser cette partie-là en tout cas pour le moment mais bon vous l'aurez compris je pense à travers tout ce qu'on a dit c'est qu'un produit est vivant globalement une application et dans une entreprise c'est pareil donc pas forcément sur les mêmes échelles les mêmes besoins etc mais une fois que c'est en ligne et que les gens commencent à s'en servir j'ai envie de dire que c'est un peu que le début parce que là déjà vous avez vu dans tout ce que Lulu a cité on a plein d'évolutions plein de changements parce que je disais ouais la V2 c'est bon elle est finie mais en fait oui des V3 il peut y avoir plein de choses dedans entre Les connecteurs pour les automatisations, la gestion des événements, le rajout sur la partie carousel et les visuels pour les invités, on va avoir de quoi s'amuser sur les prochains mois. Ah oui, et un autre truc qu'on n'avait même pas dit, mais ça sera aussi branché à notre site web. Notre site web va mettre un peu de temps aussi à arriver. C'est parce que Lu nous fait un musée. Littéralement. Et en plus du fait que ce soit un musée, on va vous mettre à disposition énormément de ressources. Donc petit à petit, vous n'aurez pas tout dès le début parce qu'il y a un peu trop de choses qu'on a en tête et que ça va prendre du temps. Mais déjà, par défaut, toutes les sources qu'on met aujourd'hui sur les épisodes qui sont de la bibliographie, ça alimentera aussi le site. Donc vous pourrez retrouver ces informations directement. Et voilà, il y a des choses qui vont servir de notre portail. Notre portail va vraiment faire office de hub, enfin de point. centrale de l'information sur lesquelles on va rajouter différentes fonctionnalités nous autour et qui allait nous entrer dans une partie de site web et après d'autres choses. Donc un produit est vivant. Vous avez besoin de le travailler dans la durée et c'est pour ça qu'on est enfin je veux pas t'inclure dedans mais en tout cas c'est pour ça que je suis aussi chiant sur les tests sur la sécurité, sur la confidentialité sur tous ces trucs là parce que j'ai en tête que voilà que ça va... Ce qu'on fait aujourd'hui, en tout cas, côté le dernier clic est pensé pour durer, mais dans le cas d'une application, c'est normalement la même chose que vous ayez en tête pour vos utilisateurs et utilisatrices. Ça veut dire que l'app doit durer dans le temps, elle va avoir des bugs et des soucis qu'il faudra corriger, donc il faudra pouvoir être en mesure d'identifier ce qui ne va pas dans votre app pour les corriger, identifier quand vous avez des choses à améliorer, des fonctionnalités à ajouter, trancher aussi sur quand est-ce que c'est le bon moment ou pas de les faire. Parce que c'est bien d'avoir un peu de recul, d'avoir un peu éprouvé les différentes choses. Qu'est-ce qui vaut le coup ou pas ? Parce qu'il y a des choses qui ne sont pas nécessaires à développer, qui sont superfus au vu du jeu. Si c'est pour s'en servir deux fois dans l'année, ce n'est pas la peine de faire une fonctionnalité, il faut le faire à la main. Si ça doit être fait, utilisé chaque semaine, ou en tout cas régulièrement par des personnes, là, ça a du sens. Et voilà. Après, il y a d'autres sujets aussi sur les sauvegardes, comment on se les met en place, comment on s'assure qu'en cas de pépin, on puisse continuer à bosser. Ça, c'est un sujet sur lequel on ne s'est pas penché pour l'instant parce que le portail est encore trop frais. On est à deux, donc on s'organise, on bossait sans portail avant, mais dans un contexte d'app en production, vous devez aussi normalement avoir un plan de continuité, je crois que c'est ça, ou de continuité et reprise d'activité, il me semble que c'est les deux intitulés, qui consiste à se dire, OK, demain, mon app n'est plus accessible du tout, comment je fais ? Ou est-ce que j'ai accès à la même information ? Est-ce que je peux avoir accès à une application en mode dégradé qui me permette quand même de bosser ? Le cas échéant, est-ce que j'ai accès à des backups et des sauvegardières pour aller récupérer des choses et pouvoir les remonter en cas de pépin ? Voilà, ce genre de choses qui font que ça se pense dans la durée, une application.

• Speaker #1

  Ça et de se demander, pour moi là, on disait c'est important d'avoir une base solide et bien documentée parce que pour l'instant, et on en a déjà parlé, L'IA reste abordable, en tout cas les modèles frontières restent abordables, mais qu'est-ce qui se passe si ce n'est plus le cas, où il n'y a plus accès, il faut que ça puisse être maintenu, au moins maintenu sur les fonctions vitales, avec des modèles qui sont peut-être moins puissants, plus petits. C'est vrai que c'est encore pas mal de questions. Je pense qu'on va profiter que les modèles soient encore accessibles. pour essayer de faire une transition un peu douce et pouvoir tester un peu des deux côtés, voir si on arrive à avoir la même efficience, la même efficacité. Et plutôt que de se retrouver au pied du mur du jour au lendemain, c'est plus possible de les utiliser. Maintenant, on est obligé de tout changer un peu, comment dire, de manière un peu à la va-vite et de ne pas forcément bien le faire. Ça va être aussi... à gérer en parallèle des nouvelles features à ajouter, des bugs à corriger. Donc, c'est tout un système à penser.

• Speaker #0

  Oui. Et d'ailleurs, là, c'est vrai que je... Enfin, il y a des points que je n'ai pas évoqués tout à l'heure, notamment quand je parlais du Supabase qu'on va héberger chez LSTO. Un des intérêts aussi de ça, c'est que, en fait, là, par exemple, si on gardait notre backend chez Supabase, demain, Supabase, acteur ricain... pour un motif d'administration ou légal, parce que là, il y a eu des choses qui ont été invalidées dernièrement. Potentiellement, on se retrouve avec un petit trou juridique ou des galères, en tout cas, sur le fait d'utiliser des outils américains pendant un temps. Plus que potentiellement, c'est très probable. Mais bref, scénario catastrophe, on n'a plus le droit d'utiliser des outils américains ou Supabase est coupé pour X raisons. Aujourd'hui, on perdrait notre portail. Parce que tout le moteur est dessus. Donc, bien sûr, on pourrait partir de sauvegarde pour remonter la chose ailleurs et tout, mais en fait, tout le boulot que je suis en train de faire là de migration, il faudrait le faire de zéro. Et sur une application qui, là pour l'instant, ça va, elle n'a que quelques mois d'existence. Mais quand vous avez une app qui est vide depuis deux ans, trois ans ou plus, ce n'est pas du tout le même taf de remettre ça en état et de le redéployer ailleurs.

• Speaker #1

  D'où l'intérêt aussi de le faire à ce moment-là, même si on se... on aurait pu se dire, oui, mais c'est plus important de développer de nouvelles features, d'avancer sur le portail. Là, c'est sûr que ça retarde la suite, mais en même temps, plus tu attends, plus c'est compliqué de migrer. Après, il y a d'autres choses, effectivement, qui vont se rajouter aussi. Même là, te dire, ok, j'ai réussi ma migration, ça veut dire que la prochaine fois, je pourrais développer mon app directement là-dessus aussi, sans passer. par le cloud Supabase et ça sera mieux. Enfin, après, on se dit, voilà, on peut très bien se dire, bah oui, mais pourquoi, à quoi bon faire tout ça ? Parce que pour l'instant, on n'est pas obligé. On peut encore utiliser de l'IA autant qu'on veut. On peut encore utiliser les outils US, mais c'est un peu comme le changement climatique. Pour l'instant, oui, on peut continuer à prendre l'avion, on peut continuer à faire... plein plein de choses mais est-ce que ça vaut pas le coup de commencer à s'habituer et perdre un tout petit peu en confort pour le faire bien et le faire aussi de la manière qu'on veut enfin en transition plutôt que du jour au lendemain de ne plus pouvoir le faire et de se retrouver et de devoir le faire comme tu disais à l'arrache pas dans les bonnes conditions et tout quoi ouais

• Speaker #0

  et après là je parlais du truc un peu raide où ça coupe les accès mais sans aller jusque là il y a juste l'augmentation des coûts demain je suis pas baise au lieu de faire la bonheur à 25 balles ils le font à 100 balles et en fait sur la frappe qu'on a besoin ils font un peu plus encore ce genre de choses les coûts peuvent potentiellement exploser ça on l'a déjà vu et on l'a vu aussi sur ma chaussée professionnelle il y a eu un gros moment avec VMware notamment qui permettait de la virtualisation dans les boîtes qui a fait je sais plus combien de pourcents ils ont augmenté mais c'était très très très raide et en fait les boîtes sont en grosse galère parce que énormément de logiciels tournés sur des machines virtualisées comme ça depuis des années et les mecs étaient partout mais en fait juste voilà, ils étaient partout il y a des alternatives qui existaient déjà mais en tout cas c'était un outil professionnel tellement... ancré que quand ils ont tout le monde a gueulé mais ça les a pas empêché de monter les prix de manière féroce et donc là le fait d'avoir tout ça sur Elest enfin sur un serveur du coup managé par Elest c'est aussi une histoire de résilience parce que demain en fait Elest monte ses tarifs ça me va pas mais j'ai juste besoin d'une infrasuper base sur un serveur et je peux redéployer tout ce que j'ai Donc globalement, je peux aller voir le premier développeur un peu calé en infra qui gère ça, un prestataire, une agence, une boîte, qui me refait un serveur propre et qui reprend la gestion de l'infrastructure, et je n'ai plus qu'à redéployer mon code dessus et mes données dessus, etc. Et donc ça fait que je ne suis pas prisonnier d'Ellest, pas prisonnier de Supabase, et du coup on a une infra qui peut vraiment être redéployée ailleurs. Pas se mentir, c'est toujours pénible si jamais il faut quitter LS pour se remettre ailleurs et tout. Mais en tout cas, l'infrastructure qu'il faut derrière, les moyens qu'il faut derrière sont complètement abordables. Et quitte à repasser, payer un dev pour qu'il fasse le montage propre et même peut-être la migration lui-même, typiquement, en tout cas, c'est quelque chose qui se fait sans IA, qui se fait très bien. Et derrière, il y a des coûts d'infrastructure cohérents. Oui, du coup, complètement accessible. Je mets un petit bémol avec la crise de l'infrastructure liée à l'IA qui a fait qu'il y a plein de pièces et de choses qui coûtent un bras pour rien. Mais en tout cas, c'est carrément à la portée de n'importe quelle boîte. Et du coup, sur les autres points de souveraineté, il y aura le fait, comme on disait, de quitter du cloud code à un moment. Idéalement. Moi, ce que j'aimerais tester, alors ce que je visais d'ici fin août, mais je ne sais pas si ce sera effectif d'ici fin août, de basculer de Cloud Code à Open Code avec des modèles hébergeurs d'Europe. On verra, mais en tout cas, c'est l'objectif cible aussi. Même si derrière, peut-être que je garderai du Cloud Code et les deux qui cohabitent, mais dans l'intention, ce serait de ne plus être prisonnier d'un écosystème quel qu'il soit, dans la mesure du possible, toujours pareil. Mais en tout cas, aujourd'hui, on commence à avoir assez d'options open source pour avoir des alternatives, même si effectivement, c'est plus galère. Et même si aujourd'hui, le monde du LLM et des IA est très incertain sur la fin d'année et sur comment ça va tourner vis-à-vis des différents camps, que ce soit américains avec les modèles frontières, les chinois avec les modèles open weight et nous en Europe. avec ce qu'on va bricoler, plus ou moins.

• Speaker #1

  J'allais dire du vent par rapport à Mistral, mais...

• Speaker #0

  Ouais, mais non, c'est un peu méchant. Même si, voilà, j'aime pas trop leur modèle, mais n'empêche que... Là,

• Speaker #1

  j'ai vu que Microsoft avait investi de fou dedans, justement, pour pousser un peu plus Mistral en Europe. Mais voilà, après, comme tu dis, on peut, dans un premier temps, garder un abo Claude à côté. Et c'est toujours un peu cette idée, c'est de... pas se retrouver à devoir le faire dans l'urgence et prendre le temps de prendre ses marques, de faire des tests aussi tout simplement, de se dire bah tiens je demande exactement la même chose à mes deux systèmes et je peux les faire tester derrière pour certifier s'assurer qu'on a les mêmes performances ou en tout cas que c'est tout à fait ok pour nous plutôt que de se retrouver du jour au lendemain à devoir prendre des outils qu'on n'a pas forcément pu tester, qu'on n'a pas pu prendre en main. Parce que oui, on peut toujours remettre à plus tard en se disant là, pour l'instant, autant en profiter au maximum tant que c'est pas trop cher, mais ça fait développer des habitudes qui ne sont pas très saines non plus par rapport à ça, parce qu'on augmente notre dépendance quand même. Ça, c'est aussi des questions à se poser. Parce que oui, le marché, même le monde des LLM est très incertain, mais le monde aussi en lui-même est très incertain. Même en discutant avec d'autres personnes dans le milieu du logiciel, c'est très incertain aussi. Donc c'est important de rester résilient, de ne pas se fermer à un seul outil, à un seul modèle, et de continuer à développer nos compétences et notre esprit critique, ça me semble bien.

• Speaker #0

  Oui, j'ai vraiment d'accord. Et j'ajouterais quand même un point, parce que c'est vrai qu'on en avait parlé il n'y a pas longtemps, tous les deux, et que personnellement, ça me choque aujourd'hui d'un développeur ou d'une développeuse qui est une... n'utilise pas un peu de IA générative dans son taf sans faire du vibe coding et qu'il fasse tout son code à sa place. Mais aujourd'hui, il y a quand même dans la partie développement, dans le sens où l'IA a prouvé complètement sa valeur et sa pertinence, c'est dans le développement logiciel.

• Speaker #1

  D'ailleurs, j'avais vu des études qui sortaient. De là où les coûts explosent et où on n'a pas de rentabilité, c'est des personnes non techniques qui utilisent l'IA. Donc pour des choses qui auraient pu être faites autrement aussi, sans utiliser d'IA. Et là où par contre il y a quand même de la pertinence, c'est dans le code. Alors après il y a aussi des dérives de ce côté-là, parce que là on se retrouve à générer beaucoup, beaucoup, beaucoup de code. Pas forcément de la bonne manière. Et où il y a le goulot d'étranglement maintenant, c'est sur la review de code. tout ce qu'il y a au-dessus. Et le problème, c'est que ça mène certains développeurs aussi à tout ce qui est Brainfry, de se demander à quoi je sers aujourd'hui. Est-ce que je ne fais que relire du code généré par de l'IA ? Ça, c'est aussi des sujets qu'on va explorer à partir de septembre. Donc ça, ça va être très, très cool. Mais voilà, il n'y a rien de certain, il n'y a rien de fixe. Il faut tout prendre un peu avec nuance. Et il faut s'y intéresser. On peut choisir de ne pas l'utiliser, mais en connaissance de cause. Et il faut quand même s'y intéresser, parce que c'est aujourd'hui un sujet de société, c'est politique, c'est géopolitique. Si on ne se l'approprie pas, alors pas dans le sens où on va devoir l'utiliser et tout ça, mais si on ne se l'approprie pas, c'est d'autres personnes qui vont se l'approprier et qui vont choisir un peu le futur vers lequel on va. Donc voilà, ça implique énormément de choses. C'est en train de changer. assez profondément nos sociétés, notre travail, notre rapport aux autres, notre rapport à l'information. Donc oui, il faut se saisir de ce sujet et s'y intéresser.

• Speaker #0

  Complètement d'accord. On a encore fait très court.

• Speaker #1

  Ce sera peut-être notre deuxième plus long épisode.

• Speaker #0

  Celui-là, on s'était dit justement que c'était le troisième parti et qu'il y aurait moins à dire. Voilà. En tout cas, on espère, à travers ce triptyque plus l'épisode dédié vraiment au développement logiciel qu'on vous aura donné. On a aperçu un peu plus complet de ce que nous, on voit, en tout cas, vis-à-vis du vibe coding, des choses qu'on a expérimentées, de comment on s'en est servi, un peu en tout cas de notre vision et nos points de vue sur le sujet. On espère aussi que ça vous aidera à un peu mieux voir ce que ça implique de développer une app de bout en bout, et en quoi justement le vibe coding un peu magique qu'on peut vous vendre dans des formations, dans des ateliers, dans des vidéos, dans des... post-LinkedIn, dans tout ça. Voilà, faites attention et partez du principe que, oui, l'exécution peut être plus rapide, mais il y a quand même beaucoup de choses autour qui sont importantes et même sur des applications juste pour soi, sur son ordi, vous avez vu, quand je lui en parlais, il y avait quand même un certain nombre de choses à avoir en tête et de garde-fous. Voilà, c'est une chance, je pense, quand on a une chance d'avoir de la programmation visuelle, de la programmation conversationnelle aujourd'hui, après avoir eu la programmation visuelle. Je reste convaincu qu'un des meilleurs moyens d'appréhender ce sujet, c'est de passer par de la programmation visuelle, donc de passer par des outils no-code avant pour voir un peu ce qui se passe quand on se pose les questions en fait, quand on essaie de mettre en place Au revoir. une idée, une solution et de voir un peu les différentes étapes et différents points qu'il va y avoir. Du coup, ce n'est pas forcément nécessaire, mais en tout cas, c'est ce que je recommanderais. Et quand vous allez après directement sur la programmation assistée par l'IA et la programmation conversationnelle, ne faites jamais, ne donnez jamais, pas de confiance aveugle à l'IA. J'ai des mots, vous avez compris. Et comme tout, c'est des méthodes, des process de littération. Et voilà, je pense qu'on a fait un bon tour de tout ça. Est-ce que tu veux ajouter quelque chose, Lulu ?

• Speaker #1

  Non, là-dessus, je pense qu'on a un petit peu divergé, comme à chaque fois, mais c'est là qu'on voit que ça va au-delà de juste développer une app. Ça fait poser plein de questions. que ce soit au niveau de la sécurité qu'on veut mettre dedans, au niveau de la dépendance vers tel ou tel acteur qu'on veut avoir ou qu'on veut un peu minimiser. Donc, ce n'est pas juste faire un prompt et puis c'est parti. On suit un peu avec le mens que Lya a dit.

• Speaker #0

  et voilà remercier les gens qui se sont tapés tous les épisodes là-dessus j'espère qu'ils auront appris des choses quand même j'espère aussi en tout cas merci beaucoup effectivement de nous avoir écouté n'hésitez pas à nous poser des questions que ce soit sur les différents canaux là où ça marcherait le mieux si vous venez nous parler directement sur LinkedIn ou via notre boîte mail En tout cas, vous avez les différents contacts qui sont dans les liens de chaque épisode. Mais après, pour celles et ceux aussi qu'on connaît, il y a d'autres billets qui sont sur la communauté de Créacy, qui sont sur Voslack et tout. Venez nous parler sur le canal qui vous arrange, mais si vous avez des questions, des sujets, des choses que vous aimeriez qu'on aborde ou qu'on clarifie, faites-vous plaisir, venez nous en parler, on est là pour ça.

• Speaker #1

  Et dans mes devoirs du mois d'août, j'ai d'alimenter, de commencer à alimenter l'insta.

• Speaker #0

  C'est vrai.

• Speaker #1

  Voilà. Maintenant que j'ai un générateur de Karoo, c'est bon, je vais pouvoir décliner sous d'autres formats tout le contenu qu'on a. Parce qu'on commence à avoir un petit paquet d'heures d'enregistrement.

• Speaker #0

  On commence à en avoir pas mal.

• Speaker #1

  Oui, oui.

• Speaker #0

  Pour le mois d'août, on sera en vacances. Vous aurez des petits épisodes qui arriveront les différents vendredis. Vous aurez probablement un épisode de surprise un peu plus long. courant dé... enfin voilà, courant août. On n'y est pas plus, vous verrez ce qu'il en est. En tout cas, on est ravis et on vous remercie de nous avoir suivis sur cette première saison du Dernier Clic. On vous invite à écouter bien sûr tous les épisodes qui viendront au mois d'août et qui seront un peu plus détentes, un peu plus courts, un peu plus légers. Et on vous retrouve en septembre pour une nouvelle saison. D'ici là, portez-vous bien, passez de bonnes vacances. Et Lulu, encore merci de m'avoir accompagnée sur cet épisode.

• Speaker #1

  Merci à toi aussi.

• Speaker #0

  Et de toute façon, je te revois d'ici là, toi. Et tu me referas encore plein de tickets de support. Mais voilà, merci beaucoup. On souhaite une très bonne journée ou fin de journée, selon quand vous nous écouterez. Et on se retrouve très bientôt.

• Speaker #1

  Salut.