Guide / Prix & budget

Le cahier des chargestient en une page

Le cahier des charges de 40 pages est un mythe qui retarde les projets et fige des décisions prises trop tôt. Pour obtenir un devis fiable, une seule page bien remplie suffit : problème, utilisateurs, parcours clés, intégrations, contraintes, budget. Voici le modèle exact, et pourquoi le reste vient après.

La réponse courte

Un cahier des charges efficace pour une application web tient en une page : le problème à résoudre, les utilisateurs et leurs rôles, 3 à 5 parcours clés, les intégrations, les contraintes, un budget cible et une échéance. Ces six points suffisent à un studio sérieux pour produire un devis fiable en 24 à 48 h. Les maquettes et les spécifications détaillées viennent après, pas avant.

Pourquoi 40 pages, c'est trop (et souvent contre-productif)

L'idée reçue veut qu'un projet sérieux commence par un document exhaustif : chaque écran décrit, chaque champ listé, chaque cas limite anticipé. En pratique, ce document joue contre vous, pour trois raisons :

  • Il fige des décisions prises trop tôt. Vous rédigez au moment où vous en savez le moins : avant tout échange technique, avant tout retour utilisateur. Les choix d'interface et de fonctionnalités écrits à ce stade sont revus dans la quasi-totalité des projets.
  • Il coûte des semaines sans réduire l'incertitude. Le temps passé à décrire la page 32 serait mieux investi dans une conversation d'une heure avec le prestataire, qui détecte en direct les angles morts et les fausses bonnes idées.
  • Il produit des devis moins fiables, pas plus. Face à 40 pages, un prestataire chiffre tout, y compris les fonctionnalités superflues, et ajoute une marge de sécurité sur chaque zone floue. Le devis gonfle sans que le projet y gagne.

Ce qui rend un devis fiable, ce n'est pas le volume du document : c'est la clarté sur le problème, les utilisateurs et le budget. Et cela tient en une page.

Le modèle : votre cahier des charges en 6 points

