Expression des besoins

  • Concept
  • Intermédiaire
  • Transversal
  • Toujours utilisé

En bref

L'expression des besoins est l'étape où le client décrit clairement ce qu'il attend d'un projet, avant toute solution technique.

Définition complète

L’expression des besoins est l’étape, généralement en tout début de projet, au cours de laquelle le client ou le commanditaire décrit ce qu’il attend d’un projet : le problème à résoudre, les objectifs poursuivis, les contraintes à respecter. Elle se concentre sur le « pourquoi » et le « quoi » attendu, avant de basculer vers le « comment » technique, qui relève ensuite du prestataire ou de l’équipe projet.

Par exemple, une association qui souhaite un nouveau site internet peut exprimer son besoin ainsi : « nous voulons que les visiteurs puissent s’inscrire à nos évènements en ligne et payer leur adhésion, sans avoir besoin de créer un compte compliqué ». Ce n’est qu’ensuite que l’équipe technique traduira ce besoin en solution concrète (formulaire, module de paiement, etc.).

Attention : un besoin mal exprimé, trop vague ou trop technique dès le départ, est l’une des causes les plus fréquentes d’échec de projet. Un besoin exprimé en termes de solution (« il nous faut telle application ») cache souvent le vrai besoin sous-jacent, qu’il faut prendre le temps de faire émerger.

À quoi ça sert

L’expression des besoins sert de fondation à tout le projet : c’est elle qui permet ensuite de rédiger un cahier des charges fiable, d’estimer un budget réaliste et de vérifier, à la fin, si le résultat livré correspond bien à ce qui était attendu au départ.

Elle sert aussi à faire dialoguer des personnes qui ne parlent pas le même langage : un client exprime souvent son besoin avec ses mots à lui, pas toujours avec la précision technique attendue, et c’est le rôle du chef de projet ou du consultant de reformuler ce besoin pour s’assurer qu’il est bien compris avant de s’engager.

Enfin, bien exprimé et documenté dès le départ, le besoin devient une référence commune tout au long du projet, qui permet de trancher les désaccords ultérieurs sur ce qui était réellement prévu.

Cas d'usage typiques

– Démarrer un projet : organiser un entretien ou un atelier avec le client pour formuler clairement ses attentes avant de proposer une solution.
– Rédiger un cahier des charges : traduire les besoins exprimés par le client en exigences précises et vérifiables.
– Éviter un malentendu commercial : reformuler le besoin du client avec ses propres mots pour vérifier qu’on l’a bien compris avant de chiffrer une offre.
– Distinguer besoin et solution : aider un client qui demande « un outil comme celui du concurrent » à exprimer le vrai problème qu’il cherche à résoudre.
– Prioriser un backlog produit : classer les besoins exprimés par ordre d’importance pour décider ce qui sera traité en premier.
– Justifier un choix technique : relier chaque fonctionnalité livrée à un besoin explicitement exprimé au départ.

Ce que tu sauras faire

Savoir recueillir, reformuler et documenter le besoin réel d'un client ou d'un commanditaire, en le distinguant clairement de la solution technique qui sera choisie ensuite.

Mises en situation

Situation 1 : un client qui demande une solution toute faite

Contexte : un commerçant demande à un prestataire « une application comme celle de mon voisin » sans autre précision.

Application : le prestataire l’interroge sur ce qu’il cherche réellement à obtenir : plus de clients, un gain de temps, une meilleure image.

Résultat attendu : le vrai besoin apparaît (gagner du temps sur la prise de commande), ce qui oriente vers une solution différente de celle du voisin, mieux adaptée.

Situation 2 : une association aux attentes floues

Contexte : une association souhaite « moderniser sa communication » sans détail supplémentaire.

Application : un atelier avec les bénévoles permet de faire émerger des besoins précis : un site plus lisible sur mobile, une page d’inscription aux évènements plus simple.

Résultat attendu : le cahier des charges reflète des besoins concrets et vérifiables, plutôt qu’une intention générale difficile à traduire en solution.

Situation 3 : un besoin qui change en cours de discussion

Contexte : un client affine sa demande au fil des échanges avec son prestataire, en ajoutant progressivement des précisions.

