Différencier demande et besoin : pourquoi c’est la clé de la réussite d’un projet

Différencier demande et besoin : pourquoi c’est la clé de la réussite d’un projet

Il y a une confusion que je rencontre constamment dans les projets — en formation, en conception pédagogique, en management, en gestion de changement. On répond à ce qu’on a demandé. Et pourtant, ça ne satisfait pas.

Ce n’est pas un problème de compétence. C’est un problème de distinction : la demande n’est pas le besoin.

L’échange audio ci-dessous illustre exactement cette situation — écoutez-le, le propos est concret et direct.

 

La demande, c’est une proposition de solution

Quand quelqu’un vous confie un projet, il vous formule généralement une demande. « On a besoin d’un outil collaboratif. » « Il nous faut une formation à la conduite de projet. » « Pouvez-vous développer un module sur la communication managériale ? »

Ces formulations ont quelque chose en commun : ce sont des solutions. Pas des problèmes. Celui qui formule la demande a déjà, dans sa tête, une idée de ce qu’il faut faire.

Et c’est normal. Si on vous confie un projet, c’est précisément parce que vous n’êtes pas sûr de la solution — sinon, ça s’appelle une commande. On passe commande quand on sait exactement ce qu’on veut. On confie un projet quand on a un problème à résoudre.

La différence est fondamentale — et souvent ignorée.

Ce que cache la demande

Derrière une demande d’outil collaboratif, il peut y avoir un problème de collaboration. Mais pas nécessairement. Si les équipes collaborent déjà bien et qu’il leur manque seulement l’outil, la demande est correcte. Si le vrai problème est un manque de confiance entre services, un outil ne changera rien.

C’est ce que j’appelle le syndrome du marteau : pour celui qui a un marteau, tous les problèmes sont des clous. Vos interlocuteurs ont souvent une idée préconçue de la solution — et cette idée peut parfaitement ne pas répondre au besoin réel.

Idem en formation : on me demande une formation à la gestion de projet. Ce qu’on veut vraiment, ce sont des projets qui réussissent. Or, des équipes peuvent maîtriser toutes les méthodes de gestion de projet et continuer à rater leurs projets — parce que le problème n’était pas là.

Répondre à la demande sans interroger le besoin, c’est risquer de livrer exactement ce qui a été demandé — et de rater complètement la cible.

Les enjeux avant tout

Ce qu’il faut chercher avant la solution, c’est les enjeux. Pourquoi fait-on ce projet ? Dans quel contexte ? À quelle finalité doit-il répondre ? Qu’est-ce qui ne fonctionne pas aujourd’hui ? Qu’est-ce qu’on a déjà essayé ?

Ces questions semblent évidentes. Elles sont rarement posées — parce qu’on a l’habitude d’entrer directement dans la solution dès qu’une demande est formulée.

Ce que je recommande systématiquement : avant de répondre à une demande, prenez le temps de poser des questions sur le besoin. Sur le problème actuel. Sur les gains recherchés. Sur ce qui a déjà été tenté. Et sur ce que la personne — ou l’organisation — attend vraiment comme résultat.

Un client m’a dit un jour quelque chose qui m’a marqué : « On court partout, on tire en permanence. Ce qu’on voudrait, c’est apprendre à identifier la cible avant de tirer. » C’est exactement ça.

Deux phases, pas une

Dans la conduite d’un projet, il y a une première phase de cadrage — comprendre le besoin, clarifier les enjeux, vérifier que la solution envisagée répond vraiment au problème posé. Et une deuxième phase de développement de la solution.

Mais ces deux phases ne sont pas linéaires. En avançant dans la solution, on peut découvrir des éléments qui remettent en question la compréhension initiale du besoin. C’est normal. C’est même souhaitable — à condition d’avoir créé les conditions pour pouvoir revenir en arrière sans tout refaire.

Ce qui est nécessaire : ne pas attendre la livraison finale pour itérer. Avancer par étapes, valider au fur et à mesure, revenir vers les parties prenantes régulièrement — pas seulement au départ et à la fin.

Un dernier point souvent oublié

La personne qui vous formule la demande n’est pas toujours celle qui a le bon besoin.

Parfois, c’est un intermédiaire qui relaie une demande qu’il n’a pas lui-même construite. Parfois, le vrai problème se trouve ailleurs dans l’organisation. Parfois, la personne qui commande n’est pas la personne qui va utiliser le résultat.

Mon conseil dans ces situations : appelez directement les personnes concernées. Il y a toujours des choses qui ne sont pas dans le brief, qui ne sont pas formulées dans la demande initiale — et qui sont pourtant essentielles pour comprendre ce qui compte vraiment.

En résumé

Répondre à une demande ne garantit pas de répondre au besoin. L’écart entre les deux est souvent là où les projets dérapent — pas dans la qualité de la réalisation, mais dans la compréhension de ce qui était vraiment attendu.

Prendre le temps de poser les bonnes questions au départ, revenir régulièrement vers les parties prenantes pendant le projet, et distinguer ce qui relève de la demande de ce qui relève du besoin réel : c’est ce qui fait la différence entre un livrable conforme et un projet réussi.

Pour aller plus loin :

 

FAQ

Quelle est la différence entre une demande et un besoin ? La demande est une proposition de solution formulée par celui qui confie le projet. Le besoin est le problème réel à résoudre. L’écart entre les deux est fréquent — et c’est cet écart qui explique pourquoi on peut livrer exactement ce qui a été demandé et ne pas satisfaire.

Comment identifier le besoin réel derrière une demande ? En posant des questions sur les enjeux — pourquoi ce projet, dans quel contexte, à quelle finalité — et sur le problème actuel : ce qui ne fonctionne pas, ce qui a déjà été essayé, ce qu’on attend concrètement comme résultat.

Que faire si la demande et le besoin sont en contradiction ? Signaler l’écart à votre interlocuteur, avec des arguments concrets. Proposer de cadrer le besoin avant de définir la solution. Dans certains cas, cela peut remettre en question la solution initialement envisagée — c’est une valeur ajoutée, pas un problème.

Faut-il respecter la demande même si elle ne répond pas au besoin ? Oui, dans un premier temps — la demande est le point d’entrée. Mais il faut l’interroger avant de la traiter. Respecter la demande sans questionner le besoin, c’est prendre le risque de répondre à la mauvaise question.

Bienvenue sur le blog

Les actualités, les moments forts et le point de vue des designers pédagogiques d’Eikos sur la formation professionnelle.

Catégories

La newsletter

Pour ne rien manquer de l’activité d’Eikos Concepts, abonnez-vous à notre newsletter !

Articles récents

Télécharger la ressource

Indiquez votre adresse email pour recevoir la ressource dans votre boite de réception