J'ai abandonné mon app iOS. Puis je l'ai reconstruite de zéro avec une vraie méthode.

Le constat qui fait mal

Quelques mois plus tôt, j'avais lancé Caffio, une application pour suivre sa consommation de café et explorer des recettes. Construite en une semaine, portée par l'enthousiasme autour du framework FoundationModels annoncé à la WWDC 2025. De l'IA locale, directement sur iPhone, sans connexion au cloud. Techniquement passionnant.

Sauf que je ne l'utilisais plus. Non pas à cause de bugs, mais parce qu'elle ne résolvait aucun problème réel. En scrollant mes propres captures d'écran, la réalité s'est imposée : j'avais créé une démo technique maquillée en produit.

Ce type de prise de conscience pique, mais c'est aussi le meilleur point de départ. J'ai donc tout repris à zéro, cette fois avec une méthodologie rigoureuse. Voici les 8 étapes de ce processus, documenté en temps réel.

Étape 1 : Prendre du recul sincèrement

Avant de toucher la moindre ligne de code, je me suis imposé trois questions fondamentales.

Qu'est-ce que l'app fait d'unique ? Non pas "elle permet de noter des cafés" (n'importe quelle app de notes le fait), mais qu'est-ce qu'elle apporte que rien d'autre ne propose exactement de cette manière ?

Est-ce que je l'utiliserais encore dans six mois ? Pas dans l'euphorie de la création ni pour impressionner des proches, mais dans ma routine quotidienne, six mois plus tard ?

C'est une application ou simplement une fonctionnalité ? Parfois, ce que l'on construit mériterait d'exister au sein de quelque chose de plus large plutôt que seul sur l'App Store.

Les réponses étaient limpides. La première : floue. La deuxième : non. La troisième : incertaine. Le signal était clair : repartir du problème, pas de la solution.

Étape 2 : Cibler un public précis

L'erreur typique du développeur qui construit pour lui-même, c'est de croire que sa cible, c'est "les amateurs de café". Autrement dit tout le monde, c'est-à-dire personne.

J'ai identifié quatre profils potentiels : le barista pro, la personne soucieuse de sa consommation de caféine pour des raisons de santé, le passionné qui veut un journal de dégustation, et le curieux qui explore des recettes. Quatre comportements radicalement différents qui appellent quatre applications distinctes.

Choisir sa cible implique d'accepter de ne pas plaire à tout le monde. C'est inconfortable, mais c'est la seule façon de vraiment servir quelqu'un au lieu de vaguement satisfaire un large public.

Étape 3 : Valider les besoins auprès de vraies personnes

L'intuition donne un point de départ. Les données donnent une direction.

J'ai mis en place un formulaire personnalisé avec Next.js et MongoDB, puis je l'ai partagé sur Instagram, Reddit et LinkedIn. L'objectif n'était pas d'obtenir des milliers de réponses mais des réponses de qualité.

16 personnes ont répondu. Ce n'est pas un échantillon statistiquement significatif, certes. Mais 16 personnes qui décrivent avec précision leurs frustrations liées à leur routine café, c'est infiniment plus utile que 1000 clics sur un formulaire bâclé.

Le constat principal : les gens oublient ce qui a bien fonctionné. Ils prennent des notes sur papier, en mémo vocal, dans leur tête... et ne les retrouvent quasiment jamais au bon moment.

Le vrai problème n'était pas "je veux une app café" mais "je reproduis les mêmes erreurs parce que je n'ai aucun système pour retenir ce qui fonctionne".

Étape 4 : Construire un persona comme boussole

En fournissant les réponses du formulaire et ma cible idéale à Claude Code, il m'a aidée à créer Léa.

Léa, 28 ans, designer freelance, passionnée de café en autodidacte. Elle a découvert le V60 sur YouTube, investi dans un bon moulin, et explore activement. Sa frustration centrale : elle ne se souvient plus de ses ratios, de ses températures, de ce qui avait rendu un café exceptionnel un mardi matin trois semaines plus tôt.

Léa n'est pas réelle, mais elle incarne un comportement validé par les données du sondage. Avec un persona, chaque décision de design devient concrète : est-ce que Léa utiliserait cette fonctionnalité ? Plus de "est-ce une bonne idée ?" ni "est-ce faisable ?", juste : est-ce que Léa, dans sa vie de tous les jours, ouvrirait cette feature ?

Étape 5 : Prioriser les fonctionnalités avec MoSCoW

