Transcription

• Manu

  Bonjour et bienvenue sur Le Dernier Clic, votre podcast tech, IA et no-code. On se retrouve comme chaque semaine avec Lulu pour parler de sujets technologiques et d'outils numériques. Comment tu vas Lulu ?

• Lulu

  Ça va bien et toi ?

• Manu

  Très bien. Et on se retrouve cette semaine pour un épisode côté outils qui est un petit peu particulier. puisqu'il va prendre un peu la tournure d'un épisode plus ou moins thématique. L'idée étant aujourd'hui de revenir sur le webcoding, ce que j'aime appeler le développement assisté par IA. On en avait déjà parlé dans des épisodes précédents, dans des côtés outils, c'est un sujet qu'on a évoqué à plusieurs reprises. Et aujourd'hui, l'idée va être de vous en parler de manière un peu plus détaillée pour rentrer vraiment dans la logique de... construction et de ce que ça représente pour nous de faire une application. Pourquoi le faire maintenant ? Alors pour de bonnes raisons. La première, c'est qu'on a fait notre propre portail qui est notre outil au final aujourd'hui qu'on utilise avec Lulu depuis déjà un bon mois et demi, quelque chose comme ça.

• Lulu

  C'est en prod.

• Manu

  Oui c'est en prod depuis un bon mois et demi pour préparer nos épisodes du dernier clic et qui nous sert en fait à vraiment préparer tout l'épisode du début jusqu'au moment où on va le mettre dans notre outil de diffusion et qui nous sert à gérer toutes les différentes étapes donc on reparlera un petit peu après dans le détail de ce qu'il y a dans cette application mais c'est l'occasion de vous parler vraiment d'une application concrète qui a été développée avec de l'IA qui est en production et qui a évolué sur lesquels il y a eu des apprentissages et ce genre de choses et l'autre point aussi qui fait qu'on avait envie d'en parler maintenant, c'est parce qu'on voit fleurir de plus en plus de formations, de bootcamps, d'ateliers qui vendent du vibe coding à tout va avec des promesses du type créer votre site web en une heure de bout en bout, faites votre application, ou pire, faites votre SaaS en trois semaines. Pour rappeler ce qu'est un SaaS, c'est Software as a Service. Globalement, c'est des... outils que vous allez utiliser en ligne. La plupart des outils qu'on a en ligne qui vont fonctionner généralement avec des abonnements où on vous propose un service, on vous propose un programme utilisable à distance et hébergé chez une entreprise, chez un fournisseur du service en question. Et donc aujourd'hui, beaucoup de contenu pédagogique est orienté autour de cette tendance du développement assisté par IA et va le vendre de manière vraiment très... expéditive en promettant de la vitesse en promettant que vous allez pouvoir faire des choses que vous pouviez pas faire avant et il ya beaucoup de choses après enfin voilà il ya un tri à faire là dedans donc effectivement l'IA et le value coding permet de faire des choses qu'on ne pouvait pas faire avant quand on n'était pas un profil un peu technique ou qu'on pouvait faire mais si on accordait du temps à se former sur du développement visuel à travers des outils no code par exemple mais ça reste des outils ce n'est pas magique et si effectivement vous faites par exemple votre site web en une heure, il y a de fortes chances pour qu'il soit complètement bâclé. Parce que si je prends juste le cas et l'exemple du site web, l'exécution technique, la création du code à proprement parler, ne peut prendre qu'une heure, mais sur un site web, on a besoin de réfléchir déjà au contenu qu'on va y mettre, et rien que ça, ça prend généralement plus d'une heure si on veut faire quelque chose un peu cali, et en fonction de l'objectif aussi. Mais si vous voulez faire une page de vente pour vous, normalement vous allez passer bien plus d'une heure. à réfléchir à votre contenu, à le préparer, à mettre des choses dessus. Il y a aussi tout le temps...

• Lulu

  Là, c'est vrai que tu parles aussi du côté formation qui vante du rêve, mais c'est aussi en tant que personne, si on doit passer par un prestataire pour réaliser une application ou un site internet, même si on ne va pas construire de connaître tout ce que ça implique et de ne pas se faire avoir. Parce que bon, on en parlera après, mais ce n'est pas les mêmes niveaux de... précautions à prendre selon ce qu'on va développer. Et vu qu'on va y être, je pense que c'est important qu'on soit tous à peu près sensibilisés à ça, parce qu'on va tous être exposés, que ce soit en tant qu'utilisateur, en tant que, pourquoi pas, décideur et de passer par des prestataires pour développer ce type de contenu ou d'application, ou comme personne qui va en construire, pour soi ou pour d'autres personnes. Ce qui peut devenir un peu dangereux si on ne fait pas gaffe.

• Manu

  Exactement, et alors juste pour revenir sur l'exemple du site web et faire le lien avec ce que tu viens d'expliquer sur effectivement le fait qu'il y a plusieurs niveaux de complexité en fonction de ce qu'avant on va vouloir produire et pour qui on va vouloir produire des choses. Juste pour revenir là sur votre site faire une heure, mais en fait, ça ne tiendra pas compte du contenu que vous avez préparé et qui va prendre déjà vachement plus qu'une heure. Le design et le maquettage aussi, en tout cas de réfléchir à ce qu'on veut, avoir une identité visuelle, une charte graphique. Ensuite, il va y avoir la partie exécution qui, ça, techniquement, peut prendre une heure, mais derrière, il va y avoir des enjeux de test pour voir si ça fonctionne bien sur téléphone, donc si c'est responsive, de savoir si en termes d'accessibilité, ça répond à toutes les normes. De voir si ça fonctionne bien partout et pas juste sur votre machine de manière générale. Si la mise en place du domaine et de la messagerie qui va avec aussi, la connexion si vous avez des formulaires, si vous intégrez des vidéos, si vous intégrez d'autres contenus.

• Lulu

  S'achant qu'au même titre que la RGPD et l'IA Act, le mois dernier, il y a une nouvelle réglementation qui est passée sur l'accessibilité. Donc c'est aussi maintenant à prendre en compte. Ce n'est pas quelque chose qu'on rajoute à la fin pour faire joli live. Il y a des normes et des lois à respecter aussi de ce côté-là. Donc je pense que ça pourrait être l'occasion de revenir dessus aussi à un moment pour creuser un peu ce côté-là.

• Manu

  Oui. En tout cas, c'est effectivement à prendre en compte dans tout développement aujourd'hui, dans toute mise à disposition d'applications. Là, sur le site web, c'était juste pour vous illustrer qu'en fait, la promesse de le faire en une heure fait que techniquement, oui, vous allez pouvoir le faire en une heure en demandant à Claude ou à n'importe quel IAM, en tout cas, en demandant à IAM de vous produire. Mais derrière, pour avoir quelque chose qui soit de qualité et qui réponde à tous ces enjeux-là, il faut un peu plus de temps. On ne parle pas de semaines ou de mois. mais il n'empêche que ça se prend normalement nettement plus de temps qu'une heure pour avoir quelque chose d'un peu qualitatif. Et le fait est qu'il ne faut pas mélanger le fait de pouvoir produire et de créer rapidement avec de l'IA avec le fait de pouvoir produire et créer des choses qui sont adaptées à de la production, des choses qui vont impliquer aussi des données utilisateurs, et de savoir aussi un petit peu s'outiller. c'est-à-dire qu'aujourd'hui vous avez des outils qui vous facilitent un petit peu ça quand on est complètement novice, par exemple un Loveable, va vous permettre, sans avoir jamais rien touché, et sans avoir aucune compétence technique, d'aller discuter avec l'IA, et il va vous faire déjà des premiers jets qui sont hyper intéressants, par exemple sur la partie design. Mais toute la réflexion, tout ce que je vous ai évoqué avant, ça reste à prendre en compte. Et un outil comme Loveable vous permettra de faire une partie site web, mais si vous commencez à aller sur de l'application vraiment, Là, vous allez avoir votre responsabilité sur les données qui circulent dessus, donc sur les données utilisateurs, sur la sécurité, sur l'accessibilité, sur un peu tous les enjeux. Ce n'est pas parce que vous utilisez des outils qui sont plus accessibles et qui sont là pour vous donner l'impression d'aller très vite et que tout soit clean du premier coup, qu'en arrière-boutique, c'est réellement le cas. Il y a d'autres questions à se poser, il y a d'autres enjeux.

• Lulu

  Et c'est là que ça peut être pertinent de rester sur du no-code. Parce que les outils de nos codes vont intégrer en général toute la partie qu'on ne voit pas quand on déplace des blocs pour construire. La partie derrière de déploiement, de connexion si on gère des utilisateurs, d'authentification. Et tout ça, c'est géré par le service qui fournit des applications pour produire nos codes.

• Manu

  Oui, en plus, sachant que l'avantage aussi des outils no-code, c'est que ça oblige à se poser ces questions-là. De se dire comment je vais agencer ma page, qu'est-ce que je vais mettre comme contenu, même si effectivement, si on prend un Webflow ou un Framer ou ce type d'outils, ou même des plus accessibles comme du Card notamment, ils vont vous gérer effectivement tout ce qui est hébergement, tout ce qui est sécurité, tout ce qui est sauvegarde, restauration, les formulaires qui sont déjà intégrés comme tu le disais. et quelque part même quand on a son domaine à soi, par exemple nous c'est ledernierclic.fr, sur ces outils là vous allez avoir deux lignes globalement à toucher dans votre éditeur de domaine pour mettre en place ça et tout le reste effectivement sur la partie sécurité sera très en charge. Sur des outils no-code de type Bubble, de type WeWeb qui vous permettent de faire des applications complètes, là, il va quand même y avoir des enjeux de sécurité de votre côté dans la construction et dans ce que vous allez faire. Donc, vous n'y échapperez pas non plus. Et c'est peut-être l'occasion déjà de revenir un petit peu sur la différence entre... Quels sont les niveaux, au final, d'application un peu différents ? Est-ce que tu veux nous présenter un peu ça, Lulu ?

