Comment rédiger un cahier des charges efficace pour votre application ?

Vous projetez une application web. On sent à peu près ce que vous avez en tête. Mais à l'heure de la transmettre à un prestataire, la complétude se révèle nébuleuse : trop de détails, pas assez, les mauvaises priorités. Sans cahier des charges, votre projet fait pschitt, et souvent n'arrive nulle part.

Il semblerait qu'un projet sur dix seulement arrive à finaliser un produit. Les neuf autres ? Un cadrage à la fois inexistant parfois, et en tout cas bâclé systématiquement. Pas forcément un document de 50 pages, ou presque vierge, mais au moins une vision du chantier, de ce que l'on construit, pour qui, et dans quel ordre.

Quel est donc le rôle d'un cahier des charges ?

Le cahier des charges décrit ce que devra réaliser votre application. Pas comment elle sera codée, c'est le travail du prestataire. Mais ce qu'elle devra permettre, en direction de qui, dans quel contexte etc.

Avant de vous lancer, votre interlocuteur vous obligera à formuler vos idées à l'écrit. Tant que vous gardez votre projet dans votre tête, tout vous semble évident. Le jour où vous devez commencer à l'écrire, des zones de flou apparaissent. C'est normal. C'est tout l'intérêt de l'exercice.

C'est par ailleurs la référence commune entre vous et votre prestataire. Au cours du développement, s'il y a un désaccord, le cahier des charges tranche. "C'était prévu" ou "ça ne l'était pas", écrit noir sur blanc.

Et avec un document structuré, vous obtiendrez des devis équivalents. En envoyant une description floue à trois prestataires, vous recevrez trois propositions incommensurables. Avec un cahier des charges construit, vous aurez des réponses précises et des prix fiables.

Version 0, MVP : on parle de quoi ?

Avant d'aborder le contenu du cahier des charges, clarifions deux termes que l'on utilise souvent.

La version 0, c'est votre prototype. Son but n'est pas de faire illusion, c'est un projet de brouillon fonctionnel, il montre l'idée sans être un produit final. C'est une maquette cliquable, un tableur Excel qui simule les flux, un prototype bricolé avec un outil no-code. L'idée est de valider cela avec quelques utilisateurs afin de les amener à se prononcer sur le concept avant d'investir dans le développement.

Le MVP (Minimum Viable Product, produit minimum viable) est une première version de l'application, c'est la version qui ira en production. Et le mot clé est « viable » ! Ce n'est pas une version de bricoleur, c'est la version minimale, la plus simple qui amène véritablement de la valeur à vos utilisateurs. Beaucoup de porteurs de projet confondent MVP avec produit négligé. Un MVP que l'on prend soin de penser, c'est un produit entier, mais sur une portée réduite.

Le cahier des charges permet de définir ce périmètre. Qu'est-ce qui appartient au MVP ? Qu'est-ce qui attend la version 2 ? Sans ce tri, on part sur un projet trop large, trop cher, trop long, et avec des chances de ne jamais sortir.

L'IA pour établir votre version 0

Aujourd'hui, la combinaison d'outils comme ChatGPT ou Claude et d'un monde no-code permet d'élaborer une version 0 sans avoir à coder et générant des maquettes, des parcours utilisateurs ou un prototype qui fonctionne à la marge.

C'est un vrai gain de temps pour tester l'idée, valider le concept, retravailler les fonctionnalités avant de montrer le tout aux utilisateurs et ce, avant de débourser le moindre euro dans le développement.

Cela dit, on est d'accord que la version 0 n'est pas un produit. Le code fourni par l'IA est structuré pour une première version mais ne suit pas une structure permettant d'évoluer, du coup chaque changement se paye et casse de l'existant. On connaît suffisamment de dirigeants arrivant avec un prototype IA convenablement opérationnel mais fragile et tous se posent la question : comment passer au produit réel ? Si vous êtes dans ce cas, vous pouvez lire notre article sur la suite à donner.

Le cahier des charges vient alors en jeu. Votre version 0 a fait passer l'idée de test : il va maintenant donc falloir formuler le besoin pour réaliser un vrai MVP solide.

Quand rédiger le cahier des charges ?

Ne commencez pas trop tôt ! Si votre idée de projet n'est pas encore mûre, le document va vivre au fil des saisies. Feedbacks avec votre partenaire, pertes de temps, frustrations des deux côtés.

Rédigez-le lorsque vous êtes sûr de votre concept à 80 %. Connaît-on vraiment sa cible ? A-t-on une vision précise des fonctionnalités principales du produit ? Pensez-vous avoir budgété ce projet ? Les détails viendront plus tard, en mode co-créatif de votre produit avec le bon partenaire.

En revanche, si vous êtes au stade de l'idée seulement, restez encore un peu dans le travail de cadrage : échanges avec vos futurs utilisateurs, benchmarking des solutions existantes, estimation à la louche de votre enveloppe. Ou bien construisez dès maintenant une version 0 pour mieux matérialiser votre vision, le cahier des charges viendra après.

