Cahier des charges d’application : le modèle en 8 rubriques qui évite les malentendus

Les projets d’application qui tournent mal ont presque toujours le même point de départ :
un malentendu que personne n’a écrit. Le client pensait « évidemment que la facturation est
incluse », le prestataire avait chiffré sans. Rappel des statistiques du secteur : environ
70 % des projets dépassent budget ou délais, et 43 % de ces dépassements viennent
d’ajouts de périmètre en cours de route (Clutch). Le cahier des charges est le vaccin — à condition
d’en faire un document de compréhension, pas un roman technique. Voici la trame en
8 rubriques que nous demandons (ou co-écrivons) avant tout chiffrage : 10 à 15 pages
suffisent.

Ce qu’un cahier des charges n’est PAS

• →Pas un document technique : vous n’avez pas à choisir le langage ou la base de données — c’est le métier du prestataire, et un CdC qui impose la technique sans raison ferme des options.
• →Pas une liste de fonctionnalités au kilomètre : « le logiciel devra permettre de… » x 200 lignes, sans priorités, produit des devis énormes et des projets informes.
• →Pas un document figé : c’est la référence qui permet justement de discuter les changements — « c’est hors périmètre V1, on le chiffre pour la V2 » est une phrase saine, pas un conflit.

Les 8 rubriques, dans l’ordre

1. Le problème — une page, chiffrée

« Aujourd’hui, la planification des interventions se fait sur trois fichiers Excel, deux
personnes y passent 6 heures par semaine, et on estime deux erreurs de planning par mois à
X € chacune. » Cette page est la plus importante du document : elle permet au
prestataire de proposer parfois plus simple que ce que vous imaginiez, et elle donne l’étalon du
retour sur investissement.

2. Les utilisateurs — qui, combien, où

Trois techniciens sur chantier avec des gants et un réseau incertain, ce n’est pas le même
produit que quinze administratifs sur double écran. Précisez : rôles, effectifs, appareils,
contexte d’usage (bureau, terrain, hors-ligne ?), niveau d’aisance numérique. Une ligne par
profil suffit.

3. Les parcours clés — racontez, ne listez pas

C’est notre rubrique préférée, et la plus discriminante : 5 à 10 scénarios racontés comme
des histoires. « Julie reçoit une demande par téléphone. Elle ouvre l’appli, crée la fiche,
voit les disponibilités de l’équipe, propose un créneau. Le client reçoit un SMS de
confirmation. » Un scénario de dix lignes contient plus d’information utile — et lève plus de
malentendus — que trois pages de « le système devra permettre ». C’est sur ces récits que
se détectent les cas particuliers : et si le client annule ? et si deux personnes
modifient en même temps ?

4. Le périmètre V1 / V2 — la rubrique anti-dérapage

Deux colonnes. V1 : ce sans quoi l’application ne sert à rien.
V2 : tout le reste, explicitement listé pour montrer qu’il n’est pas oublié —
juste reporté. Cette rubrique est celle qui neutralise le « tant qu’on y est », première
cause de dépassement. Règle de tri impitoyable : si l’application est utilisable et utile sans
la fonctionnalité, c’est de la V2. C’est toute la logique MVP défendue dans
notre méthode en 6 étapes.

5. L’existant — outils, données, intégrations

• Les outils en place (CRM, ERP, comptabilité, agendas) et lesquels doivent être connectés — les intégrations sont le poste le plus sous-estimé des chiffrages.
• Les données à reprendre : le fichier clients historique, dans quel état, avec combien de doublons (soyez honnête : tout le monde a des doublons).
• Les exports attendus : comptabilité, Excel, PDF — souvent découverts « en urgence » au moment de la première clôture mensuelle.

6. Les contraintes — le non-négociable

Données personnelles ou de santé (RGPD, hébergement), fonctionnement hors-ligne, volumes
(10 utilisateurs ou 10 000 ?), échéance impérative (salon, saison haute, fin de contrat de
l’outil actuel). Chaque contrainte tue ou valide des options techniques : mieux vaut les poser
au chiffrage qu’au mois 4.

7. Les critères d’acceptation — comment on saura que c’est réussi

Concrets et testables : « une intervention se planifie en moins de 2 minutes »,
« le technicien consulte sa tournée sans réseau », « l’export comptable est importé
sans retraitement ». Ces critères deviennent le protocole de recette de fin de projet — et
évitent le flou du « ce n’est pas ce qu’on attendait » sans qu’on sache ce qui était
attendu.

8. Budget et propriété — les deux lignes que tout le monde esquive

Donnez votre enveloppe. La peur classique — « si je donne mon budget, le
devis le remplira » — se trompe de risque : sans enveloppe, vous recevez des propositions
de 8 000 à 120 000 € impossibles à comparer, car chacune devine un projet différent.
Une enveloppe permet au prestataire sérieux de dire ce qui rentre dedans et ce qui n’y rentre pas —
les repères de prix sont dans
notre article sur les coûts. Et
écrivez noir sur blanc : le code et les données appartiennent au client, avec
restitution possible à tout moment. Deux lignes qui valent de l’or au premier désaccord.

Sources : Clutch (43 % des dépassements liés aux ajouts de périmètre) ;
études sectorielles sur les dépassements de projets logiciels (~70 %) ; trame et retours
de cadrage : projets EVICO.