• Lulu

  Oui. Donc, on a, comme tu as dit, il y a le... site internet, qui va plus être la landing page ou site vitrine, où là, on ne va avoir même pas de CMS, donc Content Management System. Là, on va être sur du contenu, quelque chose de fixe, de statique. Là, c'est... comment dire ? Ça peut être bien pour commencer, se faire la main et itérer dessus, et ce n'est pas là-dessus qu'on va avoir le plus de problèmes de sécurité, même si... Il y a quand même toute la partie accessibilité à prendre en compte, la partie, enfin si on veut, il y a la partie référencement et les performances du site aussi en lui-même. Donc c'est aussi tout plein de choses à prendre en compte que dans des, on va dire, des builders plus classiques, ça peut déjà être pris en charge et on n'a pas trop à s'en soucier. Sinon après, on a aussi le site internet un petit peu au-dessus, donc avec CMS. Donc là, ça veut dire qu'on va avoir... un back-end, et le back-end, c'est tout ce qu'on ne voit pas. C'est ce qui est en arrière boutique, et le front-end, ça va être ce qui va être devant et être affiché, mais les deux communiquent sans cesse. Et ça va être toutes les données qui vont être stockées, donc là, on va avoir des choses qui vont être plus dynamiques dans le contenu sur le site. Je ne sais pas si tu veux rajouter des trucs pour la distinction back-front.

• Manu

  Alors déjà, oui, pour les sites, donc effectivement, tu as bien résumé sur le fait que... En gros, les sites web, ça va être vraiment des vitrines. Donc vous êtes là pour avoir une interface, pour avoir une présentation d'informations, mais vous n'êtes pas vraiment dans l'interaction avec de la logique derrière. Dès que vous allez être sur du site vitrine avec CMS, comme disait Lulu, c'est là où on va voir, par exemple, une partie blog, et du coup, vous commencez à rentrer dans le besoin d'avoir ce qu'on appelle un back-end. Le back-end étant, en fait, à la fois votre base de données, donc là, vous allez ranger les informations. mais c'est aussi l'endroit qui va vous permettre de mettre en place de la logique, de mettre en place des mécanismes qui font que quand vous allez interagir, il va se déclencher telle et telle chose derrière. Donc le back-end, c'est vraiment un ensemble de choses. C'est aussi là que vous allez gérer la partie authentification, donc les utilisateurs. Par exemple, si vous avez un espace membre sur votre site web, de dire qu'il y a un espace, le blog rentre dans le CMS, a besoin d'un fameux back-end pour stocker les différents articles. et les références pour les métadonnées, pour le référencement, ce genre de choses. Mais vous pouvez avoir un espace membre à côté qui est payant pour du contenu supplémentaire. Et donc là, il y a besoin d'avoir une gestion, par exemple, de niveau de droit, de dire en fonction de ce que la personne a payé, elle voit tel ou tel contenu, elle peut interagir avec tel ou tel contenu, elle peut poser des questions, par exemple, elle a accès à un formulaire supplémentaire, toutes ces choses-là. Donc là, on rentre vraiment dans comment ça apporter de la logique et de l'intelligence et du process qu'on a. qu'on va qualifier de métier, derrière. Et après, on va aller sur les applications, les applications web, enfin, les applications à proprement parler. Et donc, là, la partie front-end, back-end va se prendre un petit peu d'ampleur sur les deux sujets. C'est-à-dire que le front-end, c'est vraiment cette interface, c'est la partie émergée de l'iceberg, c'est ce que vous voyez. Quand vous allez naviguer sur un site, sur une appli, c'est vraiment tout ce que vous voyez. Mais dans une application, Quand vous allez utiliser votre outil de travail au quotidien qui est sur votre ordi, derrière, à travers les fenêtres, les pages dans lesquelles vous allez naviguer, à travers vos différents boutons, vos différents formulaires, quand vous cliquez dessus, quand vous remplissez des champs, ça va déclencher à chaque fois différentes logiques, différentes fonctions qui vont elles-mêmes envoyer des informations au backend qui lui va traiter tout ça et en faire des choses. Et vous allez avoir une communication permanente entre les deux et des enjeux qui sont... très fort au niveau du back-end sur l'intelligence et la logique de notre application. Et en revanche, la partie front-end, c'est plus que du visuel. Donc il y a l'enjeu visuel, évidemment. Mais le design va plus loin parce qu'il va aussi impacter ce qu'on appelle la partie UX, donc l'expérience utilisateur, et la partie UI qui va être, elle, pour la partie vraiment plus interface, le fait que ce soit agréable, que ce soit clair de trouver de l'information, que ce soit agréable... comme je l'ai déjà dit, mais que ce soit joli et qu'on prenne plaisir à utiliser l'outil.

• Lulu

  C'est ça, et qu'on ne se retrouve pas avec des fuites de données aussi dans le front, accessoirement. C'est pour ça qu'il faut quand même qu'il y ait une séparation entre les deux, même si c'est un peu plus pourruxable, parce qu'on va quand même avoir des choses qui vont rester stockées dans la partie front pour justement améliorer l'expérience utilisateur. Ça peut être temporaire et tout ça, mais voilà, ça c'est des choses, normalement on n'a pas trop à se poser la question. Et parfois, même en demandant à l'IA, en disant « fais quand même un truc sécurisé » , on peut se retrouver avec des choses en clair. En clair, ça veut dire que ça va être disponible. Sur le front, ça va être visible. Alors pas visible directement sur la page, ça peut être dans le code source, ça peut être en bidouillant un petit peu et on peut se retrouver à retrouver les informations d'autres membres. Des fois, c'est des bugs ou des garde-fous qui n'ont pas été mis en place et des fois, c'est tout bête. Et ça, pour la confiance utilisateur derrière, en termes de légal aussi, c'est pas très bon. Donc, on ne se lance pas là-dedans si on ne s'est pas renseigné un minimum ou on n'a pas fait auditer à quelqu'un qui est du domaine.

• Manu

  Alors, effectivement, sur ces points-là, première chose, aujourd'hui, dans tout ce qu'on vous explique, c'est vraiment pour clarifier un petit peu les différents niveaux entre les sites, les apps, ce qu'on met dans les apps et les différentes étapes qu'on a, en tout cas, nous, qu'on a réalisées pour le développement d'une application et ce qui nous semble fondamental dans le développement d'une application. mais sur la partie technique poussée et notamment sur la sécurité, on vous renvoie vivement sur le vibecoding, et on vous mettra d'ailleurs le lien dans les sources, vers les contenus créés par Alexi Kovalenko, qui crée du contenu sur le vibecoding depuis un moment, plus d'un an, un an et demi, et ils avaient notamment fait un épisode très très bien avec Xavier Garpé, qui parlait de la sécurité, et des choses que Lulu vient d'évoquer, sur le fait que dans l'interface, vous pouvez avoir déjà des failles de sécurité, des trous, d'une. des choses sur des points d'attention qu'il faut avoir en tête. Et derrière, il y en a aussi énormément côté back-end, c'est là où c'est le plus critique. Mais voilà, il y a énormément de choses, notamment dans l'épisode en question, il y a plein de points à prendre en compte. Et voilà, on ne s'aventurera pas ici aujourd'hui, mais on vous invite vivement à aller écouter l'épisode qui détaille davantage tout ça. Mais voilà, gardez en tête que du coup, qu'un site web au sens classique, c'est une vitrine. Et une application, c'est vraiment un outil de travail avec des granularités différentes en fonction du type d'outil, en fonction du besoin, en fonction de ce qui est mis à disposition. Mais c'est un outil de travail, donc les enjeux ne sont pas les mêmes.

• Lulu

  Sachant que même si on fait un site vitrine, on peut, pour le développement, avoir eu besoin de connecter des clés API. Et ça, ça peut se retrouver aussi sur le site. Donc effectivement, il n'y a rien de sensible sur le site. mais s'il y a quelqu'un qui arrive à récupérer ses clés et utiliser votre clé API qui n'est pas censée être utilisée par d'autres personnes, là, vous allez vous retrouver avec quelques problèmes aussi. Donc, ce n'est pas qu'une question de niveau comme ça. C'est de montrer que c'est complexe. Parce qu'on peut se dire, oui, c'est facile, c'est juste une page web. On peut aussi se retrouver un petit peu démuni quand la facture qui arrive et qu'on se rend compte que les crédits ont été beaucoup utilisés.

• Manu

  Oui, d'être. Pour clarifier ça, effectivement, les API, c'est ce qui vous permet de communiquer d'un outil à l'autre. C'est un peu les passerelles qui font le lien entre tout ça. Et une clé API, globalement, ça va être votre clé d'autorisation qui vous permet, avec votre abonnement à tel outil, d'aller vous connecter à tel autre outil. Et en fait, ces clés-là, quand elles sont visibles, comme le disait Lulu, qu'elles n'ont pas été sécurisées et qu'on peut y accéder facilement à travers le navigateur, c'est-à-dire qu'on peut le récupérer, on peut utiliser votre compte en étant authentifié avec votre clé. et utiliser le service en question. Et du coup, comme les services en question qui fonctionnent avec des API sont généralement conditionnés à des abonnements ou à des prêts ou à de la facture à surusage, peu importe, c'est une faille et un trou de sécurité qu'on voit très régulièrement depuis l'arrivée de l'IA. Les fameuses clés API qui sont dites en clair. Donc, ils sont stockés directement dans le navigateur et que n'importe quel pinpin venu qui va sur votre site les voit dans sa page, peut le récupérer et s'en servir. Voilà, ne faites pas ça. et globalement quand une IA vous demande votre clé API de la saisir en clair et de la mettre dans votre fenêtre de conversation pour en faire quelque chose, ne le faites pas il y a forcément d'autres moyens d'intégrer et les outils quand ils sont bien faits vous permettent d'ajouter ce type de clé ou ce type d'authentification à travers des intégrations ou à travers des endroits qui sont déliés sécurisés, cryptés, cachés peu importe selon les outils mais qui permettent de ne pas laisser ça Zzzzz En clair, c'est comme si vous laissiez en permanence votre carte bancaire posée sur votre boîte aux lettres. Globalement, évitez de le faire.

• Lulu

  Ce serait quand même plus sécurisé parce que maintenant avec la double authentification, alors que pour une clé API, il n'y a pas forcément.