La méthode MoSCoW (Must have, Should have, Could have, Won't have) est un filtre à la fois radical et indispensable. Radical parce qu'il oblige à refuser des idées. Indispensable parce que sans lui, le backlog devient infini et le MVP ne sort jamais.

Les données du sondage parlaient d'elles-mêmes : 100% des répondants souhaitaient un suivi de caféine, 79% des statistiques, 64% des notes de dégustation, et seulement 21% une dimension sociale ou communautaire.

• Must have : suivi caféine, statistiques, notes de dégustation
• Won't have : tout ce qui est social

Pour chaque fonctionnalité retenue, un dernier filtre : est-ce que Léa l'utiliserait dans sa première semaine ? Pas dans six mois, dans les sept premiers jours. Ce critère élimine beaucoup de choses qui paraissent importantes mais ne le sont pas pour un MVP.

Étape 6 : Structurer le brief avant d'utiliser l'IA

C'est l'étape que la plupart des gens négligent quand ils travaillent avec l'IA. Ils lancent Claude et improvisent le contexte au fil de la conversation. Puis ils sont déçus par des résultats génériques.

Un modèle de langage ne peut pas deviner ce que vous savez déjà. Il travaille exclusivement avec ce que vous lui fournissez.

J'ai préparé un document structuré en cinq volets : le contexte de l'application, le persona Léa avec ses frustrations précises, les fonctionnalités priorisées par MoSCoW, les contraintes techniques (iOS 18+, SwiftUI uniquement, pas de backend pour le MVP), et surtout ce que l'on ne veut pas. Ce dernier point est sous-estimé : dire explicitement "pas d'onboarding long" ou "pas de features accessoires qui diluent le coeur de l'app" évite de nombreux allers-retours.

J'ai aussi créé un fichier CLAUDE.md à la racine du projet. C'est une convention de Claude Code : ce fichier est lu à chaque session, ce qui évite de répéter le contexte à chaque reprise du travail.

Étape 7 : Itérer avec Claude Code

Beaucoup utilisent l'IA comme un simple générateur de code. On décrit ce qu'on veut, on copie-colle, on espère que ça compile. Ce n'est pas la bonne approche.

Mon workflow s'est organisé en trois phases.

Les fondations d'abord : demander à Claude de bâtir le squelette de l'app (architecture, navigation, modèles de données) sans aucune fonctionnalité réelle. L'objectif est d'obtenir quelque chose qui compile et qui possède une structure saine avant d'ajouter de la complexité.

Feature par feature ensuite, dans l'ordre des must-haves. Pour chacune, un cycle : décrire précisément l'objectif, laisser Claude implémenter, passer en revue le code soi-même, tester sur simulateur ou appareil réel. Jamais deux fonctionnalités en parallèle.

Le ping-pong enfin : challenger l'IA. "Pourquoi ce choix d'architecture ?", "Existe-t-il une meilleure approche pour ce cas d'usage ?", "Quels cas limites n'a-t-on pas couverts ?". C'est là que la collaboration devient véritablement productive : non pas en acceptant tout ce qui sort, mais en questionnant.

Étape 8 : Le MVP fonctionnel

Au terme de ce processus, j'avais une application qui fonctionnait. Pas parfaite, pas prête pour l'App Store, mais suffisante pour valider les hypothèses : le flux de saisie d'une note de dégustation est-il naturel ? Les statistiques sont-elles lisibles ? Quelqu'un comme Léa pourrait-il utiliser ça sans mode d'emploi ?

C'est ça, un MVP. Pas la version 1.0, pas quelque chose dont on est fier à 100%. Un outil qui permet de savoir si l'on construit dans la bonne direction avant d'investir six mois supplémentaires.

La différence entre Caffio v1 et v2 ne tient pas à la qualité du code. Elle tient à la clarté de l'intention derrière chaque fonctionnalité.

Ce que j'en retiens

On entend beaucoup parler de "shipper vite" dans la culture indie dev. C'est un principe valable, mais souvent mal interprété. Shipper vite ne signifie pas coder sans réfléchir. Cela signifie réduire le délai entre une hypothèse et sa validation.

Les 8 étapes décrites ici ne ralentissent pas le développement. Elles suppriment le travail inutile. Le sondage, le persona, le brief structuré : tout cela représente quelques heures qui évitent des semaines de code sur des fonctionnalités que personne n'utilisera.

Quant à l'IA, elle est précieuse. Claude Code m'a fait gagner un temps considérable sur l'implémentation. Mais ce temps n'a de valeur que si ce que l'on implémente mérite d'être construit. Le vrai travail (comprendre le problème, choisir sa cible, prioriser), aucun modèle de langage ne peut s'en charger à votre place.

L'IA accélère l'exécution. Mais elle ne remplace pas la vision.