Transcription

• Speaker #0

  Bonjour et bienvenue dans Le Dernier Clic, votre podcast tech, IA et no-code. On se retrouve cette semaine pour un épisode Côté Outils. Je suis en compagnie de Lulu. Comment tu vas Lulu ?

• Speaker #1

  Ça va et toi ?

• Speaker #0

  Très bien. Ravi de te retrouver pour un épisode. Comment on y est ? Une semaine sur deux on se retrouve pour parler d'outils numériques, d'outils logiciels et de ce qu'on utilise dans nos vies pro et perso. Et aujourd'hui on va parler pas mal de développement assisté par IA, ce que vous avez sûrement déjà entendu sous le nom et le terme de vibe coding. Terme que nous on n'aime pas trop, on va revenir un peu dessus après. Mais non, d'ailleurs tout de suite en fait, le vibe coding... On ne va pas refaire l'historique du terme et de toute la mouvance. Là-dessus, si vous voulez avoir un peu toute l'histoire et toute l'évolution, je vous invite vivement à aller écouter les podcasts d'Alexis Kovalenko et également à lire son livre qui s'appelle Traité du Vibe Coding Éclairé. Oui, du Vibe Coding Éclairé, mais c'est Traité du Vibe Coding Éclairé.

• Speaker #1

  Oui, c'est ça.

• Speaker #0

  J'avais plus le titre en tête. Et il a également fait aussi des conférences sur le sujet pour en parler. On ne va pas faire mieux que lui sur ce sujet-là. Et on reparlera un petit peu du livre juste après, un peu plus tard dans cet épisode. Mais pour en revenir au concept, l'idée de base du vibe coding, c'était de se dire, on va développer, assister par IA, mais un peu en roue libre. Donc vraiment en se disant, j'ai une idée en tête, je vais donner mes indications à l'IA. je vais rédiger ce qu'on appelle un prompt et après converser avec elle et je ne vais pas me pencher sur les choix techniques, sur la façon dont elle procède, sur la logistique à suivre, etc. Vraiment, je vais la laisser en autonomie développer mon application et mon programme. Initialement, on s'est arrivé beaucoup là-dessus et à travers le fait d'aller développer des applications vraiment... un peu jetable, donc itérer sur un concept, le monter sur un week-end ou sur quelques jours, voir si ça marche, et soit en faire quelque chose derrière en reprenant de zéro, soit le jeter, avoir vérifié une idée, ou tester une idée, ou ce genre de choses. Et le terme s'est popularisé, a été repris par beaucoup d'outils, notamment un des noms, enfin les deux noms peut-être les plus connus, dont vous n'allez plus entendre parler, ça peut être Lovable et Cloud Code. Donc, Lovable étant la version accessible, qui a fait beaucoup de bruit à un moment, puisque justement, on est sur une plateforme où on peut arriver. Et c'est très simple, en fait, à prendre en main, de parler avec l'IA et qu'elle commence à nous faire notre site web, notre page de vente, notre petite application, etc. Et voilà, ils ont levé énormément d'argent. C'est une boîte européenne qui a cartonné, qui est devenue une licorne en neuf mois seulement. Ça a fait pas mal de bruit, donc il y a deux ans. Et d'ailleurs, Lovable existe encore. il y a d'autres concurrents, d'autres alternatives mais pour vous donner un nom un peu peut-être qu'il parle un peu plus et que vous pouvez aller consulter et CloudCode qui lui est orienté vraiment aussi sur du développement assisté par IA, aussi du vibe coding mais de manière beaucoup plus technique et poussée et plutôt orientée pour les développeurs et c'est lui qui a un petit peu fait basculer en tropique enfin pas un petit peu, qui a complètement fait basculer en tropique dans une autre dimension avec justement l'IA vraiment orientée entreprise en armant les développeurs d'outils qui leur permettent de travailler d'une manière plus... je vais dire plus vite, oui et non, mais en tout cas beaucoup plus efficiente. Ce qui nous amène donc à en discuter aujourd'hui, c'est que le vibe coding, voilà, cette consonance et cette logique, et en tout cas au niveau du terme, il y a cette idée de vibe, et de se dire, ouais, on va laisser l'IA piloter et gérer, on lui balance nos idées, sauf qu'en fait, voilà, ce qui a été... démontré mille fois depuis c'est que du coup si on réfléchit pas et qu'on délègue tout à l'IA elle va nous faire quelque chose qui va marcher rapidement qu'on va pouvoir tester mais qui n'est absolument pas viable dans le temps qui n'est pas viable dans un contexte de production qui n'est pas viable dans un contexte d'entreprise classique et voilà qui n'est pas la bonne approche en tout cas l'approche qui nous correspond à nous du coup pour en revenir justement à concrètement comment nous on a été au contact de ce vibecoding et comment on s'en est saisi j'aimerais bien le lieu que tu nous parles un petit peu de toi, de la première app vibe codée que tu as fait et voilà j'arrêterai de dire vibe codée justement pour qu'on parle vraiment sur l'application développée donc quelle est la première application que tu as développée avec Flood Code ? si je n'ai pas de bêtises, et après peut-être que tu avais fait d'autres essais avant, justement sur du lovable ou autre chose, tu vas nous dire ça ?

• Speaker #1

  Non, effectivement, il fallait que j'aille assez vite, parce que ce n'était pas une idée qui me trottait en tête, ou ce genre de choses, je me suis juste retrouvée frustrée face à un problème de conversion de fichiers. Enfin, un truc assez bête, normalement on peut trouver sur Internet un site qui fait ça, Voilà, où on n'a pas forcément besoin de s'inscrire, où il y a des pubs. Enfin voilà, donc là, je n'arrivais vraiment pas à trouver. Enfin, j'avais des fichiers audio, des livres audio qui étaient dans un format qui demandait un lecteur spécifique. Et je voulais en passer un à ma belle-sœur et elle n'a plus de place sur son téléphone. Donc je n'allais pas lui dire, il faut qu'en plus de prendre le livre audio, il faut que tu installes une autre application pour pouvoir l'écouter. Je me suis dit, MP3, on va essayer de convertir ça en MP3. Et c'était vraiment la croix et la bannière. Soit il fallait que je m'inscrive, soit je téléversais. Et ça coupait en me disant que j'avais atteint mon quota ou ce genre de choses. Après, il fallait que j'installe un logiciel. Donc, j'étais pas chaude. Ça commençait un petit peu à m'énerver.

• Speaker #0

  Quand tu dis que tu téléversais, c'est-à-dire que là, globalement, il y avait l'app de lecture audio qui est propriétaire. qui te gardent dans l'écosystème, qui impliquent d'avoir le compte, de payer, etc., de l'utiliser. Au même titre, j'imagine que, genre un Spotify, un Deezer et ce genre de choses, la musique, tu peux la télécharger, mais qu'en étant connecté sur l'application, avec ton application, elle est en local, tu paries que tu ne peux pas la sortir.

• Speaker #1

  Encore différent, parce que, bon, là, c'était dans le cadre d'Audible, dire qu'Amazon, ils sont quand même assez fermés. Là, c'est des livres audio que j'ai achetés. Donc au même prix, voire des fois plus cher qu'un livre physique qu'on peut prêter. Et on ne peut pas les récupérer et les avoir juste pour soi. Ou alors on peut les télécharger, mais dans un format propriétaire. Et d'ailleurs, la communauté open source est assez active là-dessus, en se disant que c'est juste un moyen de faire acheter plusieurs fois. Alors que c'est censé nous appartenir. Après, voilà, c'est des... Il y a plein de considérations derrière tout ça. Mais là, Audible permet quand même de les récupérer. Mais c'était un format qui ne m'arrangeait pas et qui n'arrangeait pas la personne à qui je voulais prêter le livre. Là, je me suis dit, j'ai Cloud Code, autant c'est juste un fichier de conversion, je m'en fous. Si l'interface est moche, ça va ressembler à un logiciel des années 90 et ça sera très très bien sur Windows. Et là, j'ouvre Cloud Code, je commence à expliquer mon problème. Donc là, il n'y a rien de technique.

• Speaker #0

  Donc déjà, à ce moment-là, Cloud Code, tu ne l'avais jamais utilisé.

• Speaker #1

  Jamais, non. Il a fallu que j'installe Git dessus.

• Speaker #0

  Ok. Pourquoi tu as choisi Cloud Code et tu n'as pas testé, par exemple, un low-babel ou un autre outil ? Première question. Et deuxième étant, justement, Cloud Code, tu l'as ouvert dans la version application de bureau sur Windows. J'imagine qu'elle est aussi sur Mac. Donc, il ressemble quand même à ce qu'on a avec du Cloud habituel, avec la fenêtre de chat, mais avec quelques subtilités. Mais c'est par là que tu as commencé.

