« 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é.
« J'avais écrit trente pages d'écrans et de boutons. Le développeur m'a posé une seule question : à quel problème ça répond, pour qui ? Je n'avais pas la réponse, et c'était ça, le vrai cahier des charges. »
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.
Le problème et la phrase nord
Une à deux phrases : quel problème, pour qui, et pourquoi ça compte. C'est la boussole de toutes les décisions qui suivront. Si une fonctionnalité ne sert pas cette phrase, elle attendra. Ce bloc, écrit noir sur blanc, vaut mieux que dix pages de spécifications qui partent dans tous les sens.
Les profils d'utilisateurs
Qui se sert du produit, et dans quel contexte. Un client qui réserve, un gérant qui suit son activité, un administrateur qui modère. Chaque profil n'a pas les mêmes besoins ni les mêmes droits : les nommer évite de construire un produit moyen pour tout le monde et juste pour personne.
Les parcours clés
Le coeur du document. Pour chaque profil, la séquence d'étapes qui mène à la valeur : « je m'inscris, je crée mon profil, je publie ma première annonce, je reçois une demande, j'y réponds ». Du début à la fin, en langage humain. C'est ça qui se construit, pas une liste de boutons.
Les règles métier
Ce que votre domaine impose et qu'un développeur ne peut pas deviner : un devis n'est modifiable qu'avant signature, un utilisateur gratuit est limité à trois projets, une commande passe par une validation manuelle. Ce sont vos contraintes, pas les siennes : à vous de les énoncer.
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.
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.
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.
Envie d'en discuter ?
Réservez un créneau de 30 minutes pour un premier échange. Je vous aiderai à y voir plus clair sur votre situation.
Prendre rendez-vous