Cahier des charges application web : ce qu'il contient et comment l'écrire

Le cahier des charges d’une application web est le document dans lequel vous décrivez l’outil que vous voulez faire construire : à quoi il sert, qui l’utilisera, ce qu’il doit faire, et dans quelles limites de budget et de délai. Vous l’envoyez aux prestataires avant qu’ils chiffrent, puis il sert de référence pendant tout le projet. Une application web désigne ici un outil qui s’ouvre dans un navigateur, sans installation sur les postes : un logiciel de suivi de dossiers, un espace où vos clients passent commande, un planning partagé entre plusieurs agences.

Ce document s’écrit avec vos mots, sans connaissance technique. Cet article détaille à quoi il sert, les rubriques qu’il contient, la longueur à lui donner et les erreurs qui le rendent inutilisable, puis propose une méthode en cinq étapes avec un sommaire à reprendre pour le vôtre.

À quoi sert un cahier des charges pour une application web

Le cahier des charges sert à trois moments du projet : quand vous consultez des prestataires, pendant le développement, et à la livraison, quand vous vérifiez que l’outil fait ce qui était prévu. Il a aussi une limite, qui le sépare des spécifications techniques.

Recevoir des devis comparables

Sans document commun, chaque prestataire reconstitue votre projet à partir d’un rendez-vous et chiffre sa propre version. L’un imagine trois profils d’utilisateurs, l’autre un seul. L’un prévoit la reprise de vos fichiers existants, l’autre la laisse à votre charge sans l’écrire. Les écarts de prix que vous constatez viennent alors de projets différents, et vous ne pouvez pas savoir lequel est le plus cher pour un même travail.

Avec un cahier des charges, tous les candidats répondent à la même demande. Leurs devis se comparent ligne par ligne, et un écart de prix désigne alors un poste précis, que vous pouvez faire expliquer au prestataire concerné.

Garder une référence commune pendant le projet

Pendant le développement, les demandes changent, les interlocuteurs aussi, et le souvenir de ce qui avait été convenu s’efface. Le cahier des charges fixe par écrit le périmètre de départ. Quand une nouvelle demande arrive, vous savez si elle faisait partie du projet initial ou si elle s’ajoute, avec ce que cet ajout change au prix et à la date de livraison.

Il sert encore à la fin. La vérification de ce que le prestataire livre, qu’on appelle la recette, se fait à partir de ce document : chaque fonction décrite doit exister et se comporter comme prévu. Un besoin qui n’y figure pas se réclame difficilement une fois l’outil livré.

Cahier des charges fonctionnel et spécifications techniques

Le document que vous rédigez s’appelle un cahier des charges fonctionnel, ou expression du besoin. Il décrit ce que l’outil doit faire, du point de vue de ceux qui s’en serviront, et laisse de côté la manière de le construire. Le choix du langage de programmation, de la base de données ou de l’hébergement relève des spécifications techniques, que le prestataire rédige à partir de votre document une fois le projet lancé.

Cette répartition vous protège. Si vous imposez une technologie sans raison liée à votre activité, vous écartez des prestataires compétents et vous portez seul un choix qui revient normalement au prestataire. Si votre entreprise a une contrainte réelle, par exemple un service informatique qui n’accepte qu’un type d’hébergement, elle figure dans le cahier des charges comme une contrainte, avec sa raison.

Ce que contient un cahier des charges d’application web

Les rubriques vont du contexte vers le détail. Un prestataire qui lit d’abord qui vous êtes et pourquoi vous lancez le projet comprend mieux les fonctions que vous décrivez ensuite.

Ces rubriques valent pour tout outil de gestion sur-mesure construit pour votre entreprise.

Votre entreprise, le projet et ses objectifs

Présentez votre entreprise en quelques lignes : votre activité, vos clients, votre organisation, le nombre de personnes et de sites concernés par le projet. Décrivez ensuite la façon dont le travail se fait aujourd’hui et ce qui coince : des informations saisies deux fois dans deux logiciels, un tableur que trois services modifient en même temps, des relances clients faites de mémoire, un suivi que personne ne voit en entier.

Formulez les objectifs comme des résultats que vous pourrez constater. « Moderniser notre gestion » ne donne aucune indication à un prestataire. « Qu’un commercial retrouve l’historique d’un client sans appeler l’administration » ou « que les demandes d’intervention arrivent au planning sans ressaisie » lui indiquent déjà quelles fonctions construire en priorité. Si vous connaissez vos volumes, notez-les : le nombre de dossiers traités par mois, le nombre de clients actifs, le nombre d’utilisateurs prévus.

Si votre processus tourne aujourd’hui dans un tableur, décrivez ce fichier : qui le remplit, qui le consulte, ce qu’il calcule. Notre article sur la façon de passer d’un classeur Excel partagé à une application aide à repérer ce qui, dans ce fichier, relève d’un processus à reproduire.