• Manu

  Oui, mais si on te la prend pour aller au bar et faire que des paiements sans contact pendant toute une soirée, je pense que ça marche pareil.

• Lulu

  C'est limité à cinq paiements sans contact.

• Manu

  Oui, alors que la clé API n'est pas limitée. Ah si, si tu as mis un plafond, et d'ailleurs si, petit point d'ailleurs. Oui,

• Lulu

  ça c'est,

• Manu

  Petit bonus, bon, s'écarte un peu, on va revenir sur le jeu. Bon point sur n'importe quel outil que vous utilisez qui fonctionne avec un paiement à l'usage, et c'est notamment le cas d'ailleurs des outils d'IA aussi, de plus en plus, et déjà évoqué, ça va l'être davantage quand les abonnements vont plus ou moins disparaître ou partiellement disparaître. Pensez à vous mettre des quotas, des limites d'utilisation. Comme ça, au moins, vous savez qu'en cas de pépin, ça ne dépassera pas le quota que vous avez fixé. Et ça, je veux dire, ça ne sauve des lits peut-être pas, mais en tout cas, ça sauve des grosses factures dans des boîtes, ça c'est sûr. Voilà. Donc, à prendre en compte. Donc, vous l'avez compris normalement à ce stade, développer avec de l'IA va impliquer des choses côté sécurité, va impliquer du taf en amont. Et du coup, le fameux taf en amont, par quand on commence ? Avant de se jeter la tête dans l'IA, dans un prompt, pour qu'elle commence à nous faire notre fameux outil magique ou notre fameux site web. Donc là, aujourd'hui, on veut vraiment orienter sur la partie application. Mais toutes les étapes, enfin pas toutes les étapes, mais la plupart des étapes qu'on décrit peuvent s'appliquer à un site web. C'est juste que là,

• Lulu

  on vous parle vraiment de la gestion de projet pour tout ce qui est en amont.

• Manu

  Oui, je veux dire, dans certaines étapes qu'on va évoquer, qui sont très orientées de dev, il y a des petits bouts qui sont plus adaptés, plus propres vraiment à l'application, puisque là, on parle de notre application, du portail, le dernier clic. Le point de départ de tout, d'un site d'une appli, donc vraiment, pour notre coup, d'une appli, c'est le problème. qu'est-ce qu'on avait comme souci à la base et pourquoi on a voulu se faire nous-mêmes d'ailleurs un portail pour le dernier clic. Parce qu'au début, on a bricolé sans. Oui, c'est ça.

• Lulu

  Et on était assez ambitieux de se dire bon, on fait un épisode par semaine. Alors oui, c'est cool. Bon, on avait dit 45 minutes aussi, mais ça, c'est... Voilà, c'est loin.

• Manu

  On y arrive presque des fois. Pas loin, pas trop loin.

• Lulu

  Quand t'as rendez-vous chez le coiffeur.

• Manu

  Oui, et je crois qu'on a deux épisodes à 45 minutes. Alors, c'est une prouesse à noter.

• Lulu

  Ah oui, bravo nous. Non, mais c'était... Le but, c'était de vraiment pouvoir se concentrer sur la production. Vraiment, le côté, on fait nos recherches. Mais le problème, c'est que vu qu'on fait des sujets qui sont creusés une semaine sur deux, on va aller lire de la biblio. Donc, s'envoyer des liens sur Discord au milieu du reste, c'est peut-être... cette passe 4 plus simple. Alors, on avait fini par avoir une page Fibery partagée, sauf que je n'avais pas forcément les droits pour en créer une nouvelle. Donc, en fait, c'était juste que l'information était éclatée. C'était toujours de devoir un peu communiquer, de ne pas savoir aussi où l'autre en est, parce qu'on a fini par se répartir un peu les tâches naturellement aussi. Mais de ne pas avoir cette visibilité parce qu'on ne se rend pas forcément compte. Les gens qui font du podcast, sans rendre compte, mais il y a tout le travail de préparation, le cadrage, la partie sur les sources. Il y a aussi des discussions potentiellement en amont pour définir un peu de quoi on va parler, les sujets qu'on va aborder. Et ensuite, il y a le calendrier aussi respecté. Et une fois que l'épisode est produit, il faut le monter. Il y a toute la partie des visuels à faire. Il y a la partie publication. Il y a plusieurs descriptions aussi à rédiger. Ça va être la publication sur l'endroit où on héberge le podcast. Ça va être la transcription aussi. Peut-être la publication sur LinkedIn, la gestion des sources. On peut vite se retrouver, pas perdu, mais c'est juste que ça rajoute des frictions. On a l'impression toujours de déranger l'autre en demandant « oui, mais toi, t'en es où ? » « Attends, moi, j'ai fait ça et puis on s'était fait un drive, donc en soi, ça va, mais... » Là, ça permet de vraiment avoir toutes les infos au même endroit. Et on se dit que le jour où on aura peut-être plusieurs épisodes en parallèle, est-ce qu'on aura peut-être des hors-série ? Ça sera gérable parce que sinon, ça n'aurait pas été forcément possible.

• Manu

  Ce qui va être le cas là cet été, puisqu'on a plusieurs choses qui sont en attente et qui vont nous amener à avoir des épisodes effectivement parallèles. Mais oui, en fait, dans notre partie métier sur le podcast, pour parler en termes de nombre d'outils, On a des outils pour la partie vraiment technique. Donc, on utilise Riverside pour enregistrer nos podcasts. On le fait en visio, en live. Lui habitant à l'autre bout de la France. Voilà, en présentiel.

• Lulu

  C'est toi qui habites à l'autre bout de la France ?

• Manu

  Oui, peut-être. Ça dépend du point de vue. Quoi qu'il en soit, on utilise Riverside pour vraiment la partie enregistrement. On va utiliser Ausha qui est notre hébergeur et diffuseur de podcasts. Et dernièrement, on a... Aussi un théoréophonique qui nous fait tout le traitement audio, le nettoyage et au final maintenant qui est en train de basculer, de me faire la partie vraiment montage audio en soi quelque part. Enfin, pas quelque part, non, j'en ai mis le fait, depuis un ou deux épisodes. Donc vous avez peut-être dû remarquer que le son est plus fort, différent, et en tout cas, il nous semble mieux aussi depuis qu'on est passé sur Auphonic. D'ailleurs, il y aura un autre sujet, on reviendra un peu plus tard, mais ça va nous permettre également d'automatiser un certain nombre de choses bientôt. Ça fera l'objet d'autres séances. Mais en gros, même si on sort Auphonic de l'équation, on avait ces deux outils techniques-là. et après on avait les outils qu'a cité Lulu donc Fibery vraiment pour la préparation on avait Discord pour échanger et faire le lien et il y a un drive sur Proton pour tout regrouper au niveau des fichiers et des documents. Donc en termes d'informations on avait tout mais c'était, sincèrement c'était le bordel puisqu'en fait à chaque fois qu'on allait sur Oshike, il faut tout réuploader. Au niveau des échanges on avait des boosts sur Discord mais des fois il fallait retrouver une info, on s'est dit quoi déjà pour tel épisode, pour tel truc Sur Fiverr, vu que Lulu n'avait pas de compte payant dessus, c'est un peu comme à Notion. Vous pouvez partager des pages, vous pouvez partager des choses, mais c'est vite le bordel aussi.

• Lulu

  On est passé sur Anytype aussi, entre.

• Manu

  C'est vrai.

• Lulu

  Et j'ai toujours pas de compte dessus non plus.

• Manu

  Oui, mais sur Anytype, par contre, on a un espace, même sans que tu aies de compte, on a un espace commun où tu as accès à tout. Et sans limite, ce qui n'est pas possible sur Notion. Non, pas possible en l'état, d'ailleurs. Et donc le principe de départ, c'était ça, c'était vraiment de se dire, non mais là ça passe parce que c'était le temps qu'on apprenne un peu, qu'on en bossait, qu'on avait besoin dans chaque partie, qu'est-ce qu'on allait mettre, parce que pour nous c'était nouveau, c'était un process métier à découvrir, à construire et à formaliser ensemble. Et une fois qu'on l'a eu, on s'est dit, bon ben maintenant ce serait bien qu'on ait un outil dans lequel on regroupe tout, même si derrière on a des backups sur un drive, mais c'est des backups volontaires, Et même si derrière... on redépose au début, en tout cas, sur Ausha manuellement, on a quand même toutes les infos, tous les fichiers, toutes les ressources, toute la bibliographie, tout à un seul endroit.

• Lulu

  C'est ça, puis on s'est dit aussi que si, dans l'idée, c'est aussi de faire intervenir des invités et que là, ça n'aurait pas été gérable. Même que ce soit pour nous ou pour les invités. N'allez pas faire une discussion de groupe ou des échanges de mail. Enfin, ça n'aurait pas été... convenable et je veux dire il y a déjà des gens qui vont peut-être prendre du temps pour nous accorder du temps pour une interview où on va pas leur en prendre d'autant plus et là c'est vrai que j'ai quand même beaucoup apprécié ce moment où on a juste appris à bosser et à découvrir le process de construire un podcast parce que c'est sûr que si on s'était posé la question, oui on savait que ça serait mieux d'avoir tout au même endroit mais on n'aurait clairement pas construit la même appli si on avait attendu de la construire avant de se lancer. C'est pour ça que ça peut être important, même que ce soit automatisation ou application, je trouve que c'est super important de savoir presque le faire à la main avant et d'avoir testé des choses, parce que les besoins évoluent vraiment beaucoup, et d'y aller petit à petit.

• Manu

  Et ça, c'est fondamental ce que tu dis, parce qu'on n'automatise pas un process qu'on n'a pas déjà éprouvé. Et pour une application, c'est pareil. Si on fait une application sur quelque chose qu'on n'a jamais vécu, qu'on ne connaît pas, on va forcément se planter dans le cadrage, on va forcément se planter sur comment répondre aux besoins, tant qu'on n'a pas conscientisé ce besoin et qu'on ne l'a pas éprouvé d'une manière ou d'une autre. Et c'est pour ça que le passage bricolage ou outils provisoires est, à mon sens, indispensable. Oui, outils no-code,