Éléments de base

Pas besoin d'un pavé de 50 pages. Un bon cahier des charges doit être court et concis. Quel contenu doit-il comporter ?

Présentation du projet

En quelques paragraphes, présentez de quoi il s'agit et pourquoi c'est à la fois important et urgent. Quel problème votre appli web a le mérite de résoudre ? Quelle nécessité aborde-t-elle ? Votre prestataire doit bien comprendre le contexte de votre activité pour être en mesure de vous proposer la bonne solution.

Si vous avez déjà un outil en place (fichier Excel, logiciel plus que vieillissant, processus 100 % manuel), décrivez-le. Ce qui ne va plus, ce qui n'est plus satisfaisant doit être mis en avant. Si vous avez construit un MVP, montrez-le. C'est bien sûr plus parlant qu'un document rébarbatif. Un prestataire qui comprend d'où vous partez construira mieux ce vers quoi vous allez.

Vos utilisateurs

Qui va utiliser votre appli au final ? Vous seul, dit-on derrière votre bureau ? Vos clients, depuis leur portable ? Il est essentiel de se poser cette question même pour une micro-structure, puisque l'artisan a certes besoin d'un outil de prise de rendez-vous, qui impliquerait 2 types d'utilisateurs, lui (qui gère le planning) et ses clients (qui réservent un créneau), le consultant avec un portail client aura aussi besoin d'un espace pour lui, un espace pour ses clients... Qui fait quoi, s'il y a beaucoup de monde ?

Si votre projet prévoit un volet mobile (ce qui va de soi ayant à travailler en déplacements par exemple), précisez quel profil utilise quel support, si vous hésitez entre web et mobile, les critères de choix ont été détaillés dans un article à cet effet.

Les fonctionnalités, c'est ce qui constitue le noyau du MVP

C'est la partie la plus significative de la phase de définition. Faites le tri entre ce que vous voulez faire tout de suite et ce que vous pouvez décaler dans le temps. Divisez vos fonctionnalités en 2 colonnes :

Ce choix pèsera sur le budget et les délais. Si développer tout fait exploser la dépense, vous saurez quoi reporter sans remettre en cause l'ensemble du projet. Mieux vaut faire 3 fonctionnalités bien que 10 mal.

L'arborescence et les maquettes

Énumérez les écrans ou pages principales de votre application web : accueil, connexion, dashboard, fiche détail, page de paramètres... Bien que peu précise, cette arborescence permet à votre prestataire d'évaluer le volume de travail à effectuer.

Si vous le pouvez, faites aussi des wireframes. Un croquis sur papier, ou un schéma PowerPoint suffisent. L'objectif n'est pas de parvenir à un design finalisé, mais simplment de représenter la localisation des différents éléments présents sur chaque écran. Où se trouve le menu ? Comment passe-t-on d'une partie à l'autre ? Quel est le parcours type d'un utilisateur ?

Ne figez pas trop le design à ce stade. Laissez quelques marges de créativité à l'équipe qui conçoit l'interface. Un cahier des charges trop rigide en termes visuels bridera la créativité, et parfois la solution retenue est moins bonne que celles qu'aurait proposées un designer libre.

L'identité visuelle

Communiquez votre logo, la charte graphique (Couleurs, polices), et si vous le pouvez, une liste d'applications que vous jugez bien designées. Pas en termes de fonctionnalités, mais seulement d'esthétique. Cela permettra aux designers d'orienter leur réflexion dans le bon sens.

Si vous n'avez pas encore établi de charte graphique, qu'il soit dit, ce chantier est à part, il peut être intégré au projet ou mené à bien en amont, au choix.

Les contraintes techniques

Votre cahier des charges devra répondre à ces questions : par rapport aux données : avez-vous un fichier Excel, un tableur ou un logiciel existant de qui il faudra reprendre les informations ? Utilisez-vous déjà un outil de facturation ou de comptabilité sur quoi l'application devra se connecter ? Par rapport à l'accès : l'application sera-t-elle utilisée uniquement depuis votre bureau ou aussi sur vos lieux de déplacement ? Faut-il qu'elle fonctionne sans connexion internet ? Par rapport aux langues : l'application sera-t-elle en français (uniquement) ou sera-t-il utile qu'elle soit mise en d'autres langues ?

Si votre projet comporte un volet application mobile (iOS, Android, les deux), indiquez-le. Pensez aux modèles économiques : si votre app mobile est gratuite mais propose des achats intégrés ou lorsque les ventes de produits physiques sont en cause, n'oubliez pas que les commissions des stores qui en sont les vecteurs sont lourdes, jusqu'à 30 % chez Apple. C'est une donnée à confier d'emblée.

Le budget et le planning

Donnez des ordres de grandeurs, même approximatifs. De toute façon, le prestataire n'est pas tenu de chiffrer au maximum, cela lui sert à calibrer sa proposition. En l'absence de budget, on ne saura s'il faut proposer formule 1 ou citadine.

