Budget
Rédiger un cahier des charges qui sert à quelque chose
Ce qu'un prestataire a réellement besoin de savoir pour chiffrer, ce qui ne sert à rien, et un modèle en une page qui suffit dans la plupart des cas.
Les cahiers des charges de quarante pages produisent les projets les plus mal chiffrés. Voici pourquoi, et ce qu’il faut écrire à la place.
Le problème des documents trop longs
Un cahier des charges long décrit une solution — des écrans, des boutons, des menus — avant d’avoir décrit un problème. Le prestataire chiffre alors ce qui est écrit, pas ce dont vous avez besoin. Si la solution imaginée n’est pas la bonne, tout le monde s’en aperçoit à la livraison.
Il donne aussi une fausse impression de précision. Quarante pages d’écrans ne disent rien du volume de données, des cas particuliers, ni de qui fait quoi — les trois choses qui décident réellement du coût.
Les six questions qui permettent de chiffrer
Que doit faire le visiteur ? Une action, prioritaire. Appeler, réserver, demander un devis, acheter, s’inscrire. Si vous en listez cinq, aucune ne sera bien traitée.
Qui est ce visiteur ? Un particulier pressé sur mobile et un acheteur professionnel qui compare trois devis ne demandent pas le même site.
Qu’est-ce qui existe déjà ? Site actuel, adresses en place, contenus réutilisables, outils à connecter, données à reprendre. C’est le poste qui fait le plus varier un devis, et celui qu’on oublie le plus souvent.
Qui écrit le contenu ? Vous, nous, ou personne — auquel cas le projet prendra trois mois de plus. C’est la première cause de retard, très loin devant la technique.
Qui modifiera le site après ? Vous, à quelle fréquence, avec quel niveau d’aisance. Cette réponse détermine l’architecture — voir site statique ou WordPress.
Quel est le budget ? Le donner n’est pas se désavantager. Un prestataire sérieux ajuste le périmètre au budget ; sans repère, il chiffre au hasard et vous recevez trois devis incomparables.
Ce qui ne sert à rien
La liste des technologies. Sauf contrainte réelle — votre équipe maintient déjà du Symfony, votre hébergeur impose PHP — imposer une technologie revient à choisir l’outil avant d’avoir vu le problème.
Les maquettes détaillées. Sauf si vous avez un designer. Sinon, vous payez un prestataire pour exécuter des choix graphiques que vous n’êtes pas outillé pour prendre.
« Le site doit être moderne, responsive et optimisé SEO. » Cela va de soi en 2026, exactement comme une voiture équipée de freins. Ces phrases occupent de la place sans rien décider.
Les fonctionnalités « pourquoi pas ». Chacune est chiffrée, et gonfle un devis que vous trouverez trop cher. Gardez-les pour une deuxième version.
Le modèle qui suffit, en une page
1. Ce que nous faisons, en trois phrases
2. Ce que le visiteur doit faire sur le site (une action)
3. Qui sont nos visiteurs
4. L'existant : site actuel, outils, données à reprendre
5. Le contenu : qui l'écrit, ce qui existe déjà
6. Qui modifiera le site, à quelle fréquence
7. Budget et échéance
8. Trois sites que nous trouvons réussis, et pourquoi
9. Ce que nous ne voulons surtout pas
Le point 8 vaut dix pages de description : montrer trois sites et dire ce qui vous plaît dans chacun transmet en une minute ce qu’un texte ne transmet jamais.
Le point 9 est le plus utile de tous, et personne ne l’écrit.
Et si vous n’en avez pas
Ce n’est pas bloquant. Une conversation d’une heure produit un meilleur cadrage qu’un document rédigé seul, parce que nous posons les questions dont vous ne soupçonnez pas qu’elles comptent.
Chez nous, cette étape n’est pas facturée.
Envoyez une page, ou rien du tout, et nous démarrons par une conversation. Réponse sous 48 heures ouvrées. Décrire le projet.