Comment préparer un cahier des charges pour un site web ou une application ?

Pourquoi écrire le document avant de parler de prix

L’erreur courante est de commencer par « combien coûte un site ? » avant d’avoir décrit le site. La question sans description n’a pas de réponse honnête : deux projets appelés « site » peuvent différer du tout au tout — un site vitrine de cinq pages n’est pas une boutique avec paiement et gestion de stock.

Le cahier des charges vous oblige à trancher vos choix avant l’arrivée du premier prestataire, puis s’envoie à l’identique à tous les candidats. C’est la condition de la comparaison : des devis construits sur la même description. Le guide France Num pour les TPE et PME en liste quatre bénéfices directs : clarifier vos objectifs, comparer les offres, piloter le projet et disposer d’une base contractuelle en cas de litige.

• Le document n’a pas besoin d’être technique : cinq à dix pages bien structurées suffisent pour un site ou une application simple.
• Rédigez-le vous-même d’abord, puis envoyez-le aux candidats ; ne laissez pas chaque prestataire vous faire remplir son propre formulaire.

Les sept questions auxquelles votre brief doit répondre

Tout bon cahier des charges répond à sept questions, pas une de plus pour commencer. Premièrement, l’objectif : un objectif principal et un résultat mesurable (par exemple doubler les demandes de contact en un an) valent mieux que trois formules générales. Deuxièmement, les utilisateurs : décrivez votre client réel, pas un public imaginaire. Troisièmement, les pages et fonctionnalités : marquez chaque élément « indispensable » ou « phase 2 », car cette séparation rend les devis comparables quand le budget impose des arbitrages.

Quatrièmement, les contenus : qui rédige, qui photographie, qui relit ? Cinquièmement, les langues : une deuxième langue signifie une structure bilingue et une gestion de traduction. Sixièmement, la date limite : une date de lancement souhaitée avec la raison du calendrier. Septièmement, la fourchette budgétaire, qui est votre décision : écrivez-la vous-même, car un prestataire qui connaît vos limites propose une solution atteignable plutôt qu’un rêve.

• Objectif : un résultat mesurable dans une durée donnée.
• Utilisateurs : qui ils sont, ce qu’ils cherchent, sur quel appareil.
• Pages et fonctions : une liste, chaque élément marqué indispensable ou différé.
• Contenus : qui écrit, qui produit les visuels, qui valide.
• Langues : leur nombre et qui valide la traduction.
• Date limite : la date de lancement souhaitée.
• Budget : une fourchette approximative que vous décidez.

Ce dont le prestataire a besoin pour chiffrer honnêtement

Un chiffrage honnête n’est pas un nombre jeté dans un e-mail, c’est le résultat d’une lecture de votre description. Le prestataire sérieux construit son devis sur : un périmètre clair, des actifs prêts ou dont l’origine est connue (logo, visuels, textes, nom de domaine), des intégrations nommées (paiement, e-mailing, réservation) et des attentes d’après-lancement (maintenance, mises à jour, sauvegardes). Chaque élément que vous laissez flou apparaît dans les devis comme une marge de sécurité, ou n’apparaît pas et vous surprend plus tard.

Le modèle d’appel d’offres du Government Performance Lab de Harvard recommande un périmètre clair, précis et réaliste, et de mentionner le budget pour aider les candidats à dimensionner leur réponse. La norme internationale d’ingénierie des exigences ISO/IEC/IEEE 29148 définit ce qui fait une bonne exigence : sans ambiguïté et vérifiable. Écrivez chaque point de votre brief pour qu’on puisse en vérifier la livraison, pas pour qu’il demande une interprétation.

• Joignez des liens vers des sites qui vous plaisent, avec une ligne sur ce qui vous plaît dans chacun.
• Nommez les systèmes à connecter : paiement, e-mail, réservation, tout outil que vous utilisez déjà.
• Indiquez qui administrera les contenus après le lancement et combien de personnes.
• Précisez vos attentes de maintenance : fréquence des mises à jour, sauvegardes, propriété du code et des comptes.