• Speaker #1

  Oui, c'est ça. L'OVB, alors j'avoue que je n'ai jamais essayé. Je n'ai pas de compte et je ne voulais pas commencer à aller là-dessus. Là, je savais que ça allait être juste de l'application qui marche en offline, parce qu'à la fin, il fallait que je produise un exe, et voilà, c'est tout. Et je ne suis pas partie dans le chat de Claude, je suis directement allée sur Claude Code, parce que je me doutais que pour convertir des fichiers, j'allais devoir installer peut-être des librairies, enfin bon, du Python, ce genre de choses, et c'est ce qui s'est passé. Oui,

• Speaker #0

  pour celles et ceux qui nous écoutent et qui ne sont peut-être pas familiers avec les concepts et les outils de développement, généralement quand on développe un logiciel, on va s'appuyer sur des briques qui existent déjà, qu'on appelle des librairies, et qui vont permettre de ne pas réinventer la roue à chaque fois en allant chercher des petits morceaux pour faire telle ou telle partie dont tout le monde a besoin dans toutes les applications. Donc ça peut être pour l'authentification, ça peut être pour l'envoi de mail, ça peut être pour plein de choses. Mais en tout cas, on appelle ça des librairies. Et donc, systématiquement, effectivement, Cloud va avoir besoin de librairies pour créer un logiciel.

• Speaker #1

  Et là, je me retrouve devant Cloud Code. Alors, il y a écrit qu'il faut installer Git pour commencer à l'utiliser, donc je suis là, oh là là, ça fait longtemps que je ne suis pas allée dans mon terminal et ce genre de choses. Donc j'ai quand même tout installé, après j'ai décrit mon problème, il a proposé les librairies qui seraient intéressantes à télécharger, il m'a guidée, il y a eu des moments où en fait je... Je ne comprenais pas où est-ce que je devais mettre un répertoire dans un projet cloud ou ce genre de choses. J'ai juste demandé. En fait, je ne comprends pas, je dois le mettre où ? Et puis, c'était vraiment super bien détaillé. En l'espace de 30 minutes, j'avais téléchargé tout ce qu'il fallait pour lancer ce qui était Python. Donc, l'environnement et ce genre de choses. Et j'avais mon petit programme où je glissais déposer mes fichiers, j'avais pu convertir chaque chapitre en MP3 et ça marchait. Donc c'était vraiment un petit peu magique où je me suis dit mais il n'y a plus besoin d'aller souffrir sur internet, sur des sites plein de pubs où tu laisses toutes tes données. où tu es frustré parce que tu convertis, ça va faire exprès d'arriver à 90%, et à la fin, ils vont dire, maintenant, il faut payer, ou alors il faut créer un compte et installer une autre application. Là, je sais que j'ai mon petit programme et je peux le relancer au besoin. Pourquoi pas, si à un moment, j'ai besoin de faire d'autres conversions de fichiers, l'adapter, vu que j'ai déjà les librairies et ce genre de choses, je sais que c'est faisable. Et voilà. Donc ça, c'était trop cool et ça a répondu pile à une frustration qu'il y avait là. Et au final, ça m'a pris moins de temps que de chercher une solution plus classique, de télécharger une appli, de potentiellement payer pour le faire. Et voilà.

• Speaker #0

  Ouais, donc là, l'appli que tu t'es fait, elle était installable directement sur ton ordinateur. Elle n'a pas besoin de connexion Internet pour fonctionner.

• Speaker #1

  C'est ça.

• Speaker #0

  Et tu as pu le filer à... plus à qui c'était,

• Speaker #1

  qui en avait besoin.

• Speaker #0

  Ma belle-sœur, oui, c'est ça. Et elle, elle a pu l'installer, s'en servir directement aussi, parce que c'était très simple. Ou même pas, tu lui as envoyé juste le fichier. Ah non,

• Speaker #1

  j'ai juste envoyé le fichier, parce que, voilà, c'était... J'ai dit, bon, là, j'ai des livres qui pourraient te plaire. Voilà, il y a les MP3, il n'y a pas besoin de soucis de compatibilité, ce genre de choses.

• Speaker #0

  Trop bien. Et après, du coup, cette première application, est-ce que ça t'aide ? Donner envie d'en refaire directement ou pas ? Puisqu'on fera le lien aussi justement avec la partie design et maquettage qui a l'air quand même de beaucoup te plaire. Mais sur la partie vraiment app et petite app, est-ce que depuis, tu en as refait avec l'autre code ou pas ? Et juste tu gardes des idées dans un coin pour les faire à un autre moment ?

• Speaker #1

  Je me garde des idées. Le problème, c'est que j'ai souvent trop d'idées. Donc si je me mettais à développer à chaque fois que j'avais des idées, je ne serais pas rendue. parce que ça n'irait pas. Là, c'était vraiment bien, parce que ça partait d'une frustration et d'un problème qui était bien identifié. Je savais à peu près, même techniquement, ce que ça allait me demander en termes d'installation. Je savais que ça n'allait pas être trop complexe. Et surtout, je n'avais pas besoin que l'appli soit jolie, il fallait que ça soit fonctionnel, ça tournait en local sur mon PC. Voilà, là, c'était un peu le cas facile. Et il y avait un petit peu cette peur. d'aller sur des applications peut-être un peu plus grosses, de penser tout de suite déploiement, mise en ligne, ce genre de choses. Et c'est pour ça que je tentais encore un petit peu sauveteur à côté, en me disant, ça peut être le juste milieu, avec des composants qui sont déjà testés, l'hébergement est géré. Mais en même temps, il y a la petite limitation où tu sens que tu ne peux pas tout faire dedans. De se dire, si j'ai déjà la logique et... peut-être trouver une méthode qui permet de bien définir en amont et ensuite juste guider l'IA une fois que tu as ta bonne architecture, que tu as bien tout défini. Et c'est ce petit pas qui me manquait et justement la lecture du livre a donné les billes pour faire ça avec des méthodes qui m'ont plutôt bien parlé et qui me semblent assez pertinentes sans tomber dans l'usine à gaz. Et là j'explore des petites idées mais je vais beaucoup plus me concentrer sur la partie design avant. même de passer dans Cloud Code pour pas pourrir du code avec du front et plein de modifications.

• Speaker #0

  Et c'est vrai que l'autre fois justement tu avais parlé, enfin dans notre épisode précédent, enfin dans nos épisodes précédents, où tu parlais du fait que tu utilisais pas mal Obsidian, et qu'une des raisons pour lesquelles tu aimais bien Obsidian c'était aussi justement pour le fait d'avoir des fichiers on dit à plat, c'est-à-dire que tu as directement dans ton dossier, dans ton explorateur de fichiers, et qui sont utilisables en l'état par Cloud Code, qu'est-ce qui fait que tu préfères utiliser Cloud Code avec les fichiers comme ça, plutôt que les projets Cloud, par exemple, qui ne sont pas dans Cloud Code ?

• Speaker #1

  C'est peut-être juste une fausse idée, mais de me dire que ça ne fait pas... partie du contexte et Claude peut aller piocher dedans s'il faut et d'itérer dessus parce que c'est un peu un des problèmes quand tu mets des fichiers dans un projet Claude, c'est que les fichiers sont fixes et tu vas produire des artefacts après par dessus. Moi j'aimais beaucoup ce côté vivant de tous les fichiers que tu vas mettre en contexte, si t'avances et que t'itères, tu peux demander aussi après à modifier et tirer des... conclusion ou ce que tu as appris sur ton projet et ça va te servir ensuite. Donc c'est un peu une préférence de savoir qu'il écrit même en dehors de Claude. Enfin je me dis bon Claude c'est qu'un outil que je rajoute par dessus mes fichiers en Markdown et le reste m'appartient c'est sur mon PC. Voilà c'est un peu visuel, je pense que c'est surtout ça. Et de pas me retrouver avec plein d'artefacts à télécharger. Là c'est rangé. Je pense que même, tu as pu voir le nombre d'onglets que j'ai, je vais me retrouver avec plein d'artefacts dans mes téléchargements, je ne range pas. Là, ça me permet d'avoir un truc qui est à peu près ordonné et c'est cool.

