« Il me faut un cahier des charges, mais je ne suis pas technique. » Beaucoup de fondateurs croient qu'il faut décrire des écrans, des bases de données, des choix de techno. C'est l'inverse. Votre rôle n'est pas de dire comment construire, c'est de dire ce que le produit doit permettre, et pour qui. Le reste, c'est le métier de celui qui code.
Un cahier des charges d'application sans être technique, c'est un document qui décrit l'intention du produit et les parcours utilisateurs (le quoi), pas l'implémentation (le comment). Vous y posez le problème résolu, les profils d'utilisateurs, les parcours clés étape par étape et les règles métier. Vous laissez au prestataire les écrans, l'architecture et la techno.
Si vous cherchez d'abord à cadrer le périmètre de votre premier produit, le cadre d'ensemble est dans le guide du MVP au PMF. Ici, on regarde le document que vous, fondateur, devez produire pour qu'on construise la bonne chose.
Décrire le quoi, jamais le comment
La frontière est simple à tenir une fois qu'on l'a vue. Tout ce qui décrit l'expérience visée et la valeur attendue vous appartient. Tout ce qui décrit la fabrication appartient à celui qui code. Confondre les deux est la première cause de cahiers des charges qui se périment avant même le premier écran livré.
Quand vous écrivez « un bouton bleu en haut à droite qui ouvre une fenêtre », vous avez déjà tranché une dizaine de décisions de conception sans le savoir, souvent mal, et vous avez verrouillé une solution avant d'avoir énoncé le problème. Écrivez plutôt « l'utilisateur doit pouvoir lancer une nouvelle commande à tout moment ». Le prestataire trouvera la meilleure forme, c'est son métier, et il la trouvera mieux que vous.
Les quatre blocs qui suffisent
Un bon cahier des charges de fondateur tient en quatre blocs. Aucun n'exige de compétence technique. Tous exigent que vous sachiez précisément ce que votre produit doit faire vivre à ses utilisateurs.
Remarquez ce qui n'y figure pas : aucune base de données, aucun langage, aucune maquette d'écran, aucun choix d'hébergement. Tout cela découle des quatre blocs et relève du prestataire. Votre travail s'arrête là où commence le sien, et c'est précisément ce qui rend le document robuste.
Écrire un parcours utilisateur, concrètement
Le parcours est la pièce que les fondateurs ratent le plus, parce qu'ils sautent à l'écran au lieu de raconter l'histoire. Un bon parcours se lit comme un récit à la première personne, étape après étape, sans jamais nommer un composant d'interface.
| À éviter (le comment) | À écrire (le quoi) |
|---|---|
| « Un formulaire avec champs email et mot de passe » | « Le client crée un compte pour retrouver ses commandes » |
| « Une modale de confirmation avec deux boutons » | « Le gérant valide la commande avant qu'elle parte » |
| « Un tableau filtrable avec colonnes triables » | « Le gérant retrouve vite une commande passée » |
| « Une API REST qui renvoie un JSON » | « Les données du client se synchronisent sur ses appareils » |
La colonne de droite décrit une intention que n'importe qui comprend, fondateur, développeur, designer, et qui laisse ouvertes toutes les bonnes solutions. La colonne de gauche fige une solution, souvent au moment où vous en savez le moins. Écrivez l'intention : la forme suivra, mieux pensée que vous ne l'auriez fait.
Le test du « pourquoi » à chaque ligne
Relisez chaque phrase de votre cahier des charges et demandez « pourquoi ». Si la réponse parle de l'utilisateur et de
sa valeur, gardez. Si la réponse est « parce que je l'imagine comme ça », vous décrivez une solution, pas un besoin :
reformulez en intention. Ce seul filtre transforme un document technique mal ficelé en un vrai cahier des charges de
fondateur.
Le format que je fais signer en cadrage
Quand je cadre un produit avec un fondateur, le livrable de cette phase n'est pas un document technique. C'est un document de périmètre : la phrase nord, les profils, cinq à huit parcours racontés, et la liste des règles métier. On le relit ensemble, on le coupe pour ne garder que ce qui sert la première version, et on le signe. À partir de là, chacun sait ce qu'on construit et, surtout, ce qu'on ne construit pas encore.
Ce document devient le contrat tacite entre vous et celui qui code. Quand une demande nouvelle arrive, on la confronte au document : sert-elle un parcours validé, ou est-ce un ajout qui repousse la livraison ? C'est ce cadre partagé, pas une liste d'écrans, qui tient un projet dans son budget et son délai. Si le vôtre a déjà dérivé, les leviers pour le reprendre sont dans MVP qui coûte trop cher.
On écrit votre périmètre ensemble ?
J'interviens comme CTO fractional armé d'IA pour traduire votre intention en un périmètre clair, puis le construire.
Découvrez le Sprint Fondateur, ou réservons 30
minutes pour poser ensemble le cahier des charges de votre app, sans
jargon.
Top comments (0)