Recueillir le besoin : parties prenantes et entretiens

Le rôle de l’analyste métier

L’analyste métier (business analyst) traduit un problème d’entreprise en exigences claires qu’une équipe peut construire et tester. Il ne commence pas par la solution : il cherche d’abord à comprendre quel problème on résout, pour qui, et comment on saura que c’est réussi.

Fil rouge du cours : l’enseigne fictive Les Paniers du Coin veut informatiser la préparation des commandes en ligne retirées en magasin.

Identifier les parties prenantes

Une partie prenante est toute personne ou équipe affectée par le projet ou capable de l’influencer : la direction qui finance, les utilisateurs quotidiens (préparateurs, clients), le service informatique qui maintiendra l’outil, le délégué à la protection des données, la comptabilité… Oublier une partie prenante, c’est découvrir une exigence bloquante trop tard.

On les classe dans une matrice pouvoir / intérêt :

	Intérêt faible	Intérêt fort
Pouvoir fort	Garder satisfaits	Gérer étroitement
Pouvoir faible	Surveiller	Tenir informés

Les parties prenantes à « gérer étroitement » participent aux ateliers et valident les décisions ; celles à « tenir informées » reçoivent des comptes rendus réguliers et peuvent être interrogées sur leur quotidien.

Conduire un entretien ou un atelier

L’entretien individuel permet d’aller en profondeur avec une personne ; l’atelier réunit plusieurs parties prenantes pour confronter les points de vue et décider. Dans les deux cas :

1. Préparez : objectif, liste de thèmes, documents existants (procédures, tableurs, captures).
2. Faites raconter : « Montrez-moi comment vous traitez une commande aujourd’hui. » Observer le poste de travail révèle les contournements (tableurs parallèles, post-it).
3. Questionnez ouvert et relancez : « Que se passe-t-il quand un produit manque ? », « À quelle fréquence ? ».
4. Reformulez pour vérifier votre compréhension : « Si je résume, vous… ».
5. Rédigez un compte rendu dans la journée et faites-le valider par l’interlocuteur.

Remonter de la solution au besoin

Les interlocuteurs expriment souvent une solution : « Il nous faut un export Excel. » Ce n’est pas faux, mais c’est rarement le vrai besoin. La technique des 5 pourquoi consiste à demander « pourquoi ? » plusieurs fois :

« Il nous faut un export Excel. »
  Pourquoi ? « Pour compter les commandes par créneau. »
  Pourquoi ? « Pour savoir combien de préparateurs placer chaque matin. »
→ Besoin : connaître chaque matin le nombre de commandes à préparer par créneau.

Le besoin ouvert laisse plusieurs solutions possibles (un export, un écran de planification, une alerte) ; l’équipe choisira la meilleure.

Exigences fonctionnelles et non fonctionnelles

• Une exigence fonctionnelle décrit ce que le système fait : « Le préparateur peut marquer une commande comme prête. »
• Une exigence non fonctionnelle décrit comment il le fait, ou sous quelles contraintes : temps de réponse, disponibilité, sécurité, accessibilité, hébergement des données, réglementation.

Les exigences non fonctionnelles sont souvent oubliées car personne ne les formule spontanément. Posez la question explicitement : combien d’utilisateurs simultanés ? Que se passe-t-il si l’outil est indisponible ? Quelles données personnelles sont traitées ?

Une bonne exigence est mesurable : « rapide » ne se teste pas ; « la liste des commandes s’affiche en moins de 2 secondes pour 500 commandes » se teste.

À retenir

• Comprendre le problème avant la solution.
• Cartographier les parties prenantes et adapter leur implication.
• Questions ouvertes, observation, reformulation, compte rendu validé.
• Exigences fonctionnelles et non fonctionnelles, toujours mesurables.