• Speaker #0

  C'est les SEO qui n'ont pas forcément utilisé Cloud classique dans la version, que ce soit bureau ou web d'ailleurs, mais en fait dans Cloud et comme sur les autres outils d'IA, on peut faire des projets. Le principe d'un projet, c'est qu'on va lui mettre des instructions spécifiques au projet pour lui dire ici je suis là pour travailler sur tel ou tel sujet et on peut y déposer des fichiers ou après pendant qu'on discute avec Claude lui faire créer des fichiers dans Claude ça s'appelle des artefacts qu'on va pouvoir rajouter au projet et du coup qui seront disponibles pour toutes les conversations un des gros intérêts des projets dans la version web c'est que déjà c'est dans la version web donc vous pouvez retrouver ça sur n'importe quelle machine si vous avez plusieurs ordi ou un ordi de boulot justement sur le travail, un portable à la maison, ce genre de choses, alors que du cloud code, lui, il va interagir avec vos fichiers en local, les fichiers qui sont vraiment sur votre machine. Donc voilà, l'aspect web est un intérêt. L'autre intérêt, c'est que les documents, les fichiers, les artefacts que vous avez dans un projet vont être mis en RAG. Pour faire court, disons qu'en fait, là, ils vont être découpés en plein de petits morceaux, stockés dans une base de données chez Anthropic. Et ça permet d'aller, quand vous discutez avec lui, qu'il aille piocher dedans des petits bouts. Mais en fait, il n'a pas tous les documents en permanence stockés dans son contexte. Donc, s'il a besoin d'une info dans un document, il va piocher dedans, il ne va pas ouvrir et ingurgiter tout le document d'un coup. Et là-dessus, par rapport à un cloud code, on va gagner aussi en contexte sur cet aspect-là. Mais la limite, c'est qu'effectivement, un artefact qui est dans le projet, si on veut le mettre à jour, il faut le supprimer du projet. pour depuis la conversation le réajouter au projet dans sa version modifiée. Et des fois, quand on va itérer et qu'il va mettre à jour plein de fois le même artefact, en fait, on doit attendre qu'il soit terminé pour le remettre dans le projet. Et on peut s'y perdre un peu quand on a plein d'artefacts dans la même conversation et qu'il y a eu plusieurs itérations, etc. Ça peut être un peu le bordel. Et après, l'autre point étant celui que tu viens de dire, que les artefacts et tout ça, ça reste dans le cloud. Donc OK, c'est dans le cloud web et c'est en Markdown et on peut aller les copier, les récupérer. Mais on ne les a pas sur la machine, on ne les a pas dans un format exploitable directement. On ne va pas enrichir des fichiers qui font que là, si tu peux faire l'improvise dans deux minutes, tu as encore tout de dispo sur ton poste, alors que côté web, ce ne sera pas le cas. Donc, voilà. Et surtout,

• Speaker #1

  alors, c'est cool de compartimenter, mais des fois, il y a quand même... J'aime bien faire des... pont entre des différents projets, ce qui est plus compliqué, en tout cas, avec la version classique des projets cloud, où tu ne peux pas juste faire des références en disant, tiens, il y a tel fichier de tel autre projet qui peut être intéressant, prends ce qui peut être bien, quitte à générer un nouveau fichier ou juste le mettre dans la fenêtre de contexte et le prendre en compte pour ce projet-là. Je trouve l'approche beaucoup plus flexible. Comme ça et au final dans la partie Claude classique on peut quand même aller mettre une sorte de mémoire générale. Mais ça reste... Il y a la partie skill aussi. Les frontières ne sont pas complètement délimitées. Il y a des cas où un projet cloud va largement suffire et d'autres cas où j'aime bien avoir cette architecture où il y a un petit peu les projets sur lesquels j'ai envie de travailler mais des préférences que j'ai et qui vont se retrouver un peu partout. Mais c'est quand même dur à formaliser d'un seul coup, dans un seul paragraphe. Je trouve que c'est beaucoup plus puissant dans Cloud Code. Et j'avais vu beaucoup d'utilisateurs d'Obsidian utiliser Cloud Code, justement. Alors pas forcément pour créer et écrire de la connaissance ou de l'information. Ça, j'en avais déjà parlé avant que je séparais encore beaucoup. Mais par exemple, on importe énormément de notes. On peut s'en servir pour aller... modifier tout ce qui va être les tags, ce genre de choses, et bosser là-dessus. Et ça, par exemple, ça va coûter beaucoup moins de crédit que prendre un MCP et agir dessus.

• Speaker #0

  Oui, là-dessus, effectivement. C'est vrai que l'approche en question, je suis à moitié d'accord. Ah bah, si, on va reprendre dans l'ordre. Ce que tu viens de dénoncer sur le cloisonnement des projets, et le fait qu'on peut avoir besoin d'autres documents et d'autres choses, d'autres sources de données qui sont dans l'espace, enfin qui seraient dans un espace, et du coup que ce soit bloqué en côté projet, c'est quelque part, si nous n'avons plus tous les deux sur Notion et AI au début, se dire, ah c'est bien, enfin on peut travailler sur des pages, sur des notions, sur des projets, mais quand on a besoin, on peut aller chercher dans notre Notion, si on lui donne la page, etc., en référence, la page ou le dossier ou la base de données, il va pouvoir aller chercher de l'info par lui-même et compléter. Il faut savoir que dans Notion AI, le travers de ça, c'est qu'à l'usage, en tout cas sur mes usages, il allait manger un peu trop n'importe quoi dès qu'il sortait de la page ou du projet, et même des fois, ce qui m'a tué, c'est le nombre de fois où il allait me chercher des choses que j'avais mises dans des archives ou que j'allais carrément à la corbeille et qu'il s'appuyait dessus pour me répondre, ce qui m'obligeait des fois à les supprimer. définitivement des documents de la corbeille alors que ça m'aurait arrangé de les avoir au cas où j'ai besoin d'un historique. Et j'étais obligé de faire comme ça.

• Speaker #1

  Je crois que si jamais aujourd'hui ils ont mis une fonction d'archive, enfin une vraie fonction d'archive, et là, ce que tu dis, je pense que c'est inhérent même à la structure même de nos chaînes où tout est bloc. Et je pense que de ne pas avoir un peu cette vue peut-être de plus haut, de voir la hiérarchie de chaque... Le projet de savoir où est-ce que c'est rangé, et encore, s'il passe à côté du document qui explique où est-ce que tu as tout bien rangé, je trouve que c'est encore assez opaque. Alors tu vois où est-ce qu'il va aller chercher, mais tu ne sais pas dans quel ordre, machin, et ça peut être complètement à côté de la plaque.

• Speaker #0

  Après, c'est effectivement structurel, parce que ce qui semble être une force de notion au début, et puis plus on s'en sert, plus on se rend compte que c'est plutôt une grosse faiblesse, c'est le fait de pouvoir imbriquer des pages dans des pages. Parce que c'est comme ça que tu construis des labyrinthes et que même si tu as peu d'étages dans ton labyrinthe et que tu t'en tiens à deux ou trois, en pratique, ton info, elle est déjà en bord. Elle est déjà difficile à exploiter. Il faut favoriser les bases de données, mais en même temps, les bases de données dans Notion, elles ne sont pas forcément adaptées à tous les usages. Elles sont bien pour certaines choses, mais... Alors là, ils ont beaucoup de choses qui sont à la fois très intéressantes et intuitives au premier abord, mais qui sont, dans la durée, pour moi, des... points vraiment bloquants et emmerdants. Et en revanche, dans ce que tu as dit, le fait par exemple d'être dans un projet cloud et de lui demander d'aller chercher de la donnée dans un ocean ou dans autre chose, il va utiliser le MCP et ça va coûter excessivement pour rien. C'est-à-dire que pour aller chercher un document, il va devoir faire plein d'appels et donc consommer beaucoup de tokens. et c'est pas du tout une approche efficiente et en plus ça bourre le contexte de l'IA donc c'est vraiment à éviter autant que possible les MCP même si c'est devenu malheureusement oui et non parce que ça dépanne mais c'est un des standards aujourd'hui et en pratique c'est quand même assez limité pour ces raisons là et en même temps quand tu travailles dans le Cloud Code de base tu travailles dans un dossier tu travailles dans un répertoire, moi c'est vrai que je m'en sers surtout pour du développement, donc je vais travailler dans un répertoire qui va être orienté code et synchronisé avec du git et ce genre de choses. Donc normalement, t'es pas censé non plus polluer en allant mettre d'autres documents à l'intérieur qui n'ont pas lié au projet. Mais le gros intérêt qu'il va y avoir côté Cloud là-dessus, c'est qu'il va pouvoir travailler dans son espace et quand on va avoir besoin qu'il aille chercher de la donnée ailleurs, ponctuellement, il peut le faire soit via MCP, si on a déjà rajouté le MCP de l'autre côté, côté Cloud classique, mais il va aussi pouvoir potentiellement utiliser des API, directement des outils. Et là, on y gagne énormément puisque... On s'extirpe des travers des MCP sur la consommation de tokens, sur le contexte et tout ça, pour avoir quelque chose de bien plus efficient sur la manière dont il va rechercher l'information ou il va interagir avec notre espace de travail. Parce qu'API, après, ça peut être peu importe. Au final, ça peut être par Notion, par... c'était plutôt Fibery. Toi, du coup, Obsidian, c'est... Ouais, je ne sais même pas. C'est aussi par API, je ne sais plus avec quoi il interagit.

• Speaker #1

  Obsidian ? CloudCode, il interagit directement avec les fichiers en Markdown sur ton PC en local. C'est là où c'est très efficace.

• Speaker #0

  Oui, du coup, quand j'ai testé Obsidian l'autre fois, justement, il y avait le fait de, si tu donnais accès à ton workspace Obsidian, il fallait aussi un CloudMD à la racine et il l'explorait d'une manière un peu différente. Je n'ai pas très bien compris ce concept d'intégration, s'il allait juste triturer les fichiers, mais avec un format, une structure particulière. Pardon. bref,