Les signaux d’alerte d’un brief faible

Les signaux d’alerte décrivent le brief, pas le prestataire. Un document plein de « site professionnel » et de « design moderne » sans un seul exemple annonce que rien n’est tranché, et le devis sera bâti sur une supposition. Un brief qui demande le prix avant toute description sélectionne le prestataire qui lance le chiffre le plus bas. Un brief sans date limite autorise qu’on repousse votre projet derrière tous les autres.

À l’inverse, exigez du prestataire la preuve de son sérieux : des projets similaires livrés, le nom de l’équipe qui travaillera réellement sur votre projet et un planning par jalons vérifiables. Le guide des appels d’offres de la ville de Portland rappelle que l’évaluation ne repose pas sur le prix seul mais sur des critères annoncés dès le départ ; écrivez dans votre brief comment vous comparerez les offres, pour que chaque candidat voie les mêmes règles.

• Des formules vagues sans exemples ni mesures : « professionnel », « moderne », « haut de gamme ».
• La demande de prix avant la description du projet.
• Aucune date limite, ou aucun responsable unique de la décision.
• Des fonctionnalités cachées qui apparaissent dans les questions posées après coup.
• Un devis qui ne sépare pas périmètre, délais, propriété et maintenance.

Modèle à copier et à compléter

Copiez les points suivants dans un fichier et complétez-les avant d’envoyer quoi que ce soit. Ne laissez aucun point vide ; si vous ignorez la réponse, écrivez « non tranché, proposition attendue » : un bon prestataire proposera et justifiera sa proposition.

• 1. Qui nous sommes : l’activité en deux lignes et qui décidera sur ce projet.
• 2. Objectif : que doit accomplir le site ou l’application sur 12 mois, et comment le mesurerons-nous ?
• 3. Utilisateurs : qui est le client principal, que cherche-t-il, sur quel appareil ?
• 4. L’existant : y a-t-il un site ou une page actuelle ? Que garde-t-on, que remplace-t-on ?
• 5. Pages : la liste des pages, chacune marquée indispensable ou phase 2.
• 6. Fonctionnalités : formulaire de contact, réservation, boutique et paiement, compte client, recherche, blog... chacune marquée de la même façon.
• 7. Contenus : textes, visuels, vidéo, logo : prêts, à rédiger ou à acheter, et qui valide la version finale.
• 8. Langues : les langues souhaitées et qui valide la traduction.
• 9. Intégrations : paiement, e-mail, réservation, tout outil à connecter, nommé.
• 10. Après le lancement : mises à jour, sauvegardes, propriété complète du code, du design et des comptes.
• 11. Date limite : la date de lancement souhaitée et la raison du calendrier.
• 12. Budget : une fourchette approximative que vous fixez ; on ne demandera pas au prestataire de la fixer à votre place.
• 13. Références : des liens vers des sites ou applications qui vous plaisent, avec une ligne par lien.
• 14. Délai de réponse : la date de réception des offres et le canal pour les questions.

Comment comparer les offres une fois reçues

Comparez avant le prix : périmètre couvert, planning par jalons, propriété, maintenance, puis prix. Deux devis au même montant peuvent différer parce que l’un n’inclut pas la rédaction des contenus ni une année de maintenance. Le modèle de Harvard recommande de laisser plusieurs semaines pour la remise des offres et les réponses aux questions ; si vous pressez le prestataire, vous pressez aussi la qualité de sa lecture de votre projet.

Envoyez le document à trois candidats au maximum : au-delà, la comparaison se dilue et chacun perd du temps. Demandez à chaque candidat de pointer explicitement les points flous de votre brief ; les questions qu’il pose révèlent ce qui manque à votre document, que vous pouvez corriger et renvoyer à tous dans la même version.