Brief de projet de site web : Comment en rédiger un qui fixe le bon prix

Pourquoi un cahier des charges vague épuise discrètement votre budget

Réponse directe : un studio ne peut pas évaluer votre intention, seulement votre document. Tout ce que le document omet, les deux parties le complètent silencieusement et différemment — et les deux visions se rencontrent finalement lors de la démo, lorsque changer de cap coûte cher.

Prenez une phrase qui semble parfaitement claire : nous avons besoin d'un site web d'entreprise, d'environ dix pages, avec un formulaire de demande.Il y a au moins quatre fourches cachées là-dedans, et chacune coûte de l'argent :

• Le formulaire de demande — s'agit-il d'un email vers une boîte de réception, ou cela crée-t-il un deal dans votre CRM et envoie-t-il un auto-répondeur au client ?
• Dix pages — dix écrans uniques, chacun conçu et construit séparément, ou un modèle rempli dix fois ?
• Contenu — remettez-vous le texte final et la photographie, ou quelqu'un doit-il les écrire et les prendre ?
• Langues — une, ou trois, et qui traduit ?

L'écart entre la lecture bon marché et la lecture coûteuse est un multiple, pas une erreur d'arrondi — et les deux sont honnêtes, la réponse n'était tout simplement pas dans le texte.

Puis vient le calendrier. L'ambiguïté arrive par tranches, chacune déguisée en une petite chose — un filtre ici, une calculatrice là, un formulaire de citation sur la page des services. Chacune semble prendre une demi-heure ; ensemble, elles réécrivent la moitié du projet, et le lancement est retardé de plusieurs mois. Un bon document de exigences n'est pas de la bureaucratie ; c'est un moyen de désaccord précoce, tant que le désaccord est encore gratuit. L'ignorer et le client paie pour le retravail, tandis que le studio absorbe le coût ou argumente et perd la relation.

Cahier des charges, Spécification, Portée des travaux — et qui les rédige

Le brief est un document d'accueil — une ou deux pages que le client remplit : qui vous êtes, ce que vous vendez, à qui, pourquoi vous avez besoin d'un site, ce que vous aimez et détestez chez les concurrents, budget, délai. Il décrit le problème, pas la solution, donc il ne peut pas être évalué avec précision — seulement estimé pour l'ordre de grandeur.

La spécification technique décrit ce qui sera construit : liste des pages, structure de chaque page, fonctionnalités, scénarios, intégrations, exigences administratives, critères d'acceptation. Il est rédigé après que le problème soit compris, et il devient une annexe au contrat. Le périmètre de travail est la limite — ce qui est inclus et ce qui est exclu. Une ligne disant le contenu de la carte produit est rempli par le client vaut plus d'une page de prose élégante.

Qui devrait rédiger le cahier des charges

Réponse courte : le client rédige le brief, le studio rédige le cahier des charges. Vous êtes l'expert de votre entreprise — marges, saisonnalité, les objections que vos commerciaux entendent. Le studio est expert sur ce qui va casser au bout de trois mois : quelles solutions existent et ce que chacune coûte. Laisser un client l'écrire seul, c'est inventer des solutions où il n'a aucune expérience, et le résultat spécifie soit des choses qui ne fonctionnent pas de cette manière, soit exige tout en même temps.

Donc le schéma est le suivant : le client remplit un brief ; le studio réalise une découverte — quelques sessions de questions inconfortables, cartographiant le véritable processus commercial — puis rédige le cahier des charges, et le client le lit, argumente et approuve. La découverte et la rédaction du cahier des charges sont un véritable travail : un studio qui propose un cahier des charges détaillé gratuitement produira un formel, juste assez pour obtenir une signature. Pour faire la distinction entre les équipes qui creusent réellement et celles qui réutilisent des modèles, nous avons couvert les signaux dans notre guide sur choisir un studio web.

L'Ouverture : Objectif commercial, public, concurrents

La première section de toute spécification décente répond à pourquoi, pas quoi. Ignorez-le et aucune décision ultérieure ne pourra être prise : chaque argument sur la nécessité d'un bloc se résume à un critère, et le critère provient de l'objectif.

L'objectif commercial

