Besoin fonctionnel : passer d’une demande vague à une exigence testable
Un besoin fonctionnel décrit ce qu’un système doit permettre de faire pour répondre à une attente utilisateur ou à un objectif métier. Consulter un stock, modifier une adresse de livraison ou attribuer une tâche sont des exemples concrets. Pour guider un projet, cette attente doit ensuite devenir une exigence précise, priorisée et vérifiable : une simple liste de fonctionnalités ne suffit pas.
Distinguer l’objectif métier, la fonction attendue et l’exigence
Le besoin métier explique pourquoi le projet existe. Le besoin fonctionnel indique le service attendu du système. L’exigence fonctionnelle formalise ce service avec suffisamment de précision pour permettre sa réalisation et sa validation. Ces notions sont liées, mais elles ne se remplacent pas.
Prenons une équipe qui perd du temps à répartir ses tâches. Son objectif n’est pas nécessairement d’obtenir un nouvel écran : elle cherche d’abord à rendre les responsabilités visibles. L’attribution d’une tâche à un collaborateur constitue une réponse fonctionnelle possible, à confronter aux pratiques réelles.
| Notion | Question traitée | Exemple |
|---|---|---|
| Besoin métier | Quel problème résoudre ? | Éviter que des tâches restent sans responsable. |
| Besoin fonctionnel | Que doit-on pouvoir faire ? | Attribuer une tâche à un membre de l’équipe. |
| Exigence fonctionnelle | Quel comportement précis obtenir ? | Le responsable peut sélectionner un utilisateur actif et enregistrer son affectation à la tâche. |
| Exigence non fonctionnelle | Avec quelle qualité de fonctionnement ? | La liste contenant 100 tâches actives se charge en 2 secondes maximum, dans les conditions de test convenues. |
La fonctionnalité est la capacité proposée dans le produit pour répondre au besoin. La règle métier, elle, encadre son comportement : par exemple, une tâche clôturée ne peut plus être réattribuée. Distinguer ces niveaux évite de confondre l’objectif poursuivi avec une solution choisie trop tôt.
Reconnaître le fonctionnel et le non fonctionnel dans des cas concrets
Le fonctionnel porte sur les actions et les comportements attendus. Le non fonctionnel concerne notamment la performance, l’utilisabilité, la sécurité ou la maintenabilité. Les deux sont complémentaires : une fonction présente mais inutilisable en situation réelle ne répond pas correctement au besoin.
- E-commerce : ajouter, modifier ou supprimer un article du panier relève du fonctionnel. Rendre les pages accessibles depuis l’accueil en 3 clics maximum constitue un exemple d’objectif d’utilisabilité à préciser selon les parcours concernés.
- Application vidéo : lancer une vidéo est une fonction ; fixer son délai maximal de lancement à 5 secondes est une exigence de performance, avec des conditions réseau et matérielles à définir.
- Gestion des accès : attribuer des droits différents selon les rôles décrit un comportement fonctionnel contribuant à la sécurité.
- ERP : enregistrer une réception de marchandises et mettre à jour le stock sont des fonctions ; supporter une augmentation du volume d’activité relève de l’évolutivité.
La frontière demande parfois de décomposer la demande. « Sécuriser les données » est trop général : cela peut conduire à des fonctions de gestion des habilitations et à des contraintes de protection. De même, la conformité au RGPD ne se réduit pas à une fonctionnalité. Elle peut nécessiter des mécanismes d’information, de gestion du consentement lorsqu’il est requis ou d’exercice des droits, selon le traitement concerné.
Les qualités logicielles peuvent être structurées en s’appuyant sur des références comme ISO/CEI 25000. Pour le projet, l’essentiel reste de traduire chaque qualité attendue en conditions vérifiables, plutôt que de demander un système simplement « rapide » ou « intuitif ».
Recueillir les besoins sans recopier les habitudes existantes
Le recueil commence auprès des utilisateurs finaux, mais doit aussi inclure les responsables métier et les personnes intervenant en amont ou en aval du processus. L’analyste métier ou le Product Owner organise ces échanges ; les développeurs et les testeurs apportent leur regard sur la faisabilité et la vérification.
Croiser les demandes avec l’observation du travail
Les entretiens expliquent les difficultés, les ateliers confrontent les points de vue et les questionnaires élargissent la consultation. L’observation d’une opération réelle révèle aussi les besoins implicites : ressaisies, contrôles manuels, informations recherchées ailleurs ou exceptions gérées hors du logiciel.
Une procédure ancienne ressemble parfois à un sillon : à force d’y passer, on finit par croire que c’est le seul chemin possible. Lorsqu’un utilisateur réclame « le même tableau dans le nouvel outil », demandez quelle décision ce tableau permet de prendre et quelles colonnes sont réellement utilisées. Vous pourrez préserver l’information utile sans reproduire les détours, les doubles saisies et les validations devenues inutiles.
Structurer un ERP par processus et par échanges
Dans un cahier des charges ERP, classez les besoins par processus : comptabilité et finance, achats et stocks, ventes et CRM, ressources humaines, production et logistique. Vérifiez ensuite les passages entre domaines : une réception fournisseur peut alimenter le stock, puis le contrôle de facture. Cette lecture transversale évite des fonctions correctes isolément, mais incompatibles entre services.
Anticipez également les besoins d’intégration avec le CRM, la BI, le commerce en ligne ou un WMS de gestion d’entrepôt. L’ajout de modules, la gestion multi-entités ou multi-devises doivent correspondre à des perspectives identifiées, non à une accumulation de possibilités hypothétiques.
Rédiger une exigence que le métier et l’équipe technique comprennent
Une bonne formulation indique l’acteur, l’action, l’objet concerné et les conditions applicables. Elle reste centrée sur le comportement attendu, sans imposer inutilement un écran ou une technologie. Séparez les attentes indépendantes pour pouvoir les discuter et les tester individuellement.
La demande « mieux gérer les tâches » ne permet ni d’estimer le travail ni de prononcer une acceptation. Une user story peut amorcer la clarification : « En tant que responsable, je veux attribuer une tâche à un collaborateur afin que chacun connaisse son périmètre. » Elle doit être complétée par les règles et les critères d’acceptation.
Voici un scénario formulé avec la syntaxe Gherkin :
- Étant donné une tâche ouverte et un responsable autorisé à la modifier ;
- Quand il sélectionne un collaborateur actif et confirme l’affectation ;
- Alors le collaborateur est enregistré comme responsable et apparaît lors de la consultation suivante.
Ajoutez les exceptions : utilisateur désactivé, droit insuffisant, tâche clôturée ou enregistrement impossible. Pour chaque exigence, conservez un identifiant, son origine métier, un responsable de validation, ses dépendances et ses critères d’acceptation. Cette fiche rend les échanges plus fiables qu’un paragraphe mêlant plusieurs demandes.
Prioriser, valider et garder la trace des changements
La méthode MoSCoW distingue les indispensables (Must Have), les besoins importants mais non bloquants (Should Have), les options souhaitables (Could Have) et ce qui est exclu du périmètre considéré (Won’t Have). Cette dernière catégorie ne signifie pas nécessairement un abandon définitif.
Arbitrez selon la valeur métier, le risque, l’effort et les dépendances. Attribuer une tâche suppose, par exemple, de disposer d’utilisateurs identifiés. Une priorité élevée ne dispense donc pas d’organiser les prérequis. Si tout devient indispensable, revenez à l’objectif de la première version et aux conséquences concrètes d’un report.
Avant réalisation, faites valider les exigences et les critères par les représentants métier concernés. Lors de la recette, les utilisateurs vérifient les scénarios sur des cas représentatifs. Maintenez ensuite une chaîne de traçabilité : objectif métier → besoin → exigence → test.
Toute modification doit entraîner une analyse d’impact sur les règles, les intégrations, les délais et les tests. Consignez la décision et mettez à jour la version de référence : un besoin fonctionnel reste utile tant qu’il reflète une attente partagée, et pas seulement une demande formulée au début du projet.