Vibe coding : une révolution dans le développement d'applications ?

L'ère du développement agile et accessible

Deux enseignements majeurs émergent de cette session Open Research : premièrement, la barrière d'entrée pour créer des applications est en chute libre grâce aux outils de "vibe coding". Deuxièmement, nous assistons à l'émergence d'une nouvelle approche du développement, plus proche du "jam" musical que de la programmation traditionnelle.

Comme le souligne Timo : "c'est dingue à quel point ça s'améliore, dans le sens où les interfaces de création d'applications s'améliorent, les LLM eux-mêmes [...] C'est dingue à quel point c'est encore plus puissant que les LLM qu'on avait il y a 6 mois, rien que ça déjà. Donc c'est assez fou à quel point la technique ça avance vite et je pense que c'est un problème de plus en plus résolu."

L'expérimentation d’Ulrich avec quatre outils différents (Bolt, Create, Lovable et Replicate) a permis de comparer leurs forces et faiblesses. Bolt et Lovable se sont distingués par leur intégration native avec SupaBase, permettant une gestion efficace des données. Cependant, les limitations de la version gratuite de SupaBase et les coûts potentiels par projet soulèvent des questions de viabilité économique. La possibilité de self-hosting apparaît comme une solution prometteuse.

L'expérience a mis en lumière l'importance d'une approche progressive et structurée dans le développement. Commencer par une vue simple et bien définir les étapes du projet s'avère crucial. Bien que le Vibe Coding permette de générer rapidement des interfaces utilisables, la pérennité d'une application nécessite une compréhension fondamentale des principes de développement. La prochaine étape consistera à explorer l'implémentation d'un middleware, possiblement via N8N ou un worker Cloudflare, pour permettre l'interaction entre Notion / Airtable et le front.

Les défis du développement moderne

Les participants ont exploré plusieurs problématiques concrètes :

• La connexion entre les interfaces frontales et les bases de données (notamment Notion et Supabase)
• La gestion des problèmes de sécurité (CORS), comme l'explique Ulrich : "J'ai passé quelques heures à forcer au pied de biche les différents outils d'essayer de résoudre ces problèmes de CORS - sans succès"
• La création d'interfaces utilisateur intuitives pour le traitement de données, avec notamment un exemple concret partagé par Timo d'une interface de traitement de mémos vocaux

On le voit, tout n’est pas parfait, sans assez de connaissance des mécanismes et des principes informatiques on se perd dans des problèmes que ces outils ne sont pas à même de véritablement résoudre.

Mais… il y a un MCP et un outil pour ça:

Let your AI tool create & run tests from anywhere

Build fast with AI and test just as effortlessly. Octomind turns natural language prompts from your AI powered interface to end-to-end tests, runs them, analyzes failures, and auto-fixes issues - so your code doesn’t just vibe, it thrives.

www.octomind.dev

Une exploration pratique des outils

Les participants ont testé plusieurs outils de "vibe coding", chacun avec ses particularités :

• Bolt : Considéré comme le plus "sympathique" avec un déploiement rapide via Netlify. Comme le note Ulrich : "celui que je considère comme étant le plus sympathique et celui qui m'a donné le plus de satisfaction c'est Bolt"
• Create : Apprécié pour ses capacités de design type Figma, permettant de "fine-tuner pas mal l'interface en mode Figma-like"
• Lovable : Offrant une bonne intégration avec GitHub et Supabase, permettant une gestion efficace du code
• Cursor : Plus technique, orienté développeur, offrant selon Timo l'avantage d'avoir "accès au tout dernier modèle donc j'utilise essentiellement Claude 3.7 et puis Gemini 2.5, le tout nouveau qui vient de sortir"

Les enseignements clés

Plusieurs leçons importantes ont émergé de cette session, enrichies par des expériences concrètes :

• La démocratisation du développement : Timo souligne que "ça réduit drastiquement la barrière d'entrée dans la création d'interfaces, d'applications, de systèmes, d'outils"
• L'importance de la conception avant le code : Comme l'explique Ulrich : "c'est hyper important d'avoir d'avoir ton cahier de charge pour pour la création de ton application."
• La possibilité de créer des applications "one-shot" : Timo développe cette idée : "tu peux en fait juste te focaliser sur un aboutissement qui peut être du one shot ou du récurrent ou même du personnel [...] Ça peut valoir la peine de créer une application custom-made pour ça"

Défis et opportunités

Cette révolution apporte son lot de défis et d'opportunités :

Défis

• La nécessité d'une progression graduelle : Ulrich met en garde : "avant de pouvoir vibe coder, je pense qu'il faut que les gens aillent faire leur devoir à domicile [...] s'ils passent d'Excel à du vibe coding, je pense qu'ils vont s'arracher une jambe"
• La gestion des aspects techniques : Comme l'explique Ulrich : "tous les chemins convergent vers le fait de devoir faire un outil intermédiaire" concernant la connexion avec des bases existantes et les enjeux de sécurité.

Opportunités

• La possibilité de prototyper rapidement : Ulrich évoque la possibilité de "faire un prototype pour imaginer ensemble, avec le client ou l’utilisateur, les fonctionnalités à tester"
• La démocratisation de l'innovation : Timo suggère que "plutôt que d'engager, de créer un pôle d'innovation [...] maintenant tu prends une heure par semaine, tu crées des applications qui sont utiles pour toi"
• L'analogie musicale : Comme le dit Ulrich : "un peu comme un groupe de musique en fait. On joue, on jam, et puis à un moment donné, on a quelques petites mélodies et hop, on fait un morceau"

Les prochaines étapes

Les participants ont identifié plusieurs pistes concrètes pour la suite :

• Explorer la modularisation des workers sur Cloudflare pour faciliter les connexions avec les bases de données, une solution que Ulrich considère comme prometteuse
• Approfondir l'intégration entre les différents outils de "vibe coding" et les bases de données existantes
• Développer des prototypes avec les utilisateurs finaux, comme le suggère Ulrich : "avec le client à côté, d'une certaine manière, on pourrait faire un prototype [...] pour imaginer ensemble les fonctionnalités à tester"

Comme le résume Timo : "il y a moins les contraintes, on va dire, les contraintes, plutôt les enjeux, on va dire, de ressources et de pérennité et de mise à échelle, dans le sens qu'on peut du coup potentiellement se permettre en fait de créer une application one shot".