Dans un projet Finance ou SI, l’expression de besoin commence souvent par une fonctionnalité : « nous voulons un export Excel », « il nous faut un nouveau champ », « ajoutez une étape de validation » ou « nous avons besoin d’un tableau de bord ».
Ces demandes sont légitimes. Elles proviennent d’utilisateurs qui connaissent leur activité, leurs contraintes et les difficultés rencontrées au quotidien.
Mais une fonctionnalité demandée n’est pas encore un besoin métier correctement qualifié.
Elle constitue une réponse déjà imaginée à un problème qui, lui, reste parfois implicite. Si le projet reprend directement cette solution dans les spécifications, il peut livrer ce qui a été demandé sans résoudre ce qui devait réellement l’être.
Le rôle de l’AMOA consiste précisément à éviter ce raccourci. Elle doit remonter de la solution pressentie vers l’irritant, l’usage, les règles métier et le résultat attendu, puis transformer ces éléments en exigences compréhensibles, testables et priorisables.
Pourquoi les métiers expriment-ils souvent une solution ?
Lorsqu’un utilisateur rencontre régulièrement un problème, il cherche naturellement un moyen de le contourner.
Avec le temps, ce contournement devient la référence à partir de laquelle il formule sa demande. Il ne dit plus : « je ne parviens pas à contrôler les écarts avant la clôture ». Il demande : « je veux un export Excel ».
Il ne dit plus : « la facture reste bloquée parce que personne ne sait qui doit la valider ». Il demande : « ajoutez une relance automatique ».
Il ne dit plus : « nous ne partageons pas la même définition de l’indicateur ». Il demande : « créez un nouveau tableau de bord ».
Cette manière de s’exprimer n’est pas une erreur. Elle traduit une connaissance concrète du terrain. En revanche, elle ne suffit pas pour engager une conception ou un développement.
L’AMOA doit reconnaître la valeur de la demande tout en conservant la possibilité d’examiner d’autres réponses.
Une même fonctionnalité peut masquer plusieurs besoins
Prenons l’exemple de l’export Excel, fréquent dans les projets Finance.
Derrière cette fonctionnalité peuvent se cacher des besoins très différents :
- rapprocher des écritures issues de deux systèmes non intégrés ;
- identifier les anomalies avant la clôture ;
- transmettre une liste à un acteur qui ne dispose pas d’un accès à l’application ;
- enrichir manuellement des données absentes du système ;
- recalculer un indicateur non disponible dans le reporting ;
- conserver une preuve pour un contrôle interne ou un audit ;
- alimenter un traitement qui devrait, à terme, être automatisé.
Si le besoin réel est un rapprochement récurrent entre deux systèmes, l’export peut n’être qu’un palliatif. Une interface ou une règle de contrôle automatisée pourrait être plus pertinente.
Si le problème est l’absence d’accès d’un utilisateur occasionnel, la réponse peut concerner les habilitations ou la diffusion d’un rapport.
Si l’objectif est de constituer une piste d’audit, le format, l’horodatage, l’intégrité et l’archivage du document deviennent plus importants que le simple bouton de téléchargement.
La bonne solution dépend donc du problème, du contexte et du résultat attendu.
Les quatre niveaux d’une expression de besoin utile
1. L’irritant ou le problème observé
Il faut d’abord décrire la situation actuelle sans présupposer la solution.
Les questions utiles sont notamment :
- qui rencontre le problème ?
- dans quelle étape du processus ?
- à quelle fréquence ?
- avec quel volume ?
- quelles opérations manuelles sont nécessaires ?
- quelles erreurs, quels retards ou quels risques en résultent ?
- quels autres acteurs sont affectés ?
Une formulation exploitable pourrait être :
Lors de chaque clôture mensuelle, les équipes comptables consacrent plusieurs heures à rapprocher manuellement les données de facturation et les écritures comptables, faute d’un contrôle commun entre les deux systèmes.
Cette phrase décrit un problème, des utilisateurs, un moment du processus et une conséquence. Elle laisse encore ouvertes plusieurs options de solution.
2. L’usage ou l’objectif métier
Le deuxième niveau précise ce que l’utilisateur doit pouvoir accomplir.
Il ne s’agit pas encore de décrire un écran ou un bouton, mais un résultat fonctionnel :
- contrôler les écarts avant la validation de la clôture ;
- identifier les factures sans commande ;
- orienter une demande vers le bon valideur ;
- suivre les exceptions nécessitant une intervention ;
- justifier la donnée ayant conduit à une décision.
Cette formulation permet de recentrer le projet sur la valeur attendue.
3. Les règles et contraintes métier
Le besoin doit ensuite être encadré par les règles qui déterminent le fonctionnement attendu.
Dans un projet Finance, elles peuvent concerner :
- les données obligatoires ;
- les seuils de validation ;
- la séparation des tâches ;
- les profils d’habilitation ;
- les règles comptables ou fiscales ;
- les délais de traitement ;
- les cas d’exception ;
- la traçabilité et la conservation des preuves ;
- les systèmes sources et les référentiels de référence.
Une règle métier ne doit pas rester implicite. Deux services peuvent employer les mêmes mots tout en appliquant des contrôles ou des périmètres différents.
Le travail de l’AMOA consiste alors à faire émerger ces différences, à les documenter et à obtenir les arbitrages nécessaires.
4. Le résultat attendu et la preuve de satisfaction
Une exigence utile doit pouvoir être vérifiée.
Avant même la conception détaillée, il faut se demander comment les équipes sauront que le besoin est satisfait.
Le critère peut être fonctionnel :
- l’utilisateur identifie l’ensemble des écarts avant la validation ;
- chaque facture est orientée vers le valideur correspondant aux règles définies ;
- l’historique permet de retrouver l’auteur, la date et le contenu de chaque validation.
Il peut également porter sur la performance ou la qualité :
- le contrôle est réalisé dans un délai défini ;
- les données sont complètes et rapprochées selon les règles validées ;
- l’utilisateur n’effectue plus de ressaisie entre les deux applications.
Ces critères préparent directement les scénarios de recette. Ils évitent les validations subjectives du type « cela semble conforme » ou « l’écran répond globalement au besoin ».
Les questions que l’AMOA doit poser
Lorsqu’une fonctionnalité est demandée, l’objectif n’est pas de la contester systématiquement. Il faut la qualifier.
Une trame simple peut être utilisée en atelier :
- Que cherchez-vous à faire au moment où vous utilisez cette fonctionnalité ?
- Comment réalisez-vous cette tâche aujourd’hui ?
- Qu’est-ce qui vous empêche d’atteindre le résultat attendu ?
- Qui utilise l’information produite ensuite ?
- Quelles règles ou validations doivent être respectées ?
- Quels cas particuliers doivent être traités ?
- Quelle conséquence aurait l’absence de solution ?
- Comment vérifierons-nous que le problème est réellement résolu ?
Ces questions permettent de passer d’une demande isolée à une compréhension du processus de bout en bout.
Expression de besoin AMOA : du besoin métier à l’exigence fonctionnelle
Une fois le problème compris, l’AMOA peut rédiger une exigence qui décrit le comportement attendu sans enfermer inutilement la solution.
Une exigence de qualité doit être :
- claire : elle ne doit pas permettre plusieurs interprétations ;
- unitaire : elle porte sur un comportement ou une règle identifiable ;
- justifiée : elle est reliée à un besoin ou à un risque métier ;
- priorisée : son importance est connue ;
- traçable : son origine, ses évolutions et sa validation sont conservées ;
- testable : un critère permet de démontrer sa conformité.
Au lieu d’écrire :
Le système doit proposer un export Excel des factures.
Il peut être plus utile de commencer par :
Le responsable comptable doit pouvoir identifier, avant la clôture mensuelle, les factures dont les données ne correspondent pas aux écritures intégrées, selon les règles de rapprochement validées.
La conception déterminera ensuite si la meilleure réponse est un export, une vue de contrôle, une alerte, une interface ou une combinaison de plusieurs mécanismes.
Ce que cette approche change pour le projet
Une meilleure priorisation
Les demandes ne sont plus classées uniquement selon l’urgence perçue ou l’influence du demandeur. Elles peuvent être comparées selon leur impact, leur fréquence, les risques associés et la valeur attendue.
Moins de fonctionnalités inutilisées
Une solution conçue autour d’un usage vérifié a plus de chances d’être adoptée qu’une accumulation de fonctions demandées séparément.
Une recette plus objective
Les critères de satisfaction définis en amont deviennent des conditions de validation. La recette vérifie que le besoin est couvert, pas seulement que le bouton fonctionne.
Une meilleure relation entre les métiers et la DSI
La DSI reçoit des exigences contextualisées et arbitrées. Les métiers conservent la visibilité sur la manière dont leur problème a été compris et pris en charge.
Une maîtrise accrue du périmètre
Lorsqu’une nouvelle demande apparaît, le projet peut déterminer si elle répond à un besoin déjà identifié, si elle modifie une règle ou si elle constitue réellement une extension du périmètre.
L’AMOA ne doit être ni un simple scribe ni un prescripteur isolé
L’AMOA n’a pas pour rôle de recopier toutes les demandes dans un cahier des charges. Elle ne doit pas non plus décider seule de ce qui serait bon pour les utilisateurs.
Sa valeur réside dans la traduction et la mise en cohérence :
- écouter l’utilisateur sans réduire son besoin à la première solution proposée ;
- comprendre le processus et les contraintes ;
- faire apparaître les règles implicites ;
- identifier les divergences entre acteurs ;
- organiser les arbitrages ;
- formaliser des exigences compréhensibles par les métiers et la DSI ;
- préparer les conditions de validation.
La démarche officielle beta.gouv recommande elle aussi de repartir du problème rencontré par les utilisateurs plutôt que d’une solution pressentie. DesignGouv place la clarification du besoin et des objectifs parmi les activités des phases exploratoires de conception numérique.
Cette logique s’applique pleinement aux projets d’entreprise, notamment lorsque les processus Finance, les données, les contrôles et les systèmes d’information sont étroitement liés.
Avant de spécifier, reformuler
Une demande de fonctionnalité constitue un point de départ précieux. Elle exprime un irritant et souvent une idée issue de l’expérience du terrain.
Mais avant de l’inscrire dans les spécifications, l’AMOA doit pouvoir reformuler :
- le problème rencontré ;
- les utilisateurs concernés ;
- l’usage à rendre possible ;
- les règles à respecter ;
- le résultat attendu ;
- la manière dont ce résultat sera validé.
Ce n’est qu’après cette qualification que la fonctionnalité peut être évaluée parmi les différentes options de solution.
Un projet ne crée pas de valeur parce qu’il livre davantage de fonctions. Il crée de la valeur lorsqu’il résout les bons problèmes de manière fiable, compréhensible et mesurable.
BAZIRE CONSULTING accompagne les directions Finance, les métiers et les DSI dans le cadrage des besoins, l’analyse des processus, la formalisation des exigences et la sécurisation des projets de transformation Finance & SI.
Sources : beta.gouv.fr et DesignGouv/DINUM.