Précisez vos contraintes calendrier. Lancement en lien avec un salon professionnel, une saison commerciale, un partenariat : tout ce qui impose un calendrier doit figurer dans le document. C'est aussi là que la logique MVP a toute sa place : dans un calendrier serré, il vaut mieux livrer une version fonctionnelle mais limitée, qu'attendre indéfiniment une version complète.

Pour vous donner une idée des ordres de grandeurs, posez-vous la question, c'est le sujet de notre article le prix d'un site internet. Mais pour une application web sur mesure, ce ne sont pas les mêmes montants, mais la logique budgétaire est équivalente.

Les erreurs à bannir dans un projet

Être vague. « Je veux une application moderne et intuitive » ne veut rien dire. Soyez explicite : qui fait quoi, dans quel ordre, avec quelles données.

Être trop technicien. Ne choisissez pas les technologies vous-même. Vous décrivez le besoin, le prestataire propose la solution. C'est son métier.

Oublier les utilisateurs. Un cahier des charges orienté sur les fonctionnalités mais qui ne parle pas des gens à qui il est destiné, c'est comme un GPS qui ne demande pas de destination.

Confondre MVP et produit low cost. Le MVP n'est pas une excuse pour livrer un truc bancal. C'est un choix stratégique : faire moins, mais le faire bien. On a accompagné des indépendants et des petites structures en commençant avec un outil simple, puis, au fur et à mesure, en ajoutant des fonctionnalités au besoin et au fur et à mesure que le budget s'y prêtait.

Questions fréquentes

Faut-il obligatoirement un cahier des charges pour lancer un projet ? La législation ne vous y oblige pas. Mais sans cadrage écrit, les malentendus s'accumulent. Le prestataire interprète, vous êtes en désaccord, les délais glissent. Mieux vaut un dossier court de 5 pages que pas de dossier.

Combien de pages doit-il faire ? Entre 5 et 20 pages dans la majorité des cas. L'important est la clarté. Un pavé de cinquante pages qui n'est pas lu n'est d'aucune utilité.

Ma version 0 faite avec l'IA remplace-t-elle le cahier des charges ? Elle le complète, elle ne peut le remplacer. Votre prototype montre ce que vous voulez, c'est un excellent point de départ. Mais le prestataire a besoin d'un document qui pose les priorités, les contraintes et le périmètre du MVP. On en parle plus en détail ici.

Puis-je le rédiger seul ou faut-il obligatoirement se faire accompagner ? Si vous réalisez un premier exercice dans ce genre, n'hésitez pas à vous faire aider par un prestataire. Un consultant expérimenté peut bien s'acquitter de la mission d'aider au cadrage ou de la réaliser avec vous. Chez Ecma-Tech, à Brest, nous accompagnons régulièrement nos clients dans cette phase de cadrage, qui n'intervient qu'au tout début du projet, bien avant même d'avoir commencé la première ligne de code.

Le cahier des charges est-il verrouillé une fois validé ? Non. Il sert bien de point de départ au projet, non d'un contrat figé une bonne fois pour toutes. Un bon projet évolue. L'important est de suivre les évolutions, et de les documenter dans le tableau de suivi de ce qui respecte bien entendu l'équilibre budgétaire et temporel du projet.

Lexique

Quelques termes que vous trouverez dans cet article et que vous aurez souvent l'occasion de croiser avec un prestataire au travail.

MVP (Minimum Viable Product) : la première version de votre application mise en production. Elle n'intègre que les fonctionnalités indispensables, celles qui sont incontournables pour que le produit ait du sens. L'idée est de sortir vite, avec de vrais utilisateurs, pour pouvoir améliorer par la suite.

Version 0 / Prototype : un brouillon de votre application, avant le vrai développement. Ça peut être une maquette, un PowerPoint interactif ou un outil bricolé à l'IA qui permet de rendre concrète l'idée, pour la confronter à des retours réels.

Wireframe : un cahier de charges simplifié de l'écran de votre application. Pas de couleurs, pas de design, juste la position des éléments (menus, boutons, zones de texte), comme le plan de l'architecte avant le début des travaux.

No-code : des outils permettant de développer des applications ou des sites, sans avoir à écrire de code. Très utiles pour faire un prototype rapidement, mais très limités pour réaliser un produit sur mesure.

Arborescence : la liste de toutes les pages ou écrans de votre application et des liens existants entre eux. C'est la carte de l'interface de votre produit.

Charte graphique : l'ensemble des règles visuelles de votre marque : logo, couleurs, typographies. Si vous disposez déjà d'un site internet ou de vos propres supports de communication, vous avez sans doute une charte même informelle.

Passez à l'action

Un bon cahier des charges, c'est ce qui procurera à votre MVP la réussite, si tant est qu'on ait soigneusement pris le temps de poser ses idées, de trier les fonctionnalités, de définir le périmètre de sa première version. Le reste viendra par itérations.

Vous avez un projet d'application web et vous ne savez pas par quel bout prendre les choses ? Parlons-en. Nous pouvons vous aider à structurer votre cahier des charges et à définir votre MVP.