• Lulu

  où on a réfléchi même à la structuration des bases de données derrière. On se dit, bon, effectivement, on a un épisode, une saison, on va avoir une description. comment les différences statuent. Et c'est vrai que ça commence à infuser et ça ne coûte pas cher en développement. Et c'est là où on peut se permettre un peu de casser, de migrer facilement d'un outil à un autre, de se dire, finalement, cet outil-là ne me convient pas trop, donc on peut l'enlever. Parce que c'est sûr qu'après, si on avait déjà fait toute la connexion API les automnes avec cet outil, et que finalement, on se rend compte qu'il y en a un autre qui est mieux, mais qu'on n'a juste pas pris le temps de le tester, c'est un peu plus problématique. On peut vite considérer que c'est une perte de temps au début, mais c'est vraiment du temps de gagner pour après.

• Manu

  Oui, et c'est ce qui permet d'assurer qu'on va avoir un produit qui répond à un besoin réel et qu'on va pouvoir faire évoluer sur des basses scènes. Et l'enjeu, du coup, après avoir identifié ça et qu'on avait besoin d'une application pour centraliser tout ça, on s'est dit, OK, on va faire un portail. L'idée, c'était aussi de dessiner une V1, c'est-à-dire d'avoir un périmètre défini. Parce qu'en fait... Que ce soit lui ou moi, on aime bien rajouter des fonctionnalités, on a plein d'idées dedans, à mettre dans une appli, à rajouter, et ainsi de suite. Sauf qu'en fait, ça ne sert à rien de monter une usine à gaz au début, puisque la problématique en vient de se lever, tant qu'on n'a pas éprouvé un process, ça ne sert à rien de l'automatiser ou de le mettre en œuvre. Et en fait, c'est un peu pareil dans un outil, c'est qu'on va d'abord faire la V1, en fonction de tout ce qu'on a déjà identifié, pensé et ce qui nous semble beaucoup mieux par rapport à l'existant. Mais à l'usage, on va se rendre compte qu'il y a encore des choses à ajuster, à améliorer. Et des choses qui manquent... Mais voilà, le but de la V1, c'est vraiment de vous dire, ok, on va à l'essentiel. On va mettre ce dont on a besoin aujourd'hui pour bosser, qui est vraiment fondamental. Et une fois qu'on aura vu ce qui va, ce qui ne va pas, on fera évoluer vers une V2 en rajoutant des fonctionnalités, en retravaillant des interfaces, en retravaillant d'autres fonctionnalités, et ainsi de suite. Donc, on reviendra un peu plus tard sur ce qu'on a mis dans la V1 et dans la V2. Mais il faut un point de départ. Donc, d'abord, avoir conscience du problème. Ensuite, être prêt à accepter. que la solution qu'on va mettre en œuvre ne va pas répondre à tout. L'idée, c'est que ça répond à 80% des soucis et de se dire, ok, les 20% qui restent, on va les faire dans un second temps et ils ne sont pas fondamentaux aujourd'hui et le fait d'utiliser la première version nous permettra de mieux comprendre et mieux savoir où on veut aller sur la suite. Ce qui nous amène au cadrage produit. Alors, on va vous... présenté une méthode qui est fortement inspirée et adaptée de la méthode préconisée par, encore une fois, lui, Alexei Kovalenko, dans son livre qui s'était traité du vape coding éclairé, si je n'ai pas de bêtises sur le nom, et où lui, justement à travers son expérience personnelle et l'expérience de nombreux autres développeurs qui ont travaillé avec de l'IA et qui ont prouvé les différentes méthodes, il avait été... prendre le meilleur de tout le monde pour en faire une méthode un peu driveée qui l'a explosé dans le coin. Je l'ai repris et après je l'ai adapté à ma sauce et à mes besoins. Et on va vous la dépeindre et vous dire un petit peu à chaque étape ce que ça nous a permis de faire et ce que ça nous a permis de sortir comme livrable. Parce que le but de tout ce cadrage, ça va être de dessiner tout ce qu'on a besoin dans notre application. de définir toutes les fonctionnalités, les besoins métiers, etc. Pour ensuite pouvoir passer la main à Lulu côté design pour qu'elle en fasse une maquette. Parce qu'elle aura à ce moment-là toutes les informations à disposition pour en faire vraiment des interfaces invisuelles et qu'on puisse traduire ce dont on a besoin dans quelque chose qui marche et qui ressemble à un portail, tout simplement. qui ressemble à notre portail avec nos usages à notre portail alors notre première étape ça a été ah oui il y a d'ailleurs autre chose que j'ai oublié de vous dire c'est que là sur la méthode appliquée j'ai aussi converti en fait chaque étape chaque étape pardon en un skill dédié donc les skills on en avait déjà parlé dans des épisodes précédents c'est une compétence pour l'IA qui permet de mettre en oeuvre une méthode et donc globalement l'IA quand vous arrivez à ce moment là et bah utiliser cette compétence, suivre le déroulé, elle peut faire appel à des références qui sont dedans pour avoir des informations complémentaires et elle va être là pour vous aider à structurer et répondre, définir un besoin spécifique. Je crois qu'il y a le lapin qui devient fou derrière, non ?

• Lulu

  Ouais, je crois que c'est ça. Il pète un câble.

• Manu

  Vous ne l'entendrez peut-être pas sur cet enregistrement, mais voilà.

• Lulu

  Merci au clinique d'avance.

• Manu

  Qui vous préserve les oreilles du petit lapin. Donc, Sur notre premier skill, première étape, ça va être le cadrage de problèmes. Je ne sais pas si tu veux en parler Lulu, je sais que tu l'as fait aussi justement sur d'autres applications et d'autres usages, cette partie-là.

• Lulu

  Après là, basiquement, on peut se servir de l'IA dans ce cas-là pour aller creuser encore plus loin, mais les réponses viennent de nous. Ce n'est pas l'IA qui va nous définir notre problème, et vraiment cette méthode, même avant d'aller avec l'IA, juste de se poser. la méthode papier-crayon.

• Manu

  Enfin,

• Lulu

  sans rien et juste avec nous-mêmes de déjà lister et se demander quel est le problème, sans parler de solution. Et c'est là où c'est assez important parce qu'on a souvent tendance à être biaisé par une solution en se disant « Ah, j'ai besoin de ça » . Non, non, c'est le problème avant même de parler de ce qui peut répondre aux besoins sous-jacents. Je ne sais pas si, enfin toi, oui, tu es repassé aussi par là parce que... En fait, le portail, tu avais déjà commencé à vouloir le développer dans Softr. Tu avais fait un mini-PRD, mais qui mixait du problème avec un début de solution technique. Et moi, je m'étais servi de ça au départ pour itérer sur du maquettage et réfléchir aux interfaces.

• Manu

  Alors, c'était pas tout à fait ça. Oui, parce qu'en fait, il y avait une étape sauveteur où on avait fait un G, mais c'était surtout pour tester la fonctionnalité de vibe coding. J'avais fait une version très à l'arrache. Après, j'avais fait un premier PRD, à ma sauce. avec une autre méthode et je t'avais donné un PRD qui mélangeait de la partie métier et de la partie technique et ça t'avait servi effectivement de base de travail pour une première version c'est vrai que j'avais complètement oublié que t'avais déjà fait la maquette sur l'ancien PRD et justement c'est pour ça qu'il y avait eu aussi ce on

• Lulu

  en parlera juste après mais cette étape de confrontation qui pouvait être pas mal différente du second PRD que t'avais fait Merci.

• Manu

  C'est ça.

• Lulu

  Après avoir lu le bouquin.

• Manu

  Effectivement, c'est vrai. Mais bon, ça ne va rien changer sur l'ordre des étapes qu'on précise. Mais effectivement, l'étape papier-crayon, moi je l'ai accompagnée d'un skill parce qu'en fait, l'idée c'est de toute façon, les infos de base, ce n'est pas l'IA qui va vous les sortir, c'est vous qui allez les matérialiser. Donc dans cette étape de cadrage et la compréhension de la problématique, mais ça va être de formuler en fait un... un objectif et un critère de réponse, qu'est-ce qui fait que l'application va répondre au problème ? Si vous le résumez en une ou deux phrases, comment vous saurez que l'appli marche et qu'elle répond aux besoins ? Ça va être de réfléchir à ce qu'on appelle les user flows, donc les parcours utilisateurs. Déjà, de commencer à vous dire, en tant que producteur de l'épisode, je veux pouvoir naviguer sur une liste avec tous les épisodes, je veux pouvoir créer un nouveau. aller y mettre une trame, aller y mettre des infos, aller y mettre des fichiers et ainsi de suite. Et sans rentrer complètement dans le détail, ça ça vient dans un second temps, mais déjà en fait de dégrossir toutes les grandes lignes un petit peu de ce que doit faire votre portail au niveau du parcours de navigation et du coup ce qu'il y a derrière un petit peu quoi. Et aussi déjà à partir du moment où vous allez réfléchir à tout ça, ça va faire émerger des questions qui ne seront pas forcément auxquelles vous n'allez pas pouvoir répondre sur l'instant. qui seront à trancher dans un second temps quand vous voudrez avancer dans la réflexion ou avancer avec le maquettage par exemple. Donc ça c'est le premier truc, mais du coup, voilà, il y a toute une partie à faire soi-même et après moi je me suis fait un skill pour transformer ça en livrable en Markdown, donc déjà prêt en fait pour être consommé et utilisé par l'IA derrière. Pourquoi ? Parce que ça m'a permis ensuite d'aller travailler sur la rédaction du PRD. Donc le PRD, ça va être vraiment la spécificité... spécifications pardon fonctionnelles l'objectif ça va être d'avoir un document qui décrit exactement pas le détail technique de comment on va le faire mais le quoi de qu'est ce que fait le portail et à quoi il répond comme besoin et quels sont les on appelle les user story donc en gros qu'est ce que chaque profil dans votre application doit pouvoir faire En fait, l'idée de ça, c'est d'avoir un espèce de cahier des charges, globalement, d'ailleurs c'est le terme qu'on renvoie de temps en temps, mais qui ne va pas vous dire à la base de données, elle doit fonctionner comme ci ou comme ça, et on va utiliser tel langage de programmation, on s'en fout. On est vraiment sur la partie métier. Donc de vous dire, avec ça, j'ai un cahier des charges complet, je sais exactement de quoi j'ai besoin pour que mes utilisateurs et mes utilisatrices puissent faire ce qu'elles ont besoin de faire dans l'application.

