Un projet web ou mobile qui dérape ne dérape presque jamais au moment du développement. Il dérape avant, au moment où personne n'a pris le temps d'écrire noir sur blanc ce qu'on attend vraiment du site ou de l'application. Le cahier des charges a mauvaise réputation — trop long, trop technique, jamais lu une fois signé. Mal fait, c'est vrai. Bien fait, c'est l'outil qui évite les allers-retours interminables, les budgets qui dérivent et les livraisons qui ne correspondent pas au besoin. Voici comment le construire pour qu'il serve réellement votre projet, pas seulement votre prestataire.
Pourquoi ce document compte plus qu'on ne le pense
Un cahier des charges n'est pas un exercice administratif imposé par une agence. C'est le moment où vous clarifiez, pour vous-même d'abord, ce que le projet doit accomplir. Beaucoup de dirigeants arrivent avec une idée générale — « on veut un nouveau site », « on veut une application pour nos clients » — sans avoir tranché les questions qui déterminent réellement le budget et le planning : qui utilise l'outil, pour faire quoi, avec quelles contraintes.
Sans ce travail de cadrage, chaque échange avec le prestataire devient une négociation à vue. Avec lui, la conversation change de nature : on discute de solutions plutôt que de redéfinir sans cesse le problème. C'est particulièrement vrai pour un site sur-mesure ou une application mobile ou SaaS, où les choix techniques dépendent directement de la précision du besoin exprimé en amont.
Ce que doit contenir un bon cahier des charges
Le contexte et les objectifs
Avant de parler de fonctionnalités, il faut poser le décor : qui êtes-vous, que fait votre entreprise, pourquoi ce projet maintenant. Un site qui doit remplacer un outil vieillissant n'a pas les mêmes priorités qu'une application lancée pour tester un nouveau marché. Formulez l'objectif principal en une phrase — générer des demandes de devis, vendre en ligne, fluidifier un parcours client existant — et gardez cette phrase comme boussole pour tous les arbitrages qui suivront.
Le périmètre fonctionnel
C'est le cœur du document. Listez ce que l'outil doit permettre de faire, du point de vue de l'utilisateur final, pas du point de vue technique. Quelques exemples de ce qu'on y retrouve généralement :
- Les parcours utilisateurs principaux (inscription, prise de rendez-vous, achat, consultation d'un catalogue…)
- Les profils d'utilisateurs et leurs droits respectifs (client, administrateur, équipe interne)
- Les intégrations nécessaires avec vos outils existants (CRM, paiement, emailing, ERP)
- Les contenus à prévoir et qui les fournit
- Ce qui est explicitement hors périmètre pour cette première version
Ce dernier point est sous-estimé alors qu'il évite la majorité des tensions en cours de projet. Dire ce qu'on ne fait pas maintenant est aussi structurant que dire ce qu'on fait.
Les contraintes techniques et budgétaires
Précisez ce qui est déjà en place et doit être conservé : nom de domaine, hébergement, outils métier existants, éventuelle base de données à reprendre. Indiquez aussi une fourchette budgétaire et un horizon de temps réalistes. Un prestataire sérieux préfère une fourchette honnête à un chiffre flou ou absent — cela lui permet de proposer un périmètre cohérent avec vos moyens plutôt que de deviner.
Les erreurs qui rendent un cahier des charges inutile
- Confondre fonctionnalités et solutions techniques. Dire « on veut un espace client » est utile ; imposer une technologie précise sans en avoir besoin ferme des portes inutilement.
- Vouloir tout, tout de suite. Un document qui empile les demandes sans priorité aboutit à un devis surdimensionné ou à un projet qui ne démarre jamais. Mieux vaut un MVP clair qu'une liste de souhaits.
- Écrire seul, dans son coin. Les équipes qui utiliseront l'outil au quotidien détectent des besoins que la direction ne voit pas toujours. Les associer, même brièvement, évite les surprises après la mise en ligne.
- Laisser le document figé. Un cahier des charges se précise en discussion avec le prestataire retenu. Le premier jet sert de base de dialogue, pas de contrat gravé dans le marbre.
Un cahier des charges trop précis sur la technique et trop vague sur l'usage produit souvent l'inverse de l'effet recherché : un outil qui coche des cases techniques sans résoudre le problème initial.
Vitrine, plateforme sur-mesure ou application : le cadrage change de nature
Toutes les demandes n'appellent pas le même niveau de détail. Pour un site vitrine en no-code, l'essentiel tient dans l'arborescence des pages, le ton éditorial et quelques intégrations simples (formulaire, prise de rendez-vous). Le cadrage peut tenir en quelques pages et se finaliser en un atelier.
Pour une application mobile ou une plateforme SaaS, le niveau d'exigence monte d'un cran : gestion des comptes, logique métier propre à votre activité, éventuelle synchronisation entre plusieurs interfaces (web, mobile, back-office). Le cahier des charges doit alors décrire les règles métier avec précision — c'est souvent là que se jouent les écarts de budget entre un devis optimiste et un devis réaliste.
Cadrer une refonte ou une reprise de projet : un exercice différent
Si votre projet consiste à refondre un site existant, le cahier des charges ne part pas d'une page blanche. Il doit d'abord documenter ce qui fonctionne et ce qui doit changer — un audit de site web en amont permet souvent d'objectiver ces choix plutôt que de se fier aux impressions. Si vous héritez d'un projet mal documenté ou abandonné par un précédent prestataire, la logique est encore différente : la priorité devient de comprendre l'existant avant d'écrire quoi que ce soit de nouveau, ce qui correspond davantage à une démarche de reprise qu'à un cadrage classique.
Dans les deux cas, mieux vaut commencer par un diagnostic factuel plutôt que par une liste de fonctionnalités désirées — on évite ainsi de reproduire les mêmes angles morts que la version précédente.
Comment avancer concrètement
Vous n'avez pas besoin d'un document parfait pour démarrer une conversation avec une agence. Un cahier des charges peut évoluer en plusieurs étapes :
- Un premier jet interne : objectifs, utilisateurs, contraintes connues.
- Un atelier de cadrage avec le prestataire pour challenger le périmètre et prioriser.
- Une version consolidée qui sert de base au devis et au planning.
- Des ajustements documentés au fil du projet, sans repartir de zéro à chaque changement.
Chez HWS, cette phase de cadrage fait partie intégrante de nos projets, qu'il s'agisse d'un site vitrine ou d'une plateforme complexe. Elle permet de proposer un devis fiable et d'éviter les mauvaises surprises pour les deux parties.
Un exemple concret : Nemo
Nemo, plateforme destinée aux kinésithérapeutes, illustre bien ce qu'apporte un cadrage sérieux sur un projet sur-mesure. Une plateforme métier de ce type touche à des usages précis — gestion de patients, organisation du cabinet — qui ne se devinent pas depuis l'extérieur : ils doivent être explicités avant que la première ligne de code ne soit écrite. C'est ce travail de compréhension du métier, en amont du développement, qui permet ensuite de construire un outil réellement adapté plutôt qu'une application générique habillée aux couleurs du client. Vous pouvez consulter la fiche du projet Nemo pour plus de détails.
Ce qu'il faut retenir
Un cahier des charges n'a pas besoin d'être exhaustif pour être utile — il doit surtout être honnête sur les objectifs, les priorités et les contraintes réelles du projet. C'est ce document, même imparfait, qui permet à une agence de vous proposer une solution juste plutôt qu'une estimation à l'aveugle. Si vous préparez un projet de site ou d'application et que vous ne savez pas par où commencer ce cadrage, autant en discuter directement avec une équipe qui pourra vous aider à structurer vos idées avant même de parler devis.
