« Je ne sais pas exactement ce que je veux. » Cette phrase, prononcée d'un air désolé au premier rendez-vous, est la plus normale du monde. Personne ne sait exactement ce qu'il veut au départ, et les rares qui croient le savoir changent d'avis à la première maquette. Bonne nouvelle : transformer un besoin flou en plan précis, c'est littéralement notre métier. Le vôtre, c'est de connaître votre activité. Ça tombe bien, c'est tout ce qu'on vous demandera.
En résumé : vous n'avez pas besoin d'un cahier des charges, vous avez besoin d'un problème clair. Le document de quarante pages rédigé seul dans son coin fige des hypothèses jamais vérifiées. Le cadrage fait l'inverse : des questions simples, des maquettes validées avant la première ligne de code, un périmètre écrit à la fin, un prix ferme dessus. Ensuite, livraisons par étapes et démos régulières remplacent l'effet tunnel.
Le mythe du cahier des charges parfait
On imagine souvent qu'il faut arriver avec un document de quarante pages pour être pris au sérieux. C'est l'inverse : le cahier des charges béton, rédigé seul dans son coin six mois avant le projet, est un piège. Il fige des réponses avant d'avoir posé les bonnes questions. L'espace client « indispensable » que personne n'utilisera, la fonctionnalité copiée chez un concurrent, le détail technique imposé qui coûtera trois fois son utilité : tout y est écrit avec assurance, et tout reste à vérifier. On finit par livrer scrupuleusement l'idée d'hier au lieu du besoin d'aujourd'hui.
Les projets qui déraillent ne manquent presque jamais de documentation : ils manquent de conversation.
Précisons : le périmètre écrit n'est pas l'ennemi, c'est même lui qui rend un prix ferme possible. Mais il s'écrit à la fin du cadrage, une fois les hypothèses confrontées au réel, pas six mois avant dans un huis clos.
Les questions qu'on vous pose au cadrage
Ça commence par un entretien, sans jargon (notre glossaire anti-jargon du web est là si un mot s'échappe). Trois questions structurent la discussion : pourquoi ce projet, et pourquoi maintenant (l'objectif business, pas la liste de fonctionnalités) ; pour qui (vos clients réels, pas « tout le monde ») ; et qu'est-ce qui fait votre différence. On y ajoute deux questions qui débloquent souvent tout : qu'est-ce qui vous fait perdre du temps aujourd'hui, et à quoi ressemblerait la réussite dans un an, en chiffres si possible.
Vous remarquerez ce qui manque : aucune question technique. Les outils, l'architecture, l'hébergement, c'est notre travail. Le vôtre : répondre franchement, y compris « je ne sais pas », qui est une réponse très utile puisqu'elle nous dit où creuser.
À quoi ressemble la restitution
De cet entretien, on construit l'arborescence, les parcours, puis les maquettes : vous voyez votre site avant qu'une ligne de code n'existe. C'est sur l'image qu'on débat, qu'on corrige, qu'on tranche. Modifier une maquette coûte une heure ; modifier un site construit coûte une semaine.
La restitution tient en quelques pages, et c'est voulu : les parcours clés, les maquettes des écrans qui comptent, un périmètre découpé en lots, et un prix ferme sur ce périmètre. Pas une fourchette élastique, un engagement. Si le besoin bouge en cours de route (ça arrive), on en parle et ça se chiffre avant, jamais après. Ce périmètre est solide parce qu'il décrit quelque chose que vous avez vu et validé, pas quelque chose que chacun imagine à sa façon.
Envie de situer le budget avant même de nous écrire ? Obtenez un ordre de grandeur en ligne, sans document à fournir : quelques questions, quelques minutes.
Pourquoi les étapes battent le tunnel
Le grand cahier des charges va presque toujours avec son jumeau : le développement en tunnel. On signe, le prestataire disparaît trois mois, et on découvre le résultat à la livraison. L'effet tunnel est le premier tueur de projets web, et il se soigne très simplement : en montrant son travail.
Nous, on découpe en lots et on livre par étapes : vous suivez l'avancement sur le vrai produit, à intervalles réguliers. Pas des captures d'écran, pas des « ça avance bien » : le site, cliquable, dans votre navigateur. Une remarque en semaine 2 se règle en semaine 2. La même remarque découverte à la livraison, c'est un chantier. Ce découpage pèse aussi sur le calendrier réel : on a détaillé combien de temps il faut vraiment pour livrer un site, et pourquoi les plannings de tunnel sont les moins fiables.
« Sans document, je perds le contrôle » : c'est l'inverse
C'est l'objection qu'on entend le plus, alors répondons frontalement. Le cahier des charges donne un contrôle de papier : tout est écrit, mais vous ne voyez rien avant la fin. Le cadrage suivi de démos donne un contrôle réel, qui tient à des choses concrètes :
- Vous voyez le vrai produit à chaque démo, pas un rapport d'avancement.
- Vous priorisez. L'ordre des lots se décide avec vous, et se rediscute si vos priorités changent.
- Vous parlez à la bonne personne. Chez nous, vous parlez directement à celui qui code, pas à un intermédiaire qui traduit.
- Le code et les données vous appartiennent, à chaque étape, pas seulement à la fin.
- On mène un seul projet à la fois, donc le vôtre n'attend jamais derrière un autre.
Le cas du produit à construire : cadrer le bon MVP
Quand le projet n'est pas un site mais un produit (un outil métier, une plateforme, un service en ligne), le cahier des charges maison fait encore plus de dégâts. Il liste tout ce que le produit pourrait faire un jour, et le projet meurt sous son propre poids avant d'avoir rencontré un seul utilisateur.
Le cadrage sert alors à trancher une question unique : que doit contenir la première version pour que vos premiers utilisateurs s'en servent vraiment ? Tout le reste attend la suivante, et c'est une force, pas un renoncement : chaque fonctionnalité différée se décidera avec de vrais retours plutôt qu'au doigt mouillé. C'est le cœur de notre approche pour cadrer et développer votre SaaS sur mesure. Le CRM qu'on a construit pour Perpitech, spécialiste de la détection de fuites, fonctionne ainsi : il évolue en continu, au rythme des besoins du terrain, pas d'un plan figé au départ.
Ce qu'il faut préparer (rassurez-vous : presque rien)
Trois choses suffisent pour le premier rendez-vous. Pourquoi vous lancez ce projet maintenant. Deux ou trois sites que vous aimez, même hors de votre secteur, et pourquoi. Et l'inventaire honnête de ce que vous avez déjà : logo, textes, photos.
Vous avez déjà commencé un document ? Apportez-le. On ne le jette pas : c'est un bon point de départ, à condition de le traiter comme une liste d'hypothèses à vérifier, pas comme un contrat gravé. Le reste, les bonnes questions au bon moment, c'est notre partie du travail.
Depuis 2015 et plus de vingt projets Laravel menés partout en France, on n'a jamais refusé un projet parce qu'il arrivait sans cahier des charges. Un projet en tête, même vague, surtout vague ? Venez comme vous êtes : le premier rendez-vous de cadrage est offert, et vous repartirez avec une vision plus claire, que vous travailliez avec nous ou pas.
Cet article vous intéresse ? Allons plus loin ensemble.
Venez avec votre problème
