Cahier des charges d'application métier : la version courte qui suffit, avec un modèle

Une PME veut remplacer le tableur partagé qui sert à suivre ses chantiers. Elle demande trois devis. Pour les obtenir, quelqu'un passe trois semaines à écrire un document de quarante pages : contexte, organigramme, cent vingt fonctionnalités numérotées, exigences techniques recopiées d'un modèle trouvé en ligne. Les trois prestataires répondent avec trois prix qui vont du simple au quadruple. Personne ne sait lesquels comparer, parce que personne n'a compris le même document.

Le cahier des charges d'une application métier n'a pas besoin de ressembler à ça. Quand le développement avance en sprints d'une semaine, avec une version utilisable à la fin de chacun, le document de départ n'a qu'un rôle : faire en sorte que le premier sprint construise la bonne chose. Deux pages y suffisent, à condition qu'elles contiennent les bonnes informations. Ce guide donne les sept rubriques qui comptent, un modèle à recopier, et ce qu'il vaut mieux laisser ouvert.

Pourquoi le cahier des charges exhaustif ne protège plus

Le cahier des charges long vient d'une époque où développer coûtait cher et où chaque changement en cours de route se payait en avenant. Il fallait tout prévoir, parce que corriger revenait plus cher que prévoir. Le document servait de contrat : ce qui y figurait était dû, ce qui n'y figurait pas se renégociait.

Deux choses ont changé.

D'abord, le coût d'un écran. Avec des agents de code comme Claude Code, une équipe qui sait cadrer son travail produit une première version fonctionnelle en quelques jours, pas en quelques mois. Montrer un écran à un utilisateur et le refaire le lendemain coûte moins cher que débattre trois semaines de sa description. Le document n'a plus à anticiper toutes les réponses : la version suivante les apportera.

Ensuite, la liste de fonctionnalités ne dit presque rien. « L'utilisateur peut exporter les données » tient en une ligne et peut représenter une heure ou trois semaines de travail selon le format, les filtres, les droits, le volume. Cent vingt lignes de ce genre donnent une impression de précision. Elles laissent en réalité toutes les vraies décisions au développeur, qui les prendra sans vous.

Le cahier des charges court ne cherche pas à être complet. Il cherche à être juste sur ce qui coûte cher à changer plus tard : le problème, les utilisateurs, les données, les règles métier, les outils à brancher. Le reste se décide écran par écran, avec ceux qui s'en serviront.

Les sept rubriques d'un cahier des charges d'application métier

1. Le problème, en trois phrases

Pas la solution : le problème. « Les demandes d'intervention arrivent par e-mail, téléphone et WhatsApp, elles sont recopiées à la main dans un tableur, et plusieurs se perdent chaque mois. » Une phrase sur la situation, une sur ce qu'elle coûte, une sur ce qui doit changer.

Si vous n'arrivez pas à l'écrire en trois phrases, le projet n'est pas mûr. C'est le meilleur test de toute la liste.

2. Les utilisateurs et ce qu'ils font

Qui ouvrira l'application, et pour quoi faire. Un tableau suffit : un rôle par ligne, ce qu'il doit pouvoir voir, ce qu'il doit pouvoir modifier, combien de personnes l'occupent.

« Technicien terrain : voit ses interventions du jour, saisit le compte rendu depuis son téléphone, une quinzaine de personnes. » Cette ligne dit au développeur qu'il faut une version mobile, des droits par utilisateur et une saisie rapide. Elle en dit plus qu'une page d'exigences techniques.

3. Le parcours principal, de bout en bout

Décrivez le chemin que suit l'objet central de l'application, du moment où il naît à celui où il est clos. Une demande d'intervention est reçue, qualifiée, planifiée, réalisée, facturée. Un dossier client est ouvert, complété, validé, archivé.

Écrivez-le en étapes numérotées, avec pour chacune qui agit et ce qui change. Cinq à dix étapes. C'est ce parcours que le premier sprint doit rendre utilisable, même dans une version dépouillée.

Si votre process n'est écrit nulle part, commencez par là. Une procédure qu'on n'a jamais formalisée ne se développe pas mieux qu'elle ne s'automatise : notre guide pour standardiser vos SOPs donne la méthode.

