Définition · Expression du besoin et cahier des charges
L'expression du besoin en projet informatique et en achats
En bref
L'expression du besoin décrit, avant toute solution, ce que le demandeur veut obtenir : le contexte, les objectifs, les contraintes et les critères de réussite. En projet informatique comme en achats, c'est la première étape, avant le cahier des charges. Elle s'écrit avec les mots du métier, puis les Achats la complètent par leurs questions.
Définition
Dans un projet informatique ou un achat, l'expression du besoin est le document par lequel un demandeur (un service, une direction, un chef de projet) explique ce qui ne va pas aujourd'hui et ce qu'il attend demain. Elle répond à la question « quoi et pourquoi », jamais à la question « avec quoi ». Le nom d'un logiciel ou d'un fournisseur n'y a pas sa place, sauf comme information.
Elle porte plusieurs noms selon les organisations : fiche de besoin, note de cadrage, expression des besoins, parfois « demande » tout court. Le contenu, lui, ne change pas : un contexte, des objectifs, des contraintes et des critères de réussite. Le travail qui permet de l'obtenir s'appelle le recueil des besoins, et il revient souvent aux Achats ou au chef de projet.
C'est un document court. Une ou deux pages suffisent, et un demandeur qui en écrit dix est en général en train de décrire une solution qu'il a déjà choisie.
Expression du besoin et cahier des charges
Les deux documents se suivent, ils ne se remplacent pas. L'expression du besoin est écrite pour l'entreprise elle-même ; le cahier des charges est écrit pour les fournisseurs.
| Expression du besoin | Cahier des charges | |
|---|---|---|
| Qui l'écrit | Le demandeur, avec ses mots | Les Achats et la DSI, avec le demandeur |
| Pour qui | L'entreprise : direction, budget, Achats | Les fournisseurs consultés |
| Ce qu'il contient | Un problème, des objectifs, des contraintes | Des exigences numérotées, priorisées, vérifiables |
| Moment | Avant toute recherche de solution | Au lancement de la consultation |
| Longueur | Une ou deux pages | De quelques pages à plusieurs dizaines |
Le passage de l'un à l'autre est une traduction. « Nos commerciaux perdent une demi-journée par devis » devient, dans le cahier des charges fonctionnel, une série de fonctions attendues ; « on doit garder notre logiciel comptable » devient une exigence d'intégration dans le cahier des charges technique. Sans expression du besoin, cette traduction se fait à partir de suppositions.
Elle se distingue aussi de la demande d'achat. Une demande d'achat porte sur un article ou une prestation déjà identifiés, avec une quantité et souvent un prix : dix écrans, une licence de plus. L'expression du besoin intervient quand la solution n'est pas encore connue, ou qu'il faut consulter plusieurs fournisseurs pour la trouver.
Comment la rédiger
Comment rédiger une expression de besoin ? En quatre rubriques, dans cet ordre. Pour l'illustrer, prenons un exemple d'expression du besoin construit pour l'occasion (chiffres fictifs) : le service commercial d'une entreprise industrielle prépare ses devis dans un tableur.
Contexte
Décrivez la situation actuelle comme si le lecteur n'avait jamais mis les pieds dans le service : qui fait quoi, avec quels outils, depuis quand le problème existe et ce qu'il coûte. Donnez les volumes, même approximatifs.
Nos 12 commerciaux établissent environ 150 devis par mois dans un tableur, à partir d'une grille de prix mise à jour deux fois par an. Un devis complexe demande une demi-journée. Depuis la hausse des prix matières de cette année, la grille n'est plus à jour : nous avons relevé 9 devis erronés le trimestre dernier, dont 2 acceptés par le client à perte.
Objectifs
Un objectif dit ce qui doit avoir changé, pas comment y arriver. Chiffrez-le dès que possible : un délai, un volume, un taux d'erreur. Dans l'exemple, « produire un devis complexe en moins d'une heure » et « ne plus émettre de devis sur une grille de prix périmée » sont deux objectifs. « Avoir un configurateur de devis » n'en est pas un : c'est une solution, peut-être la bonne, que les fournisseurs proposeront d'eux-mêmes.
Limitez-vous à trois ou quatre objectifs. Au-delà, ce sont des souhaits, et ils iront rejoindre les critères de réussite avec une priorité plus basse.
Contraintes
Les contraintes sont ce qui ne se négocie pas, ou très peu. Elles se rangent en cinq familles : le délai (une date impérative, et pourquoi), le budget s'il est déjà connu, la réglementation ou la conformité, la technique (les outils à garder ou à relier) et l'interne (qui sera disponible pour le projet, et combien de temps).
Chaque contrainte mérite sa justification. « Avant le 1er janvier » ne pèse pas pareil selon qu'il s'agit d'une préférence ou du lancement d'une nouvelle gamme. Une contrainte sans raison finit contestée en cours de projet.
Critères de réussite
La question à poser au demandeur est simple : dans six mois, comment saura-t-on que l'achat était le bon ? Les réponses deviennent les critères de réussite, classés en trois niveaux (Bloquant, Important, Bonus). Ils serviront deux fois : pour choisir entre les offres, puis pour vérifier, une fois la solution en place, que le résultat promis est là.
Dans l'exemple : « aucun devis émis sur une grille de prix de plus d'un mois » est bloquant ; « un devis complexe en moins d'une heure » est important ; « un devis envoyé directement depuis l'outil » est un bonus.
Les pièges courants
- La solution déguisée en besoin. « Il nous faut tel logiciel » exprime une préférence. Elle a sa place dans la fiche, à la rubrique des pistes connues ; les objectifs, eux, disent ce qui doit changer.
- Le besoin d'une seule personne. Le demandeur parle pour son équipe, mais la comptabilité, la DSI ou le service client utiliseront peut-être aussi l'outil. Demandez-lui qui d'autre est concerné.
- L'objectif qui ne se mesure pas. « Gagner en efficacité » met tout le monde d'accord parce que personne ne sait ce que cela veut dire.
- Les volumes oubliés. Sans nombre d'utilisateurs, de documents ou de transactions, aucun fournisseur ne peut chiffrer, et chacun inventera ses propres hypothèses.
- La liste au Père Noël. Tout est bloquant, tout est urgent. Faites classer les critères : s'il ne reste que des Bloquants, le demandeur n'a pas encore choisi.
- Le besoin rédigé après une démonstration. Un demandeur qui a vu un produit la semaine précédente décrit ce produit, fonctions comprises. Mieux vaut recueillir le besoin avant les rencontres avec les fournisseurs.
- Le silence sur l'existant. Ce qui fonctionne bien aujourd'hui doit être dit, sinon personne ne pensera à le préserver.
Le demandeur n'a pas à connaître ces pièges. C'est le rôle de celui qui relit, acheteur ou chef de projet, de les repérer et de poser les questions qui manquent.
La fiche d'expression de besoin (modèle)
Notre fiche d'expression de besoin, au format Word, tient sur deux pages. Un en-tête identifie le demandeur, la date, l'intitulé du besoin en une phrase et la date souhaitée de mise en place, avec une case pour préciser si elle est impérative et pourquoi. Viennent ensuite sept rubriques :
- Contexte : la situation aujourd'hui, le problème, depuis quand, avec quelles conséquences.
- Objectifs : ce qui doit avoir changé, chiffré si possible.
- Périmètre : qui est concerné, quels sites, quels volumes, et ce qui est hors sujet.
- Contraintes : délai, budget estimé, réglementation, technique, ressources internes.
- Critères de réussite, classés en Bloquant, Important ou Bonus.
- Pistes déjà connues : solutions ou fournisseurs rencontrés, à titre d'information.
- Validation par le demandeur, le responsable du budget et les Achats.
Comment remplir une fiche d'expression des besoins ? Avec ses propres mots, sans chercher le vocabulaire technique, et en répondant aux questions posées dans chaque rubrique plutôt qu'en rédigeant un texte libre. Les Achats relisent et complètent, puis les trois signataires valident. Une fiche validée par le responsable du budget évite de lancer une consultation que personne ne financera. Pour recevoir ce modèle de fiche d'expression de besoin Word, remplissez le formulaire en haut de page.
| Rubrique | Exemple de fiche remplie (chiffres fictifs) |
|---|---|
| Intitulé du besoin | Fiabiliser et accélérer la préparation des devis commerciaux |
| Objectifs | Devis complexe en moins d'une heure ; aucun devis sur une grille de prix périmée |
| Périmètre | 12 commerciaux, 2 assistantes, 150 devis par mois ; la facturation est hors sujet |
| Contraintes | Opérationnel avant le salon professionnel de mars ; relié au logiciel de gestion commerciale actuel |
| Pistes connues | Un configurateur vu chez un client ; aucune préférence arrêtée |
Recueillir le besoin des demandeurs
Le recueil des besoins prend trois formes, souvent combinées. La fiche, d'abord, que le demandeur remplit seul. L'entretien, ensuite, pour les achats importants : une heure avec le demandeur suffit à faire apparaître ce qu'il n'a pas écrit. L'atelier, enfin, quand plusieurs services sont concernés et qu'il faut les mettre d'accord avant d'aller plus loin.
Dans tous les cas, l'acheteur ajoute ses propres questions, celles que le demandeur ne se pose pas : existe-t-il déjà un contrat qui couvre une partie du besoin, et quand arrive-t-il à échéance ? Qui décide, qui paie ? Le besoin est-il ponctuel ou durable ? Combien de fournisseurs crédibles existent sur ce marché ? Les réponses changent parfois la nature de l'achat, d'une consultation complète à un simple avenant.
Le recueil est la première étape de la chaîne qu'on appelle intake to contract : de la demande du métier jusqu'à la signature du contrat. Plus il est complet, moins on revient vers le demandeur en pleine consultation.
Dans Naigo, l'agent de recueil du besoin envoie au métier un lien sans compte : il décrit son besoin avec ses mots, et l'IA ajoute les questions qu'un acheteur expérimenté poserait, chacune avec ce qui la motive. Une fois validé par les Achats, le recueil sert de base au cahier des charges et à la grille de notation.
Publié le 6 octobre 2026