Benoit nous fait découvrir HelloLeo
Benoît de Montecler présente HelloLeo couplé à Xano pour construire un gestionnaire de liens intelligent (Link Digest) capable de scraper automatiquement des URLs, générer un résumé IA et extraire des images, dans l'objectif de simplifier la production d'une newsletter hebdomadaire.
Outils utilisés
Résumé de la session
Benoît commence par se présenter : entrepreneur depuis l'adolescence, passé par Bubble en 2017, fondateur d'InScale (solution de monitoring pour apps no-code, qui n'a pas décollé face à la concurrence des plateformes elles-mêmes) et désormais CTO d'Ecolux, une solution IA pour la finance dans l'hôtellerie et la restauration. Il explique son problème concret : il fait déjà sa veille, mais n'a pas le temps de la transformer en newsletter. L'idée est de construire un outil où il colle des liens, obtient automatiquement un résumé et des images, puis exporte le tout au format Markdown vers Substack.
Il précise avoir déjà tenté une première version sur Loveable, jugée trop approximative pour être reprise, et explique son choix de stack : Xano pour le contrôle visuel du backend (notamment la sécurité, les RLS de Supabase lui posant problème), et HelloLeo pour le frontend, car l'outil est nativement connecté au MCP de Xano.
La session démarre sur HelloLeo avec la création du projet "Link Digest" et la connexion à l'instance Xano via clé API. Benoît explique qu'il faut manuellement fournir la base URL de l'instance Xano, car le MCP ne la récupère pas seul. Une fois connecté, HelloLeo génère une page de login et une page de signup, corrige rapidement une erreur d'URL de groupe d'API, et réussit l'authentification.
Benoît crée ensuite une table Links dans Xano via prompt HelloLeo. L'IA place correctement les APIs dans le bon groupe, mais génère un endpoint GET trop complexe : elle récupère tous les records puis filtre en boucle côté applicatif, au lieu de faire une requête filtrée directe. Benoît corrige manuellement en mode visuel dans Xano, illustrant précisément l'intérêt de la programmation visuelle pour auditer et corriger le code généré.
Il simplifie également le formulaire d'ajout de lien : l'IA avait exposé tous les champs de la table (titre, description, images) alors que seule l'URL est nécessaire à la saisie, le reste devant être rempli automatiquement par le scraping.
La partie backend se poursuit dans Xano en direct : Benoît crée une fonction dédiée "scrap_link", intègre un appel à Firecrawl via curl importé depuis la documentation, gère les variables d'environnement pour les clés API. Il rencontre un problème avec le bearer token OpenAI lié à une expression Xano mal formée, qu'il résout en passant à une configuration manuelle classique. Il construit ensuite le prompt pour OpenAI (résumé en 300 caractères + liste d'URLs d'images), récupère la réponse, la décode en JSON et met à jour l'enregistrement en base.
De retour sur HelloLeo, Benoît demande l'affichage des images disponibles avec un effet de survol agrandi. Le résultat n'est pas parfait mais itérable. Il ajoute ensuite la sélection d'une image au clic, qui déclenche un PUT vers Xano pour mettre à jour le champ "selected image". La session se conclut sur un produit fonctionnel de bout en bout (ajout de lien, scraping automatique, résumé IA, sélection d'image), avec une démo rapide d'Ecolux construit selon la même approche.
Il précise avoir déjà tenté une première version sur Loveable, jugée trop approximative pour être reprise, et explique son choix de stack : Xano pour le contrôle visuel du backend (notamment la sécurité, les RLS de Supabase lui posant problème), et HelloLeo pour le frontend, car l'outil est nativement connecté au MCP de Xano.
La session démarre sur HelloLeo avec la création du projet "Link Digest" et la connexion à l'instance Xano via clé API. Benoît explique qu'il faut manuellement fournir la base URL de l'instance Xano, car le MCP ne la récupère pas seul. Une fois connecté, HelloLeo génère une page de login et une page de signup, corrige rapidement une erreur d'URL de groupe d'API, et réussit l'authentification.
Benoît crée ensuite une table Links dans Xano via prompt HelloLeo. L'IA place correctement les APIs dans le bon groupe, mais génère un endpoint GET trop complexe : elle récupère tous les records puis filtre en boucle côté applicatif, au lieu de faire une requête filtrée directe. Benoît corrige manuellement en mode visuel dans Xano, illustrant précisément l'intérêt de la programmation visuelle pour auditer et corriger le code généré.
Il simplifie également le formulaire d'ajout de lien : l'IA avait exposé tous les champs de la table (titre, description, images) alors que seule l'URL est nécessaire à la saisie, le reste devant être rempli automatiquement par le scraping.
La partie backend se poursuit dans Xano en direct : Benoît crée une fonction dédiée "scrap_link", intègre un appel à Firecrawl via curl importé depuis la documentation, gère les variables d'environnement pour les clés API. Il rencontre un problème avec le bearer token OpenAI lié à une expression Xano mal formée, qu'il résout en passant à une configuration manuelle classique. Il construit ensuite le prompt pour OpenAI (résumé en 300 caractères + liste d'URLs d'images), récupère la réponse, la décode en JSON et met à jour l'enregistrement en base.
De retour sur HelloLeo, Benoît demande l'affichage des images disponibles avec un effet de survol agrandi. Le résultat n'est pas parfait mais itérable. Il ajoute ensuite la sélection d'une image au clic, qui déclenche un PUT vers Xano pour mettre à jour le champ "selected image". La session se conclut sur un produit fonctionnel de bout en bout (ajout de lien, scraping automatique, résumé IA, sélection d'image), avec une démo rapide d'Ecolux construit selon la même approche.
Ce qu'on a appris
- Architecture et choix de stack**
- Xano offre une inspection visuelle du backend que Supabase ne permet pas aux profils non-développeurs : les fonctions, les RLS et les edge functions de Supabase restent opaques dès qu'on doit les corriger manuellement, ce qui est un vrai frein en vibe coding.
- Choisir ses services tiers avant de commencer est non-négociable. L'IA choisira toujours le premier outil qu'elle connaît, sans le tester sur le cas d'usage réel. Résultat classique : des fonctions mortes qui s'accumulent dans la codebase.
- Tester les services de scraping en amont est particulièrement critique. Scraper LinkedIn est un cas limite que la majorité des outils ne gèrent pas. Firecrawl est actuellement le plus fiable pour ce type de besoin.
- Séparer backend et frontend dans le vibe coding est une stratégie efficace : Benoît maîtrise et valide son backend visuellement dans Xano, et délègue uniquement la génération frontend à HelloLeo. Cela réduit la surface d'erreur non détectable.
- Qualité et limites de la génération IA**
- Les LLM ont tendance à surcharger les formulaires avec tous les champs disponibles en base de données, même quand l'UX devrait n'en exposer qu'un seul. Il faut anticiper ce comportement et cadrer le prompt ou corriger après coup.
- XanoScript est trop récent pour être fiable en génération automatisée, y compris via le Logic Assistant natif de Xano. Le modèle manque encore de données d'entraînement sur ce langage. Il vaut mieux rester en mode visuel pour tout ce qui est édition backend, et ne pas s'attendre à ce que l'IA génère du XanoScript robuste à court terme.
- L'IA peut générer des requêtes fonctionnellement correctes mais architecturalement mauvaises (récupérer tous les records et filtrer en mémoire plutôt qu'en base). Sans lecture du code généré, ces problèmes passent inaperçus et deviennent des bombes à retardement en production.
- Les appels API externes (OpenAI, Firecrawl) nécessitent une vérification manuelle de la configuration : authentification, paramètres obligatoires vs optionnels, format attendu. L'IA copie souvent tous les paramètres d'un exemple curl sans distinguer ce qui est requis.
- Gestion de la sécurité**
- Ne pas déléguer la cybersécurité à l'IA. Loveable gère les RLS Supabase de façon binaire : soit tout ouvert (ça marche, mais c'est un risque), soit il configure des règles qu'il oublie de mettre à jour lors des nouvelles features. Dans les deux cas, le résultat est fragile.
- Les clés API apparaissent facilement à l'écran en live. Prendre l'habitude de révoquer immédiatement toute clé exposée dans un stream ou une démo.
- Xano permet d'auditer visuellement ce que l'IA a fait sur la sécurité (authentification des routes, filtrage par user ID, etc.), ce qui est beaucoup plus rassurant qu'un code généré dans une black box.
- Méthodologie de vibe coding**
- Le proto jetable reste une bonne pratique. Benoît fait une première version rapide pour explorer l'interface, la met à la poubelle une fois qu'il sait ce qu'il veut, puis repart proprement. C'est un coût assumé et productif, pas un échec.
- Cadrer le format de sortie de l'IA (JSON, markdown, structure d'objet) directement dans le prompt évite les post-traitements coûteux et les erreurs de parsing. OpenAI en particulier a tendance à envelopper ses réponses JSON dans des blocs markdown si on ne l'en empêche pas explicitement.
- La console développeur reste l'outil de debug de base en vibe coding, quel que soit l'outil utilisé. Copier une erreur console et la donner à l'IA est souvent plus efficace que d'essayer de lire les logs de l'outil lui-même.
- Éviter de se laisser embarquer par l'IA sur des directions qu'on n'a pas choisies. Benoît a eu un exemple concret où l'IA a ajouté un formulaire complet alors qu'il voulait un champ unique. Il faut savoir reprendre la main.
- Modèle économique et positionnement des outils**
- Le modèle "outil de vibe coding + support humain développeur" est probablement l'approche la plus réaliste pour des projets professionnels aujourd'hui. HelloLeo propose ce packagé nativement, ce qui change la proposition de valeur par rapport à Loveable ou Cursor seuls.
- Combiner plusieurs outils de vibe coding sur un même repo Git est techniquement possible mais déconseillé : chaque outil a ses propres conventions et fichiers manquants chez les autres.
- Pour les profils no-code qui veulent monter en puissance, Xano est une meilleure rampe d'accès que Supabase : la programmation visuelle du backend reste lisible même quand c'est l'IA qui l'a écrit, ce qui permet de corriger sans être développeur.
- Les fonctions dans Xano (réutilisables par plusieurs APIs) sont un pattern à adopter dès le départ pour les opérations communes comme les appels LLM. Ça évite de dupliquer les configurations et facilite la maintenance.