Comment je réfléchis un projet avec Claude avant d'écrire une ligne de code

Le syndrome du développeur pressé

La tentation est toujours la même. Tu as une idée, tu es enthousiaste, et ta première envie c'est d'ouvrir VS Code et de commencer à coder. Je l'ai fait. Plusieurs fois. Et à chaque fois, j'ai perdu du temps.

Le problème n'est pas de coder trop tôt en soi. C'est de coder sans savoir ce qu'on construit vraiment. Tu pars sur une architecture, tu construis des features, tu peaufines des détails — et trois semaines plus tard, tu réalises que tu as résolu le mauvais problème. Ou que personne ne veut ta solution. Ou que ton business model ne tient pas.

Avec Babines, j'ai vécu ça en accéléré. Le produit marchait, les clients étaient là, mais l'infrastructure de production n'avait pas été pensée pour scaler. Si j'avais passé plus de temps en amont à modéliser la chaîne complète — de la préparation à la livraison — j'aurais anticipé le mur.

Depuis, j'ai changé d'approche. Avant de toucher au code, je passe du temps à penser. Et mon outil de réflexion principal, c'est Claude.

Pourquoi Claude et pas un tableau blanc

Un tableau blanc, c'est bien. Un doc Notion, aussi. Mais ces outils sont passifs. Tu écris tes idées, tu les organises, mais personne ne te challenge. Personne ne te dit "attends, tu as pensé à ce cas de figure ?" ou "ton modèle de commission ne marche pas si le panier moyen est sous 20 €".

Claude fait ça. Pas parfaitement — il n'a pas l'expérience terrain, il ne connaît pas le marché réunionnais aussi bien que moi, et il peut se tromper. Mais il pose les bonnes questions. Et surtout, il me force à formuler mes intuitions en arguments structurés.

Quand je dis à Claude "je veux créer une plateforme de réservation pour les gîtes de Mafate", il ne répond pas juste "bonne idée". Il demande : combien de gîtes ? Quel est le parcours actuel du randonneur ? Pourquoi les gérants accepteraient une commission ? Comment tu gères le paiement dans une zone sans réseau stable ? Chaque question m'oblige à creuser.

Mon process, étape par étape

1. Le problème

Je commence toujours par ça. Pas par la solution. Par le problème. Je décris à Claude la situation actuelle — ce que les gens font aujourd'hui, ce qui ne marche pas, ce qui les frustre. Et je lui demande de challenger : est-ce un vrai problème ou un inconvénient mineur ? Combien de gens sont touchés ? Est-ce qu'ils sont prêts à payer pour une solution ?

Pour MafateRésa, la conversation a duré longtemps sur ce point. Le problème est réel : appeler 15 gérants un par un, sur un réseau instable, sans savoir s'il reste des places. Mais la question suivante était : les randonneurs sont-ils prêts à payer un surcoût (la commission) pour la commodité ? La réponse n'était pas évidente. C'est en allant sur le terrain, en parlant à des randonneurs, que j'ai validé.

2. Les personas

Qui sont mes utilisateurs ? Pas des personas fictifs avec des prénoms inventés et des hobbies fantaisistes. Des profils réels, basés sur des gens que je connais ou que j'ai interviewés.

Pour Kala, j'ai identifié deux personas clés : le propriétaire de matos (il a un kayak au garage qu'il utilise deux fois par an) et le locataire (il veut essayer le SUP sans acheter une planche à 600 €). Chacun a ses motivations, ses freins, ses attentes. Claude m'aide à les formaliser, à identifier les points de friction, et à vérifier que mon produit répond aux deux côtés.

3. Le parcours utilisateur

Une fois les personas définis, je cartographie le parcours complet. Pas seulement le "happy path" — le parcours réel, avec ses moments de doute, ses abandons potentiels, ses frustrations.

Pour un propriétaire sur Kala : il met son matos en ligne → quelqu'un réserve → il confirme → la caution est bloquée → le locataire récupère le matos → il le rend → la caution est libérée → le propriétaire est payé. Chaque étape est un point de friction potentiel. Et c'est là que Claude est utile : il m'aide à anticiper les edge cases. Que se passe-t-il si le matos est rendu en retard ? Si le locataire annule à la dernière minute ? Si le matos est endommagé ?

4. Le business model

C'est le moment de vérité. Comment tu gagnes de l'argent ? Et surtout : est-ce que les chiffres tiennent ?