• Lulu

  C'est pas influencé par de futurs choix techniques. Parce que sinon, on peut se retrouver à faire des compromis et à moins bien répondre aux besoins. Alors que c'est le besoin et le problème qui priment. Parce que même si on fait une bonne application, si on ne répond plus exactement à ce besoin, on ne va pas forcément avoir une bonne... Les gens ne vont pas forcément bien adopter cette solution-là.

• Manu

  C'est ça. Après, si on a déjà des contraintes d'outils, il faut les avoir en tête quand même. effectivement avec du développement assisté par IA on n'a pas carte blanche mais en tout cas on peut faire énormément de choses si vous allez sur un outil, si on reprend software, typiquement je sais que justement je suis passé de software au développement assisté par IA parce que je rencontrais des frictions sur ce que je voulais faire dans software et que j'avais plein de choses qui m'embêtaient et visuellement par exemple je n'aurais jamais pu faire ce que je voulais dans software par rapport justement au développement assisté par IA. Donc si vous avez vraiment un frein de base oui c'est sûr qu'il faut l'avoir en tête.

• Lulu

  Je pense que c'est quand même intéressant de rédiger le PRD de manière totalement déconnectée de ça pour ensuite, pourquoi pas faire des compromis ? Mais on sait pourquoi on a fait ces compromis-là.

• Manu

  Effectivement, c'est pour ça que le choix d'architecture et d'outils arrive après. et que tant qu'on est sur la partie métier, on doit penser vraiment aux besoins et qu'est-ce qu'on doit faire dans l'app, et effectivement les concessions, entre guillemets, ou les arrangements sur l'isarène ou sur telle feature, elles arrivent après. Mais voilà, et donc sur cette partie PRD, alors moi je le fais, j'ai deux aspects là-dedans, donc j'ai le PRD en lui-même avec l'essentiel de tout ça, et les user stories résumés, on va dire synthétiques, et à côté j'ai un document avec les user stories détaillés. Dans une user story, qu'est-ce qu'on va y croiser ? Ça va être de dire, par exemple, en tant que producteur, je dois pouvoir remplir la trame de l'épisode dans un éditeur de texte enrichi. Enfin, ça va être de dire, j'ai besoin de remplir la trame de l'épisode. Et après, on va mettre des critères d'acceptation pour dire, en fait, pour remplir la trame, on a besoin que l'éditeur soit enrichi. On peut y mettre des tableaux ou des infos complémentaires. On va avoir besoin... que ce soit collaboratif, donc de faire que plusieurs personnes puissent travailler sur la même trame. On peut avoir un autre critère pour dire que ça prenne tel ou tel type de mise en forme, par exemple. Et après, on va avoir... En fait, ces critères-là vont permettre de déterminer les choses à tester. Et ensuite, on détermine aussi ce qu'on appelle les cas limites, les edge cases, qui sont de se dire les scénarios qu'on n'a pas anticipés. Si quelqu'un veut mettre une vidéo dans l'éditeur, qu'est-ce qui se passe ? Si on essaye de mettre du HTML directement dedans pour gruger, ou alors on essaye de mettre un script pour casser. Généralement, on réfléchit des edge cases dans des cas un peu utilisateurs réels, on va dire. Mais il y a aussi les facteurs potentiellement de piratage. Ça, ça passe par d'autres canaux, mais c'est aussi des choses à tester.

• Lulu

  Ça, l'IA n'est vraiment pas mauvaise, justement, pour aller creuser des edge cases. Même nous, il ne faut pas se fermer à essayer d'imaginer ce qui peut être mal fait parce que les utilisateurs n'utiliseront pas le happy pass.

• Manu

  Oui, mais c'est ça. D'ailleurs, quand vous avez des gens qui travaillent en service qualité, en QB, ces personnes-là sont là pour justement aller challenger chacune des user stories, de dire, OK, là, cette user story permet à tel profil d'utilisateur de faire telle action. les critères d'acceptation pour dire que ça remplit le besoin, c'est ça, ça et ça. Mais derrière, moi, il faut que j'identifie tous les tests qui peuvent venir valider que ça fonctionne sans effet de bord. Et des fois, avec quelqu'un qui est doué en QA, en qualité, en assurance qualité, va avoir un esprit que je n'ai pas. Il faut des logiques des fois un petit peu tordues pour anticiper des choses qui ne viennent pas du tout à l'esprit de prime abord, mais qui peuvent être des cas réels. Parce que, assurez-vous que... soyez sûrs et certains que vos utilisateurs et vos utilisatrices vont utiliser ce que vous leur mettez à disposition de manière complètement non conventionnelle, de manière que vous n'avez jamais pensé au préalable.

• Lulu

  Il n'y a qu'à regarder côté jeu vidéo, de voir des fois jusqu'où les gens vont, et même les développeurs qui sont là en mode mais comment ? Enfin, quel esprit il faut pour avoir imaginé faire ça ? Donc c'est vrai que ça rejoint un peu aussi tout ce qui est QA dans le jeu vidéo, de tout faire pour... casser ou faire des choses qui sont vraiment pas prévues et c'est trop marrant parce que même avec des choses qui sont très très poussées, à la sortie d'un jeu un peu populaire dans la semaine qui suit, il y a toujours quelqu'un qui arrive à casser le jeu. C'est presque s'amuser de trouver tous les trucs qui peuvent péter.

• Manu

  Oui, mais voilà, c'est vrai que le jeu vidéo est très représentatif de ça, mais ça s'applique aussi aux obligations.

• Lulu

  Il faut vraiment imaginer quelqu'un qui va cliquer partout, qui va foncer partout, et qui va tester des trucs qui ne sont pas faits pour être testés comme ça. C'est pareil dans une application.

• Manu

  Et donc, en gros, mon PRD, il ressemble à ça. À côté, j'ai un deuxième document avec toutes les user stories qui sont détaillées. Donc là, je vous ai cité un exemple avec le profil de producteur. Mais du coup, avec un profil invité, il faut que la personne puisse faire d'autres choses. Par exemple, aller... modifier son profil, aller intervenir ou modifier un tel élément sur un épisode, etc. Et voilà, vous allez lister tout ce dont vous avez besoin, mais de manière plus détaillée. Et donc ça, c'est pareil, l'IA est un bon complément, mais ça implique quand même de relire, si c'est elle qui vous produit des user stories, de les relire toutes pour voir si ça correspond vraiment à votre vision et à ce que vous avez vraiment besoin, parce qu'elle peut vite partir sur des écarts. Mais en revanche, elle est très douée, je trouve. pour vous aider à définir des critères d'acceptation et les fameux cas limites. Sachant qu'il y a un autre document qui vient plus tard. qui sera le cahier de recettes. Le principe du cahier de recettes, c'est de prendre chaque user story et de faire des scénarios de test en face. On reviendra dessus un peu après, mais dans le principe, de toute façon, c'est ça. Donc à partir du moment où on a notre PRD, on a toute notre spécification métier, donc notre spécification fonctionnelle, on a toutes les user stories détaillées, donc on sait exactement qui doit faire quoi dans l'application et sur quelles interfaces. À partir de ce moment-là, On donne tout ça à Lulu et après, elle fait de la magie.

• Lulu

  De la magie. Oui, je suis allée sur Pinterest pour m'inspirer. Non, mais j'ai un peu cette appétence de ne pas vouloir juste faire quelque chose qui... Enfin, si, c'est important que ça fonctionne. Mais après, toute la partie design et la manière dont on va l'utiliser et tout ce qui ne passe pas par des mots doit être au service de l'utilisation. Et je trouve que c'est un... très bon exercice de devoir imaginer et vraiment poser avec des schémas d'interface comment l'application va être et que ça amène presque quand tu commences à définir aussi des problèmes, ça va amener de nouvelles questions en se disant, alors oui, on avait imaginé telle chose à l'écrit, ça passait bien dans une phrase décrite, mais au final, quand je suis en train de Merci. penser mon interface, avant même de passer dans Cloud Design, j'allais un peu sur Pinterest, je regardais des inspi, et à un moment, je me suis mise vraiment devant une feuille et je dessinais. Je me suis dit, OK, les différentes parties, j'ai fait mes petits carrés, et je me dis, bon, ça va être mes différentes interfaces, de voir un peu les répartitions et de me dire, ah oui, mais là, ça ne me paraît pas logique, parce que ça veut dire qu'il faut qu'on accède à cette information en passant par là. Ce n'est pas bien en termes de parcours utilisateur et de se dire aussi de prendre un temps juste pour aller voir les applications que j'aime bien utiliser et essayer de formaliser ce qui marche bien parce qu'on voit souvent ce qui ne marche pas et ce qui irrite. Mais des fois, l'expérience utilisateur est tellement bien faite qu'on ne se rend pas compte de ce qui est bien fait et de se demander comment est-ce qu'ils ont mis telle interface ? Pourquoi est-ce que ça paraît si fluide à utiliser pour modifier telle info ? C'est un peu toutes ces questions-là exploratoires. pas vraiment de compétence là-dedans et j'y suis allée un peu au feeling, mais je pense que je creuserai de la théorie derrière après, mais là c'était un peu en mode itération. Et après, je suis passée aussi dans le cloud design avec... Enfin, j'avais fait des itérations un peu sur Stitch pour m'amuser avant. C'était un peu plus compliqué même si j'avais bien aimé l'aspect de partir d'une interface basique et de lancer différentes variations. Parce que moi, derrière, ça me donnait de nouvelles idées en me disant « Ah oui, ça, effectivement, présenter de cette manière-là, c'est pas bête. » Mais par contre, ça vient confronter quelque chose qu'on a mis et qui est à l'écrit dans le PRD. Et de se dire « Ah oui, mais tiens, ça me fait penser à telle fonctionnalité, et c'est vrai que ça serait quand même vachement cool que ça soit dans la V1. » Alors que c'est quelque chose qu'on n'avait pas forcément rencontré, mais qui pourrait vraiment améliorer la qualité de collaboration sur les épisodes. Donc voilà, après, ça a été... pas mal d'itérations, du test aussi, enfin de... C'est vraiment quelque chose qui peut pas être fait en une heure, enfin, c'est un peu ce truc de, il faut laisser reposer, et tirer dessus, bon, après là c'est aussi parce que c'est quelque chose que j'allais utiliser, donc il y avait d'autant plus d'attention et de... comment dire... Je réfléchissais à comment moi, en tant qu'utilisatrice finale, j'allais me servir de ce portail, donc je me dis ouais, si je place mal ce bouton, ça va vraiment m'embêter à chaque épisode. Chaque fois que je vais aller dessus, je ne peux pas me dire que ça passera, parce que ce n'est pas moi qui vais m'en servir, et tant pis, au pire, on bougera le bouton. Ce qui est quand même sympa de faire, surtout que c'est dans le design, il n'y avait pas du tout... Enfin, s'il y a un code qui est produit, mais ensuite, en le passant à la partie développement, on ne va pas polluer le code en disant « change ce bouton, un peu de place » . On ne va pas se retrouver avec des duplications ou des trucs qu'il ne faut pas. Bon, ça après, t'en parleras des garde-fous à mettre en place. Mais tout ce qu'on peut décider en amont, alors que ça soit dans la définition du problème, même après les user stories ou le côté interface, c'est du temps de gagner pour après. Parce qu'au final, c'est sûr, on a passé beaucoup de temps avant de passer au développement. Mais en attendant, le portail, on a pu l'utiliser quasiment dès qu'il était prêt et on n'a pas eu de grosses frictions. Il y a eu des trucs à corriger, mais c'était... vraiment minimes pour une première application. C'est là où je me dis, bon, ça va, on s'en est pas trop mal sortis. Et d'avoir quelque chose de visuel, ça permet de tester, où on se disait sur le papier, c'est trop cool comme feature, et en fait, ouais, non, c'est pas si indispensable que ça. Et finalement, il y a peut-être cette solution-là qui est un peu mieux, et surtout de pouvoir en discuter aussi à deux, d'avoir quelque chose sur lequel on peut vraiment parler, parce qu'une user story, il peut y avoir plein de manières d'y répondre. Nous, en y réfléchissant, on n'a pas forcément la même manière d'y penser et on n'aura pas forcément une solution qui nous conviendra à tous les deux à la fin. C'était sympa même d'avoir un produit et je trouve que ça motive aussi d'avoir quelque chose avec l'ADA du podcast et de se dire « Waouh, en fait, ça va ressembler à ça à la fin, c'est pas juste un grand document » et c'est sûr que ça donne envie.

