Formuler un besoin, ce n’est pas rédiger une liste de souhaits. C’est traduire une attente concrète en exigences suffisamment précises pour que toute l’équipe projet comprenne la même chose. Plusieurs méthodes permettent de formuler le besoin, mais toutes partagent un principe : séparer ce que l’on attend du résultat de la manière dont on compte l’obtenir.
Formuler le besoin avant de penser à la solution technique
Vous avez déjà vu un projet démarrer par le choix d’un outil ou d’une technologie ? Le risque est de construire une réponse à un problème mal défini. La formulation du besoin intervient avant le cahier des charges, avant le choix d’un prestataire, parfois même avant de savoir si un projet sera lancé.
Lire également : Quelle est la partie la plus difficile des ressources humaines ?
Formuler le besoin, c’est répondre à trois questions simples : à qui le futur produit ou service rend-il service ? Sur quoi agit-il ? Dans quel but ? Ces trois questions constituent le socle de la méthode dite de la bête à cornes, utilisée en analyse fonctionnelle.
Prenons un exemple. Une association veut permettre à ses adhérents de réserver des salles en ligne. Le besoin n’est pas « un site web avec un calendrier ». Le besoin est : permettre aux adhérents de vérifier la disponibilité d’une salle et de la réserver sans passer par le secrétariat. La nuance est capitale. La première formulation impose une solution. La seconde laisse le champ ouvert.
A lire également : Quelle est une citation célèbre sur les comptables ?
Méthode QQOQCPC : poser les bonnes questions pour cadrer le besoin
La méthode QQOQCPC est un outil d’analyse qui consiste à explorer un besoin sous sept angles : Quoi, Qui, Où, Quand, Comment, Pourquoi, Combien. Chaque question force à préciser un aspect que l’on aurait pu négliger.
Chaque réponse élimine une zone d’ambiguïté dans la formulation. « Quoi » identifie la nature du besoin. « Qui » désigne les parties prenantes concernées. « Où » et « Quand » situent le contexte d’usage. « Comment » décrit la forme sous laquelle le besoin se manifeste. « Pourquoi » remonte à la cause. « Combien » dimensionne le périmètre.
Reprenons l’exemple de l’association :
- Quoi ? Réserver une salle sans intervention humaine du secrétariat.
- Qui ? Les adhérents actifs, soit plusieurs dizaines de personnes aux profils variés (bénévoles, salariés, retraités).
- Où ? Depuis n’importe quel appareil connecté, y compris un téléphone portable.
- Quand ? En dehors des horaires d’ouverture du bureau.
- Comment ? En visualisant un planning et en confirmant un créneau.
- Pourquoi ? Parce que les appels téléphoniques saturent le secrétariat et génèrent des doublons de réservation.
- Combien ? Trois salles à gérer, avec une moyenne de plusieurs réservations par semaine.
Cette grille ne produit pas directement un cahier des charges. Elle produit une expression de besoins structurée, qui servira de base à la rédaction des exigences fonctionnelles.
Exigences vérifiables : le critère qui sépare un besoin flou d’un besoin exploitable
Un besoin bien formulé doit pouvoir être vérifié. Dire « l’interface doit être intuitive » n’est pas un besoin exploitable, parce qu’aucun test ne permet de le confirmer ou de l’infirmer objectivement.
La norme ISO/IEC/IEEE 29148:2018 insiste sur ce point : chaque exigence doit être claire, traçable et vérifiable. En pratique, cela signifie qu’on associe à chaque besoin une méthode de preuve, qu’il s’agisse d’un test, d’une analyse, d’une démonstration ou d’une inspection.
Reformulons l’exigence précédente. Au lieu de « l’interface doit être intuitive », on écrit : « un utilisateur n’ayant jamais utilisé l’outil doit pouvoir réserver une salle en moins de trois étapes, sans aide extérieure. » Cette formulation décrit un comportement observable. On peut le tester.
Distinguer besoin et contrainte
Un besoin décrit ce que le résultat doit accomplir. Une contrainte décrit une limite imposée par l’environnement : budget, délai, réglementation, compatibilité technique. Les deux se formulent dans l’expression de besoins, mais dans des sections distinctes.
Par exemple, si le projet implique la collecte de données personnelles (adresses email des adhérents), le RGPD impose d’intégrer la protection des données dès la conception. Ce n’est pas un besoin fonctionnel, c’est une contrainte réglementaire. Elle doit apparaître tôt dans le cadrage, pas en fin de projet.
Diagramme pieuvre et analyse fonctionnelle : cartographier les interactions
Quand le besoin concerne un produit ou un système qui interagit avec plusieurs éléments extérieurs, le diagramme pieuvre aide à visualiser ces relations. Il place le produit au centre et relie chaque élément de son environnement (utilisateur, énergie, normes, maintenance) par des fonctions.
On distingue deux types de fonctions :
- Les fonctions principales, qui justifient l’existence du produit (relier l’utilisateur à un service).
- Les fonctions de contrainte, qui traduisent les exigences imposées par l’environnement (résister à l’humidité, respecter une norme).
Cette cartographie évite un piège fréquent : oublier un acteur ou une interaction. Le concurrent qui rédige un cahier des charges sans avoir identifié le technicien de maintenance comme partie prenante risque de livrer un produit difficile à réparer.
Quand utiliser quelle méthode
QQOQCPC convient aux phases de cadrage rapide, quand on cherche à poser les bases. La bête à cornes aide à valider que le besoin est légitime. Le diagramme pieuvre entre en jeu quand le produit interagit avec un environnement complexe. Ces outils ne s’excluent pas, ils se complètent à des étapes différentes du projet.
L’expression de besoins n’est pas un document figé. Elle évolue au fil des échanges avec les parties prenantes et gagne à être relue par quelqu’un qui n’a pas participé à sa rédaction. Un besoin que seul son auteur comprend n’est pas encore formulé.