Application : le prestataire reformule régulièrement le besoin par écrit pour vérifier que la compréhension évolue bien dans le même sens des deux côtés.

Résultat attendu : le besoin final documenté correspond réellement à l’intention du client, sans malentendu découvert trop tard.

Application guidée : distinguer besoin et solution

Contexte : un cabinet médical demande « un logiciel de rendez-vous en ligne ».

Question : quel est le vrai besoin derrière cette demande de solution ?

Résultat attendu : le vrai besoin est probablement de réduire le temps passé au téléphone à gérer les rendez-vous et les annulations de dernière minute ; plusieurs solutions différentes peuvent y répondre, pas seulement celle demandée initialement.

Application guidée : reformuler un besoin flou

Contexte : un client dit vouloir « un site plus moderne ».

Question : comment transformer cette phrase en besoin exploitable ?

Résultat attendu : poser des questions précises (plus rapide, plus simple à mettre à jour, plus convaincant pour vendre) permet de faire émerger un besoin concret, qui pourra ensuite être traduit en exigences claires dans un cahier des charges.

Pour bien le retenir

L'analogie

Imaginez un patient qui arrive chez son médecin en disant « je veux des antibiotiques ». Un bon médecin ne prescrit pas immédiatement ce que le patient demande : il l’interroge d’abord sur ses symptômes, depuis quand ils durent, ce qui les déclenche. Le patient a exprimé une solution (« des antibiotiques ») alors que son vrai besoin est de guérir d’un mal précis, qui n’est peut-être même pas d’origine bactérienne. L’expression des besoins fonctionne pareil dans un projet : il faut aller chercher, derrière la solution demandée par le client, le vrai problème qu’il cherche à résoudre.

« Le client exprime souvent une solution ; le vrai travail est de trouver le besoin caché derrière. »

Pièges à éviter

À ne pas confondre avec

Un piège fréquent consiste à prendre pour argent comptant la première formulation d'un client, sans creuser davantage. Un client qui demande « un site plus moderne » peut en réalité vouloir un site plus rapide, plus simple à mettre à jour, ou qui convertit mieux : trois besoins très différents derrière un même mot.

Une autre erreur est de confondre expression des besoins et cahier des charges : l'expression des besoins vient du client, dans son langage, alors que le cahier des charges est la traduction structurée de ce besoin par l'équipe projet, souvent avec des termes plus techniques.

Enfin, certains négligent de faire valider par écrit le besoin exprimé, ce qui laisse la porte ouverte à des désaccords ultérieurs sur ce qui avait réellement été demandé au départ.

Évolution historique

Apparition : Pratique formalisée dans l'ingénierie et l'informatique à partir des années 1980-1990, généralisée à tous les métiers de service avec la gestion de projet moderne

Quels changements depuis l’arrivée de l’IA ?

Avant

Recueillir et formuler un besoin demandait des entretiens en personne ou par téléphone, suivis d’une rédaction manuelle souvent longue, avec le risque d’oublier des éléments évoqués à l’oral.

Aujourd’hui

Des outils d’intelligence artificielle peuvent aider à transcrire et résumer automatiquement un entretien avec un client, à repérer des besoins implicites dans un texte, ou à proposer une première structure de cahier des charges à partir d’une expression de besoin encore informelle. Cela accélère la mise en forme, mais ne remplace pas l’écoute active du chef de projet, seule capable de repérer les non-dits et les besoins que le client n’a pas su formuler lui-même.

Évolution historique

Avant les années 1980 : les besoins étaient souvent exprimés de façon informelle, sans méthode structurée, notamment dans l’artisanat et les petites entreprises.

Années 1980-1990 : formalisation de l’expression des besoins comme étape à part entière dans l’ingénierie et l’informatique, avec des méthodes dédiées.

Années 1990-2000 : généralisation du cahier des charges fonctionnel comme document de référence dans la plupart des secteurs.

Années 2010 : montée des méthodes agiles, qui font évoluer l’expression des besoins vers des formats plus courts et itératifs.

Années 2020 : apparition d’outils d’intelligence artificielle qui assistent la collecte, la synthèse et la structuration des besoins exprimés par les clients.