• Speaker #1

  on digresse un peu d'ailleurs t'as des skills qui existent parce qu'on en avait parlé mais dans Obsidian c'est un Markdown un peu particulier et t'as des skills exprès pour Cloud Code pour qu'ils conservent l'écriture de ces fichiers Markdown et qu'ils conservent surtout tout ce qui est rétro-liens et voilà ce genre de choses, mais il me semble qu'il va aller lire comme des fichiers de code Et c'est là où j'avais vu beaucoup de personnes qui avaient par exemple migré et qui se retrouvaient avec soit de l'Evernote ou du Notion, avec plein de notes atomiques, et d'aller mettre les tags par exemple dessus. Ça en plus t'es pas obligé de le faire avec un gros modèle, et juste de se dire ah bah tiens c'est tagué de telle manière, et comme ça après dans Obsidian t'as pas à tout refaire à la main et tout ça. Là, c'est assez pertinent. Je me dis que ça peut même être pertinent de passer par là avant de faire une importation dans un autre outil. Là, je ne sais pas si par exemple, ça pourrait te servir pour Unitype, ce genre de choses. On en reparlera,

• Speaker #0

  mais à un autre moment. On va continuer sur le truc. Parce qu'effectivement, j'ai fait une expérimentation comme ça. C'est un peu plus qu'une expérimentation. Mais j'ai voulu essayer Obsidian, et donc j'ai migré mon Fibery vers Obsidian. pas du tout aimé obsidian et du coup j'ai fait une autre migration de mon fable actuel vers any type que j'avais déjà mais que j'avais laissé un peu en stand by et du coup j'ai créé un nouveau workspace mais justement j'ai utilisé cloud code pour faire des migrations à travers l'API les api des différents outils et du coup ce qui m'a permis d'aller adapter repenser la structure de ce que j'avais d'un côté pour l'adapter aux nouveaux outils avant d'entamer mais l'immigration avant de faire les scripts avant de faire tout ça et voilà On en reparlera un peu plus tard. Mais pour en revenir justement...

• Speaker #1

  Ça me fait penser juste à un tout petit truc aussi, un truc tout bête qui fait que je préfère aussi utiliser Cloud Code, même pour des conversations que j'aurais pu faire sur la partie Cloud classique. C'est qu'on voit un peu plus les données, on voit la fenêtre de contexte, on peut choisir le niveau de réflexion. Je trouve qu'on a beaucoup plus d'informations pour orienter et bien un peu suivre et monitorer. ce qui se passe et pouvoir ajuster aussi. Ça, c'est quelque chose que j'apprécie et qui n'est pas forcément sur l'interface cloud classique.

• Speaker #0

  Ah oui, mais clairement. Juste pour ne pas me zapper après, pour finir là sur cette histoire d'exploiter ton dossier local et le fait d'aller utiliser par exemple une API derrière pour aller chercher dans ton espace de travail ou ton autre outil, c'est, et tu en as parlé, le fait de pouvoir utiliser les skills. Donc, les skills, si vous ne savez pas ce que c'est, on vous renvoie à l'épisode, quoi, il y a deux semaines ? Non, peut-être trois semaines ? Je ne sais plus. Bon, notre épisode sur les briques de l'agent TIC. C'est ça,

• Speaker #1

  on mettra le lien en description, à la limite, vu qu'on y fait référence.

• Speaker #0

  Oui, où on expliquait un petit peu justement les différentes briques d'un agent IA, mais qui s'appliquent aussi dans les assistants. Et il y a un concept, donc les skills qui sont les compétences. Et dans le cas de Cloud Code, le fait de lui mettre des skills, on peut lui mettre aussi justement... des informations sur les API à utiliser, de quelle manière les utiliser, pour qu'au besoin, quand on est en train de travailler, on a besoin qu'il aille chercher un doc quelque part dans un ocean, il ne va pas passer par le MCP, il va utiliser l'API, il va être beaucoup plus efficient, et il va juste utiliser son skills au bon moment pour savoir comment il doit travailler et comment il construit notre espace. Donc là-dessus, c'est vrai que ça a plein d'intérêt de bosser dans le code pour du local. Après, il faut avoir en tête ces choses-là. Ça va impliquer un peu plus de paramétrage et de choses à la mano que ce qu'on a dans la partie web, mais ça débloque plus d'usages et plus de possibilités.

• Speaker #1

  C'est ça. Et aussi, effectivement, quand on travaille dans un projet, on peut créer un peu des artefacts à chaque fois, quand on termine une conversation, ce genre de choses. Mais là, ce que j'aimais bien dans Cloud Code, c'est que même si on fait une conversation, on peut rédiger. sorte de mémoire qu'on a au fur et à mesure et qui peut servir pour la fois d'après. Il y a peut-être un peu plus de contrôle là-dessus, de dire, bon, là, par exemple, j'ai passé dans une nouvelle conversation avec ce même contexte, mais prends les points les plus importants qui vont te servir pour la conversation d'après, quand on voit qu'il faut un peu reset le contexte, sans forcément faire la compaction soi-même, et ça permet de vérifier aussi. et de se dire, bah non, rajoute, on a quand même eu cette conversation là-dessus, je veux que ça apparaisse pour la conversation d'après. En fait, ça permet d'avoir des choses qui sont un peu plus tangibles, qui existent en fichier, qu'on peut aller lire, qu'on peut vérifier, qu'on peut même éditer nous-mêmes, sans devoir demander à Claude Codd, ou à Claude de le faire, et ça, je trouve ça un peu plus sympa, de me dire, bon, bah là, il manque une petite... partie, je ne vais pas aller spécifiquement demander à l'IA d'aller rajouter une phrase alors que je sais exactement ce que je vais écrire dans mon fichier texte. C'est une approche peut-être un peu plus raisonnée aussi.

• Speaker #0

  Oui et puis tu l'as dit, le fait de pouvoir calibrer, de choisir le modèle, de choisir le niveau de raisonnement du modèle, de choisir d'abord une visu sur le contexte, qu'est-ce qui est utilisé et pourquoi. Et sur le contexte, c'est hyper important puisqu'en fait en pratique un LLM idéalement il faudrait pas le faire dépasser 30 à 40% de son contexte. Au-delà de ça, les erreurs commencent à devenir trop importantes, ils l'ont fait de plus en plus, et voilà, le bon dosage c'est de le garder sous ces 30 voire 40% max, et c'est des préconisations anthropiques. D'ailleurs je me demande s'ils sont pas sur 30, eux, carrément, dans leurs précos. Raison pour laquelle c'est très utile et intéressant d'avoir ce contexte-là, puisqu'on va pouvoir avoir ce pourcentage de remplissage de contexte. Et dès qu'on commence à dépasser les 30 et qu'on arrivera à les 40, on sait qu'il va falloir boucler et enchaîner sur de nouvelles conversations. Et ça permet d'utiliser une IA de manière qu'elle soit toujours pertinente et la plus utile et efficace possible, et avec les autres bénéfices que tu as cités juste avant sur les fichiers.

• Speaker #1

  Parce que c'est vrai qu'en soi... Tout ça, c'est fait dans la partie Claude classique. C'est juste que c'est caché et c'est fait plus ou moins automatiquement. Tout ce qui va être compaction du contexte, le fait de peut-être mettre à jour la mémoire, mais ce n'est pas forcément ce qu'on lui aura dit. C'est moins conscient et j'aime bien ce côté. Je maîtrise quand même ce qui est écrit. Je sais ce qui a décrit, ce qui a été écrit. Je l'ai validé et je sais que je peux... vais pouvoir m'appuyer là-dessus sur un projet d'après, sur une autre conversation et que ça soit à peu près vivant et que le jour où j'ai envie de partir de chez Anthropique, j'ai déjà tous mes dossiers qui sont propres. Et je peux en faire d'autres choses.

• Speaker #0

  Oui, oui. Effectivement. C'est une bonne approche, mais je redemandais puisque l'autre fois, on avait parlé du fait que tu avais une préférence propre. les codes sont forcément trop rentrés dans le détail et expliqués et là pour les gens qui ont jamais mis des mains dedans ce sera peut-être donner une idée de pourquoi c'est pertinent aussi pour la bureautique même si aura un autre notre fonctionnalité enfin fonctionnalité notre interface on va dire de claude qui est claude co work qui est censé être un peu le mix et l'hybride entre du cloud classique et du cloud code mais dont on discute une prochaine fois, je pense, puisque je sais que je l'ai assez peu utilisé personnellement pour privilégier le code.

• Speaker #1

  Je ne l'ai pas utilisé non plus.

• Speaker #0

  Et j'ai l'impression qu'il veut mêler un peu le meilleur des demandes, mais il n'a pas forcément autant de... Il a des limitations, il n'a pas forcément tous les avantages d'un Cloud Code.

• Speaker #1

  C'est ça. Et moi, je me dis si Cloud Code me va bien. J'ai l'impression d'être sur un workflow qui est plutôt conscient et où je maîtrise un peu plus ce que je fais et ça me plaît bien comme ça.