Formulez-le en termes commerciaux, pas en termes de site web. "Un site beau et moderne" est une opinion. Un objectif ressemble davantage à : obtenir des demandes d'installation de la part des propriétaires — en ce moment tout arrive par téléphone et la moitié est perdue, ou déplacer les clients en gros vers l'auto-service. Le premier fait que le formulaire, la confiance et la rapidité comptent ; le second, une zone de compte et une commande en un clic. Le même budget, des endroits différents.

Le public

Décrivez le comportement, pas les données démographiques. "Hommes, 25 à 45 ans" ne dit rien à un développeur. Cela dit :

• Qui décide et qui paie — souvent des personnes différentes.
• Comment ils arrivent : en cherchant un problème, en suivant une recommandation, en cliquant sur une annonce.
• Ce qu'ils vérifient avant de s'engager : prix, délai, licence, avis, zone de couverture.
• Sur quel appareil ils se trouvent. Un téléphone sur un site de travail avec un mauvais signal change les exigences de poids de page.

Concurrents

Donnez trois à cinq liens, chacun avec une phrase : ce qui est bon ici et ce qui est mauvais. Pas "beau design", mais "leur prix est visible immédiatement sans formulaire — je veux ça." Cette habitude permet d'économiser des semaines d'e-mails, car elle convertit le goût en exigences. Et écrivez honnêtement comment vous vous différenciez de ces concurrents : s'il n'y a pas de différence, ce n'est pas un problème de site web, et aucune quantité de front-end ne pourra le résoudre.

Liste des pages et structure : Où se trouve l'estimation

C'est de là que provient la majeure partie de l'estimation. La règle est simple : vous comptez modèles uniques, pas de pages. Un catalogue avec mille produits est un modèle de fiche produit, et un site de huit pages conçu page par page coûte plus de trente pages sur trois modèles. Donc, rédigez la liste en deux passes : nommez chaque page, puis indiquez lesquelles sont des modèles et lesquelles sont des créations uniques.

Comment décrire une page

Pour chaque page unique, listez les blocs de haut en bas avec l'objectif de chacun. Pour une page de service :

1. Héros : titre, description en une ligne, bouton demandant un devis.
2. Ce qui est inclus — liste à puces, cinq à huit éléments.
3. Comment le travail se déroule — trois à six étapes.
4. Tarification : tableau des niveaux ou une seule ligne "à partir de" ; décidez lors de la découverte.
5. Travail connexe — trois cartes, extraites automatiquement du portefeuille par étiquette de service.
6. FAQ — modifiable depuis l'administration. Formulaire de demande.

Remarquez les deux phrases qui font le gros du travail : "extraites automatiquement par étiquette" et "modifiable depuis l'administration." Ce ne sont pas des décorations, ce sont des heures : un bloc qu'un éditeur remplit à la main et un bloc qui s'assemble tout seul à partir des données sont des tâches différentes à des prix différents.

Navigation et liens entre les pages

Décrivez le menu principal et le pied de page en détail, et comment les pages se connectent : les services mènent à des études de cas, les études de cas retournent au service et au formulaire, les articles aux services. Un test utile est de parcourir votre futur site comme un étranger — quelqu'un qui atterrit sur un article, que voit-il ensuite et où va-t-il ? Si vous ne pouvez pas répondre, cette page n'est pas terminée. Vous pouvez voir comment cela se déroule dans notre travail récent. Et n'écrivez pas "le site doit être réactif" — c'est le minimum ; écrivez où le mobile se comporte différemment : le tableau des prix devient des cartes empilées, le filtre s'ouvre en plein écran. Ces points prennent du temps lorsqu'ils apparaissent tard.

Décrire la fonctionnalité sans ambiguïté

L'erreur classique dans les spécifications est de décrire les fonctionnalités avec des adjectifs — un filtre pratique, une recherche intelligente, un paiement rapide. Ce ne sont pas des exigences, ce sont des souhaits : vous ne pouvez pas les vérifier, vous ne pouvez pas les évaluer, et vous pouvez en discuter indéfiniment — pratique selon qui ?

L'alternative est des scénarios : qui fait quoi et ce qu'ils obtiennent. Comparez. Faible : "Compte client avec historique des commandes." Fort :

