Recueil du besoin : cadrer le problème avant de choisir l’outil

Qu’est-ce que le recueil du besoin, vraiment ?

Dans la plupart des entreprises, la demande arrive déjà formulée comme une réponse : « il nous faut un CRM », « on veut un ERP », « il me faut un logiciel de devis ». Le recueil du besoin consiste précisément à rouvrir cette question fermée. Une demande d’outil n’est pas un besoin : c’est une hypothèse de solution que quelqu’un a posée avant d’avoir nommé le problème.

Le rôle du recueil du besoin est de remonter d’un cran. Là où le dirigeant dit « je veux un logiciel », l’accompagnant demande « vous voulez résoudre quoi ? ». La nuance paraît anodine ; elle change tout le projet. Un recueil du besoin sérieux distingue le symptôme (l’outil réclamé) de la cause (l’irritant opérationnel qui, lui, coûte de l’argent chaque semaine).

C’est le même principe qui sépare l’automatisation du rangement : automatiser un process bancal ne fait qu’accélérer ses erreurs. 

Pourquoi un recueil du besoin bâclé coûte cher

• Vous figez le désordre. Sans recueil du besoin, l’outil épouse l’organisation existante, défauts compris. Vous payez pour aller plus vite dans la mauvaise direction.
• Vous payez deux fois. Un logiciel choisi sans recueil du besoin est souvent abandonné en dix-huit mois : licence, déploiement, puis un second projet pour réparer le premier.
• Vos équipes n’adoptent pas. Un outil qui ne répond pas à l’irritant vécu sur le terrain reste vide. Les tableurs et les carnets papier reviennent par la fenêtre.
• Vous perdez le vrai chiffre. Le désordre non nommé continue de coûter en recherche d’information, double saisie et reprises — le coût caché que le recueil du besoin est justement censé faire apparaître.

Comment mener un recueil du besoin utile

Un bon recueil du besoin ne commence pas par une liste de fonctionnalités. Il commence par une scène : le moment précis où ça coince. On fait décrire le déroulé réel d’une tâche — établir un devis, suivre un chantier, facturer un fournisseur — par les personnes qui la font, séparément. Les écarts entre leurs versions révèlent le problème mieux que n’importe quel cahier des charges.

Ensuite, on chiffre. Combien de temps perdu, combien de réclamations, combien de marge invisible ? Le recueil du besoin transforme un agacement diffus en montant. Ce n’est qu’à ce stade que la question de l’outil se pose légitimement — et souvent, la réponse n’est pas celle qui avait été demandée au départ.

Un cas réel

Une entreprise de plomberie-chauffage d’une vingtaine de salariés arrive avec une demande claire : « il nous faut un ERP ». La documentation du secteur décrit exactement cette situation — un quotidien à jongler entre devis sur tableur, bons d’intervention papier et factures fournisseurs qui s’accumulent. Le réflexe : acheter le logiciel le plus complet. France Num

Le recueil du besoin déplace la question. Derrière « il nous faut un ERP », le vrai irritant n’était pas l’absence d’outil, mais l’absence de marge visible en temps réel : personne ne savait, chantier par chantier, si l’affaire était rentable. La recommandation documentée pour ce type de PME est nette : auditer les trois process les plus critiques — devis, suivi d’intervention, facturation fournisseur — avant même d’assister à une démonstration logicielle. Le recueil du besoin d’abord, la démo ensuite. (Cas sectoriel anonymisé, à titre d’illustration.)

Par où commencer

Les 3 questions du recueil du besoin

1. Quel est l’irritant précis ? Décrivez le moment exact où ça coince, pas la fonctionnalité rêvée.
2. Qui en souffre, et combien ça coûte ? Mettez un nom et un chiffre sur le problème avant de mettre un budget sur l’outil.
3. Est-ce un problème de process ou d’outil ? Si trois personnes décrivent la même tâche de trois façons, aucun logiciel ne réglera ça à votre place.

Là où tout le monde se plante

« Le logiciel va nous organiser. » C’est l’inverse : un outil ne crée pas d’organisation, il fige celle qui existe. Si votre organisation est floue, le recueil du besoin sert à la clarifier avant de la couler dans le béton d’un logiciel. Beaucoup de projets échouent non parce que l’outil était mauvais, mais parce que le recueil du besoin n’a jamais eu lieu : on a répondu à la demande sans jamais interroger le problème.

Questions fréquentes

1. Recueil du besoin ou cahier des charges : quelle différence ?
Le cahier des charges décrit la solution attendue (fonctionnalités, contraintes techniques). Le recueil du besoin vient avant : il établit quel problème justifie le projet. Rédiger un cahier des charges sans recueil du besoin, c’est spécifier finement une réponse à une question qu’on n’a jamais posée.

2. Combien de temps prend un recueil du besoin dans une PME ?
Pour une PME, l’essentiel se joue en quelques jours, pas en trois mois. Il ne s’agit pas d’un audit exhaustif mais d’identifier le ou les irritants qui coûtent réellement. Un recueil du besoin qui s’éternise est souvent le signe qu’on cherche à tout couvrir au lieu de trancher.

3. Faut-il un consultant pour mener un recueil du besoin ?
Non, la démarche peut être menée en interne : faire décrire les tâches critiques par ceux qui les exécutent, repérer les écarts, chiffrer. Un regard extérieur aide surtout à poser les questions dérangeantes et à éviter que la demande d’outil initiale ne verrouille l’analyse.

4. Et si le recueil du besoin confirme qu’il faut bien un logiciel ?
C’est un très bon résultat. La différence, c’est que vous achetez alors en connaissant le problème précis à résoudre, les critères qui comptent et le coût du statu quo. Le recueil du besoin ne s’oppose pas à l’outil : il fait que l’outil soit le bon.

5. Quels sont les signes d’un recueil du besoin bâclé ?
Un projet lancé directement sur des noms de logiciels, un cahier des charges qui liste des fonctionnalités sans nommer un seul irritant chiffré, et des équipes terrain jamais consultées. Résultat classique : un outil déployé, peu adopté, et abandonné en moins de deux ans.