• Manu

  Le maquettage est hyper important pour plein de raisons. Déjà parce qu'il permet de traduire. justement tous les besoins sur quelque chose de visuel. En plus, ça permet de lui donner vraiment corps parce que sur une maquette, aujourd'hui, elle est interactive. Littéralement, ce que tu as fait, c'est au final une version du site web, sauf que c'était en vitrine. Donc si on cliquait sur un bouton ou ce genre de choses, ça pouvait soit ouvrir une nouvelle page ou une petite fenêtre. Ça n'allait pas ajouter des choses dans une base de données. On ne pouvait pas déposer des fichiers ou tout ça. mais c'est déjà une interface qui est utilisable de bout en bout et qui permet de naviguer entre les différentes pages, etc. Et donc de réaliser vraiment les enjeux de ce qu'on est en train de faire globalement et de l'application, à quoi elle va ressembler et est-ce qu'elle va répondre aux besoins de la bonne manière en termes d'expérience. Parce que là, le process que tu as décrit, ça a été d'abord les inspirations à travers Pinterest. La partie Google Teach t'a permis de tester un peu.

• Lulu

  Oui.

• Manu

  Mais au final, tu ne sais plus dans ton workflow aujourd'hui si tu dois faire du design. Tu partirais de Pinterest à Cloud Design ou je dis une bêtise ?

• Lulu

  Ouais, Pinterest, alors peut-être pas tout de suite à Cloud Design. Après, ça dépend s'il y a déjà un design système ou une direction artistique qui est existante. Parce que là, il y avait eu aussi un peu toute cette recherche de comment transcrire l'ADN que j'ai fait pour la maquette du podcast. pour que ça passe en application sans que ça soit la fête des couleurs et un truc totalement inutilisable parce qu'on reste quand même sur un outil interne. Je me suis un peu plus amusée sur le site internet. Le jour où il sortira, ça va être un peu marrant, je pense. Mais voilà, c'était vraiment de m'imprégner, d'être vraiment avec cette... curiosité de me demander ok moi qu'est-ce que j'utilise comme produit et que j'aime bien utiliser ou justement je me suis même pas rendu compte que j'aimais bien les utiliser au quotidien et de me poser ces questions et toujours avoir aussi mon carnet sur moi de penser, de dire ah tiens c'est vrai que ça, ça serait bien de l'avoir donc je me fais et puis c'est limite je vivais avec ça dans ma tête pendant plusieurs jours et à presque le confronter à tout ce que j'utilisais à côté pourquoi trouver de bonnes idées. Et après, une fois que j'arrivais dessus, j'arrivais un peu mieux à décrire mes besoins et ce que j'ai bien aimé dans Cloud Design, c'est ce côté quand même conversationnel où j'avais ce côté visuel et de pas juste dire critique, fais des audits, c'est de dire ah là, moi, en tant qu'utilisatrice, je trouve pas ça très fluide. Est-ce que t'as des propositions en UXUI pour l'améliorer ? Ou alors moi, j'aimerais bien voir ça de cette manière, propose-moi de différentes. manière de le présenter en mode très brouillon, pour pouvoir refaire trois designs différents, et de me dire, ah oui, ça visuellement, c'est ça que je veux, parce que ça me parle plus et je sais qu'à l'utilisation, ça sera mieux. Donc c'est vraiment ce côté itératif, c'est comme ça que j'ai procédé de cette manière-là, en tout cas.

• Manu

  Et oui, et puis du coup, ça nous a permis d'avoir une maquette qui était déjà hyper calide. et de faire émerger des choses dont on parlera dans le prochain épisode, parce que là, il nous reste encore énormément de choses à vous dire sur le sujet, donc ce sera un épisode en deux parties. Mais effectivement, d'avoir fait la maquette, au fur et à mesure, tu t'es rendu compte, et tu l'as un peu évoqué, qu'il manquait potentiellement des fonctionnalités, qui avaient du sens dès l'AV1, enfin, qui pouvaient avoir du sens dès l'AV1, et sur lesquelles il allait falloir trancher sur est-ce qu'on le fait ou pas dès maintenant, ou est-ce qu'on le garde en tête pour plus tard. Et de se dire, en fait, tout ce qui était dans le PRD en termes de fonctionnalité était présent, mais n'était pas forcément présent de la manière dont on l'avait pensé au niveau des interfaces ou de l'engencement. Et tout ça, tu l'as fait justement en remaniant un peu la... Ça,

• Lulu

  parce qu'on était surtout partie des frictions qu'on avait, qu'on avait rencontrées et des outils qu'on avait. C'est sûr, on est parti avec nos propres biais et peut-être que... à l'utilisation d'une V1 peut-être moins aboutie, on aurait eu les mêmes réflexions à l'utilisation. Et là, juste d'avoir pris un peu plus de temps, et parce que j'ai bien aimé faire cet exercice, ça nous a permis derrière d'avoir quelque chose qui était vachement abouti en V1. Et là, au final, vu que le développement a bien été fait, tu peux faire des correctifs et rajouter des fonctionnalités. Ça ne va pas tout casser. Au final, là, c'est presque du... Enfin, on n'est pas dans l'inutilisable qu'il faut corriger ou de la grosse fiction. Enfin, c'est vraiment du... Ah oui, là, bon, c'est vrai, à l'utilisation, ça serait cool que ça soit comme ça. Donc, bon, allez, on ouvre un ticket. Mais je considère même pas vraiment ça comme des bugs, en fait.

• Manu

  Non, mais après, bon, on en parlera plus tard, quand on sera au dev. Je ne sais pas toutes les étapes, là-dessus. Tu fais des spoilers. Mais... Mais oui, l'intérêt aussi de passer du temps sur les étapes qu'on a déjà évoquées aujourd'hui, donc la compréhension du problème, tout le cadrage, la rédaction du PRD et des user stories, et un maquettage aussi qui soit de qualité. Tout ça, il faut le voir comme des fondations, comme un socle qui va servir à tout ce que vous allez dérouler derrière. Plus votre socle est bon, plus vos fondations sont solides, plus derrière quand vous allez... commencer à développer et à transformer ça en code, à transformer ça en fonctionnalité, en choses sur lesquelles vous avez la main et vous interagissez, plus ça va être possible de le faire évoluer, de le maintenir et de le corriger sans tout casser. Tout simplement,

• Lulu

  la bonne métrique aussi, c'est qu'on l'utilise et qu'on n'ait pas repassé des solutions à côté parce que c'était finalement mieux comme on faisait avant. Et d'avoir ce truc, de se dire, ouais, on a pris le temps de se poser pour réfléchir à vraiment penser notre outil idéal qui colle aussi à notre manière de travailler, comme on avait pu le constater en mode bricolage, et de l'utiliser, et d'être content de l'utiliser, et de vouloir le faire évoluer pour qu'il soit encore mieux. Et ça, je pense que c'est une des métriques, enfin, c'est KPI qu'il faut suivre. En fait, là, on se rend bien compte qu'on est quand même très loin du prompt pour Cloud Code de faire un portail collaboratif pour qu'on puisse produire des épisodes de podcast. Je pense que...

