Expression de besoin et cahier des charges : la trame pour faire chiffrer votre projet

Pour faire développer une application, vous devez d’abord écrire ce dont vous avez besoin, puis le transmettre aux prestataires que vous consultez. L’expression de besoin décrit le problème à résoudre, les personnes qui le vivent et les résultats attendus. Le cahier des charges reprend ce contenu et y ajoute le périmètre, les contraintes, les critères d’acceptation et les règles de la consultation. Vous pouvez rédiger les deux sans connaissances techniques. Vous trouverez ci-dessous ce qu’un prestataire cherche dans ces pages pour chiffrer, une trame commentée à reprendre section par section, et les erreurs qui font dériver un budget.

La différence entre expression de besoin et cahier des charges

L’expression de besoin vient en premier. Elle répond à la question « pourquoi ce projet ? » : quel problème, pour quels utilisateurs, avec quels objectifs mesurables. Le client la rédige en interne, souvent avant de savoir qui réalisera le projet, pour mettre la direction d’accord avec les équipes métier, puis décider de lancer le projet ou non. Elle décrit le problème et laisse la solution pour plus tard.

Le cahier des charges vient ensuite. Il s’adresse aux prestataires, qui s’en servent pour chiffrer leurs devis. Une fois le prestataire choisi, on l’annexe au contrat. Il reprend l’expression de besoin et y ajoute ce qu’un prestataire doit connaître pour s’engager : le périmètre fonctionnel, l’existant, les contraintes, le budget, le calendrier et la façon dont la livraison sera validée.

La norme NF EN 16271, publiée par l’AFNOR en 2013 à la suite de la NF X50-151, nomme les deux documents « expression fonctionnelle du besoin » et « cahier des charges fonctionnel ». Le second décrit le besoin en fonctions à remplir plutôt qu’en solutions. Le prestataire rédige ensuite, en général, les spécifications techniques.

Pour un outil métier de PME, rédigez un seul document qui commence par le besoin et continue sur le périmètre. Deux documents distincts se justifient dans une grande organisation, où l’expression de besoin circule entre plusieurs directions avant que quiconque parle de prestataire.

Les informations qu’un prestataire cherche pour chiffrer

Un prestataire qui chiffre une application découpe le projet en tâches et estime chacune d’elles. Chez Lonestone, on liste toutes les tâches d’un projet, y compris les tâches secondaires qu’on a tendance à oublier, puis on pèse les facteurs de complexité de l’estimation : les zones de flou du périmètre, le nombre de parties prenantes, les dépendances à des services externes, les contraintes de planning.

Chaque question laissée sans réponse par le cahier des charges devient une hypothèse. Un prestataire prudent ajoute une marge pour chacune. Un prestataire pressé choisit une réponse à votre place, sans toujours vous le signaler. Dans les deux cas, les devis reçus deviennent difficiles à comparer, puisque chacun chiffre un projet différent.

Pour estimer sans deviner, un prestataire cherche six informations :

• le contexte, c’est-à-dire l’entreprise, le problème actuel et ce qui se passe si rien ne change
• les utilisateurs, leurs rôles et leur nombre
• les parcours principaux, décrits comme une suite d’actions
• l’existant, c’est-à-dire les logiciels en place, les fichiers Excel à reprendre et les API à appeler
• les contraintes, comme l’hébergement, la sécurité, le RGPD, l’accessibilité ou l’usage sur mobile en extérieur
• les critères d’acceptation, c’est-à-dire la façon de vérifier qu’une fonctionnalité marche

Les intégrations pèsent souvent plus lourd dans un devis que les écrans. Une synchronisation avec un ERP dont l’API est mal documentée peut prendre plus de temps que tout le back-office. Si vous ne savez pas comment votre logiciel actuel expose ses données, écrivez-le : un prestataire préfère lire « à vérifier » plutôt que de découvrir le problème au troisième sprint.

Modèle de cahier des charges commenté section par section

Cette trame convient à une application web ou mobile sur mesure, un outil métier ou un SaaS. La plupart des sections donnent un exemple tiré d’un même projet fictif, un outil de gestion des interventions pour une PME de maintenance de 40 techniciens.

1. Contexte et objectifs

Présentez l’entreprise en quelques lignes, puis le problème. Décrivez la situation actuelle telle qu’elle est, avec ses contournements. Donnez deux ou trois objectifs chiffrés.

Pour l’outil d’interventions, cela donne : « Les interventions sont planifiées sur un fichier Excel partagé et transmises aux techniciens par SMS. Les bons d’intervention papier arrivent au bureau avec une semaine de retard, ce qui décale d’autant la facturation. Nous voulons facturer une intervention le jour même et diviser par deux le temps de planification hebdomadaire. »

2. Utilisateurs et rôles