• Speaker #0

  Avec l'application de bureau. Oui,

• Speaker #1

  l'application de bureau.

• Speaker #0

  Typiquement, sur de Linux, il n'y a que le terminal. c'est déjà un peu plus raide à prendre en main.

• Speaker #1

  Oui, en fait, je ne perds pas trop quand même tout ce qui est commodité de mes projets cloud, sauf que là, les projets, c'est juste des dossiers sur mon ordinateur que je peux aller modifier et aller citer.

• Speaker #0

  Et notre point dont on n'a pas parlé sur le fait d'avoir la main, c'est qu'on peut aussi choisir la manière dont Cloud Code va bosser et réfléchir sur nos fichiers, puisqu'on va avoir le fait, vu qu'à la base, c'est pensé pour du code, On a plusieurs modes où il va soit demander les permissions dès qu'il veut faire quelque chose, soit il va avoir par défaut le droit de faire des choses, de la consultation et de la lecture et ce type de manip, mais il viendra demander un accord pour les modifications. Soit on a un mode où il va être en planification, et là on va lui donner le prompt, l'objectif et ce qu'on veut faire, et il va mouliner tout ça, il va réfléchir, il va nous proposer tout un plan d'action. qui va mettre en oeuvre pour atteindre justement l'objectif qu'on lui a donné ou les objectifs qu'on lui a donné et après il y a encore deux modes qui sont le mode automatique et donc là il peut dérouler le plan et tout faire en autonomie en autonomie enfin voilà à nuancer puisqu'il faut le surveiller, il faut voir un peu ce qu'il fait mais dans l'idée c'est ça, c'est que si le plan est bien calibré et qu'il n'y a pas de piège il va avancer, il va dérouler tout seul et après il y a un autre mode à ne jamais utiliser qui est le fait de autonomie avec On appelle le bypass des protections et des autorisations. Donc vraiment, il est en roue libre. Il a tous les droits. Et en mode automatique, il va quand même s'arrêter à certains endroits quand c'est critique, quand c'est important. Il y a encore des garde-fous humains qui n'arrivent pas à outrepasser. Par contre, le dernier mode, là, c'est...

• Speaker #1

  Ça peut être marrant dans une machine virtuelle, à la limite. Pourquoi pas ?

• Speaker #0

  Oui, éventuellement, mais même comme ça, à la fin, c'est de la perte de temps parce qu'il va forcément faire des conneries. Et il faudra forcément les rattraper. Et bon, du coup, c'est de l'énergie, des tokens et tout, de consommer pour rien.

• Speaker #1

  Surtout qu'on est plus, nous, dans une philosophie de beaucoup préparer en amont avant de passer à la prod.

• Speaker #0

  Oui, oui, non, qui veut plus.

• Speaker #1

  On ne va pas être en mode à laisser, vas-y, fais-moi une application, et puis je reviens demain.

• Speaker #0

  Non, et puis l'équilibre, ça reste sur un petit moment. Le mode automatique, en fait, il convient déjà largement, puisqu'il donne assez d'autonomie à Claude pour avancer tout seul, tout en ayant quand même des garde-fous sur les trucs les plus importants. Et même en autonomie, il faut quand même le surveiller, l'avoir à l'œil, parce que des fois, il va prendre des initiatives de lui-même qui ne vont pas être les bonnes, ou en tout cas pas celles qu'on veut.

• Speaker #1

  C'est ça. Tout ça pour dire, avant qu'on repasse peut-être sur la partie vibe coding rapidement, que... Cloud Code, ce n'est pas parce qu'il y a code dedans qu'il faut forcément coder avec. Et ça peut juste être de l'édition de fichiers, textes et ce genre de choses. Donc, ça peut valoir le coup de tester.

• Speaker #0

  Ou de la conversation, puisque contrairement à son code classique, justement, quand il va avoir besoin de faire des choses, il va être en mesure de faire du code, donc de faire des scripts, de faire des interactions ou d'aller utiliser des API et des choses comme ça qui ne sont pas forcément possibles en MCP, donc avec les intégrations classiques. qui pourraient l'être mais qui vont être beaucoup plus consommatrices avec les connecteurs habituels et mettre en place des tout petits outils comme tu nous as cité tout à l'heure. Il y a quand même beaucoup de bonnes raisons à aller sur du Cloud Code et sans que ce soit nécessairement l'approche terminale qui fait peur avec du noir et blanc façon geek. Ils ont mis une belle interface. Et petit à petit, en plus, ce genre d'outils, il y a déjà des alternatives qui existent en open source, il y en aura d'autres qui viendront, et c'est quand même, voilà, ça ou Cowork resteront des alternatives intéressantes pour aller travailler avec des vrais fichiers de votre ordinateur, c'est comme ça, et une approche plus maîtrisée et plus granulaire dans ce que vous allez faire avec l'IA. Mais tout l'intérêt de comprendre un peu les briques, Chose dont on avait déjà parlé à travers les fondamentaux, à travers les briques de l'agentique. Et pour demain, dans votre boîte et dans vos prochains usages, plus vous avez la maîtrise et plus vous savez comment vous voulez utiliser l'IA et dans quel objectif, plus vous pourrez tirer parti des petits réglages dont on a parlé avant, de toutes les petites spécificités pour en faire quelque chose de vraiment le plus adapté à vos besoins. Bon, je vois que le temps a déjà filé, en parlant de Cloud.

• Speaker #1

  Est-ce que tu veux nous parler un petit peu de ton approche avec Cloud Code aussi ? Comment est-ce que tu as appréhendé tout ça ?

• Speaker #0

  Alors, pas tout détaillé puisque... En fait, ce sera aussi l'occasion d'en reparler dans des prochaines fois. Mais quand même refaire le lien avec ce qu'on disait tout à l'heure avec le livre, puisque le vibe coding, pour le coup, pour donner un peu mon contexte perso, je suis no-coder depuis pas mal d'années. J'ai bossé dans l'informatique, dans plein de boîtes, dans plein de domaines depuis 10-15 ans, globalement, plutôt 15 ans. Et donc j'ai vu plein de niveaux différents, j'ai toujours bien aimé ça. Mais je ne suis pas développeur, j'ai déjà fait du code il y a longtemps, mais c'est dans le cadre justement d'une école d'ingé, et ça ne m'avait pas plu. J'ai essayé bien plus tard avec le no-code, donc il y a 6 ans, 2026, 6, 7 ans, 7 ans, quand j'ai découvert le no-code, que je me suis rendu compte qu'en fait, j'aimais les logiques de développement, j'aimais la programmation, et voilà, le raisonnement qu'il y avait derrière, mais pas rédiger et écrire des lignes de code. Pourquoi c'est pareil ?

• Speaker #1

  Non, c'est juste que c'est exactement pareil. Je voulais faire plein de trucs avec l'informatique, mais je ne voulais pas apprendre à écrire du code. Les logiques, l'algorithmique et ce genre de choses, ça m'intéresse énormément. De savoir comment un logiciel, on va faire l'architecture, comment est-ce qu'on va le penser, le parcours utilisateur, comment est-ce qu'on va gérer les données, et tout ça derrière. Mais par contre, le traduire en ligne de code, avec la syntaxe, ce genre de choses, les types de variables. Si, j'ai un peu la culture là-dessus, mais voilà, j'ai la culture, c'est cool, et ça me va très très bien comme ça. Je préfère me casser la tête sur d'autres choses.