• Le client se connecte avec son email et son mot de passe ; la réinitialisation du mot de passe fonctionne via un lien envoyé par email.
• Le client voit ses commandes : numéro, date, total, statut, et un bouton "réapprovisionner".
• Il y a cinq statuts — nouveau, en cours, expédié, livré, annulé — définis par un responsable dans l'administration.
• "Réapprovisionner" remet les articles dans le panier ; tout ce qui est en rupture de stock est ignoré et le client est informé de ce qui l'est.
• Le client télécharge une facture PDF mais ne peut pas modifier le nom de l'entreprise enregistré — seul un responsable peut le faire.

La deuxième version peut être évaluée en heures sans un seul appel ; la première n'est qu'une estimation, hors cible.

Notez les cas limites

Le coût n'est rarement le chemin heureux — c'est tout ce qui l'entoure, où la moitié du budget se cache :

• Que se passe-t-il sans données : panier vide, recherche sans résultats, une catégorie sans rien dedans.
• Que se passe-t-il en cas d'échec : paiement refusé, fichier trop volumineux, email déjà enregistré.
• Ce que l'utilisateur voit si la connexion se coupe en plein paiement, et qui peut faire quoi — les éditeurs et les administrateurs ont besoin de permissions différentes.

Et marquez chaque élément : requis pour le lancement, agréable à avoir, ou phase deux. C'est le meilleur outil de budget qui existe : lorsque l'estimation revient plus élevée que prévu, vous couperez délibérément au lieu de tailler dans ce qui est le plus proche.

Contenu, intégrations, langues : Qui fournit quoi, et quand

Plus de projets échouent ici que dans n'importe quelle ligne de code. Le site est terminé et le lancement n'a pas lieu — parce que le texte n'est jamais arrivé, ou que les photos sont des clichés pris avec un téléphone dans un entrepôt sombre.

Contenu

La spécification doit indiquer clairement qui possède chaque type de contenu et à quelle date il existe :

• Texte de la page. Écrit par vous, par le rédacteur du studio, ou rédigé par vous et édité par nous ? Trois prix.
• Photographie. Votre archive, une séance photo, ou des images de stock ? Si c'est une séance photo — qui l'organise et la paie.
• Catalogue. Qui remplit les fiches, d'où viennent les descriptions, dans quel format l'export arrive.
• Pages légales. Politique de confidentialité, conditions, détails de l'entreprise — le territoire du client, mais le studio doit vous le rappeler.

Et une ligne de plus : que se passe-t-il si le contenu n'est pas prêt à temps. La réponse sensée est de lancer avec des espaces réservés sur une liste de pages convenue, et non de garder un site fini dans un tiroir pendant des mois.

Intégrations

Décrivez chacun de la même manière : quel système, quels mouvements où, à quel moment, et que se passe-t-il quand cela échoue. "Intégrer avec le CRM" n'a pas de sens — cela couvre à la fois deux heures de travail et deux semaines. Passez en revue la liste habituelle — CRM, passerelle de paiement, expédition, logiciel d'entrepôt, marketing par e-mail, messagers, reçus fiscaux, analyses — et pour chacun répondez à trois questions : a-t-il une API, y a-t-il de la documentation, qui détient les identifiants. Des identifiants manquants représentent un risque, et cela doit figurer dans le cahier des charges plutôt que d'apparaître une semaine avant le lancement.

Langues

Le multilingue n'est pas un commutateur dans l'en-tête. C'est un modèle de données séparé, des URL séparées, des balises méta séparées, un travail éditorial séparé, et une règle pour ce qui se passe lorsqu'une page n'a pas de traduction. Décidez à l'avance : quelles langues au lancement, lesquelles plus tard, qui traduit. Intégrer une deuxième langue dans un projet qui n'en attendait pas coûte plus cher que de le planifier dès le premier jour.

Références de design et le piège du "Faites-le comme X"

Les références sont nécessaires : sans elles, un designer devine vos goûts, et le goût ne peut pas être deviné par e-mail. Mais la manière dont vous les fournissez compte.

Le piège du "faites-le comme X" semble inoffensif et devient coûteux. Copier le site de quelqu'un d'autre ne fonctionnera pas pour votre entreprise — produit, public, point de prix différents — mais le problème plus profond est que vous voyez un site Web de l'extérieur tandis que le coût se trouve à l'intérieur : derrière cette animation fluide peut se cacher trois mois de travail, derrière le catalogue vivant une intégration d'entrepôt, derrière "juste de belles photos" une séance photo que vous n'avez pas.