• Manu

  Oui, parce que toutes les étapes qu'on vient d'énoncer là... Alors, dans les prochaines étapes dont on parlera la prochaine fois, il y aura notamment le choix d'architecture, après une phase d'audit, il y aura d'autres choses. Mais avant même de commencer vraiment le dev en lui-même, Et c'est vrai que sur l'architecture ou sur certains points, là ce qu'on vous présente aujourd'hui, c'est une application qui a été développée avec Cloud Code. Et donc avec un backend qui est hébergé sur Supabase et un frontend qui est dédié. Là aussi, si vous utilisez par exemple un lovable pour faire tout ça, vous aurez des contraintes et des possibilités qui seront différentes puisque vous allez être bridé par l'outil. Soit lovable ou un autre. Donc là, ce qu'on vous présente... toutes les étapes qu'on vous a présentées aujourd'hui sont valables, peu importe l'outil que vous allez utiliser. Et le maquettage, Lulu l'a travaillé essentiellement avec le design, mais aujourd'hui, vous pouvez très bien le faire sans IA, entièrement à la main, dans du Figma, dans du Canva, dans des outils de ce type-là. Et voilà, d'ailleurs...

• Lulu

  Je pense que je finirais par y arriver, peut-être à Figma aussi. Moi, là, ça m'a bien plu le design, parce que... Il y avait un peu ce côté cadré. Mais là, si je continue à accumuler des compétences là-dedans, j'arriverai un peu plus à le faire moi-même et avoir plus de contrôle sur le côté maquettage et pas dépendre... Je pense qu'il y a un mix à trouver et peut-être que design en amont peut être bien pour avoir une première idée, mais après, de faire vraiment quelque chose de propre dans Figma. Parce que même après, pour le donner à développer, ça reste bien aussi. Il y a d'autres choses qui se rajoutent sur les différents composants, comment est-ce qu'ils sont mis l'un dans l'autre ?

• Manu

  Un des gros intérêts des outils comme Cloud Design aujourd'hui, c'est que sur Figma, tu vas pouvoir faire les interfaces principales, ou te questionner sur comment tu veux le faire côté graphique et tout, mais l'implémentation d'en faire quelque chose d'interactif avec toutes tes pages, toutes tes interactions, et des fois des modals, ce qu'on appelle des modals en gros, quand vous allez cliquer, bonne petites fenêtres qui vont s'ouvrir sur le côté ou au-dessus, ce genre de choses. d'avoir des choses comme ça qui sont implémentées très rapidement avec ton design system et qui n'ont pas toujours énormément de valeur à être travaillées à fond dès le maquettage par exemple donc il y a une partie gain de temps même si effectivement tu fais une première couche directement dans un outil spécialisé pour le design

• Lulu

  Oui et il y a un peu cette envie de ne pas dépendre uniquement de l'écosystème anthropique et de juste me dire ok je peux choisir l'outil un peu, enfin c'est vraiment des compétences que je vais avoir moi et suivant les besoins que je vais avoir, je vais utiliser ça ou utiliser ça, mais si à un moment, il y a ça qui devient trop cher ou plus accessible, je sais que je peux utiliser mes compétences ailleurs.

• Manu

  Et d'ailleurs, comme ça, on bouclera aujourd'hui sur ce sujet, mais là, comme je disais, on vous présente du travail, enfin, on parle d'une app qui a été faite avec du cloud design et avec du cloud code. On l'avait déjà évoqué dans des épisodes précédents quand on parlait de vibe coding. Là, vous êtes en train de vous dire, vous êtes mignon, vous me parlez de souveraineté et d'IA frugale et d'ouverture sur les modèles. Et en fait, vous bossez avec du cloud. Et comme on l'avait déjà évoqué, en fait, on a conscience que l'IA, en tout cas, mon avis, va rester, même si l'infrastructure et la bulle d'IA en ce moment ne vont pas très bien. Il va y avoir probablement des gros changements cette année à plein de niveaux économiques et tout. Il n'empêche que les changements qu'elle a apporté, en tout cas côté développement, probablement rester. Et en fait, le pari qu'on avait fait avec Lulu il y a 2-3 mois, 3 mois, quelque chose comme ça, c'était de se dire, bon, c'est le moment où l'IA est encore subventionnée, où l'écosystème et les modèles sont assez matures et ont prouvé que, en tout cas, sur la partie développement et certains sujets, c'était viable, c'était adapté à de la mise en production et ça allait probablement rester. C'est le bon moment d'utiliser ces technos et d'apprendre à s'en servir de la bonne manière. quitte à cramer des tokens un peu en trop et à utiliser des outils qu'on aimerait quitter, globalement, sur du anthropique par exemple.

• Lulu

  Et de se construire des communs et des méthodes de travail.

• Manu

  C'est ça, et de le faire justement tant que c'est accessible aussi financièrement, puisque là, tout ce qu'on a fait comme itération, comme apprentissage et tout ça, sont des choses qui, la même chose dans un an, va très certainement coûter beaucoup plus cher pour le même apprentissage. l'objectif. On en reparlera aussi à la fin du prochain épisode quand on aura déroulé toutes les étapes pour que ce soit un peu plus clair et plus parlant. Mais notre ambition, c'est d'appeler sur des outils open source pour pouvoir choisir des modèles et travailler avec des modèles notamment qui sont garagés qu'en Europe. C'est-à-dire que là, dans nos prochaines étapes sur le développement, déjà, je peux parler de cloud design à l'instant, mais en fait, il y a du open design. Il y a des alternatives qui existent déjà à cloud design et qui font la même chose en permettant de choisir. le modèle qu'il y a derrière. Il y en a plusieurs aussi côté côté Cloud Code dont un des plus connus est OpenCode. On va avoir notamment sur les OpenCode, qui peuvent être utilisés avec différents routers et différents modèles européens. Celui que j'ai déjà ciblé, que j'ai essayé très vite fait, c'est Cortex AI, qui est un routeur de LLM européen qui permet d'aller taper que sur des modèles, enfin pas que, mais qui permet en tout cas de filtrer, d'aller choisir que des modèles hébergés en Europe, voire avec zéro rétention de données. On a différents. pallier le niveau de granularité de filtre. Et c'est juste qu'il y avait une réalité aussi, donc il y avait la réalité économique de se dire tant que c'est subventionné, on va en profiter pour apprendre. Et une réalité technique aussi, qui est que quand on va sur les outils open source les plus libres et les plus ouverts et qui permettent davantage de choses, il y a quand même un niveau de technique supplémentaire à prendre en main. Un open code va apporter, et d'ailleurs, c'est pas pour rien que... Donc, Cloud s'est autant développé sur ces outils. Ça traverse son écosystème qui s'est implanté massivement sur le marché. Parce que Cloud Code pour un dev, c'est hyper facile à prendre en main. C'est très complet, il y a plein de facilités dedans. Un Cloud Design, ça se prend en main aussi en deux-deux et ça permet de faire énormément de choses nativement. Là où les alternatives open source ont plus de points de friction. Il y a des choses qu'on ne peut pas faire avec ou qu'on peut fermer différemment ou qu'il faut repenser ou alors qu'il faut un niveau technique un peu plus avancé pour faire telle ou telle chose. Alors, vous allez être très assisté dans les outils Cloud. C'est normal, comme toujours, de toute façon, les outils propriétaires font beaucoup sur l'aspect simplification pour vous ayant envie de rester dans l'écosystème. C'est comme ça qu'on s'est retrouvé avec du Google et du Microsoft partout, même si quand on utilise les outils, on ne trouve pas forcément plus simple. Mais en tout cas, c'est vrai qu'un Google, vous en savez parce que vous allez sur n'importe quel site. vous avez un bouton se connecter avec Google. Et en un clic, vous êtes connecté, vous avez paramètres d'identifiant, de mot de passe et tout ça. Vous avez un drive, vous avez tout qui est unifié, vous avez un écosystème, vous l'avez sur le téléphone. Microsoft, c'est un peu pareil, mais côté entreprise, avec plein d'autres sujets. Les outils propriétaires seront toujours plus faciles à prendre en main. Enfin, pas toujours, mais la majorité du temps. Et c'est voulu, et c'est normal, et c'est pensé pour vous garder captifs de ces écosystèmes-là. Mais il n'empêche qu'on peut en sortir, qu'on peut s'en dégager. Et nous, en tout cas, à travers l'IA et à travers notre utilisation de cloud sur ces derniers mois, c'est déjà avec ces objectifs-là. depuis un moment. C'est juste que, typiquement, je n'avais pas fait de développement assisté par IA avant, il y a quelques mois. Et enfin, si, à travers des outils comme Loveable, mais c'est un peu comme tout, en fait, quand vous allez essayer d'apprendre un nouvel outil pour l'automatisation, pour vous saisir des concepts, ce n'est peut-être pas la meilleure chose d'aller directement sur du N8M, qui est l'outil le plus puissant du marché, mais aussi le plus dur à prendre en main. Vous avez tout intérêt à essayer un Zapier ou un Make avant pour comprendre les logiques qui ont revéc, pour comprendre les différentes étapes. et après d'aller sur un outil plus complexe. Et peut-être que vous n'aurez même pas besoin d'aller sur l'outil aussi puissant. Et même chose pour des sites web. Vous allez pouvoir utiliser UX avant d'aller sur le Webflow, par exemple. C'est un peu comme ça sur toutes les familles. C'est que, à mon sens, en tout cas, c'est comme ça que je fonctionne sur les apprentissages. J'aime bien comprendre les concepts, prendre des outils qui sont déjà m'apportés techniquement, et aller sur davantage ce qui me correspond après. Et si c'est plus dur à apprendre, au moins j'aurais fait des étapes intermédiaires pour comprendre la logique. Voilà, ce qui nous amènera sur les outils, et c'est pour ça qu'on vous parle déjà de souverain sur certaines choses, on vous a déjà parlé de dictée vocale, on vous a parlé de modèles du Open Whisper et plein d'autres choses comme ça qu'on utilisait. On parlera davantage de ces outils-là et d'écosystèmes open source sur des choses qu'on n'a pas encore, parce qu'on en a sur plein d'autres sujets déjà, mais au fur et à mesure que, techniquement aussi, on peut vous en parler avec davantage de conscience et d'utilisation.