Les utilisateurs, leurs profils et leurs droits

Listez les personnes qui utiliseront l’outil, regroupées par profil : les commerciaux, l’administration, les techniciens sur le terrain, la direction, et vos clients ou vos partenaires s’ils doivent y accéder depuis l’extérieur. Pour chaque profil, indiquez ce qu’il fait dans l’outil, ce qu’il doit voir et ce qui doit lui rester caché. Un technicien consulte ses interventions du jour sans voir les marges. Un client voit ses propres commandes et aucune autre.

Précisez aussi les conditions dans lesquelles chaque profil travaille. Un technicien qui ouvre l’outil sur son téléphone, sur un chantier où le réseau passe mal, n’a pas les besoins d’une assistante installée devant deux écrans au bureau. Ces profils et droits d’accès pèsent dans le chiffrage, et ils se corrigent mal une fois l’outil construit.

Ce que l’outil doit faire : des règles plutôt que des écrans

Cette rubrique occupe l’essentiel du document. La tentation est de la remplir avec des écrans : une page d’accueil avec des indicateurs, un bouton pour créer un devis, une liste des clients avec un filtre. Un prestataire sait dessiner ces écrans sans votre aide. Ce qu’il ne peut pas deviner, ce sont les règles de gestion que votre entreprise applique : ce qui se passe, dans quel ordre, qui décide, et ce qui est interdit.

Comparez deux façons de décrire la même fonction. La première : « un écran de création de devis avec les champs client, produits, quantités et remise ». La seconde : « un commercial crée un devis pour un client déjà enregistré. Au-delà du taux de remise fixé par la direction, le devis part en validation chez le directeur commercial et ne peut pas être envoyé avant son accord. Un devis accepté devient une commande sans ressaisie. Un devis resté sans réponse passe en relance après le délai que vous fixez. » La seconde version dit au prestataire ce que l’outil doit contrôler, et ce sont ces contrôles qu’il devra développer et chiffrer.

Pour chaque fonction, décrivez la situation de départ, ce que fait la personne, ce que l’outil doit vérifier ou calculer, et le résultat attendu. Ajoutez les exceptions : le devis modifié après acceptation parce que le client ajoute un article, le client qui paie en plusieurs fois, la commande annulée après expédition. Ces exceptions distinguent votre fonctionnement de celui d’un logiciel standard, et vos équipes reprendront leurs anciens fichiers si l’outil ne sait pas les traiter.

Classez ensuite chaque fonction selon sa priorité : indispensable dès la mise en service, utile mais qui peut attendre, ou à étudier plus tard. Cette priorisation donne au prestataire de quoi proposer une première version réduite, mise en service plus tôt, puis des ajouts par étapes. Elle vous sert aussi le jour où le budget ne couvre pas tout, puisque vous savez déjà ce qui sort du périmètre.

Les données, les logiciels existants et les contraintes

Les logiciels avec lesquels l’application échangera des informations se listent un par un : votre logiciel de comptabilité, votre outil de facturation, votre agenda partagé, le site sur lequel vos clients passent commande. Pour chacun, précisez le sens de l’échange et son rythme. Les nouvelles commandes partent-elles vers la comptabilité à chaque validation, ou une fois par jour ? Ces liaisons ont leur propre coût, qui varie selon les échanges que chaque logiciel autorise, et notre article sur les moyens de faire communiquer deux logiciels détaille les cas possibles.

Décrivez ensuite les données à reprendre : votre fichier clients, l’historique des dossiers, vos grilles tarifaires. Dites où elles se trouvent, sous quelle forme, et dans quel état. Si votre fichier clients a été tenu pendant des années par plusieurs personnes, cherchez les doublons et les champs remplis de façons différentes : quelqu’un devra payer le temps passé à les corriger. Mieux vaut que ce poste apparaisse dans les devis, où vous pouvez le comparer, que sur une facture complémentaire.

Terminez par les contraintes : les appareils utilisés (ordinateur, téléphone, tablette), le travail sans connexion si vos équipes interviennent sur le terrain, les exigences de votre service informatique, le lieu d’hébergement des données si votre activité en impose un, et le traitement des données personnelles si l’outil conserve des informations sur vos clients, vos salariés ou vos patients. Pour ces données, notez qui doit y accéder et combien de temps vous devez les garder. Ces décisions vous reviennent, et le prestataire en tiendra compte dès la conception.

L’apparence et les maquettes

Si vous avez une charte graphique, avec un logo, des couleurs et des polices, joignez-la. Pour le reste, décrivez ce qui fait gagner du temps à vos équipes. Si certains outils que vous utilisez déjà vous plaisent, citez-les en précisant ce qui vous plaît : la lisibilité d’un tableau, la façon de filtrer une liste, un formulaire qui se remplit vite.