D'où la règle : une référence sans commentaire est inutile. Chaque lien a besoin d'une phrase disant ce que vous en tirez réellement :

• "J'aime comment le prix est juste là, pas de formulaire de demande."
• "J'aime le sens de l'espace — beaucoup d'air, peu de texte par écran."
• "J'aime la structure de la fiche produit, pas les couleurs."
• "Je n'aime pas du tout le carrousel héro."

Les anti-références fonctionnent tout aussi bien : "pas comme ça, trop corporate" réduit la recherche plus rapidement que cinq exemples de ce que vous aimez.

Quoi d'autre à préciser

S'il existe un livre de marque et à quel point il est contraignant ; ton — formel ou conversationnel ; et surtout, qui approuve le design. Les projets stagnent sur les approbations bien plus souvent que sur la technologie, lorsqu'un maquette passe à un troisième directeur adjoint et revient avec des notes contredisant la première. Mettez un nom dans le cahier des charges — dont le "oui" est final — et convenez d'un nombre de tours. Deux ou trois est normal ; illimité n'est pas un projet, c'est un hobby.

Contraintes techniques, SEO et vivre dans l'administration

C'est la section que les clients sautent avec "vous savez mieux." Le studio sait mieux sur les solutions — mais seul vous connaissez les contraintes dont vous partez.

Contraintes techniques

• Hébergement et domaine.Où les choses résident maintenant, qui détient les identifiants, si des règles régissent où les données peuvent se trouver.
• Le système existant.Si un site existe déjà — ce qui migre, ce qui est abandonné, ce qui continue à fonctionner en parallèle.
• Politique interne.Revue de sécurité, règles de mot de passe, restrictions sur les services tiers.
• Propriété du code et données personnelles.Qui possède le résultat, ce que vous collectez, comment cela est supprimé sur demande.

SEO

Énoncez les exigences de recherche comme des mécanismes, pas des promesses. Aucun studio ne peut garantir des classements, mais tout studio doit fournir la base :

• Titre, description et en-têtes modifiables sur chaque type de page — depuis l'admin, sans développeur.
• Adresses lisibles, un schéma d'URL cohérent, et mappage de redirection lors de la migration.
• Données structurées, un plan du site, canoniques corrects, et avec plusieurs langues, attributs de langue appropriés.
• Vitesse indiquée comme des métriques spécifiques sur un appareil spécifique, pas comme "rapide."

L'admin et l'édition quotidienne

La section la plus sous-estimée dans toute spécification. Répondez à une question :qu'est-ce que vous changerez vous-même, et à quelle fréquence ?La réponse détermine l'architecture. Changez un numéro de téléphone une fois par an et vous avez à peine besoin d'un admin ; assemblez de nouvelles pages d'atterrissage chaque semaine et vous avez besoin d'un constructeur de blocs — un système et un budget différents. Décrivez les rôles et ce qui se passe lorsqu'un éditeur fait une erreur : brouillons, aperçu, retour en arrière. Et soyez honnête sur les compétences des personnes qui l'utiliseront — une interface conçue pour un développeur paralyse un éditeur ordinaire.

Critères d'acceptation, calendrier et fourchette budgétaire

Ces trois éléments clôturent la spécification et la transforment d'une description d'un rêve en un document de travail.

Critères d'acceptation

Un critère d'acceptation est une déclaration vérifiable. Pas "le site fonctionne correctement", mais une liste de ce qui sera vérifié :

• Chaque page de la liste s'ouvre ; aucun lien ne mène à une erreur.
• Le formulaire de demande est soumis, l'email arrive et le lead apparaît dans le CRM.
• Le site s'affiche correctement dans les navigateurs actuels et sur un téléphone.
• Les métriques de vitesse sur la page d'accueil et sur une fiche produit se situent dans le seuil convenu.
• Un paiement par carte de test est effectué, une commande est créée et l'email de confirmation est envoyé.

