Quand un porteur de projet me contacte, son besoin arrive sous toutes les formes. Parfois, c'est juste une idée : on en discute, et je lui demande de tout noter dans un fichier au fur et à mesure. Parfois, c'est un cahier des charges déjà rédigé, souvent très (trop) fourni et écrit avec l'aide d'une IA. Parfois encore, ce sont des maquettes générées par IA ou des croquis faits à la main.
Dans presque tous les cas, il manque les mêmes choses : un vrai découpage des fonctionnalités, une définition claire des besoins prioritaires, ceux de la première version, et une charte graphique.
Voici la trame que j'utilise, les erreurs que je vois le plus souvent, et un modèle à télécharger pour partir sur de bonnes bases.
À quoi sert un cahier des charges
Un cahier des charges sert à deux choses : obtenir des devis comparables, et construire ce que vous avez vraiment en tête. Sans lui, chaque développeur imagine un projet différent, et les devis vont de 1 000 € à plus de 30 000 € pour une même idée (j'en parle ici pour les plateformes de mise en relation).
Ce n'est pas un document administratif. C'est l'endroit où l'on tranche, avant d'écrire la moindre ligne de code, les questions qui coûteraient cher à trancher après.
Avant et après le devis : deux documents différents
On confond souvent deux documents, qui n'arrivent pas au même moment.
Avant le devis, le cahier des charges. Il décrit le besoin : ce que l'application doit faire, pour qui, et dans quel ordre. C'est au porteur de projet de le porter, parce que personne ne connaît mieux que lui son métier et ses clients. Et même quand il l'a rédigé seul, je le reformule avec mes mots pour être sûr d'avoir bien compris, puis je le lui fais valider. C'est aussi le moment où j'apporte mon regard de CTO : orienter certains choix, ou argumenter contre une fonctionnalité qui coûterait cher pour peu de valeur.
Après le devis accepté, les spécifications. C'est là qu'on prépare la construction : les écrans et les parcours détaillés (les spécifications fonctionnelles), puis la structure de la base de données, l'architecture et les services externes (les spécifications techniques). Ce travail-là revient au CTO ou au développeur.
Cet article parle du premier document : celui qui permet d'obtenir des devis fiables.
La trame d'un cahier des charges d'application web
- Contexte et objectifs. Le projet en trois phrases, le problème qu'il résout, ce qui permettra de dire qu'il a réussi, l'échéance et le budget envisagé.
- Modèle économique. Comment le projet va vous rapporter de l'argent : commission sur chaque transaction, abonnement, mise en avant payante, offre gratuite puis payante… Qui paie, combien et à quel moment ?
- Utilisateurs et rôles. Chaque type d'utilisateur (client, prestataire, administrateur…), ce qu'il peut faire, et comment les comptes sont organisés : une personne seule, ou une société avec plusieurs utilisateurs ?
- Parcours principaux. Pour chaque rôle, les étapes clés, de l'inscription à l'action qui compte (réserver, publier, payer), décrites concrètement.
- Fonctionnalités et priorités. La liste découpée en trois niveaux : la première version (MVP), la version suivante, et « plus tard ». Pour chaque élément important (une annonce, une offre, une commande), les informations qu'il contient et les règles qui s'appliquent.
- Back-office et statistiques. Ce que l'équipe doit pouvoir gérer au quotidien, et les chiffres à suivre : inscriptions, ventes, activité.
- Charte graphique et maquettes. Logo, couleurs, typographies, sites que vous aimez, et vos maquettes ou croquis en annexe.
- Contenus et données. Qui fournit les textes et les images, et quelles données existantes doivent être reprises.
- Services externes et coûts récurrents. Paiement, cartes, envoi d'e-mails ou de SMS, hébergement : ce qui sera facturé chaque mois, et par qui.
- Contraintes. RGPD, sécurité, langues, appareils à prendre en charge, outils à connecter.
- Après la mise en ligne. Maintenance, hébergement, évolutions : qui s'en occupe, et comment.
- Planning et budget. Les grandes étapes et l'enveloppe disponible pour chacune.
Les rubriques 1 à 8 relèvent du porteur de projet. Les rubriques 9 à 12 se construisent avec le CTO ou le développeur.
Le modèle économique est la question que je pose le plus souvent, et celle qui change le plus de choses. Une commission prélevée sur chaque vente impose un paiement partagé entre plusieurs comptes et la vérification d'identité des vendeurs (j'en parle ici). Un abonnement demande plutôt une gestion des formules, des renouvellements et des factures récurrentes. L'inscription, le paiement et une bonne partie du back-office en découlent.
Les erreurs que je vois le plus souvent
Aucune priorité. Tout est au même niveau, et il devient impossible de dire ce qui doit être prêt pour le lancement. C'est pourtant la décision la plus importante du cahier des charges.
L'oubli des rôles. On décrit ce que « l'utilisateur » peut faire, sans préciser lequel. Or un client, un prestataire et un administrateur n'ont ni les mêmes écrans ni les mêmes droits.
Des phrases trop vagues. Je lis souvent des formulations comme « le prestataire doit pouvoir guider le client ». Guider comment ? Par messagerie, par visio, par des étapes à valider ? Chaque réponse est un développement différent, avec un prix différent.
Un back-office et des statistiques flous. Les porteurs de projet savent rarement quels chiffres ils voudront suivre. Ils le découvrent après le lancement, quand il faut alors tout ajouter.
Vouloir tout pouvoir modifier soi-même. Les menus, les textes des pages, la mise en page… Sur le papier, c'est rassurant. En pratique, le client n'a pas le temps de s'en occuper, et ces modifications sont plus simples et moins chères à inclure dans un forfait de maintenance.
Deux imprécisions qui coûtent cher
Une annonce mal décrite. Le cahier des charges dit « le prestataire peut créer une annonce », sans préciser ce qu'elle contient. Une fois en place, elle ne correspond pas à ce que le client avait en tête, et il faut la réécrire entièrement : formulaire, affichage, recherche.
Une structure qui change en cours de route. Au départ, on parle d'utilisateurs. À l'arrivée, le client veut des sociétés, avec plusieurs utilisateurs rattachés à chacune. Ce changement oblige à reprendre la structure de la base de données, l'inscription, les liens entre les données et une bonne partie des écrans. Une question posée au départ (« un compte, c'est une personne ou une entreprise ? ») aurait évité des semaines de travail.
Et le cahier des charges rédigé avec l'IA ?
Je reçois de plus en plus de cahiers des charges rédigés avec ChatGPT, et de maquettes générées par IA. C'est une bonne chose : l'idée est souvent plus facile à comprendre. Mais ces documents ont un défaut commun : ils sont trop fournis et sans priorités. L'IA ajoute des fonctionnalités par dizaines, toutes présentées comme indispensables.
Utilisez-la pour ne rien oublier, puis faites le tri : qu'est-ce qui doit absolument être là le jour du lancement ?
Télécharger le modèle
Pour vous lancer, voici la trame ci-dessus au format Word, avec des questions et des exemples dans chaque rubrique. Il est libre d'utilisation, sans inscription.
Les questions à se poser, un exemple complet et des cadres à remplir pour chaque rubrique.
Word · 12 rubriques · 10 pagesEt si vous voulez être accompagné, c'est exactement ce que je fais lors d'un cadrage : partir de votre idée, de vos notes ou de votre document existant, et en tirer un cahier des charges priorisé, validé et prêt à être chiffré.
Questions fréquentes
Qui doit rédiger le cahier des charges d'une application web ?
Le porteur de projet écrit le besoin : ses utilisateurs, ce qu'ils doivent pouvoir faire et ce qui compte en premier. Le CTO ou le développeur le reformule et le fait valider avant de chiffrer, puis se charge des spécifications techniques une fois le devis accepté.
Quelle est la différence entre un cahier des charges et des spécifications ?
Le cahier des charges décrit le besoin, avant le devis : ce que l'application doit faire, pour qui et dans quel ordre. Les spécifications se rédigent après le devis accepté : les écrans et les parcours détaillés (spécifications fonctionnelles), puis la base de données, l'architecture et les services externes (spécifications techniques).
Combien de pages doit faire un cahier des charges ?
Il n'y a pas de bonne longueur. Un cahier des charges de dix pages bien priorisé vaut mieux qu'un document de cinquante pages où tout a la même importance. Ce qui compte, c'est que chaque fonctionnalité soit assez précise pour être chiffrée sans deviner.
Peut-on rédiger son cahier des charges avec ChatGPT ?
C'est un bon point de départ pour ne rien oublier, mais le résultat est souvent trop fourni et sans priorités : tout y paraît indispensable. Il faut ensuite le relire, couper, et décider ce qui fait partie de la première version.
Faut-il un cahier des charges pour obtenir un devis ?
Pour un devis fiable, oui. Sans description précise, chaque prestataire imagine un projet différent, et les devis vont de 1 000 € à plus de 30 000 € pour une même idée. Avec un cahier des charges, vous comparez des propositions qui chiffrent la même chose.