Vous pouvez joindre des croquis, même dessinés à la main, pour montrer l’enchaînement d’une tâche. Ils aident à comprendre votre besoin, et le prestataire les reprendra dans une maquette, une représentation des écrans sur laquelle vous pourrez cliquer avant tout développement. Inutile de passer des jours à dessiner des écrans définitifs, puisque leur conception fait partie du travail du prestataire.

Budget, calendrier et décisionnaires

Une fourchette de budget, même large, donne aux prestataires l’ampleur de la réponse attendue, et chacun vous dit alors ce qu’il peut faire pour ce montant et ce qu’il renverrait à une étape suivante. Pour situer cette fourchette, notre article sur les postes qui composent le prix d’une application de gestion détaille ce qui pèse dans un chiffrage.

Donnez la date à laquelle l’outil doit être en service, et ce qui la fixe : une saison d’activité, l’arrivée de nouveaux collaborateurs, la fin d’un abonnement à un logiciel que vous voulez quitter. Comptez aussi votre propre temps dans ce calendrier. Vos équipes participeront à des ateliers, valideront des maquettes et testeront des versions, et un retard de leur côté décale la livraison comme un retard du prestataire.

Nommez enfin les décisionnaires : la personne qui suit le projet au quotidien et répond aux questions, et celle qui tranche quand deux services demandent des choses contradictoires. Le prestataire sait alors à qui s’adresser, et chaque arbitrage n’a pas à remonter jusqu’à la direction.

Ce que vous attendez du prestataire

Précisez ce que vous voulez recevoir en plus de l’outil : une formation de vos équipes, une documentation d’utilisation, l’accès au code source et aux comptes d’hébergement. Indiquez comment vous vérifierez la livraison, c’est-à-dire quelles situations réelles vous testerez avant d’accepter chaque partie.

Prévoyez enfin l’après : qui corrige les anomalies découvertes une fois l’outil en service, qui le fait évoluer quand votre activité change, et à quelles conditions. Ces conditions forment la maintenance, qui se chiffre avec le projet.

Quelle longueur donner au cahier des charges

La longueur dépend de la taille du projet et de ce que vous savez déjà. Pour un outil qui remplace un tableur partagé par une équipe, quelques pages bien remplies suffisent : le contexte, les profils, les règles de gestion principales avec leurs exceptions, les logiciels à relier, le budget et la date. Pour une application qui touche plusieurs services, échange avec plusieurs logiciels et s’ouvre à vos clients, le document s’allonge, et c’est la partie des règles de gestion qui grossit.

Trop de détail crée un autre problème. Un cahier des charges qui décrit chaque bouton de chaque écran fige des choix avant que quiconque ait vu une maquette, et un prestataire qui reçoit un tel document risque de le survoler. Visez un texte que chaque candidat lira en entier et dont chaque paragraphe lui apprend quelque chose sur votre fonctionnement.

La longueur dépend aussi de la façon de travailler que vous envisagez. Certains prestataires développent l’outil en une fois à partir d’un document figé, puis vous le livrent. D’autres le construisent par étapes courtes, vous montrent à la fin de chacune une partie qui fonctionne, et ajustent la suite avec vous. Dans le second cas, le cahier des charges fixe les objectifs, les profils, les règles essentielles et les priorités, et le détail se précise étape par étape.

Les erreurs qui rendent un cahier des charges inutilisable

Un cahier des charges peut être bien présenté et produire quand même des devis qui ne répondent pas à votre besoin. Quatre défauts de rédaction produisent ce décalage.

Décrire la solution au lieu du besoin

« Un bouton pour exporter la liste des commandes dans Excel » décrit une solution. Le besoin derrière peut être tout autre : la comptable doit rapprocher les commandes des paiements chaque fin de mois, et elle le fait aujourd’hui dans un tableur faute de mieux. Décrit ainsi, le besoin appelle une autre réponse, un rapprochement fait par l’outil lui-même par exemple, que le prestataire ne proposera pas si vous lui demandez un bouton. Pour chaque fonction que vous avez en tête, cherchez le problème qu’elle règle, et écrivez ce problème.

Rester vague là où le prix se joue

« Gestion des clients », « suivi des commandes », « tableau de bord » : ces intitulés tiennent sur une ligne et recouvrent des outils de tailles très différentes selon ce que chaque prestataire imagine derrière. Un tableau de bord peut afficher trois chiffres tirés de l’outil, ou croiser les données de plusieurs logiciels avec des alertes adaptées à chaque profil. Faites suivre chaque intitulé de ce qu’il contient : quelles informations, pour qui, mises à jour à quel moment.