• Speaker #0

  Mais c'est vrai que justement, le no-code nous a porté ça, le fait de se dire on voit des usages, on voit des besoins, on a envie de faire des solutions avec et de faire des choses que les gens vont vraiment utiliser. Et à ce titre là, les outils NoCode, c'est super parce qu'on fait quelque chose de concret, c'est visuel, c'est actionnable rapidement, on peut le mettre dans les mains des gens et ils s'en servent et on voit l'intérêt et ainsi de suite. C'est vrai que moi ça m'a donné une vue différente du produit et une approche différente. Après j'ai un gros passif dans le support client, donc c'est vrai que j'ai toujours été attaché au fait de vouloir aider les gens qui utilisent les produits. que ce soit matériel, logiciel, peu importe, et pouvoir leur expliquer à chaque fois comment s'en servir. J'ai toujours eu besoin de sens là-dessus, et du coup que ce que je fasse serve à quelqu'un, ait une réelle utilité, et que quand on travaille sur des logiciels, que ce soit dans une finalité effective pour les utilisateurs, et les utilisatrices, et pas que ce soit une fonctionnalité fantasmée ou idéalisée. pour du marketing ou ce genre de choses, si à la fin les gens ne s'en servent pas, ça n'a aucun intérêt. Et donc avec le code, le no code pardon, j'ai développé beaucoup de cette appétence-là et après j'ai été informé sur plein de choses, sur les ops, sur les automatisations et avoir plein d'autres familles à travers tout ça. Et c'est vrai que du coup quand j'ai rejoint Kobble, c'était il y a quoi, 3 ans ? 4 ans ? Je me dis que je reste à peu près 3 ans. Bon bref, il y a quelques années. Et je suis rentré du coup en tant Customer Delivery Manager, pour faire du déploiement de la chefferie de projet et aussi du support. Et après, j'avais eu la chance de basculer Product Owner, donc responsable produit, et de bosser directement justement avec les devs. Et mon collègue Sam qui était CTO, pour du coup développer le produit, notre logiciel, puisque... COBOL, j'en ai déjà parlé dans des épisodes précédents, mais c'est une plateforme no-code qui permet de créer ses propres générateurs de documents sous forme d'applications IA. Qui mêlait les deux, la partie programmation visuelle et le fait de mettre de l'IA et de l'agentique dès le départ pour mettre en œuvre des logiques métiers qui étaient complexes derrière sur la partie documentaire. Et donc de travailler justement avec une équipe de dev m'a permis d'avoir rentré encore plus dans le dire sur... tout le process de développement et tout le process produit entre justement le... vers là où on veut aller nous en tant que boîte, qu'est-ce qu'on a en tête pour les besoins des gens, la confrontation avec ce qui se passe quand ils ont vraiment les choses dans la main, tout le chemin technique pour arriver d'un endroit à l'autre, avec le fait d'identifier un besoin, de le comprendre, de le traduire en solution métier, de voir ensuite pour la partie implémentation, les contraintes techniques, les contraintes avec le reste de ce qu'on a fait avant, ce qui doit arriver après, la partie test et assurance qualité, enfin voilà. C'est tout un mandat le produit, c'est passionnant, il y a des étapes dans tous les sens, il y a des choses partout, mais c'est vraiment passionnant quand à la fin on arrive à mettre quelque chose dans les mains des gens qui leur sert vraiment et dont ils sont contents. Et là-dessus, ça m'a beaucoup servi dans le no-code, mais malgré tout ça, le vibecoding, et même avec ce bagage-là, j'étais très réticent au fait d'aller sur le vibecoding. parce que je ne sais pas lire le code. Enfin, je peux lire des petits bouts de code commenté, mais je ne sais pas en écrire des parpaings comme il faudrait pour un logiciel. Et je n'avais pas envie de ne pas avoir la main sur ce que je fais et d'être tributaire, au final, de l'IA pour piloter le code. Mais j'ai quand même suivi tout ça avec attention depuis le début du vibe coding, notamment à travers les contenus d'Alexis, dont on a parlé tout à l'heure, d'Alexis Koblenko. Il n'y en a pas que, après, sur d'autres médias et d'autres choses. J'avais joué un petit peu justement avec du lovable, mais pour moi, je m'en étais surtout servi pour faire des landing pages ou des supports de présentation. J'ai fait des supports de formation notamment avec, plutôt que d'avoir des PowerPoints. Je déteste PowerPoint. Donc ça m'a permis de faire des supports quand même un peu plus plaisants, soit pour des formations pro, mais d'ailleurs aussi pour CreaCity, quand on avait fait des ateliers sur l'IA. Et d'ailleurs, n'hésitez pas à rejoindre la communauté de CreaCity. Justement, on a tout un Discord où il y a des formations gratuites et des formations payantes. Il y a plein de choses, mais on échange dessus.

• Speaker #1

  Et des hamsters.

• Speaker #0

  Et des hamsters. J'étais obligée. Et oui, pour les hamsters, celles et ceux qui s'intéressent justement à la formation IA qui arrive prochainement. où il y a déjà eu un premier webinaire, en prenant justement le rapport à Hamster. Mais bref, Loveable, j'avais un peu joué avec, mais sur de la partie plutôt interface et justement vitrine web, sans aller plus loin. J'avais joué un petit peu avec d'autres outils d'ailleurs que Loveable, mais sans être convaincu au moment de devoir mettre en œuvre des bonnes pratiques de dev. J'avais notamment essayé une alternative que j'avais connectée avec Duxano, vraiment un moteur... tout le back-end, donc vraiment la partie base de données, moteur, logique, authentification, etc. Et en fait, au moment où j'avais voulu mettre en place, c'était sur la partie front, donc la partie vraiment interface, il y avait des fondamentaux qui ne marchaient littéralement pas. Mettre en place un design system, etc., ça cassait complètement. Et donc, quand les premières briques de base ne marchaient pas, je me disais, non, ce n'est toujours pas viable, il faut encore attendre. Et donc il y a quelques semaines, ça fait un mois, quelque chose comme ça, un mois ou deux qu'il a sorti son livre, Alexis. Et en fait, le livre a fini de me convaincre. Alors ça et d'autres questionnements que j'avais sur les outils dont on avait déjà parlé dans les épisodes précédents, puisque j'utilisais notamment Softair pour les portails clients. J'avais suivi de près aussi le retour de WeWeb avec leur ajout justement de la partie moteur et base de données derrière le back-end. Et les outils no-code avaient des points intéressants puisqu'il y avait tout le côté maîtrise de bout en bout, mais ils avaient aussi des limitations, notamment sur la partie produit, et sur ce qui me semble être un changement de paradigme et une évolution dans les standards du développement d'entreprise, qui se met à utiliser, que ce soit du cloud code ou des alternatives, puisqu'il y a la même chose chez Google et chez OpenAI, de se dire que le développement assisté par IA, ça devient des... peu à peu des vraies pratiques et des nouvelles pratiques de développement en entreprise et que c'est plutôt là pour durer, pour s'inscrire dans le temps, même s'il y a encore plein de choses qui bougent sur les techniques, sur les méthodes, sur tout ça. Mais je vois ça comme l'avenir du développement logiciel. Je me suis dit, bon, ça pourrait être le bon moment pour y investir du temps, essayer de prendre les bonnes pratiques, l'apprentissage et vraiment... se faire les dents maintenant, que les modèles sont assez matures pour pouvoir aller sur du code efficace, que l'écosystème et les outils autour nous permettent de le prendre en main d'une bien meilleure manière qu'il y a encore un an, ou même six mois, et aussi justement d'apprendre dès maintenant pour avoir la main. pour changer d'outil quand l'IA va commencer à coûter un bras, enfin même si c'est déjà cher en réalité. Mais voilà, l'inflation sera là quand il va y avoir des choix à faire au niveau des infrastructures, des acteurs, de la gestion des données, de la géopolitique qui peut encore nous amener plein de surprises sur l'année à venir. Et voilà, donc j'avais déjà tous ces questionnements-là, j'envisageais déjà ça comme... quelque chose à tenter et se mettre dedans, et le bouquin d'Alexis m'a complètement convaincu. Et alors, je vous le dis direct, le bouquin ne vend pas une solution miracle, il ne vend pas de la magie. Il ne va pas vous dire que le pipecoding, que le développement assisté par IA est exemple de défaut, exemple de limite, et que vous allez tout faire avec. Ce n'est pas du tout le cas, ce n'est pas le parti pris du livre. Et fort heureusement, d'ailleurs, puisque la réalité, justement, elle est bien plus nuancée, et bien plus complexe que ça. Mais le point étant que... Avec de la pratique, avec des méthodes, avec des process et en prenant le temps de faire les choses bien, on peut aujourd'hui faire des logiciels et des applications qui soient utilisables, même en production, avec des cartes de fou. Si jamais ça devient vraiment hors d'un périmètre de compétences qu'on a au niveau des vérifications, on peut se faire assister par des vrais devs pour aller... faire un petit tour de check-out complet avant la mise en prod par exemple, mais ça dépend aussi d'ampleur. Mais le but premier du whiteboarding, c'est quand même d'aller sur des applis pour peu d'utilisateurs ou quelques dizaines ou quelques centaines maximum, mais pas d'aller justement faire le prochain Facebook. Ce n'est pas l'objectif.

• Speaker #1

  Et pas les données de santé.

• Speaker #0

  Et pas les données de santé. J'allais nuancer en disant peut-être avec des vrais, mais aujourd'hui on n'a pas. Si, avec des LLM open source, ce serait très le bordel.

• Speaker #1

  Ou il ne faut pas se lancer là-dedans, ou de se faire assister par des personnes qui connaissent vraiment, pour le coup.

• Speaker #0

  Oui, c'est ça. Il faut avoir plein d'armes en main, on va dire, pour pouvoir faire du développement assisté par AI dans un contexte de données de santé. Parce que l'hébergement des données de santé, tout ce qu'il y a autour, est très... Alors c'est pas juste réglementé, c'est que c'est vraiment important, mais ça implique plein d'infras, plein de choses, et vous pouvez pas utiliser du cloud, du open AI comme ça pour aller sur de la donnée de santé, à moins d'être dans un environnement où vous êtes déjà justement sur du HDS, dans un contexte entreprise, et au final vous serez déjà développeur si jamais vous êtes dans ces milieux-là, et à même de traiter ces problématiques-là. Mais voilà, en tout cas, le bouquin a fini de me dire, bon ben oui je sais pas lire tout le code, Biii ! probablement qu'en ayant des méthodes, en s'organisant, en prenant le temps de tester, en prenant le temps de faire les choses bien, en prenant le temps de pratiquer et d'aller par contre utiliser un outil en tout cas no code ou low code pour le backend, donc là où c'est le plus épineux et le plus dangereux, chose qui fait que j'ai choisi du Supabase là pour travailler avec, on va pouvoir faire des applications de bout en bout qui soient quand même sécurisées, qui soient quand même fiables et qui soient... quand même déployable pour des gens. Et on est presque à une heure d'épisode, donc je vous raconterai la suite une prochaine fois. Mais la conclusion, c'était de dire que suite à ça, j'ai mis les mains dans le code il y a quoi ? Deux semaines ? Trois semaines ? Je ne sais plus. Trois semaines ? Je ne sais plus.