Listez chaque type d’utilisateur, son nombre et ce qu’il a le droit de faire. Précisez son contexte d’usage : au bureau sur grand écran, sur le terrain avec un téléphone, avec ou sans réseau.

Les utilisateurs de l’outil d’interventions sont trois planificateurs au bureau, 40 techniciens sur smartphone, souvent dans des sous-sols où le réseau passe mal, et un comptable qui exporte les interventions terminées.

3. Parcours principaux

Décrivez les trois à six parcours qui font l’essentiel de l’usage, sous forme d’étapes. Le format « en tant que [rôle], je veux [action] pour [bénéfice] » des user stories fonctionne bien.

Le parcours principal du technicien s’écrit ainsi : « En tant que technicien, je veux voir mes interventions du jour dans l’ordre de la tournée, pour ne pas appeler le bureau chaque matin. »

4. Périmètre fonctionnel priorisé

Listez les fonctionnalités et classez chacune en « indispensable au lancement », « utile ensuite » ou « si le budget le permet ». Ce classement compte plus que la liste elle-même : il permet au prestataire de proposer une première version réaliste, et à vous de comparer les devis sur une même base.

Dans l’outil d’interventions, la signature du client sur le téléphone du technicien est indispensable au lancement. Le calcul automatique des tournées passe dans « utile ensuite ».

5. Données et volumes

Indiquez les données manipulées, leur volume et leur croissance, ainsi que les données à reprendre depuis l’existant.

L’outil d’interventions gère 800 interventions par mois et 3 000 clients, avec des photos jointes à chaque intervention et un historique de cinq ans à importer depuis Excel.

6. Existant et intégrations

Nommez chaque logiciel avec lequel l’application doit échanger, puis précisez dans quel sens, à quelle fréquence, et ce que vous savez de son API. Joignez la documentation si vous l’avez.

L’outil d’interventions envoie chaque soir les interventions terminées au logiciel de facturation et récupère la liste des clients depuis le CRM.

7. Contraintes

Regroupez ici les points non négociables : hébergement en France, authentification unique avec les comptes Microsoft de l’entreprise, conformité au RGPD, accessibilité, compatibilité avec les téléphones des techniciens. Distinguez les contraintes réelles des préférences, pour que le prestataire sache ce qu’il peut discuter.

8. Critères d’acceptation

Pour chaque fonctionnalité indispensable, écrivez une ou deux phrases vérifiables qui diront si elle marche. Rédigez ensuite le cahier de recette à partir de ces critères, pendant le développement.

Pour la signature sur le terrain, le critère peut être : « Une intervention signée sur le terrain sans réseau apparaît au bureau dans les cinq minutes qui suivent le retour du réseau. »

9. Budget et calendrier

Donnez une fourchette de budget. Beaucoup de clients la cachent, de peur que les devis s’alignent dessus. En pratique, un budget annoncé permet à chaque prestataire de proposer ce qui tient dedans. Sans lui, vous recevez trois devis construits sur trois idées différentes du projet. Indiquez la date qui compte vraiment et pourquoi : une saison, un salon, la fin d’un contrat de licence.

10. Modalités de la consultation

Précisez ce que vous attendez dans la réponse (compréhension du besoin, démarche, planning, équipe, devis détaillé), la date limite, la date de décision, et les critères qui guideront votre choix.

Copiez la trame vide ci-dessous dans votre éditeur de texte.

# Cahier des charges : [nom du projet]

## 1. Contexte et objectifs
- L’entreprise en quelques lignes
- Le problème actuel et ses contournements
- Deux ou trois objectifs chiffrés

## 2. Utilisateurs et rôles
- Rôle, nombre, droits, contexte d’usage (bureau, terrain, mobile, réseau)

## 3. Parcours principaux
- En tant que [rôle], je veux [action] pour [bénéfice]

## 4. Périmètre fonctionnel priorisé
- Indispensable au lancement
- Utile ensuite
- Si le budget le permet

## 5. Données et volumes
- Données manipulées, volumes, croissance, reprise de l’existant

## 6. Existant et intégrations
- Logiciel, sens de l’échange, fréquence, documentation de l’API

## 7. Contraintes
- Hébergement, sécurité, RGPD, accessibilité, appareils
- Contraintes non négociables / préférences

## 8. Critères d’acceptation
- Une phrase vérifiable par fonctionnalité indispensable

## 9. Budget et calendrier
- Fourchette de budget
- Date clé et raison de cette date

## 10. Modalités de la consultation
- Contenu attendu de la réponse, date limite, date de décision, critères de choix

Décrire le besoin sans imposer la solution

Un cahier des charges décrit ce que les utilisateurs doivent pouvoir faire. Quand il décrit les écrans ou la technique, le prestataire chiffre la solution imaginée par le client, même quand une autre coûterait moins cher ou servirait mieux les utilisateurs.

