Shubham nous montre ses meilleures techniques
Session méthodologique où Shubham Sharma démontre l'importance cruciale de la préparation avant le vibe coding, en prenant l'exemple concret d'un SaaS de paiement automatisé de factures de prestataires.
À propos de cette session
Alexis reçoit Shubham pour une session de vibe coding collaborative où le chat décidera du projet. Shubham choisit délibérément de ne pas préparer pour montrer sa méthode en situation réelle.
Shubham introduit immédiatement sa philosophie : le vibe coding ressemble au pilotage de Formule 1 - pas besoin d'être mécanicien mais il faut comprendre les virages et savoir quand accélérer. Il critique l'approche "solution first" qui domine aujourd'hui.
Il présente sa méthodologie en 5 étapes sur iPad avec analogie de la trajectoire d'avion : un petit décalage initial mène à des destinations complètement différentes.
Étape 1-2 : Définition du problème Shubham part d'un problème personnel : trop de friction pour payer ses prestataires. Il décompose méthodiquement : emails perdus, copier-coller d'IBAN pénible, double authentification bancaire, relances stressantes pour les prestataires. Il insiste sur l'aspect humain du problème : la culpabilité mutuelle créée par les retards de paiement.
Étape 3-4 : Décomposition et critères de succès Il liste granulairement chaque sous-problème identifié puis définit son critère de succès en une phrase : "payer en un clic". Cette simplicité contraste avec la complexité du problème initial.
Étape 5 : Catalogue de solutions Brainstorming des approches possibles : interface d'upload, notifications, paiement un clic, statistiques par prestataire. Il croise sa réflexion avec ChatGPT pour validation mais garde la main sur l'analyse.
Démonstration Lovable : Pour illustrer les limites du "prompt direct", Shubham lance rapidement Lovable avec un prompt généraliste. Le résultat est esthétiquement correct mais fonctionnellement creux - il obtient une interface avec des IBAN visibles sans logique métier derrière.
Architecture technique Transition vers Claude Opus pour spécifications techniques. Shubham explique l'importance de choisir les bonnes APIs avant de coder. Il explore Bridge API, Stripe, et finalement retient Conto API après vérification de la documentation officielle.
Claude propose une architecture Next.js/Supabase classique mais Shubham la challenge pour simplifier. Il privilégie SQLite pour un MVP plutôt qu'une stack complexe.
Réflexions sur l'ordonnancement du développement Point crucial souvent négligé : Shubham critique l'approche standard qui développe tout en parallèle sans possibilité de test incrémental. Il prône une approche "en escalier" : UI d'abord pour valider les concepts, puis base de données, puis fonctionnalités, avec test à chaque étape.
La session se termine sur les fondamentaux de l'architecture (frontend/backend/API/BDD) et l'importance de la documentation centralisée dans un fichier claude.md comme boussole projet.
Points clés
- ### Méthodologie et préparation
- La phase de réflexion pré-coding est plus importante que les outils utilisés
- Bien décomposer le problème, c'est être proche de la solution
- Les 5 étapes (problème vague → problème précis → sous-problèmes → critères de succès → catalogue solutions) sont non-négociables
- L'analogie de la trajectoire d'avion : corriger tard coûte exponentiellement plus cher
- La réflexion manuelle sur papier reste irremplaçable pour la compréhension profonde
- ### Limitations des outils découvertes
- Lovable produit du "joli mais inutile" sans spécifications précises
- Les LLM excellent en technique mais échouent sur l'expérience utilisateur réelle
- ChatGPT-5 moins fiable que GPT-4 pour respecter les instructions système
- Les prompts directs sans contexte génèrent des solutions génériques sans valeur
- ### Problèmes récurrents du vibe coding
- Saut immédiat vers la solution sans comprendre le problème réel
- Multiplier les essais LLM plutôt que d'améliorer les spécifications
- Délégation totale de la réflexion aux LLM au lieu de les utiliser comme validation
- Architecture technique ignorée jusqu'à ce que tout explose
- Ordonnancement chaotique du développement empêchant les tests incrémentaux
- ### Bonnes pratiques architecture
- Séparer clairement frontend/backend/API/base de données
- Les API externes doivent vivre dans le backend, jamais dans le frontend
- Choisir la stack technique après avoir défini les besoins, pas avant
- Valider la faisabilité des intégrations (APIs bancaires) avant l'architecture
- Préférer la simplicité fonctionnelle à la sophistication technique pour un MVP
- ### Stratégies de développement
- Développement "en escalier" : chaque étape doit être testable individuellement
- Commencer par l'UI pour valider les concepts utilisateur
- Ajouter les fonctionnalités une par une avec test à chaque itération
- Éviter les développements en parallèle qui empêchent le debugging
- Garder un fichier claude.md central comme documentation vivante du projet
- ### Collaboration avec l'IA
- Utiliser les LLM pour challenger sa réflexion, pas la remplacer
- Croiser plusieurs LLM pour éviter les biais d'un seul modèle
- Demander aux LLM de générer des prompts de recherche plutôt que des réponses directes
- L'expertise humaine reste cruciale au début de la trajectoire projet
- Les LLM excellent quand le contexte et les contraintes sont bien définis
- ### Sécurité et robustesse
- Les clés API ne doivent jamais être exposées côté client
- L'authentification bancaire requiert une validation préalable des bénéficiaires
- Les solutions "no-code pures" atteignent vite leurs limites sur des besoins métier spécifiques
- La documentation officielle des APIs prime sur les suggestions des LLM
- ### Réalités économiques
- Un SaaS viable nécessite une architecture robuste dès le départ
- Refactoriser après coup coûte exponentiellement plus cher
- La friction utilisateur peut être plus coûteuse que les frais techniques
- L'expérience développeur (debugging, maintenance) compte autant que l'expérience utilisateur