L'expression des besoins est l'étape où l'entreprise décrit les problèmes qu'un logiciel doit résoudre et les résultats qu'elle en attend, avec ses mots de métier, avant de parler de fonctions ou de technique. Elle précède le cahier des charges : elle dit pourquoi et pour qui, le cahier des charges dit ensuite quoi et avec quelles contraintes.
Bien faite, elle évite l'erreur la plus coûteuse d'un projet sur mesure : développer correctement un outil qui répond à une autre question que la vôtre. Voici comment la mener dans une PME, sans consultant et sans jargon.
Besoin, fonction, solution : trois niveaux à séparer
Une même demande peut s'écrire à trois niveaux, et les mélanger brouille tout le projet. Prenons un exemple inventé pour l'illustration :
- Le besoin : « Nous perdons des commandes parce que personne ne sait qui a rappelé le client. »
- La fonction : « Chaque demande client a un responsable et une date de rappel visibles par tous. »
- La solution : « Un CRM avec des tâches et des rappels par e-mail. »
L'expression des besoins reste au premier niveau, et descend au deuxième quand c'est utile. La solution revient au prestataire, qui pourra d'ailleurs conclure qu'un outil du marché suffit. Cette séparation est décrite par une norme européenne reprise en France, la NF EN 16271 sur l'expression fonctionnelle du besoin, publiée en décembre 2012 et qui a remplacé la NF X50-151. Une PME n'a pas besoin de l'appliquer à la lettre pour en garder l'idée principale : décrire ce qu'on attend du logiciel, et laisser le prestataire proposer comment y arriver.
Écrire au niveau du besoin a un autre avantage : deux prestataires peuvent proposer deux solutions différentes au même problème. Vous comparez alors des approches, et pas seulement des prix.
Source : AFNOR Boutique, fiche de la norme NF EN 16271, consulté le 22 octobre 2026.
Partir du travail tel qu'il se fait
Les besoins les plus utiles sortent rarement d'une réunion de direction. Ils apparaissent quand on observe le travail réel.
- Suivez un dossier de bout en bout. Une commande, un chantier, une demande client : notez chaque personne qui le touche, chaque outil utilisé, chaque document produit, chaque attente.
- Repérez les ressaisies. Toute information tapée deux fois dans deux outils différents signale un besoin.
- Ouvrez les fichiers Excel partagés. Leurs colonnes, leurs couleurs et leurs onglets cachés contiennent des règles de gestion que personne n'a jamais écrites.
- Notez les contournements. Le cahier sur le bureau, le post-it collé à l'écran, le message envoyé « pour être sûr » : chacun révèle un manque de l'organisation actuelle.
- Gardez les exceptions. Le cas qui arrive une fois par mois prend souvent plus de temps que le cas courant.
- Chronométrez quelques tâches. Sans instrument particulier : notez l'heure de début et de fin d'une saisie, d'une recherche, d'une préparation de commande. Ces mesures serviront plus loin.
Rassemblez au passage les documents qui circulent : bons de commande, devis types, tableaux de suivi, e-mails de relance. Joints à l'expression des besoins, ils montrent au prestataire la réalité du travail mieux qu'une description, et lui évitent de deviner des formats.
Si l'essentiel de votre gestion tient aujourd'hui dans des tableurs, le guide pour remplacer Excel par un logiciel aide à voir ce qui mérite d'en sortir et ce qui peut y rester.
Qui interroger, et quelles questions poser
Interrogez chaque type d'utilisateur séparément : la personne qui saisit, celle qui valide, celle qui exploite les chiffres. Leurs attentes divergent souvent, et mieux vaut le découvrir avant le développement qu'après. Gardez les mêmes questions pour tous, afin de pouvoir comparer les réponses. Un entretien court, mené sur le poste de travail, en apprend souvent davantage qu'une réunion en salle : la personne montre au lieu de raconter.
- Que faites-vous, dans l'ordre, quand un nouveau dossier arrive ?
- Qu'est-ce qui vous fait perdre du temps chaque semaine ?
- Quelle erreur revient le plus souvent, et que coûte-t-elle quand elle arrive ?
- Quelle information cherchez-vous sans la trouver ?
- Qu'est-ce qui fonctionne bien aujourd'hui et ne doit pas changer ?
- Si vous ne pouviez changer qu'une seule chose, laquelle ?
- Qui d'autre faudrait-il interroger ?
La dernière question est souvent la plus utile. Elle fait apparaître la comptable qui ressaisit tout en fin de mois, ou le client qui appelle plusieurs fois pour connaître l'état de sa commande. Pensez aussi à ceux qui subissent l'organisation sans l'utiliser : clients, fournisseurs, sous-traitants.
Notez les réponses telles qu'elles sont dites, avec les mots des personnes. Un besoin formulé dans le vocabulaire de l'entreprise se comprend mieux, chez le prestataire, qu'une reformulation savante.
Trier : indispensable, utile, plus tard
Une expression des besoins honnête produit toujours plus de demandes que le budget n'en permet. Le tri se fait avant le développement, tant que chaque changement coûte encore peu.
- Indispensable : sans cela, l'outil ne remplace pas l'organisation actuelle et personne ne s'en servira.
- Utile : un gain réel, mais l'outil fonctionne sans. Candidat pour une deuxième étape.
- Plus tard : des idées intéressantes, sans usage démontré. Elles restent notées, hors chiffrage.
Pour trancher, posez une question à chaque demande : que se passe-t-il si l'outil ne le fait pas le premier jour ? Si la réponse est « on continue comme aujourd'hui pour ce point », la demande peut attendre une étape suivante.
Le même tri vaut pour les informations à enregistrer. Pour les données personnelles, la CNIL recommande de restreindre la collecte au strict nécessaire et de définir à l'avance leur durée de conservation. Chaque champ demandé « au cas où » devra être protégé, conservé, puis un jour supprimé.
Source : CNIL, Guide RGPD du développeur, consulté le 22 octobre 2026.
Ce tri prépare directement une première version du logiciel, limitée aux besoins indispensables et mise en service rapidement.
Mesurer avant, pour juger après
Un besoin bien exprimé s'accompagne d'une mesure de départ. Relevez pendant quelques semaines des chiffres simples, propres à votre entreprise : le temps de traitement d'une commande, le nombre de factures corrigées chaque mois, le nombre d'appels reçus pour connaître l'état d'un dossier.
Ces chiffres servent deux fois. Avant le projet, ils donnent un ordre de grandeur de ce que l'outil peut faire gagner, donc du budget raisonnable pour le projet. Après la mise en service, ils montrent si l'outil a tenu ce qu'on attendait de lui.
Exemple inventé pour l'illustration : si deux personnes passent chacune une heure par jour à ressaisir des commandes, cela fait dix heures par semaine. C'est ce temps que l'outil doit libérer, et c'est à lui qu'on compare le prix demandé. Notez aussi ce qui ne se compte pas en heures : une commande perdue, une pénalité de retard, un client qui ne revient pas.
À retenir Une expression des besoins tient en quelques pages : la situation actuelle, les problèmes constatés avec leurs mesures, les résultats attendus, les utilisateurs concernés et le tri entre indispensable, utile et plus tard.
Quand le besoin ne justifie pas un développement
L'expression des besoins peut aboutir à une conclusion simple : un logiciel du marché suffit. C'est souvent le cas quand vos besoins indispensables correspondent à une pratique courante (comptabilité, paie, facturation simple, prise de rendez-vous) et que vos particularités tiennent dans les réglages de l'outil. Le guide logiciel sur mesure ou standard détaille les critères de choix.
Le sur mesure se justifie quand vos règles de gestion sont propres à votre métier, quand plusieurs outils du marché devraient être reliés au prix de ressaisies permanentes, ou quand l'outil fait partie de ce qui vous distingue de vos concurrents.
Si votre expression des besoins a déjà débouché sur un devis d'agence, je peux le relire : sous 48 heures ouvrées, je réponds avec un prix fixe pour le même travail, ou avec les questions qui manquent pour l'établir, et je dis franchement quand le devis est déjà bien placé. Les repères de prix sont sur la page prix d'un logiciel métier sur mesure.
Dans tous les cas, le travail fait reste utile : il sert à paramétrer un outil du marché aussi bien qu'à rédiger le cahier des charges d'un logiciel sur mesure.
// sources
- AFNOR Boutique, fiche de la norme NF EN 16271 (décembre 2012), consulté le 22 octobre 2026
- CNIL, Guide RGPD du développeur, consulté le 22 octobre 2026