Quand vous décrivez le besoin, le prestataire peut proposer mieux, par exemple une affectation automatique au lieu d’une liste déroulante, ou une seule application web installable sur iPhone et Android au lieu de deux développements. Une contrainte technique réelle a toute sa place dans la section des contraintes : un système d’information interne qui impose une technologie, une DSI qui n’héberge que certains environnements. Signalez en revanche une simple préférence comme telle, pour que le prestataire sache qu’il peut proposer autre chose.

Trois erreurs qui font dériver un budget

Une application sur mesure coûte moins cher à développer qu’il y a dix ans, grâce aux frameworks modernes et à l’IA. Ce qui coûte cher, c’est de partir dans la mauvaise direction. Cette direction se décide dès le cahier des charges. Le Standish Group, un cabinet américain qui étudie les projets informatiques, plaçait déjà les exigences incomplètes en tête des causes d’abandon citées par les responsables informatiques interrogés pour son enquête CHAOS de 1994 (13,1 % des réponses).

Figer le besoin trop tôt

Un cahier des charges de 80 pages, rédigé six mois avant le début du développement, décrit un besoin vieux de six mois le jour où l’équipe commence. Les premiers tests avec de vrais utilisateurs remettent presque toujours en cause une partie des hypothèses. Si le contrat engage chaque ligne du document, chaque découverte devient un avenant. Écrivez avec précision les objectifs et les parcours, mais laissez les détails d’écran ouverts.

Tout déclarer indispensable

Quand tout est prioritaire, le prestataire chiffre tout, donc le devis dépasse le budget. Classez les fonctionnalités en « indispensable au lancement », « utile ensuite » et « si le budget le permet » pour l’éviter. Avec ce classement, vous pouvez aussi lancer une première version réduite, que les utilisateurs ont en main plus tôt, sur le principe du produit minimum viable.

Oublier les critères d’acceptation

Sans critère écrit, la livraison se discute fonctionnalité par fonctionnalité : le client estime que « l’export ne marche pas », le prestataire répond qu’il fait ce que le document demandait. Avec une phrase vérifiable par fonctionnalité, le client et le prestataire savent dès le départ ce qui sera validé. Ces phrases deviennent ensuite les cas de test du cahier de recette.

Cahier des charges et méthode agile

En méthode agile, le cahier des charges devient le cadre de départ du projet plutôt qu’un contrat figé. Il fixe les objectifs, les contraintes, le budget et les critères d’acceptation, qui bougent peu. Le périmètre fonctionnel, lui, devient un backlog que l’équipe et le client repriorisent à chaque sprint, à budget constant.

Pour l’application NaonAir, Air Pays de la Loire a fourni un cahier des charges et la documentation de son API. L’équipe Lonestone en a tiré l’architecture technique, puis a travaillé avec le client sur les parcours utilisateurs et les wireframes, avant de développer en sprints de deux semaines. Chaque sprint se terminait par une démo et une nouvelle version que le client testait en conditions réelles.

Un cadrage de projet a lieu avant le premier sprint. Le prestataire y anime des ateliers avec les utilisateurs, puis livre les parcours, les maquettes, le backlog priorisé et des recommandations techniques. Si le client n’a pas encore de cahier des charges, le prestataire le rédige avec lui pendant le cadrage.

graph TD
  A[Expression de besoin<br/>le problème, les utilisateurs, les objectifs] --> B[Cahier des charges<br/>périmètre priorisé, contraintes, critères d'acceptation]
  B --> C[Échanges avec les prestataires et devis]
  C --> D[Cadrage<br/>parcours, maquettes, backlog, choix techniques]
  D --> E[Développement en sprints<br/>le backlog est repriorisé à chaque sprint]
  E --> F[Recette<br/>les critères d'acceptation deviennent des cas de test]

Se faire aider pour rédiger son cahier des charges

Pour un outil interne au périmètre clair, vous pouvez souvent rédiger le cahier des charges seul, à partir de la trame commentée. Quand le produit est nouveau, que les utilisateurs sont externes ou que plusieurs équipes ont des attentes différentes, faites-vous aider. Avec son offre Shape, Lonestone livre un cahier des charges fonctionnel, des parcours utilisateurs, des wireframes ou des maquettes, une recommandation d’architecture et une estimation, pour 6 K€ en moyenne dans le cas d’un outil interne. Vous restez libre de faire développer le produit par l’équipe de votre choix.

Pour un outil métier sur mesure au besoin déjà clair, envoyez-nous votre document, même incomplet. Nos ingénieurs, qui ont pour la plupart entre 10 et 25 ans d’expérience, le relisent avec vous, posent les questions qu’un développeur poserait au troisième sprint, et vous renvoient des conseils et un devis détaillé.