• Lulu

  C'est d'y aller petit à petit, parce qu'il y a aussi une savoir de... quoi on va avoir besoin. Encore une fois, commencer par utiliser quelque chose, enfin pas en mode bidouille parce que le code, ce n'est pas du bidouille, mais de définir mieux nos besoins plutôt que d'essayer à tout prix et de mal faire les choses parce que même, je ne pense pas que du jour au lendemain, tu vas passer sur OpenCode. Tu vas peut-être faire des allers-retours. Il y aura des tests. Je pense que la partie, par exemple, PRD, rédaction de documents, ça, c'est peut-être la chose qui sera la plus simple. peut-être à sortir déjà d'Anthropic. Pourquoi pas faire le développement encore avec Cloud ? Ne serait-ce que pour aussi avoir des exemples qui vont servir de documentation après, derrière, pour un outil open source. Et il faut aussi se dire que là, toute la rédaction de documents, même des specs en amont, ça permet de mieux découper derrière pour le développement et donc d'utiliser, pourquoi pas, des modèles moins puissants, même si ton expérience avec Sonnet n'est pas... pas très très convaincante. Ça dépend.

• Manu

  J'ai beaucoup râlé les premiers jours et au final, je pense avoir trouvé le bon équilibre sur les moments où il est assez bon pour ne pas me faire des conneries dans tous les sens. J'ai trouvé un meilleur équilibre qu'à sa sortie.

• Lulu

  C'est aussi de se dire que les outils qu'on utilisera très probablement en open source, même les modèles, ne sont pas encore sortis. Là même, c'est quoi ? Début de semaine, j'ai vu c'était un modèle sous licence MIT Longcat. On va voir ce que ça va donner, mais il a un million de contextes. Enfin, en open white. Là, pour l'instant, il n'y a pas encore de fournisseur d'inférence, mais vu qu'il vient de sortir, je pense que c'est qu'une question de temps.

• Manu

  Après, tu commences à en avoir en tout cas chez Cortex, tu en as pas mal parmi les gros modèles chinois open white. qui sont déjà disponibles, hébergés sur des serveurs que européens, et avec des tarifs réglo.

• Lulu

  Là, c'était plus un million de contextes qui, toi, te bloquaient un petit peu et que tu voulais même voir arriver sursonner.

• Manu

  Ah oui, non, sursonner dans l'écosystème cloud, mais en fait, j'en avais déjà repéré dans l'écosystème classique OpenWide, parce que tu avais déjà Minimax qui le proposait, tu as GLM qui le propose, le dernier qui mit, je ne sais pas, je crois, en tout cas, sur les... Le point le plus épineux qui est le 1 million de contexte n'a de sens pour moi que dans le dev. Sur les autres, déjà, il n'y a pas besoin d'aller aussi haut. Et du coup, sur le dev, c'est vraiment intéressant puisqu'on l'avait déjà évoqué. Pour qu'il y a reste pertinente, il faut qu'elle reste en dessous des 30 ou 40% de contexte grand max. Et donc, ça vous permet d'avoir une marge de manœuvre, en fait, pour la faire bosser dans ce palier-là sans faire de bêtises. Mais du coup, en open-wise, il y a déjà des modèles.

• Lulu

  Ça commence à arriver, c'est juste que c'est pas encore... Enfin, c'est sûr que c'est pas mature, même du côté des modèles frontières, c'est pas mature non plus. Mais là, l'idée, c'est qu'on va plus forcément sortir des modèles plus puissants. On se dirige peut-être vers des modèles plus spécialisés ou mieux optimisés, parce qu'on se rend compte que, comme on en avait parlé dans l'IA frugal, on se rend compte qu'il y a une grosse partie du modèle qui peut être enlevé sans enlever de... Comment dire ?

• Manu

  D'intelligence ?

• Lulu

  D'intelligence, oui, de fonctionnalité, de pertinence aussi. Donc, je pense que ça arrive. Ça viendra peut-être du côté de la Chine. Ce n'est pas forcément ce qu'il y a de mieux. Mais après, si c'est hébergé en Europe...

• Manu

  De toute façon, il faut prendre un peu les améliorations où elles sont, quant à s'y sont, et s'en saisir. Et après, il y a un autre point aussi, parce que là, j'ai parlé d'OpenCode et du Cortex. Mais là, ma prochaine expérimentation et pour le prochain portail sur lequel on va travailler, c'est le... Première chose, ce n'est pas de tester OpenCode, c'est de tester le Supabase auto-hébergé. Alors du coup, avec du LSEO, parce que je n'ai pas envie de faire de DevOps, concrètement, je n'ai pas envie de faire de la gestion d'infrastructures et de sécurité, mais il y a une boîte européenne qui me permet de faire cette partie-là. Et du coup, vous choisissez ensuite où vous hébergez votre serveur. Donc ça peut être aussi bien chez OVH que chez ScaleWave, enfin bref, chez des acteurs français ou autres. Et là, l'idée, ça va être de faire ça. avec du Supabase en hébergement comme ça pour l'avoir sur un serveur européen et aussi déjà tenter de voir comment ça fonctionne le développement assisté par IA quand tu n'es pas hébergé directement chez Supabase qui est aussi un acteur américain même si eux ils ont le siège social je crois qu'ils en ont un aux Etats-Unis et un au Singapour bon au final c'est... à tout moment ils peuvent aussi poser soucis au niveau des infrastructures Voilà, tout ça pour dire que les questions et les enjeux, ils se font sur l'IA, évidemment, puisqu'on vous en parle beaucoup, ils se font sur les autres outils, et on l'a déjà évoqué aussi à travers le fait qu'il y avait plein d'alternatives. Aujourd'hui, de plus en plus, c'était devenu un enjeu pour tout le monde de s'affranchir des outils américains, en grande partie, enfin, en grande partie, idéalement. En tout cas,

• Lulu

  de rester agile, et de ne pas mettre tous ses œufs dans le même panier, mais voilà, c'est cette idée-là de penser plus en termes de... compétences, on va dire, d'acquis et de socles pour pouvoir bouger d'un outil à l'autre. Et dans tous les cas, c'est pas tout rien non plus. On ne va pas passer à de l'open source à 100%. C'est aussi de voir là où c'est le plus pertinent et d'y aller petit à petit tout en continuant à faire une veille sur ce qui arrive parce que ça continue de bouger quasiment chaque jour.

• Manu

  Oui, et d'y aller par étapes. En tout cas, c'est ma méthode et c'est pour ça que ça va être d'abord le ChupaBase. pour qu'en gros toute la partie moteur back-end soit vraiment où je veux globalement. Et ensuite, ce sera justement l'exploration d'open code de manière plus approfondie et de développer entièrement avec, sans toucher du cloud code sur tout un projet, toute une app, pour voir aussi jusqu'où on peut aller. Même si je suis convaincu qu'aujourd'hui on peut aller aussi loin, ce sera juste moins fluide que sur du cloud code. Et par étapes et par paliers, puisque... déjà dit aussi, aujourd'hui si vous voulez quitter du Google par exemple, il y a des alternatives mais il faut y aller petit à petit d'abord sa boîte mail, ses mots de passe on y va sur ses comptes, après si on a un autre outil de travail, bah essayez de voir s'il y a un outil qui est gros P1, est-ce qu'on peut basculer dessus, et ainsi de suite, mais si vous essayez de tout faire du jour au lendemain, ça vous va juste vous dégoûter parce que ça va vous sembler insurmontable il y a beaucoup trop de choses, et en fait à l'échelle d'une boîte c'est le même principe, c'est qu'on y va un outil après l'autre, une étape après l'autre et en perso pareil, donc voilà Je vais choisir ses priorités, ses focus et où est-ce qu'on peut se permettre d'aller et en fonction de son niveau technique aussi, puisque tous les outils ne sont pas forcément abordables et accessibles, même si les propositions sont larges.

• Lulu

  À l'échelle d'une boîte, c'est aussi stratégique. On va dire que si tu n'es pas souverain sur une partie qui n'est pas essentielle au business de la boîte et que c'est juste une petite partie, ce n'est pas grave. Par contre, si tout le cœur de ton business dépend... d'un seul fournisseur, notamment américain et d'IA, là, il faut quand même commencer à peut-être envisager d'autres options. Ne serait-ce que pour de la résilience, pour maîtriser les coûts. Et si on reste chez cet acteur américain, le faire en connaissance de cause et en se gardant des portes de sortie au cas où.

• Manu

  Complètement. On a fait une jolie digression de fin d'épisode. Mais on se retrouvera donc euh... Je ne sais pas si sur la thématique de la semaine prochaine, on continue sur ce sujet, ou si on se gardera ça pour le prochain Côté Outils, dans deux semaines. Quoi qu'il en soit, on se retrouve très bientôt pour la suite de ce sujet orienté sur le développement assisté par IA. On reprendra après la maquette, qu'est-ce qui se passe derrière, et jusqu'où on va. On vous remercie beaucoup de nous avoir écoutés jusque-là. Est-ce que tu as un petit mot de la fin de l'œuvre pour aujourd'hui ?

• Lulu

  Là, je n'ai pas forcément d'idée, mais de... Alors là, oui, on parle beaucoup aussi de... préparer en amont avant de se lancer, mais à un moment, il faut quand même se lancer. Parce qu'on ne pourra pas préparer à la perfection des documents et après, le lancement, ça peut être aussi de se lancer en se disant « je n'aurai pas l'outil parfait pour commencer » . Ou comme nous, on a commencé le podcast, on n'avait pas un super portail où tout mettre et on s'est lancé quand même et on a appris comme ça. Parce qu'on aurait pu passer beaucoup de temps à se dire « ouais, on ne se lance pas tant qu'on n'a pas notre appli et tout » . Donc c'est... Il faut trouver un peu ce juste milieu entre passer beaucoup de temps à préparer, anticiper, mais un peu, ça va être une stratégie pour éviter de se lancer et se rassurer. Et quand même, à un moment, il faut y aller. C'est comme ça qu'on apprend.

• Manu

  Très bon mot de la fin. Ça me va.

• Lulu

  OK. Parfait.

• Manu

  Encore merci à tous et à toutes. Merci, Lulu, de m'avoir accompagné pour cet épisode. et on se retrouve la semaine prochaine.

• Lulu

  Merci à toi aussi.

• Manu

  Avec plaisir. Bonne journée ou bonne fin de journée, selon quand vous nous écouterez. Et à bientôt.

• Lulu

  Salut.