• Speaker #1

  À peu près, il y a un mois. Si tu comptes la partie spec avec.

• Speaker #0

  C'est ça, c'est que j'ai passé beaucoup de temps sur les specs, vraiment beaucoup de temps. Mais je ne regrette absolument pas parce qu'aujourd'hui, je suis ravi d'avoir passé tout ce temps de préparation, de cadrage projet et ça me sauve un peu la vie quand même à plein de titres. Mais voilà, je suis complètement tombé là-dedans et j'avoue qu'aujourd'hui, c'est un réel plaisir de développer avec l'IA puisque j'y retrouve en fait toutes mes casquettes produits que j'aime bien. de réflexion, de gestion, d'organisation, de choix dans le produit, de mise en place de tests, de vérifications. Je peux mettre ma touche absolument partout. La seule chose que je ne maîtrise pas, c'est pas moi qui ai écrit le code, mais c'est moi qui pilote tout ce qu'il y a autour. Je ne laisse pas aller en roue libre et je ne suis pas du tout dans les profils qu'on peut voir sur LinkedIn des gens qui font 15 agents en même temps et qui laissent... L'IA en automatique, je mets en place ce que j'ai vu et connu en no-code, en contexte entreprise, avec les devs, et j'essaie de mettre en œuvre aussi ce que les... Mes anciens collègues de chez Cobble m'ont appris et m'ont enseigné en bossant avec eux. Mais je me régale sur le développement assisté par IA. Ce qui fait que dans des prochains épisodes de Côté Outils, on reviendra sur ce qu'on fait avec ça. Puisque toi, on vous avait parlé de Lulu qui maquettait notre outil interne pour gérer le podcast du dernier clic. Et là, en fait, ce que je suis en train de développer, c'est cet outil qu'elle a designé à partir justement des specs que j'avais fait et après on a remanié un peu tout ça. On va y designer. Mais voilà, on aura l'occasion de vous en reparler puisqu'on a ça qui va arriver pour nous dans les prochaines semaines. On va avoir aussi un site sur lequel tu es en train de travailler en ce moment pour qu'on ait une vitrine pour notre site web et que vous y trouviez...

• Speaker #1

  Sacré vitride. Ça, c'est un musée, le truc.

• Speaker #0

  L'idée, en fait, c'est que vous aurez accès dessus aux ressources des épisodes qu'on met à chaque fois en complément et à d'autres ressources complémentaires qu'on a déjà en tête sur différents sujets aussi liés à la tech, à l'IA et à d'autres choses, notamment sur les parties données, confidentialité, enfin bref. Vous allez y trouver plein de choses, donc ça arrivera petit à petit au fil des semaines et des mois qui arrivent. Le site ne sera pas de suite quand même vu comme il a l'air cotant et qu'on est déjà sur nos premiers outils pour nous. Et qu'il y a d'autres surprises qui se préparent en secret, ça c'est avec RéaCity mais on aura l'occasion aussi de vous reparler d'un autre projet qui arrive. Donc on a plein de choses pour les prochains Côtes et Outils. Lulu, est-ce que tu voulais parler d'autre chose ?

• Speaker #1

  C'est vrai qu'il y a aussi quand même ce côté de se dire, si on pouvait le faire avec du no-code, est-ce que ce n'est pas mieux en termes de résilience de le faire là plutôt que d'utiliser de l'IA ? C'est un peu le truc de se dire, pourquoi est-ce qu'on utilise de l'IA pour faire quelque chose qu'on pourrait déjà construire ? Mais en soi... on utilise l'IA dans la construction, mais après, on a un code quand même qui nous appartient. On n'est pas tributaire d'une plateforme, on n'est pas tributaire de mise à jour, de hausse de prix ou de changement de vision. Là, c'est du code. Et à la limite, si en plus, c'est une application qui n'utilise pas d'IA, une fois qu'elle est développée, elle n'en consomme plus. Et c'est presque inerte, à part tout ce qui va être hébergement et ce genre de choses. Bon, après, il y a le maintien, le... c'est pas comme c'est à toi ça existe sur ton ordinateur ou sur ton git mais non juste pour nuancer ça c'est que effectivement le code une fois qu'il est fait il

• Speaker #0

  t'appartient tu peux le prendre tu peux le déployer ailleurs tu peux le remettre à un autre endroit si tu l'as chez un hébergeur américain tu peux choisir d'aller le mettre chez un hébergeur européen tu vas pouvoir le déployer à d'autres endroits Là où je veux juste nuancer, c'est que derrière, si tu dis qu'on n'est pas tributaire des hausses de prix, si quand même, parce que le fait de changer d'acteur de LLM par exemple, si on ne sait pas écrire du code et qu'on a besoin de rajouter des features, des fonctionnalités, pardon, ou de corriger des bugs, ou de faire de la maintenance, on a besoin de rédiger du code, et à ce titre-là, quand on développe avec de l'IA, si on n'est pas développeur, on aura besoin d'une IA, donc on sera quand même soumis...

• Speaker #1

  Ça reste quand même moins fermé. Je me dis, imaginons, si on prend un cas où il n'y a plus d'IA du tout, tu as quand même ton application. Au pire, tu apprends à développer. Mais ça sera long, ce n'est pas optimal du tout. Mais tu peux encore, toi, avoir la main dessus et faire des choses dessus, ou faire appel à des devs, si, par exemple, on a pu, ce qu'on a aujourd'hui comme matière première, Je le compare pas mal, par exemple, aux énergies fossiles et énergies renouvelables, avec cette idée d'utiliser les énergies fossibles pour développer ce qui est renouvelable après, derrière, et utiliser ça un peu comme une force de levier. Je le vois un peu comme ça, dans le sens où, par rapport à quelque chose qui est développé en no-code et que tu peux pas récupérer le code derrière, bah, tu peux vraiment rien faire, par contre. Si à un moment...

• Speaker #2

  Ouais, alors... Oui.

• Speaker #0

  Effectivement, enfin là où tu as raison, c'est que sur la partie IA, enfin bon, il y aurait le fait de se former au dev, mais même sans ça, je sais que moi personnellement, si j'ai fait le choix, c'est parce que je suis arrivé au moment où je sais que, enfin je considère et je pense que l'IA générative ne va pas disparaître, qu'elle est là, qu'elle va évoluer, mais qu'elle va rester, et du coup, il y aura d'autres outils d'IA, il y en a déjà qui existent, côté justement openweight, et je pense que c'est ce que tu voulais dire tout à l'heure sur le fait qu'on n'est pas dépendant des hausses de prix parce qu'on ne sera pas... bloqué sur un seul fournisseur. Si c'est plus anthropique, on pourra utiliser l'application et continuer à la maintenir avec d'autres LLM. Mais il n'empêche qu'on sera tributaire de LLM quand même et du coup de l'usage de l'IA pour le faire. Mais après, sur la partie no-code propriétaire, c'est pareil oui et non à nuancer parce que en fait dans les outils no-code, généralement on peut quand même récupérer les données. Oui, mais c'est dans des formats qui sont galères à exploiter, sans pas se mentir. Mais après les outils Onocode ont plein d'autres avantages, c'est que c'est beaucoup plus facile au quotidien d'un point de vue métier d'aller les retoucher, les modifier, que c'est du coup chez un acteur qui va gérer pour vous l'hébergement, l'infrastructure, la sécurité, l'abonnement il va avec quelque chose, si ces solutions là elles sont en place et qu'elles sont intéressantes encore pour plein de cas. On ne va pas jeter les outils no-code loin de là, c'est encore très important et adapté à énormément de cas. Et il ne faut pas aller sur du vibe coding. Après, pour aller sur du développement d'applications pour des gens en production, c'est aujourd'hui, en tout cas, encore pas donné à tout le monde, pas dans le sens où tout le monde ne pourrait pas s'y former, mais dans le sens... où ça demande d'apprendre beaucoup de concepts pour avoir toutes les branches de création du produit du début à la fin et assez de connaissances sur tous les différents aspects et de la curiosité, puisqu'en fait, on ne saura jamais tout. Mais quand on développe, ça va être de poser les questions justement à Claude au fur et à mesure qu'on développe sur toutes les choses qu'on ne sait pas pour les clarifier. Mais il y a quand même un certain nombre de concepts techniques derrière pour avoir tous les bouts. Globalement si vous voulez faire une petite application pour vous et pour 2-3 collègues de votre boîte, allez plutôt sur du lovable et restez dans un cadre comme ça qui est un peu le no code de l'IA puisque vous êtes quand même sur quelque chose d'assez balisé et qui ne vous permettra pas d'aller dans tous les sens et qui va gérer pour vous l'hébergement, la sécurité, plein de choses même s'il ne gère pas la sécurité de votre code entièrement, vous pouvez aussi avoir des trous. mais après le bytecoding avec du code-code ce genre de choses c'est voilà c'est quand même on va pas se mentir c'est beaucoup plus coton c'est aujourd'hui je pense que c'est vraiment adapté et le chemin naturel c'est pour les gens qui faisaient du no-code et qui aiment justement enfin qui ont déjà conscience de tout le parcours produit qui ont déjà vu à travailler sur les différentes étapes d'un parcours produit et qui ont envie d'aller plus loin dans la technique et pour eux du coup justement l'aspect développement assisté par IA est vraiment le chemin logique, en tout cas moi c'est comme ça que je la ressentis en tant que no-coder, c'est que j'avais vraiment l'impression quand j'ai commencé à mettre la tête dedans, de me dire que c'est là où je devrais être, c'est vraiment logique que je kiffe autant ça et que je me régale, parce que c'est l'étape d'après normale et c'est trop bien. Mais voilà, c'est quand même pas le chemin habituel. naturel, évident, et au même titre que quand on arrive sur nos codes, au début, il y a plein de choses à apprendre, de concepts. C'est ça,

