Au chapitre précédent, nous avons confirmé que le dev indépendant avance en 5 phases — « décider → préparer → construire → publier → faire grandir » — et que la règle d'or est de « se limiter à une fonction et publier un MVP ». Ce chapitre 2 traite la première phase, « décider ». Avançons ensemble jusqu'à décider en petit quoi créer et pour qui, puis à le mettre en forme de cahier des charges (spec).
Solidifier « ce que vous voulez créer » jusqu'à pouvoir le remettre à l'IA
Pourquoi « décider » d'abord
On comprend bien l'envie de se mettre vite à coder. Mais l'échec le plus fréquent en dev indépendant, c'est de « ne plus savoir ce qu'on est en train de créer pendant qu'on le crée ». Si vous vous lancez avec un objectif flou, la direction dérive en cours de route — « tiens, ajoutons aussi cette fonction » — et rien ne se termine jamais.
C'est pourquoi le code peut attendre. Clarifiez d'abord « quoi, pour qui, et jusqu'où créer ». Sans carte ni destination, se perdre est normal ; à l'inverse, dès que la destination est fixée, l'IA, votre partenaire, vous guide par la route la plus courte.
Les fonctions s'accumulent, tout se complexifie. Les instructions à l'IA dérivent à chaque fois. La fin s'éloigne, la motivation s'épuise, le projet est abandonné.
L'objectif se fixe sur une seule cible. On donne à l'IA des instructions justes, et sa sortie ne dérive pas. On atteint « une chose qui marche » au plus court.
💡 « Décider » n'est pas un temps de rumination. Pas besoin de dossier de projet parfait. Ce que fait ce chapitre, c'est une petite décision qui tient sur une feuille A4 (ou un écran de notes). Plutôt que de rester bloqué à hésiter, décidez, même provisoirement, et avancez : vous atteindrez l'objectif bien plus vite.
Trouver une idée — brainstormer avec l'IA
« Je n'ai rien de précis à créer » — pas de souci. Une idée ne se tire pas du néant : elle se ramasse dans les gênes du quotidien. Et ce travail d'exploration est justement ce que l'IA fait le mieux. Inutile de vous creuser la tête tout seul. Faites de l'IA votre partenaire de brainstorming, et les idées jailliront.
Ce qui vous pèse un peu chaque jour. Les tâches manuelles répétitives, le temps passé à noter, à chercher. Ce qui vous gêne gêne aussi quelqu'un d'autre.
Ce que vous vous êtes dit « si une telle appli existait, je l'utiliserais ». Le premier utilisateur, c'est vous. Ce que vous désirez vraiment entretient la motivation de créer.
Lancez à l'IA un intérêt vague, et faites-vous poser des questions en retour. Les contours se dessinent au fil de l'échange. L'interlocuteur idéal pour penser à voix haute.
Le secret du brainstorming : lancer des sujets concrets. « T'aurais pas une bonne idée d'appli ? » ne donne pas de bonne réponse. Posez plutôt la question en resserrant l'angle, comme ci-dessous.
- « Donne-moi 10 idées d'appli qui résolvent la corvée de la gestion du budget, une phrase chacune. »
- « Parmi elles, laquelle est la plus petite à construire ? Explique pourquoi. »
- « Cette idée, y a-t-il vraiment des gens qui l'utiliseraient ? Donne l'utilisateur visé et le contexte d'usage. »
- « Existe-t-il déjà des services similaires ? Si oui, où est l'écart qu'un particulier peut viser ? »
- « Si on réduit cette idée à une seule fonction, laquelle faut-il garder ? »
Faire sortir 10 idées et en choisir une : cette démarche est efficace. L'IA aligne une masse de candidats en un instant, donc votre travail se concentre sur « choisir ». Dès qu'une idée vous accroche, approfondissez-la.
Se limiter à une fonction — la règle d'or
Une fois l'idée dégagée, l'important est de « ne pas en rajouter ». Vous souvenez-vous de la règle d'or du chapitre précédent ? Se limiter à une fonction et publier un MVP — c'est la règle la plus souvent enfreinte, et la plus essentielle à respecter, en dev indépendant.
À l'instant où l'on se dit « tant qu'à créer, ajoutons cette fonction et celle-ci », la fin s'éloigne. Avec deux fonctions, le travail n'est pas doublé mais triplé ou quadruplé, à cause des combinaisons. Le temps et l'énergie d'une personne seule sont limités. Au début, resserrez sur une seule chose : « si ça marche, ça a de la valeur ».
Enregistrer les livres, noter ses impressions, mettre des étoiles, un graphe du temps de lecture, partager avec des amis, des recommandations IA, scanner les codes-barres… On vise le tout-en-un, et rien ne se termine jamais.
Juste « enregistrer un livre lu avec une impression d'une ligne ». Pouvoir le relire dans une liste suffit. On publie d'abord, et on ajoute la suite si c'est utilisé.
✅ Le critère pour élaguer : « est-ce que ça tient sans ça ? » Une fonction qui vous fait hésiter, mettez-la d'abord dans la boîte « plus tard ». Ne la jetez pas : ajoutez-la après la publication si elle est vraiment nécessaire. Quand votre première fonction tourne et est utilisée, c'est la réaction des utilisateurs qui vous dira quoi ajouter ensuite.
Formuler l'idée en une ligne
La fonction unique retenue, transformez-la en une ligne de texte. C'est le cœur de ce chapitre. En coulant l'image floue de votre tête dans le moule « pour qui, quelle gêne, résolue comment », l'idée se concrétise d'un coup.
« Une appli pour les gros lecteurs, qui résout la gêne de vite oublier les livres qu'on a lus, en permettant de les noter rapidement avec une impression d'une ligne et de les revoir dans une liste. »
Si vous savez écrire cette ligne, votre dev indépendant est à moitié réussi. Tout ce qui suit — choix des technos, instructions à l'IA, texte de présentation à la publication — aura cette ligne pour axe qui ne dérive pas. Si vous n'y arrivez pas, là encore faites-vous aider par l'IA. Demandez « Formule cette fonction en une ligne : pour qui, quelle gêne, résolue comment », et elle vous proposera plusieurs versions.
La transformer en cahier des charges — la base du dev avec l'IA
Une fois la ligne solidifiée, dernière étape : en faire un cahier des charges (spec). Le cahier des charges, c'est « la note de conception de ce qu'on va créer ». Sans vous compliquer la vie, il suffit de noter au minimum trois points : écrans, données, actions.
Pourquoi le cahier des charges est-il important ? Parce qu'en codage avec l'IA, le cahier des charges devient directement la base. Plutôt que de balancer « crée une appli comme ça », remettre un cahier des charges décrivant écrans, données et actions fait renvoyer à l'IA un code bien plus juste. La démarche poussée à son terme, c'est le développement piloté par le cahier des charges (Spec-Driven Development), et le même principe vaut en dev indépendant.
Quels écrans faut-il ?
Ex. : liste des enregistrements, ajout d'un enregistrement. 2 à 3 écrans suffisent la plupart du temps.
Quoi enregistrer ?
Ex. : titre du livre, impression, date. Il suffit de lister les champs.
Que peut faire l'utilisateur ?
Ex. : ajouter un enregistrement, le voir dans une liste. Alignez les actions par des verbes.
Ces trois éléments notés forment votre tout premier cahier des charges. Pour une appli de suivi de lecture, par exemple, cela donne la note suivante.
Données : titre du livre (texte) / impression (texte d'une ligne) / date (date)
Actions : ajouter un enregistrement, voir la liste du plus récent au plus ancien, supprimer un enregistrement
💡 Le cahier des charges n'a pas besoin d'être parfait. Pas besoin de tout écrire dès le départ. Si en créant vous vous dites « ah, il faut ça aussi », ajoutez-le. L'important est de « avoir d'abord une feuille de base ». Partir d'une ébauche fait avancer l'IA comme l'humain bien plus vite que partir d'une page blanche.
La marche à suivre pour chaque route
Jusqu'ici, le travail de « décider » est le même sur les deux routes. La seule différence : jusqu'à quel point formaliser le cahier des charges, et à qui le remettre. Avancez selon votre route.
Le cahier des charges peut être écrit à la main dans un carnet ou un bloc-notes. Pas besoin d'un document soigné. Une fois « écrans, données, actions » listés, collez-les tels quels dans un chat IA pour brainstormer. Demandez « ce cahier des charges a-t-il des oublis ou des contradictions ? » et l'IA comblera les trous.
Objectif de ce chapitre : avoir la ligne unique et la note en 3 points suffit.
Rassemblez le cahier des charges dans un fichier Markdown (ex. : spec.md) et remettez-le à Claude Code ou Cursor. L'éditeur IA lit le cahier des charges pour en faire la base de l'implémentation : plus il est soigné, plus la suite est rapide. Pour la rédaction, le développement piloté par le cahier des charges est une bonne référence.
Objectif de ce chapitre : avoir un spec.md prêt à remettre à l'éditeur IA suffit.
Sur les deux routes, terminer ce chapitre avec « la formulation en une ligne » et « le cahier des charges minimal écrans/données/actions » en main — voilà l'objectif. Une fois là, il ne reste qu'à préparer les fondations pour construire. Vous voilà prêt à passer à la phase suivante.
Résumé et chapitre suivant
- Le code peut attendre. D'abord décider « quoi, et pour qui créer » pour ne pas se perdre.
- Les idées viennent des gênes du quotidien, de ce que vous voulez. Brainstormez avec l'IA : sortez-en 10, choisissez-en 1.
- La règle d'or du dev indépendant : « se limiter à une fonction ». Les fonctions hésitantes vont dans la boîte « plus tard ».
- Formulez l'idée en une ligne : « pour qui, quelle gêne, résolue comment ».
- Le cahier des charges tient en 3 points minimaux : écrans, données, actions. En codage avec l'IA, il sert de base.
- La route débutant avance avec un carnet et un chat IA, la route pratique avec un spec.md en Markdown.
La phase « décider » s'arrête là. Si l'idée tient en une ligne et que le cahier des charges minimal est en main, vous êtes à un pas de commencer à créer. Ensuite vient la phase où l'on décide avec quelles technos et outils le construire réellement. Vous pouvez revenir au chapitre 1, « Vue d'ensemble et choix de la route » pour revoir la carte, ou passer directement au chapitre 3, « Préparer ses technos et ses outils ». La construction des fondations qui donneront forme à votre ligne commence.