Écrire sans ceux qui utiliseront l’outil

Un cahier des charges rédigé par la direction seule décrit le processus tel qu’il a été prévu. Les personnes qui font le travail connaissent le processus tel qu’il se déroule, avec ses raccourcis, ses cas particuliers et les informations qu’elles vont chercher ailleurs. Un outil construit sur la première version les oblige à chercher ces informations hors de l’outil, et vos équipes le contourneront dès les premières semaines.

S’arrêter à la mise en service

Un cahier des charges qui s’arrête à la livraison laisse hors des devis des dépenses que vous aurez de toute façon : les corrections des premières semaines, les évolutions demandées par vos équipes une fois l’outil en main, les mises à jour de sécurité, l’hébergement. Vous comparez alors des prix de livraison, et le coût de l’outil une fois en service ne se découvre qu’aux premières factures.

Rédiger votre cahier des charges en cinq étapes

Le cahier des charges se rédige en interne, par la personne qui connaît le mieux le processus concerné, avec l’aide des futurs utilisateurs. Entre la première réunion et l’envoi aux prestataires, prévoyez le temps de réunir les informations, puis de faire relire le document.

Première étape, décrivez la situation actuelle avec ceux qui font le travail. Rassemblez les fichiers, les formulaires et les logiciels utilisés aujourd’hui pour ce processus, puis passez une demi-journée avec une ou deux personnes de chaque profil à dérouler des dossiers récents de bout en bout. Notez chaque endroit où une information est ressaisie, attendue ou perdue, et chaque cas qui sort du chemin prévu.

Deuxième étape, faites trancher les objectifs et les profils par la direction. Ce que l’outil doit changer et qui y aura accès fixent le périmètre, et ces deux décisions ne se délèguent pas à la personne qui tient la plume.

Troisième étape, écrivez les règles de gestion, fonction par fonction, en partant des dossiers déroulés à la première étape. C’est l’étape la plus longue. Faites-la relire par les personnes rencontrées au départ : elles repèrent les cas oubliés et confirment que le document décrit leur travail réel.

Quatrième étape, arbitrez les priorités. Pour chaque fonction, demandez ce que vos équipes feraient si elle manquait au démarrage. Une fonction sans laquelle le travail s’arrête est indispensable, les autres peuvent attendre une version suivante. Fixez ensuite votre budget, sous forme de fourchette, et la date de mise en service.

Cinquième étape, faites relire par un regard extérieur. Donnez le document à une personne de l’entreprise qui ne connaît pas le processus. Chaque question qu’elle vous pose signale un passage qu’un prestataire comprendra mal.

Voici un sommaire que vous pouvez reprendre pour votre document :

• Présentation de l’entreprise et du projet
• Situation actuelle et difficultés rencontrées
• Objectifs et volumes
• Utilisateurs, profils et droits d’accès
• Fonctions et règles de gestion, avec leurs exceptions et leur priorité
• Logiciels à relier et données à reprendre
• Contraintes : appareils, travail sur le terrain, hébergement et données personnelles, exigences informatiques internes
• Apparence : charte graphique, exemples d’outils, croquis
• Attentes vis-à-vis du prestataire : formation, documentation, vérification de la livraison, maintenance
• Budget, calendrier et décisionnaires
• Déroulé de la consultation : date limite de réponse et contenu attendu dans les propositions

La dernière rubrique facilite votre comparaison. Demandez à chaque prestataire de chiffrer séparément la première version, chaque fonction secondaire et la maintenance sur une année, et vous obtiendrez des réponses que vous pourrez mettre côte à côte.

Après le cahier des charges, consulter et choisir

Envoyez le même document à trois ou quatre prestataires, avec une date de réponse. Les réponses utiles reformulent votre besoin avec leurs propres mots, posent des questions sur les règles que vous avez décrites, et proposent un découpage en étapes avec un prix pour chacune. Une réponse qui recopie votre document et y ajoute un montant global vous apprend peu de choses sur la façon dont le projet se déroulera.

Votre cahier des charges peut aussi montrer qu’un logiciel existant, bien paramétré, couvre l’essentiel de vos règles. Dans ce cas, la comparaison entre un outil développé pour vous et une licence d’éditeur vous aide à trancher sur des critères précis avant de lancer un développement.

Si vos règles de gestion n’entrent dans aucun produit du marché, c’est le type de projet que nous prenons en charge : une application web métier construite autour de vos processus, ouverte dans le navigateur, avec les profils, les validations et les liaisons que votre cahier des charges décrit. Vous pouvez nous adresser votre document en l’état, même s’il reste des rubriques à compléter. Si personne dans votre entreprise n’a le temps de le rédiger, nous pouvons l’écrire avec vous au cours d’un atelier de cadrage, facturé à part et mené avant le devis de développement.