• Speaker #1

  et on reste aussi sur comment est-ce qu'on va structurer nos données, comment est-ce qu'on va créer notre application, et ça, les problèmes qu'on retrouve dans le vibe coding, c'est des problèmes qui se retrouvent dans toute gestion de projet et création de produit, dans tous les cas. Sauf que là, il y a les questions de sécurité en plus qui ne sont pas prises en compte, et qu'il faut... intégrés parce que là, on ne parle pas juste d'une application qui va crasher ou ce genre de choses. On voit tout ce qui se passe avec des données sensibles qui sont en clair ou ce genre de choses. Il faut quand même un peu cette curiosité et de ne pas hésiter à être un peu inconfortable aussi de se dire, par exemple, il peut y avoir des failles de sécurité, je dois y aller et pas juste faire comme s'il n'y avait rien. Mais... Voilà, non, non, mais c'est, voilà, de se dire, bah, ça passe, ça a l'air de marcher, mais en fait, il y a plein d'erreurs qu'on ne voit pas et qui ne sont pas affichées, et le livre en parle très très bien. Il parle même, d'ailleurs, des différentes phases, enfin, les différentes catégories d'applications sur lesquelles on peut aller sans trop se poser de questions, celles où, bon, là, il faut commencer un petit peu. à réfléchir dès que, par exemple, il va falloir un bac N ou ce genre de choses. Et après, dès qu'on va intégrer des paiements, données de santé ou données vraiment sensibles, là, il faut se faire accompagner ou aller sur des outils no-code qui sont accrédités ou qui ont les bons garde-fous. C'est un entre-deux et, comme tu dis, le no-code n'est pas acheté. Il peut très bien y avoir des solutions hybrides et des fois, on ne va pas aller retourner dans tous les sens un outil no-code pour lui faire faire ce qu'il n'est pas censé faire et en même temps on ne va pas en vibe-coding reproduire un Notion parce qu'on veut refaire Notion, ça n'a pas de sens donc voilà je pense que c'est...

• Speaker #0

  en vrai je pense que les outils no-code ont encore de beaux jours devant eux là où c'est peut-être un peu plus délicat ou en tout cas sur lesquels j'ai plus de réserve c'était justement Softer qui euh qui reste aujourd'hui pour moi très bien si t'es en entreprise et que t'es du métier, que t'as besoin de te faire des solutions sur mesure, et que t'es pas dev, et que t'as pas le temps, et que tu veux te faire ça. Mais derrière, sur Software, je trouvais qu'il y avait vraiment des grosses limitations. Et après, en termes de maintenance, je trouve que ça vraiment galère, parce qu'il y a plein de composants, il y a plein de choses que tu peux pas faire, ou entre guillemets, de la bonne manière. Mais ça reste très bien pour se faire plein de petites app en interne, dans une boîte, sans avoir besoin de développeurs. proprement parlé et voilà des outils comme ça qui sont orientés sur les aides la création d'applications ou selon les cas il va falloir mesurer un peu le l'intérêt d'aller sur une solution une autre et la pertinence d'aller dessus typiquement tu vois oui web justement je trouve le parti pris très intéressant et très bien qu'ils aient rajouté le bac n est aujourd'hui sans faire un outil complètement au complet tu as envie de tout maîtriser en programmation visuelle, aujourd'hui tu peux le faire avec, et tu peux même le déployer après, enfin je sais pas s'ils ont mis le déploiement de backend qui est déjà disponible ou pas, mais en tout cas c'est prévu pour là dans les prochains mois donc c'est quand même très intéressant c'est quand même très puissant et tu peux pas faire autant de choses qu'en code pur mais tu pourras quand même aller très très loin maintenant c'est à trancher un peu au cas par cas en fonction des besoins en fonction de Si c'est juste faire une application dans un contexte défini, dans une boîte, ça peut être très bien juste de faire appel à des devs, enfin des devs, à des freelances ou à une agence, ou comme ça que de se former soi-même à vouloir y aller en se disant que ça va aller vite. Et c'est en fait que ce soit du côté d'une autre côté sur des outils puissants, parce que je l'ai cité WeWeb, mais on pourrait parler de Bubble aussi, mais si on veut aller sur des outils puissants pour faire des applications complexes, ça ne s'apprend pas comme ça en un jour. Il faut du temps, il faut des compétences, il faut de la logique, il faut plein de choses qui s'apprennent.

• Speaker #1

  Et tout le monde n'a pas cette appétence.

• Speaker #0

  Et tout le monde n'a pas cette appétence.

• Speaker #1

  Et c'est OK.

• Speaker #0

  Et oui, oui. Et après, côté IA, ce sera la même chose. Mais je veux dire, d'un côté ou de l'autre, le chemin pour aller vers des applications en production en entreprise, il n'est pas facile. Il implique de faire des choix et d'apprendre des choses et de monter en compétences. Mais dans le no-code, vous le pourrez sur plein de cas métiers. le mettre en œuvre avec des outils qui ont des interfaces visuelles et qui sont très adaptés à la plupart des besoins.

• Speaker #1

  Et c'est ça, en fait, ce n'est pas nos codes où il y a, c'est vraiment juste un moyen de répondre à un problème ou à répondre à des frictions. Et à la fin, il y a un produit. Et c'est juste la manière dont on le fait, c'est plus selon ses compétences, ses appétences. Et il y a plusieurs moyens d'y répondre, mais ce qui va rester vraiment... Important, ça va être la définition de ce besoin en amont, d'aller discuter avec les gens, voir vraiment leurs problématiques, faire toute la partie spec, PRD, user story, user flow. C'est cette partie-là qui me semble vraiment la plus importante et qu'on délaisse plus des fois des débats autour de no-code, IA, vibe coding, dev-trading. Non, en fait, c'est juste des outils et il faut les voir comme ça et connaître les forces et faiblesses et faire les choix. en fonction des choix éclairés, comme dirait Alexis.

• Speaker #0

  Parfait, je pense que c'était une belle conclusion. Merci pour ça. Un mot de la fin, Lulu, ou on n'est pas ?

• Speaker #1

  Non, je pense que c'est bon, on a déjà assez dépassé comme ça.

• Speaker #0

  Ouais, on a dépassé. Désolé, tu n'auras pas ta question aujourd'hui.

• Speaker #1

  On en est au huitième épisode, je n'ai toujours pas eu de question.

• Speaker #0

  Sinon, on repart sur 5-10 minutes, ce n'est pas possible. Merci à tous et à toutes de nous avoir écoutés. On se retrouve la semaine prochaine pour un épisode thématique sur les communs. Oui, on continuera. Sur la suite de notre épisode sur les communs numériques, on vous invite à écouter l'épisode de la semaine dernière qui présente déjà les familles de communs numériques et qui pose un petit peu le ton de ce qu'on parle quand on parle de communs numériques, de quoi il s'agit. Et voilà, on ira plus loin sur ce sujet. Et on se retrouve aussi dans deux semaines pour un autre épisode côté outils où on reparlera probablement de développement... J'ai dit visuel. Non, de développement assisté par IA. mais avec d'autres facettes et d'autres choses qu'on n'a pas évoquées aujourd'hui peut-être d'autres surprises d'outils si on en a aussi d'ici deux semaines ça bouge tellement vite et puis là il y a plein de choses dont on n'a pas parlé mais qu'on avait sous le coude aussi pour lesquelles on reviendra donc bonne journée ou bonne fin de journée selon quand vous nous écouterez et à la semaine prochaine pour un autre épisode du Dernier Clic au revoir salut