4. Les données

Quelles informations l'application stocke, et d'où elles viennent. Listez les objets (client, chantier, intervention, devis), leurs champs importants, et pour chacun la source de vérité : est-ce l'application qui fait foi, ou un outil existant ?

Joignez un export réel du tableur ou du fichier actuel, anonymisé si besoin. Dix vraies lignes renseignent mieux qu'une description : elles montrent les cas tordus, les champs mal remplis, les colonnes ajoutées au fil des ans. Indiquez aussi si l'application manipule des données personnelles, et lesquelles. Ça conditionne l'hébergement et les droits d'accès dès le départ.

5. Les outils à brancher

Le CRM, le logiciel de facturation, l'agenda, la messagerie, l'outil comptable : tout ce avec quoi l'application doit échanger. Pour chacun, le sens de l'échange (lire, écrire, les deux) et la fréquence (en continu, une fois par jour, à la demande).

C'est la rubrique la plus souvent oubliée, et celle qui fait le plus varier un chiffrage. Un outil qui expose une API documentée se branche vite. Un logiciel ancien qui n'exporte qu'un fichier par jour demande un montage à part. Le prestataire doit le savoir avant de vous répondre.

6. Les règles métier

Ce que l'application doit calculer, interdire ou vérifier. « Une intervention ne peut pas être facturée sans compte rendu signé. » « Au-delà d'un certain montant, le devis part en validation chez le gérant. » « Un client en retard de paiement ne reçoit pas de nouvelle intervention sans accord. »

Ces règles vivent aujourd'hui dans la tête de vos équipes. Ce sont elles qui font qu'un logiciel générique ne vous convient pas, et ce sont elles qu'un développeur ne peut pas deviner. Notez-les toutes, même celles qui vous semblent évidentes.

7. Le hors périmètre et le critère de réussite

Une liste courte de ce que la première version ne fera pas. « Pas d'espace client. Pas de gestion des stocks. Pas de reprise de l'historique antérieur à l'an dernier. » Cette liste protège le budget plus sûrement que n'importe quelle clause.

Et une seule phrase pour dire comment vous saurez que le projet a réussi. Un chiffre de votre activité : le nombre de demandes perdues, le délai entre l'intervention et la facture, les heures de ressaisie par semaine. Pas un nombre d'écrans livrés.

Le modèle de cahier des charges à recopier

Les crochets sont à remplacer. Si une rubrique déborde d'une demi-page, elle contient probablement des détails qui se décideront en sprint.

Cahier des charges — [Nom du projet] — version du [date]

Contact projet : [Nom], qui tranche les questions sous 48 h.

1. Le problème. Aujourd'hui, [situation]. Cela coûte [temps, erreurs, argent]. Nous voulons [résultat].

2. Les utilisateurs.

3. Le parcours principal.

1. [Étape] — [qui agit] — [ce qui change]
2. …

