L'expression de besoin décrit votre projet informatique en quelques pages avant de consulter des prestataires. Définition, différence avec le cahier des charges, modèle en neuf rubriques et exemple.
L’expression de besoin est un document court, rédigé par le client, qui décrit un projet informatique dans ses grandes lignes : le problème à résoudre, les objectifs, les utilisateurs, le périmètre et les contraintes (budget, délais, outils existants). Elle sert à lancer la discussion avec des prestataires et précède le cahier des charges, plus détaillé. Elle décrit ce dont vous avez besoin, jamais comment le réaliser techniquement.
Bien rédigée, elle permet à n’importe quel lecteur de comprendre votre projet en quelques minutes et à un prestataire de vous répondre sérieusement. On voit à quoi elle sert, quand et par qui la rédiger, ce qu’elle doit contenir, avec un modèle et un exemple, puis les erreurs qui la rendent inutilisable.
- Qu’est-ce qu’une expression de besoin ?
- À quoi sert l’expression de besoin ?
- Quelle différence avec un cahier des charges ?
- À quel moment rédiger l’expression de besoin ?
- Qui doit rédiger l’expression de besoin ?
- Que doit contenir une expression de besoin ?
- À quoi ressemble une expression de besoin ?
- Quelles erreurs éviter ?
- Questions fréquentes
- Sources
Qu’est-ce qu’une expression de besoin ?
En développement informatique, l’expression de besoin (ou expression des besoins) est l’énoncé de ce qu’un futur logiciel, site ou application doit permettre de faire. Elle aborde non seulement le système envisagé, mais aussi l’environnement dans lequel il fonctionnera : les personnes qui l’utiliseront, les outils déjà en place, les contraintes de l’entreprise.
C’est aussi un moment collectif : chaque personne concernée (direction, équipes terrain, service client, comptabilité) apporte ses attentes et ses suggestions, qui seront ensuite conservées ou non dans le cahier des charges.
Besoin utilisateur ou exigence système ? Les besoins des utilisateurs s’expriment en langage courant, avec le vocabulaire du métier, et décrivent le problème à résoudre : « nos techniciens doivent consulter l’historique d’un client sur le terrain ». Les exigences système ou logicielles traduisent ce besoin en premières caractéristiques de la solution : « l’application affiche l’historique hors connexion sur smartphone ». L’expression de besoin reste du côté du besoin utilisateur, sans parti pris de solution.
À quoi sert l’expression de besoin ?
- Clarifier votre propre projet. Mettre le besoin par écrit oblige à trancher des questions restées floues : pour qui, pourquoi, avec quelle priorité.
- Aligner les parties prenantes. Personne n’a à lui seul une vision complète du futur système. Il faut souvent réconcilier des points de vue incomplets ou contradictoires pour obtenir une description cohérente.
- Consulter des prestataires. C’est le principal outil de communication entre l’entreprise qui achète un système et l’agence ou la société de développement qui le réalisera. Tous reçoivent la même base, ce qui rend leurs réponses comparables.
- Limiter les erreurs coûteuses. Les erreurs introduites au stade des besoins sont parmi les plus chères à corriger, car elles se propagent dans la conception, le code et les tests.
Quelle différence avec un cahier des charges ?
L’expression de besoin n’est pas un cahier des charges. Elle décrit le projet de manière globale, en quelques pages, pour trouver un prestataire capable de le réaliser. Le cahier des charges, lui, décrit le projet de façon exhaustive : fonctionnalités détaillées, règles de gestion, exigences techniques, critères de validation.
| Expression de besoin | Cahier des charges | |
|---|---|---|
| Objectif | Faire comprendre le projet et ses enjeux | Décrire précisément ce qui doit être réalisé |
| Longueur | Quelques pages | Variable, souvent beaucoup plus long |
| Niveau de détail | Problème, objectifs, utilisateurs, contraintes | Fonctionnalités, parcours, exigences techniques et réglementaires |
| Usage | Premier échange avec des prestataires | Devis détaillés, contrat, recette |
Les deux se suivent : l’expression de besoin est enrichie pendant la phase de cadrage pour aboutir au cahier des charges et aux spécifications. Notre guide pour rédiger un cahier des charges d’application web prend le relais une fois cette étape franchie. Pour un site vitrine ou une campagne, un brief d’agence joue un rôle proche.
En France, la démarche d’expression fonctionnelle du besoin est décrite par la norme NF EN 16271 (qui a remplacé la norme NF X50-151). Elle n’est pas obligatoire pour un projet privé, mais son principe guide toute bonne expression de besoin : formuler des fonctions attendues plutôt que des solutions.
À quel moment rédiger l’expression de besoin ?
Le plus tôt possible, avant que le projet ne soit complètement défini, et en tout cas avant de consulter des prestataires. C’est l’un des tout premiers documents d’un projet informatique, au tout début du cycle de développement.
Rien n’empêche de la faire relire par un prestataire avant le démarrage. C’est même recommandé : certaines solutions qui vous paraissent évidentes peuvent être remplacées ou simplifiées, et un regard expérimenté repère les obstacles possibles (données manquantes, intégration difficile, contrainte réglementaire). Si une incertitude technique forte subsiste, une preuve de concept permet de la lever avant d’engager tout le budget.
Qui doit rédiger l’expression de besoin ?
Le client à l’origine du projet est le mieux placé pour la rédiger : il connaît son métier, ses utilisateurs et ses contraintes. Dans une entreprise, désignez un porteur de projet qui collecte les attentes des différents services et arbitre entre elles.
Le prestataire l’enrichit ensuite pendant la phase de cadrage, qui aboutit aux maquettes et aux spécifications fonctionnelles. Il faut alors trouver le bon équilibre entre vos envies et les recommandations techniques. Il arrive qu’un client reste sur ses positions en ignorant les conseils du prestataire, ou qu’un prestataire impose ses habitudes : chaque partie doit écouter l’autre pour faire émerger un consensus. Pour bien choisir cet interlocuteur, lisez notre article sur le choix d’un prestataire de développement informatique.
Que doit contenir une expression de besoin ?
Quelques pages suffisent en général. Voici un modèle en neuf rubriques :
- Présentation de l’entreprise : activité, taille, organisation, en quelques lignes.
- Situation actuelle : comment les choses se passent aujourd’hui, avec quels outils (tableur, logiciel, papier), et ce qui pose problème.
- Enjeux et objectifs : ce que le projet doit changer, si possible de façon mesurable (délai de traitement, erreurs de saisie, chiffre d’affaires en ligne).
- Utilisateurs : qui utilisera la solution, combien, dans quel contexte (bureau, terrain, mobile), avec quel niveau d’aisance numérique.
- Besoins fonctionnels principaux : ce que les utilisateurs doivent pouvoir faire, formulé simplement et classé par priorité.
- Périmètre : ce qui est inclus et ce qui ne l’est pas, au moins pour la première version.
- Contraintes : outils existants avec lesquels communiquer, hébergement, données personnelles, accessibilité, contraintes internes.
- Budget et calendrier : une fourchette de budget et une date cible, avec la raison de cette date (salon, saison, fin de contrat d’un ancien outil).
- Interlocuteurs et suite : qui décide, qui répond aux questions, et ce que vous attendez des prestataires (proposition, estimation, atelier de cadrage).
Un point de vocabulaire : le jargon technique est admis s’il est précis, mais un même terme est souvent employé pour des choses différentes. Une pop-up (nouvelle fenêtre du navigateur) n’est pas une pop-in (fenêtre qui s’ouvre dans la page), et pourtant beaucoup de gens utilisent le premier mot pour les deux. Décrivez donc aussi, avec des mots simples, le comportement attendu : « un encadré s’affiche au-dessus de la page après 30 secondes et se ferme avec une croix ».
À quoi ressemble une expression de besoin ?
Voici un exemple fictif, volontairement court, pour une entreprise de maintenance d’équipements :
Contexte. Nous employons 12 techniciens qui interviennent chez nos clients. Les bons d’intervention sont remplis sur papier, puis ressaisis au bureau dans un tableur. Les ressaisies prennent du temps et provoquent des oublis de facturation.
Objectif. Supprimer la ressaisie et facturer chaque intervention dans la semaine.
Besoins prioritaires. Les techniciens doivent consulter leur planning et l’historique du client sur smartphone, y compris sans réseau ; remplir le bon d’intervention et le faire signer par le client sur place ; le bureau doit retrouver les bons terminés et les transmettre à notre logiciel de facturation.
Hors périmètre de la première version. La gestion des stocks de pièces.
Contraintes. Logiciel de facturation existant à conserver ; données clients à protéger ; techniciens peu à l’aise avec les outils complexes.
Budget et calendrier. Fourchette de budget indiquée ; mise en service souhaitée avant la haute saison.
Remarquez qu’aucune technologie n’est imposée : c’est au prestataire de proposer une application mobile, une application web ou un simple connecteur entre des outils existants, selon ce qui répond le mieux au besoin.
Quelles erreurs éviter ?
- Décrire une solution au lieu d’un besoin : « il nous faut une application React » ferme la porte à des solutions plus simples ou moins chères.
- Écrire seul dans son coin : un besoin rédigé sans les futurs utilisateurs passe à côté de leurs vraies difficultés.
- Tout vouloir dans la première version : sans priorités, le budget et les délais dérapent. Une première version limitée à l’indispensable permet de démarrer plus vite.
- Taire le budget : les propositions reçues seront impossibles à comparer.
- Oublier l’existant : les outils et données actuels conditionnent souvent la solution.
- Figer le document : l’expression de besoin est faite pour être discutée et enrichie.
Votre besoin porte sur un outil métier ou une application ? On peut vous aider à le formaliser puis à développer une application web sur mesure. S’il s’agit surtout de faire communiquer vos outils existants, notre service d’intégration et d’automatisation propose de commencer par un audit des flux. Écrivez-nous à contact@osmova.com ou via le formulaire de contact.
Questions fréquentes
L’expression de besoin est-elle obligatoire ?
Pour un projet privé, non. Mais sans elle, chaque prestataire interprète votre demande à sa façon et vous recevez des propositions impossibles à comparer. Même une page bien construite change la qualité des réponses.
Combien de temps faut-il pour la rédiger ?
Cela dépend surtout du temps nécessaire pour recueillir les attentes des personnes concernées. La rédaction elle-même est courte ; les entretiens avec les utilisateurs et les arbitrages internes prennent davantage de temps.
Peut-on utiliser du jargon technique ?
Oui s’il est précis et partagé, mais doublez-le d’une description simple du comportement attendu. Un glossaire en fin de document évite les malentendus.
Quelle différence entre expression de besoin et note de cadrage ?
L’expression de besoin décrit le problème et les attentes, côté client. La note de cadrage, produite ensuite, fixe l’organisation du projet : périmètre validé, planning, budget, rôles, risques. Elle s’appuie sur l’expression de besoin.
Faut-il faire signer l’expression de besoin au prestataire ?
Non, ce n’est pas un document contractuel. Ce sont la proposition commerciale, le cahier des charges ou les spécifications validées qui engagent les parties.