Voici la structure exacte à remplir. Une page, six blocs, des phrases courtes. Vous pouvez la copier telle quelle dans un email.

  • 1. Le problème à résoudre (2 à 3 phrases) : quelle situation concrète vous coûte du temps ou de l'argent aujourd'hui ? Exemple : « Nos devis sont faits sur Excel, ressaisis dans la facturation, et personne ne sait où en est chaque dossier. »
  • 2. Les utilisateurs et leurs rôles : qui utilisera l'application, et qui a le droit de faire quoi ? Exemple : 2 administrateurs, 8 commerciaux, des clients en lecture seule sur leur espace.
  • 3. Les 3 à 5 parcours clés : les actions que l'application doit absolument permettre, formulées du point de vue de l'utilisateur. Exemple : « Un commercial crée un devis en moins de 5 minutes depuis son téléphone. » Pas plus de cinq : si tout est prioritaire, rien ne l'est.
  • 4. Les intégrations : les outils existants auxquels l'application doit se connecter (comptabilité, CRM, paiement, signature électronique, emails). C'est souvent le poste le plus sous-estimé d'un devis, autant l'annoncer d'emblée.
  • 5. Les contraintes : tout ce qui est non négociable. Hébergement en France, conformité RGPD sur des données sensibles, fonctionnement hors connexion, compatibilité avec un vieux logiciel interne.
  • 6. Le budget cible et l'échéance : une fourchette honnête et une date butoir réelle s'il y en a une (salon, saison haute, fin de contrat d'un outil actuel).

Chaque bloc fait 2 à 5 lignes. Si un bloc dépasse dix lignes, vous êtes en train d'écrire des spécifications, pas un cadrage : coupez, cela viendra plus tard.

Le point 6 est le plus important (et le plus souvent omis)

Beaucoup de porteurs de projet cachent leur budget par crainte de « donner le prix » au prestataire. C'est une erreur de stratégie. Sans fourchette, le prestataire chiffre à l'aveugle et le devis a toutes les chances d'être à côté : trop ambitieux pour votre enveloppe, ou trop timide par prudence.

Annoncer une fourchette change la nature de l'échange : la question n'est plus « combien ça coûte ? » mais « que peut-on construire de plus utile avec ce budget ? ». Pour vous situer avant même d'écrire votre page, les fourchettes pratiquées chez Impin sont publiques :

Ce qui vient après le premier échange, et pourquoi c'est mieux ainsi

Les maquettes pixel-perfect, les spécifications écran par écran, le schéma de données : tout cela existe bel et bien dans un projet sérieux. Simplement, ce travail arrive après le premier échange, pour deux raisons concrètes :

  • Les bonnes décisions se prennent à deux. Un développeur expérimenté sait qu'une fonctionnalité estimée anodine peut coûter dix jours, et qu'une autre jugée complexe se règle avec un service existant. Ces arbitrages, impossibles à faire seul dans un document, se font en une conversation.
  • Le détail suit le périmètre, jamais l'inverse. Une fois le devis accepté et le périmètre figé, chaque parcours est décliné en écrans et en règles de gestion précises. Spécifier avant de connaître le périmètre, c'est spécifier des choses qui seront coupées.

C'est exactement le déroulé d'un projet de développement d'application web sur-mesure chez Impin : une page reçue, un échange de cadrage, un devis chiffré, puis les spécifications détaillées lot par lot. Pour un produit destiné à être commercialisé, la logique est la même côté création de SaaS : on cadre le parcours d'inscription et le cœur de valeur avant de dessiner le moindre écran.

Pourquoi une page permet un devis en 24 à 48 h

Un studio qui reçoit les six points ci-dessus peut chiffrer vite, car chaque bloc répond à une question de chiffrage précise : le problème donne le périmètre, les rôles donnent la complexité des droits, les parcours donnent le nombre d'écrans, les intégrations donnent les risques techniques, les contraintes donnent l'architecture, le budget donne le niveau d'ambition réaliste.

Quand l'un de ces blocs manque, le prestataire doit soit poser les questions (et le devis attend les réponses), soit deviner (et le devis est faux). Une page complète supprime ces deux détours : c'est ce qui rend possible une réponse ferme sous 24 à 48 h, avec une fourchette engageante plutôt qu'un « ça dépend ».

Un dernier conseil : n'attendez pas que votre page soit parfaite. Une page remplie à 80 % aujourd'hui vaut mieux qu'un document exhaustif dans deux mois, car les 20 % restants se règlent dans le premier échange.

Votre cahier des charges d'une page est prêt, ou presque ? Envoyez-le nous, vous recevez un devis chiffré sous 24 à 48 h.

Questions fréquentes

Que doit contenir le cahier des charges d'une application web ?+

Six éléments suffisent pour un premier chiffrage fiable : le problème à résoudre en deux ou trois phrases, les types d'utilisateurs et leurs rôles, les 3 à 5 parcours clés de l'application, les intégrations avec vos outils existants, les contraintes techniques ou réglementaires, et enfin votre budget cible avec une échéance. Tout le reste, maquettes et spécifications détaillées, se construit après le premier échange avec le prestataire.

Faut-il des maquettes avant de demander un devis ?+

Non. Les maquettes pixel-perfect produites avant le premier échange sont presque toujours refaites, car elles figent des choix d'interface pris sans connaître les contraintes techniques ni les vrais parcours utilisateurs. Un croquis à main levée ou une simple liste d'écrans suffit largement au stade du devis. Le travail de design intervient ensuite, une fois le périmètre validé avec le prestataire.

Combien coûte le développement d'une application web sur-mesure ?+

Chez Impin, un site vitrine sur-mesure coûte entre 800 et 1 200 €, une petite application ou un MVP SaaS entre 2 000 et 6 000 €, et une application métier complète entre 6 000 et 15 000 €. Une plateforme complexe fait l'objet d'un devis spécifique. Un cahier des charges d'une page bien rempli permet de situer votre projet dans la bonne fourchette dès le premier échange.

Pourquoi éviter le cahier des charges de 40 pages ?+

Parce qu'il fige des décisions prises au moment où vous en savez le moins sur votre projet. Les spécifications exhaustives écrites avant tout échange technique contiennent des choix irréalistes, des fonctionnalités jamais utilisées et des angles morts que seul un développeur détecte. Résultat : des semaines perdues à rédiger, puis des avenants pour corriger. Une page cadrée plus une conversation produisent un périmètre plus juste.

Faut-il indiquer son budget dans un cahier des charges ?+

Oui, c'est même l'information la plus utile. Annoncer une fourchette ne vous fait pas payer plus cher : elle permet au prestataire de proposer un périmètre réaliste plutôt qu'un devis hors-sol. Avec 3 000 € et avec 12 000 €, on ne construit pas la même chose, et le savoir dès le départ évite deux allers-retours inutiles et un devis à côté du besoin.

Votre page est prête ? Envoyez-la, vous recevez un devis chiffré sous 24 à 48 h.

Décrivez-nous votre projet, réponse sous 24 h