Cette liste protège les deux parties : le client sait exactement quoi vérifier, et le studio sait où se trouve la ligne d'arrivée au lieu de faire face à une phase d'acceptation qui ne finit jamais parce que quelque chose semble décalé.

Chronologie

Les dates de calendrier dans un cahier des charges sont généralement nuisibles — périmées au bout de deux semaines. Décrivez le calendrier en étapes : maquettes après validation de la structure, développement après les maquettes, population après le contenu. Le mot clé est dépendance. Les délais fonctionnent dans les deux sens : si le contenu arrive avec trois semaines de retard, le lancement est décalé — c'est de l'arithmétique, pas une punition. Indiquez clairement quels délais appartiennent au client : approbation des maquettes, livraison du contenu, accord d'accès.

La fourchette budgétaire

Les clients cachent le budget, craignant que l'estimation soit adaptée au chiffre. Le résultat est inversé. Un budget n'est pas un prix — c'est une contrainte sur le problème : si vous le retenez, vous obtiendrez soit une proposition que vous ne pouvez pas vous permettre, soit une proposition réduite au-delà de la reconnaissance. Une fourchette suffit : "nous pensons dans cette région et nous en discuterons davantage si cela est justifié." Ce qui suit est une conversation d'ingénierie sur ce qui s'inscrit dans le cadre et ce qui passe à la phase deux. Pour comprendre comment un prix est réellement assemblé, et pourquoi deux sites qui se ressemblent coûtent différemment, consultez notre décomposition de ce que coûte un site web en 2026.

Ce qu'il ne faut pas mettre dans un brief

De mauvaises spécifications ne sont pas seulement celles qui sont courtes — un monstre de quatre-vingts pages est aussi un symptôme. Voici ce qu'il faut couper sans hésitation.

Adjectifs évaluatifs.Moderne, pratique, intuitif, à fort taux de conversion. Aucun ne peut être vérifié. Rendez-le vérifiable à la place : plutôt que "un catalogue pratique", écrivez "un visiteur atteint le bon produit en pas plus de trois actions."

Solutions techniques prescrites, si vous n'êtes pas technique.Une ligne disant "construisez-le sur cette pile", sans raison, entrave et augmente le prix. Indiquez plutôt la contrainte : "notre administrateur système ne peut prendre en charge que cette pile," ou "cela doit fonctionner sur notre serveur." Le studio respectera la raison et choisira la méthode.

Tout, juste au cas où."Le système doit également permettre une future expansion des fonctionnalités" ne signifie rien, mais un studio consciencieux établira un prix avec une marge contre l'inconnu. Vous payez pour du brouillard.

Copier-coller à partir des spécifications de quelqu'un d'autre.Il est douloureusement visible lorsqu'une spécification de clinique se voit soudainement ajouter un panier d'achat et des options de livraison : maintenant, personne ne sait quelles exigences sont réelles. La conception en prose et la machinerie légale sont également exclues — l'une est le travail du maquette, l'autre celui du contrat.

Et ce qui manque presque toujours

L'autre côté : certaines choses sont omises dans neuf spécifications sur dix et ne semblent pas importantes jusqu'à ce qu'elles se déclenchent.

• Que se passe-t-il après le lancement : qui met à jour le site, qui le répare, qui répond à minuit un samedi.
• Sauvegardes : à quelle fréquence, où elles se trouvent, qui vérifie qu'elles se restaurent réellement.
• Transfert : identifiants, documentation, guide de l'éditeur, fichiers sources et formation pour vos équipes.
• Ce qui compte comme une correction sous garantie par rapport à une nouvelle tâche.

Comment le brief devient une estimation — et gérer les changements

Une estimation n'est pas un chiffre tiré de l'expérience — c'est une arithmétique effectuée sur un document.

Comment fonctionne réellement la tarification

Le studio décompose le cahier des charges en éléments et fixe un prix pour chacun en heures : chaque modèle unique, chaque page modélisée, chaque fonctionnalité, chaque intégration, l'administration, les tests, le lancement. En plus se trouvent les éléments absents de la liste des pages mais toujours présents — gestion, communication, révisions, acceptation. D'où suit la partie importante : une estimation n'est aussi précise que le cahier des charges. À partir d'un brief, vous pouvez citer une fourchette, et elle sera large car elle est honnête. Quand un entrepreneur lit un paragraphe et donne un prix exact, c'est un chiffre tiré du plafond — et à la fin, le plafond est le vôtre ou le leur.

