Pourquoi ton cahier des charges projet web démarre presque toujours sur un brief flou
La plupart des projets web qui dérapent ne dérapent pas pendant le développement. Ils dérapent avant. Au moment où un freelance ou une agence accepte de chiffrer sur la base d'un brief en trois phrases : "Je veux une application pour gérer mes clients", "Je voudrais un site comme Airbnb mais pour mon secteur", "On a besoin d'un outil interne pour automatiser nos process".
Le problème n'est pas que ces phrases soient mauvaises. C'est qu'elles sont incomplètes. Un cahier des charges projet web sérieux ne se rédige pas en deux heures à partir d'une conversation Slack. Et pourtant, c'est exactement ce qui se passe dans 90% des projets qui échouent : un brief flou est transformé en devis sans phase de cadrage intermédiaire, et tout le monde signe en pensant être aligné.
Trois mois plus tard, à la première démo, le client découvre que ce qu'il imaginait n'est pas ce qui a été chiffré. Le développeur découvre que ce qu'il a construit n'est pas ce que le client voulait vraiment. Le budget est cramé, la confiance aussi.
J'ai vu ce scénario trop de fois pour le tolérer. Que tu sois dirigeant TPE/PME, freelance ou porteur de projet, si ton prestataire te chiffre un projet web en deux jours après un seul appel, méfie-toi. Ce n'est pas un signe de réactivité. C'est un signe qu'il a deviné. Et ses devinettes vont devenir ton budget.
Pourquoi je refuse de chiffrer un projet web sans phase de discovery
Quand un prospect m'appelle pour la première fois, il a en général une vision claire de ce qu'il veut. Mais cette vision tient en une page. Le projet réel, lui, en fait 30. Entre les deux, il y a tout ce qu'il n'a pas encore imaginé : les cas limites, les parcours admin, les règles métier, les contraintes techniques, le périmètre de la V1, ce qui sera repoussé à plus tard.
Mon job, ce n'est pas de prendre sa vision et de la transformer en code. C'est de prendre sa vision et de la confronter à la réalité : son budget, son délai, sa capacité opérationnelle à exploiter l'outil une fois livré. Cette confrontation se fait avant le devis, pas après.
Le client a un rêve. Moi avec ma méthode, je le cadre et je le rends réaliste. Pas de fausse promesse, mais réaliste et en accord avec le budget.
C'est ce que j'appelle la phase de discovery. C'est la fondation de tout ce qui suit. Chiffrer un projet web sans discovery, c'est exactement comme construire une maison sans regarder le terrain. Tu peux le faire. Tu vas juste découvrir les problèmes au moment où ils coûteront le plus cher à corriger.
Cette discovery n'est pas une formalité. C'est un vrai travail, qui prend du temps, qui mérite d'être structuré, et qui produit un livrable concret. C'est aussi ce qui me différencie d'un freelance qui te file un devis express après un appel de 30 minutes.
Mon funnel en deux temps : découverte gratuite puis préconception payante
Ma méthode de cadrage tient en deux étapes claires.
Étape 1 : le RDV de découverte (gratuit)
On échange 45 minutes à 1 heure. Tu me racontes ton projet, je te pose les bonnes questions pour capter l'enjeu réel (pas le symptôme), et je te présente ma méthode de travail. À la fin de cet appel, je sais si je peux t'aider et si on est alignés.
Ce RDV est gratuit pour une raison simple : avant d'être payé, il faut qu'on se soit parlé. Tu ne paies pas pour savoir si on va bosser ensemble. Tu paies quand tu sais déjà qu'on va le faire.
Trois jours plus tard, tu reçois un mail récapitulatif qui résume ce qu'on s'est dit, le périmètre que j'ai compris, une fourchette indicative de budget (pas un devis), et la prochaine étape si tu veux avancer.
Étape 2 : le forfait de préconception (1 000 € HT)
Si tu veux avancer, on passe à la préconception. C'est un forfait fixe d'environ 1 000 € HT qui me paie pour 3 à 4 ateliers de travail avec toi, plus le temps de rédaction du dossier complet. Cette préconception est déductible du devis dev si on signe le projet derrière.
Pourquoi payant ? Pour deux raisons.
D'abord parce que c'est du vrai travail : 6 à 10 heures d'ateliers et de rédaction, c'est l'équivalent d'une semaine partielle. Le faire gratuitement, c'est s'asseoir sur sa propre valeur et finir par bâcler le travail ou refuser le projet.
Ensuite parce que ça filtre. Un prospect qui hésite à investir 1 000 € pour cadrer son projet hésitera encore plus à investir 15 000, 30 000 ou 50 000 € pour le développer. Cette étape qualifie autant qu'elle cadre.
Si tu décides après préconception de ne pas faire le projet, ou de le confier à quelqu'un d'autre, tu gardes le dossier. Tu as payé pour un livrable, tu repars avec.
Les ateliers de préconception : comment on cadre vraiment un projet web
Le nombre d'ateliers s'adapte à la complexité du projet. Un outil interne simple peut tenir en 3 sessions. Une marketplace avec plusieurs rôles utilisateur en demande 4, parfois 5. Chaque atelier dure 1h à 1h30 et a un objectif précis.
Atelier 1 : périmètre et parcours utilisateurs
On part de ta vision et on la décompose en parcours concrets. Un client qui s'inscrit, qui paie, qui reçoit une notification : c'est un parcours. Un admin qui valide une transaction, qui exporte un rapport, qui gère un litige : c'en est un autre. On les liste tous, on les ordonne, on identifie ceux qui sont essentiels à la V1 et ceux qu'on peut repousser à une V2.
C'est aussi à ce moment qu'on commence à couper. Ce qui est repoussé n'est pas perdu, c'est protégé. Tout vouloir faire en V1, c'est ce qui fait dériver les projets de trois mois en projets de neuf mois. Couper, c'est un acte de bienveillance envers ton budget.
Atelier 2 : règles métier et arbitrages
On rentre dans les règles. Comment se calcule un prix ? Qui valide quoi et dans quel ordre ? Que se passe-t-il si un utilisateur ne répond pas ? Quelles sont les exceptions ? Quels sont les cas particuliers que tu connais déjà et qui doivent être pris en compte dans le cahier des charges ?
C'est l'atelier le plus dense parce qu'il révèle souvent des angles morts dans ta propre vision du produit. Pas grave, c'est exactement à ça qu'il sert.
Si tu veux discuter de ton projet, ma carte de visite est ici, tu peux même l'ajouter à ton répertoire en un clic.
Atelier 3 : stack technique et arbitrages budget
On parle techno, hébergement, coûts mensuels d'exploitation, dépendances tierces (paiement, emails, SMS, géolocalisation). Je te présente les choix possibles et leurs implications. Toi tu arbitres en connaissance de cause.
À la fin de cet atelier, on a une vision claire : ce qui est construit, ce qui ne l'est pas et pourquoi, combien ça coûte par mois à faire tourner une fois en production.
Atelier 4 (optionnel) : validation finale
Sur les projets plus complexes, un atelier de validation où je te présente le dossier consolidé. Tu lis, tu commentes, on ajuste, je verrouille. C'est l'étape où on passe du draft au livrable final.
À quoi ressemble un cahier des charges projet web actionnable
Au bout de ces ateliers, tu repars avec un document d'une vingtaine à une trentaine de pages structuré pour être lisible par un dirigeant non-tech. Pas du jargon de développeur. Pas de schémas UML. Un document fonctionnel.
Voici la structure que j'utilise systématiquement pour rédiger un cahier des charges projet web :
- Synthèse exécutive : une page qui résume la vision, la promesse produit, les piliers
- Vision et proposition de valeur : le constat marché, la promesse, les différenciateurs
- Périmètre du projet : ce qui est construit ET, explicitement, ce qui ne l'est pas (avec la raison de chaque exclusion)
- Parcours utilisateurs détaillés : un chapitre par rôle (client, prestataire, admin, etc.)
- Règles métier et tarification : toutes les règles chiffrées noir sur blanc
- Flux financier : comment l'argent transite, qui facture qui, qui valide quoi
- Stack technique et hébergement : choix techniques, coûts d'exploitation mensuels estimés
- Planning, livrables et recette : phases de développement, durée estimée, critères de validation
- Annexes : décisions actées par RDV, glossaire, questions ouvertes à suivre
Le chapitre 3 mérite qu'on s'y arrête. La majorité des cahiers des charges projet web décrivent ce que le projet fait. Le mien décrit aussi ce qu'il ne fait pas, et pourquoi. C'est cette deuxième liste qui protège ton budget pendant les six mois suivants.
Quand un nouveau besoin émerge en cours de développement, il atterrit soit dans le périmètre, soit dans la liste des exclusions documentées. Pas dans une zone grise où ça finit par dériver. C'est ce qu'on appelle prévenir le scope creep, et c'est ce qui distingue un cahier des charges actionnable d'un cahier des charges décoratif.
Exemple concret : un cahier des charges marketplace cadré en 4 ateliers
Récemment, j'ai cadré un projet de marketplace nationale dans un secteur très artisanal. Le dirigeant arrivait avec une vision claire et ambitieuse : permettre à un client de commander un service en cinq minutes, paiement en ligne immédiat, sélection automatique du meilleur prestataire dans sa zone, dashboard temps réel pour piloter l'activité.
Sur le papier, c'était une excellente idée. Dans le détail, c'était trois projets différents : la plateforme de commande, le back-office prestataire, et le pilotage administrateur. Sans préconception, on aurait tout chiffré en bloc, signé un devis ambitieux, et constaté trois mois plus tard qu'on construisait pour neuf mois ce qui devait être livré en deux.
Pendant quatre ateliers de préconception, on a fait le tri. Une fonctionnalité de comparaison de plusieurs offres a été abandonnée au profit d'une offre unique au meilleur prix, décision prise en atelier 4, qui a simplifié l'interface et accéléré la décision côté client. La signature électronique a été supprimée : le paiement en ligne fait office d'acceptation, on gagne deux étapes. La facturation automatique des commissions a été reportée à une V2 : le dirigeant préfère valider manuellement au démarrage, c'est plus prudent quand on lance.
À l'arrivée, le cahier des charges final faisait 30 pages, listait noir sur blanc 13 fonctionnalités exclues du périmètre avec leur raison d'exclusion, et chiffrait la stack technique à environ 100 € par mois en coûts d'exploitation. Le dirigeant a signé le devis dev en connaissance de cause. Pas de surprises pendant les semaines suivantes. C'est exactement ce que je vends : pas une devinette, un cadrage.
Questions fréquentes sur la préconception et le cahier des charges projet web
Combien coûte un cahier des charges pour un projet web ?
Chez moi, la rédaction d'un cahier des charges projet web complet est intégrée dans un forfait de préconception à 1 000 € HT environ. Ce forfait couvre 3 à 4 ateliers de cadrage et la rédaction du document final. Si tu signes le devis de développement derrière, ce montant est intégralement déduit du devis. Concrètement, ta préconception ne te coûte rien si on bosse ensemble.
Combien de pages fait un cahier des charges projet web ?
Un cahier des charges projet web complet fait généralement entre 20 et 30 pages chez moi. Ça dépend de la complexité du projet : un outil interne simple peut tenir en 15-20 pages, une marketplace multi-rôles avec règles métier complexes monte à 30-35 pages. L'objectif n'est jamais le volume pour le volume : chaque page sert à arbitrer ou à protéger une décision.
Pourquoi rédiger un cahier des charges avant de chiffrer un projet web ?
Parce que chiffrer un projet web sans cadrage, c'est deviner. Et les devinettes deviennent ton budget. Un cahier des charges rédigé en amont protège ton budget contre le scope creep (l'ajout incontrôlé de fonctionnalités), aligne tout le monde sur ce qui sera livré, et permet à plusieurs prestataires de te chiffrer sur la même base si tu veux comparer. Sans cahier des charges, chaque devis que tu reçois chiffre un projet différent.
Quelle est la différence entre un brief et un cahier des charges ?
Un brief, c'est ta vision en une à trois pages : ce que tu veux, pour qui, pourquoi. Un cahier des charges, c'est ce que ton brief devient une fois confronté à la réalité technique, budgétaire et opérationnelle. Le brief vient du client, le cahier des charges est rédigé conjointement entre toi et un prestataire (ou un cadreur) qui sait quelles questions poser.
Un freelance peut-il rédiger un cahier des charges aussi bien qu'une agence ?
Oui, et c'est même souvent mieux. Une agence va te faire passer par 3 interlocuteurs différents (commercial, chef de projet, lead dev) qui se transmettent l'information de manière imparfaite. Un freelance dev senior qui rédige lui-même le cahier des charges connaît déjà les implications techniques de chaque ligne. Le document est plus dense, plus précis, et il n'y a aucune perte d'information au moment du développement parce que c'est la même personne qui passe à l'exécution.
Combien de temps prend la rédaction d'un cahier des charges projet web ?
Chez moi, 2 à 3 semaines entre le premier atelier et la livraison du dossier final. Les ateliers s'étalent généralement sur 2 semaines à raison d'un par semaine (le temps que tu digères et que je rédige les arbitrages entre deux), puis 1 semaine de rédaction-consolidation. Si tu es pressé, on peut comprimer à 10 jours en enchaînant les ateliers, mais je ne le recommande pas : laisser dormir une décision une nuit fait souvent émerger les vrais problèmes.
On en parle ?
Si tu portes un projet web ou mobile et que tu veux le cadrer avant d'engager du budget de développement, prenons 30 minutes. Le RDV de découverte est gratuit, c'est exactement fait pour ça.
Écris-moi à contact@nitrello.com avec une ou deux phrases sur ton projet, je te propose un créneau dans la foulée.
Et si tu veux d'abord voir à qui tu parles, ma carte de visite digitale est ici, tu peux même l'ajouter à ton répertoire en un clic.