4. Les données. Objets : [liste]. Source de vérité pour chacun : [l'application ou tel outil existant]. Données personnelles : [oui ou non, lesquelles]. Export du fichier actuel en pièce jointe.

5. Les outils à brancher. [Outil] — [lecture, écriture ou les deux] — [fréquence]. API disponible : [oui, non, je ne sais pas].

6. Les règles métier.

• [Règle 1]
• [Règle 2]

7. Hors périmètre de la première version. [Liste]. Critère de réussite : [un chiffre, et sa valeur actuelle].

Contraintes. Date à tenir et pourquoi. Appareils utilisés sur le terrain. Hébergement imposé, le cas échéant.

Ce modèle tient sur deux pages. « Je ne sais pas » est une réponse acceptable dans la rubrique outils : mieux vaut un trou signalé qu'une supposition qui fausse le chiffrage.

Rédiger un cahier des charges en une semaine

Le piège n'est pas la rédaction, c'est le tour de table qui ne finit jamais. Voici un déroulé qui tient en cinq jours ouvrés, pour une personne qui y consacre quelques heures par jour.

Jour 1 — le problème et le critère. Écrivez les rubriques 1 et 7 seul, puis faites-les valider par le dirigeant. Si vous n'êtes pas d'accord sur le problème, rien de ce qui suit ne tiendra.

Jour 2 — une heure avec chaque type d'utilisateur. Ne demandez pas « de quoi avez-vous besoin ? ». Demandez qu'on vous montre comment on fait aujourd'hui, à l'écran. Notez chaque contournement : le fichier en double, le post-it, le message envoyé pour vérifier une info. Chacun cache une règle métier ou une donnée qui manque.

Jour 3 — le parcours et les règles. Écrivez les rubriques 3 et 6 à partir de ces entretiens. Faites relire le parcours par la personne qui le pratique le plus.

Jour 4 — les données et les outils. Exportez le fichier actuel, listez les outils. Demandez à chaque éditeur concerné, ou à votre prestataire informatique, si une API existe. C'est souvent la question qui débloque le plus de chiffrages.

Jour 5 — le hors périmètre. Relisez tout, et rayez. Chaque fonctionnalité qui n'est pas indispensable au parcours principal passe dans la liste « pas dans la première version ». Elle n'est pas abandonnée : elle attend un sprint.

Ce que le cahier des charges ne doit pas figer

Un cahier des charges court fonctionne parce qu'il laisse des décisions ouvertes. Trois choses, en particulier, gagnent à se décider plus tard.

Les écrans. Décrire une interface en mots produit des débats sans fin et un résultat qui ne plaît à personne. Mieux vaut une première version cliquable au bout du premier sprint, testée par deux utilisateurs, puis corrigée. Si vous avez des captures d'outils dont l'ergonomie vous plaît, joignez-les : elles valent mieux qu'une description.

La technologie. Sauf contrainte réelle, comme un hébergement imposé par un client ou une politique interne, laissez le choix de la stack au prestataire et demandez-lui de le justifier. Exiger un langage ou un framework parce qu'on l'a lu quelque part ferme des options sans rien garantir. Exigez en revanche que le code, le dépôt et les accès vous appartiennent.

L'ordre des fonctionnalités secondaires. Il se décide après la première mise en main. Ce que les utilisateurs réclament au bout d'une semaine d'usage est rarement ce qu'ils avaient cité en entretien.

Du cahier des charges au premier sprint

Avec ce document, un prestataire sérieux doit pouvoir vous répondre en quelques jours, avec une estimation par lots plutôt qu'un prix global, et vous dire ce que contiendra la première semaine de développement. S'il propose d'abord un long cadrage payant pour réécrire votre cahier des charges, demandez-lui ce qui manque précisément au vôtre. Sa réponse vous dira s'il l'a lu.

La suite se joue en sprints. À la fin de chacun, une version en ligne, testée par les utilisateurs, et une liste de ce qui change pour le suivant. Le cahier des charges devient alors un document vivant : on le met à jour quand une règle métier se précise, on n'y ajoute pas tout ce qui a été discuté. Les détails vivent dans le code et dans l'outil de suivi des tâches.

C'est ainsi que nous développons une application métier sur mesure : un premier échange sur ce document, puis une version utilisable chaque semaine, construite avec Claude Code et relue par un développeur avant chaque mise en ligne. Pour comparer les prestataires, les questions de notre guide pour choisir son agence IA s'appliquent tout autant à un développement d'application.

Les erreurs qui coûtent le plus cher

Copier un modèle générique. Les modèles de quarante pages trouvés en ligne font remplir des rubriques qui ne vous concernent pas, et passer à côté de vos règles métier, qui n'y figurent pas.

Écrire la solution à la place du problème. « Nous voulons un tableau de bord avec six graphiques » ferme la porte à une réponse plus simple, comme une alerte envoyée le jour où un seuil est franchi.

Oublier ceux qui saisissent. L'application est souvent pensée pour celui qui consulte les chiffres. Si elle complique la vie de celui qui les saisit, les chiffres seront faux.

Taire les outils existants. Découvrir en cours de projet que le logiciel de facturation n'a pas d'API, c'est un sprint perdu et un budget qui glisse.

Tout mettre dans la première version. Une version qui fait peu mais qui tourne sert davantage qu'une version complète livrée trois mois plus tard. C'est la rubrique hors périmètre qui fait la différence.