Ne comparez que les estimations rédigées selon le même cahier des charges ; sinon, vous comparez des projets différents. La proposition bon marché décrit presque toujours moins — pas de tests, pas de peuplement de contenu, pas d'intégration — et une ligne indiquant "développement de site web — total" ne peut pas être vérifiée, tandis qu'une estimation détaillée prouve que l'entrepreneur a lu le cahier des charges. Notre portées de service sont établies selon cette logique : structure d'abord, puis fonctionnalité, puis acceptation.

Modifications après approbation

Des changements vont se produire — les entreprises évoluent, et une démo révèle toujours des choses qu'un document ne pouvait pas. La question n'est pas comment les prévenir mais comment les traiter :

1. Le changement est noté — comme un élément de ligne, pas une remarque lors d'un appel.
2. Le studio le tarifie : combien d'heures, quels mouvements dans le calendrier, ce que cela touche.
3. Le client décide : le faire maintenant, dans la phase deux, ou l'abandonner, et la décision est enregistrée en annexe.

Il y a une règle à mémoriser : un correctif est lorsque la construction ne correspond pas à la spécification ; un changement est lorsque la spécification ne correspond pas au besoin. Le studio corrige le premier gratuitement et facture le second. La ligne est tracée par un document plutôt que par l'humeur. Et si une fonctionnalité est ajoutée, soit quelque chose de requis passe à la phase deux, soit de l'argent est ajouté. Il n'y a pas de troisième option.

Liste de contrôle : Votre brief est prêt s'il contient

Passez en revue la liste. Si plus de trois éléments sont vides, le document n'est pas prêt à être évalué — et toute estimation à son égard est fictive.

1. Un objectif commercial en termes commerciaux, pas en termes de site web.
2. Le public comme comportement : qui décide, comment ils arrivent, ce qu'ils vérifient, quel appareil ils utilisent.
3. Concurrents : trois à cinq liens, chacun avec une note sur ce qu'il faut prendre et ce qu'il faut éviter.
4. Une liste de pages divisée en écrans uniques et en modèles.
5. Structure de chaque page unique : blocs de haut en bas et l'objectif de chacun.
6. Fonctionnalités en tant que scénarios : qui fait quoi et obtient quoi. Plus les cas limites et les échecs.
7. Priorités : requis pour le lancement / agréable à avoir / phase deux.
8. Contenu : qui rédige le texte, qui fournit les photos, d'ici quand, et que se passe-t-il si c'est en retard.
9. Intégrations par nom : ce qui bouge où, quand, quoi en cas d'échec, qui a les droits.
10. Langues : combien au lancement, qui traduit, que se passe-t-il sans traduction.
11. Conception : références annotées, manuel de marque, qui approuve, combien de tours.
12. Contraintes techniques : hébergement, accès, propriété du code, données personnelles.
13. SEO : méta modifiable, schéma d'URL, redirections lors de la migration, un seuil de vitesse.
14. L'administrateur :ce que vous éditez vous-même et à quelle fréquence, rôles, brouillons, retour en arrière, formation.
15. Critères d'acceptation :une liste vérifiable, pas "fonctionne correctement."
16. Une chronologie échelonnéeavec des dépendances, et un plage budgétaire.
17. Après le lancement :support, sauvegardes, transfert de credentials, la limite de garantie.

Avant qu'un projet ne commence, ne tentez pas de remplir toute la liste seul en une soirée. Remplissez ce que vous savez vraiment : l'objectif, le public, les concurrents, les contraintes, la plage budgétaire. Le reste — pages, fonctionnalités, intégrations, acceptation — s'assemble lors de la découverte, aux côtés d'un studio.

Une bonne spécification est comme un dessin technique : un document ennuyeux sans lequel la maison est construite à l'œil. Une heure passée sur la rédaction avant le début économise une journée de retouche au milieu. Si vous souhaitez que la spécification soit rédigée avec vous et tarifée honnêtement par rapport à cela, contactez-nous — nous commençons par un brief et une conversation, et le document a tendance à s'écrire de lui-même à partir de là.

FAQ