Je modélise tout avec Claude. Pour MafateRésa : commission de 10 % sur les paiements CB, 7 % sur les paiements sur place. Combien de gîtes ? Combien de nuitées par an ? Quel panier moyen ? Quel taux de conversion ? On projette sur 12 mois, on identifie le point mort, on teste différents scénarios.

Ce n'est pas un business plan pour investisseurs. C'est un reality check pour moi. Est-ce que ce projet peut me payer ? À quel horizon ? Quels sont les leviers de croissance ? Quels sont les risques ?

5. Le MVP minimal

Dernière étape avant le code : qu'est-ce qu'on ne construit PAS. C'est la partie la plus dure. Parce que les idées de features sont infinies, et chacune semble indispensable.

Mon critère est simple : quelle est la plus petite version du produit qui résout le problème principal ? Pour MafateRésa, le MVP c'est : une liste de gîtes avec disponibilités, un formulaire de réservation, un paiement Stripe. Pas de carte interactive, pas d'avis, pas de messagerie. Juste le cœur de la valeur.

Claude m'aide à résister à la feature creep. Quand je dis "il faudrait aussi une messagerie intégrée pour que les randonneurs puissent poser des questions aux gérants", il me demande : "Est-ce que sans cette feature, le produit ne fonctionne pas ? Ou est-ce que c'est un nice-to-have pour la V2 ?" Neuf fois sur dix, c'est un nice-to-have.

Les pièges à éviter

Ne pas confondre réflexion et procrastination

Le risque de cette approche, c'est de ne jamais passer au code. De rester dans la phase de réflexion indéfiniment parce que c'est confortable. Ma règle : deux semaines max de réflexion structurée. Après, on code le MVP, même s'il reste des zones d'ombre.

Ne pas prendre les réponses de Claude comme parole d'évangile

Claude ne connaît pas ton marché. Il ne sait pas que les gérants de Mafate ont entre 50 et 70 ans et que leur rapport à la technologie est particulier. Il ne sait pas que la saison de randonnée à La Réunion commence en mai. Ces insights viennent du terrain, pas de l'IA.

J'utilise Claude comme sparring partner, pas comme oracle. Il m'aide à structurer ma pensée, pas à la remplacer.

Ne pas négliger la validation terrain

Aucune conversation avec Claude ne remplace une discussion avec un vrai utilisateur potentiel. Après la phase de réflexion avec l'IA, je vais sur le terrain. Je parle à des gens. Je leur décris le produit en une phrase et je regarde leur réaction. Si leurs yeux s'allument, je suis sur la bonne piste. Si je dois expliquer pendant cinq minutes pourquoi c'est utile, il y a un problème.

Un exemple concret : la genèse de Zinfluence

Pour illustrer ce process, voici comment j'ai réfléchi Zinfluence avec Claude.

Le problème initial : les entreprises réunionnaises veulent de la visibilité locale. Les influenceurs locaux ont l'audience. Mais se trouver, c'est du bricolage.

La première question de Claude : "Pourquoi les plateformes d'influence nationales ne fonctionnent pas ici ?" Réponse : parce qu'elles sont conçues pour le marché métropolitain. Les influenceurs réunionnais ont des audiences plus petites mais plus engagées. Les entreprises locales ont des budgets plus modestes. Le marché a ses propres codes.

Le modèle inversé : au lieu que les entreprises cherchent des influenceurs (le modèle classique), ce sont les créateurs qui se mettent en avant — profil, audience, tarifs, spécialités. Les entreprises parcourent les profils et lancent des collaborations. Une marketplace à la Malt, pas un outil de sourcing.

Le MVP : profils créateurs, recherche par catégorie, messagerie. Pas de paiement intégré au début — les deals se font en direct. On ajoute le paiement quand le volume le justifie.

Tout ça a été structuré avant une seule ligne de code. Et quand j'ai commencé à développer, chaque décision technique était guidée par une décision produit déjà prise.

Ce que ça change au quotidien

Depuis que j'ai adopté ce process, je ne perds plus de temps sur des features inutiles. Je ne me retrouve plus avec un produit qui ne correspond pas au besoin. Et surtout, j'ai confiance dans ce que je construis — parce que chaque choix est justifié.

L'IA n'a pas remplacé ma capacité de réflexion. Elle l'a amplifiée. C'est comme avoir un associé disponible 24h/24, qui ne se fatigue jamais de répondre à tes questions, et qui te force à être rigoureux. Le reste — l'intuition, la connaissance du terrain, le jugement — ça reste humain.

Dans le prochain article, je parlerai du moment où on passe du réfléchir au construire : lancer un produit sur une île, avec un petit marché et zéro concurrent.