Quelle technique de BA pour quel problème
Partager
En bref. À chaque type de problème correspond une famille de techniques de Business Analyse. Besoin flou : entretiens et observation. Trop d'idées : priorisation, en nommant d'abord qui arbitre. Périmètre contesté : modélisation de la portée — écrire noir sur blanc ce qui est dedans et ce qui est dehors. Désaccord sur qui décide : cartographie des parties prenantes. Solution décevante : évaluation. Nommer le problème avant l'outil évite l'erreur la plus coûteuse.
Chez Edelw'ice, le glacier artisanal lausannois fondé par Heidi en 1983, le projet de vente en ligne patine, et personne ne sait pourquoi. Lexie veut lancer un atelier ; Abby l'arrête : « on ne sait même pas quel problème on traite. Est-ce qu'on ne comprend pas le besoin, ou est-ce qu'on n'arrive pas à trancher ? Ce ne sont pas les mêmes outils. » La bonne technique commence toujours par le bon diagnostic.
Pourquoi partir du problème, pas de l'outil ?
Parce qu'une technique appliquée au mauvais problème ne donne rien — et fait croire que « la méthode ne marche pas ». Un atelier d'idéation ne résout pas un désaccord sur le périmètre ; une priorisation ne remplace pas la compréhension d'un besoin encore flou.
Abby veut poser le problème avant d'ouvrir sa boîte à outils ; Lexie veut vérifier sur le terrain que c'est le vrai problème. Les deux réflexes protègent de la même erreur : traiter un symptôme au lieu de la cause.
Quel problème appelle quelle technique
Repère la ligne qui ressemble à ta situation, puis regarde l'outil.
| Ton problème | La famille de technique | Un exemple concret |
|---|---|---|
| « On ne comprend pas le vrai besoin. » | Élicitation (faire émerger le vrai besoin) | Entretiens ciblés, observation sur le terrain. |
| « Trop d'idées, il faut trancher. » | Priorisation | Nommer l'arbitre, puis l'axe : impact × urgence côté métier, impact × effort côté équipe. |
| « Personne n'est d'accord sur ce qui est dans le projet. » | Cadrage du périmètre | Modélisation de la portée, glossaire partagé. |
| « On ne sait pas qui décide vraiment. » | Analyse des parties prenantes | Cartographie influence/intérêt des personnes que le projet touche ou qui peuvent l'influencer. |
| « Le processus est lent, sans savoir où. » | Analyse des processus | Cartographie du flux, repérage des points de blocage. |
| « On hésite entre deux options. » | Analyse décisionnelle | Critères d'acceptation, grille de décision. |
| « Faut-il vraiment investir là-dedans ? » | Justification | Business case (dossier qui justifie l'investissement), analyse financière. |
| « La solution livrée déçoit. » | Évaluation de la solution | Mesures d'usage, leçons apprises. |
Prioriser : d'abord l'arbitre, ensuite l'axe
La ligne « trop d'idées » est celle qui se rate le plus souvent, et pour une raison simple : on saute sur une matrice sans avoir dit qui tranche. Or les axes dépendent de l'arbitre. Le métier arbitre des fonctionnalités : il les compare en impact × urgence — ce que ça rapporte, et ce que coûte l'attente. L'équipe IT arbitre des tâches : elle les compare en impact × effort — la charge appartient à ceux qui la portent.
Mélanger les deux tables donne la réunion où chacun défend une case différente du même tableau. Les séparer donne deux arbitrages courts, chacun rendu par la personne qui en a le mandat. Quand il s'agit seulement de séparer l'indispensable du confort, MoSCoW (Must, Should, Could, Won't) suffit.
Le réflexe d'Abby. « Un problème mal nommé appelle toujours le mauvais outil. » Elle écrit le problème avant de choisir.
À quoi ça ressemble, chez Edelw'ice
En reformulant, Abby et Lexie découvrent deux problèmes empilés : d'abord « on ne comprend pas pourquoi les clients abandonnent leur commande » (élicitation → quelques entretiens), ensuite « on a dix améliorations possibles et un petit budget » (priorisation → l'équipe métier ordonne en impact × urgence). Deux problèmes, deux outils, dans l'ordre. L'atelier fourre-tout, lui, les aurait mélangés.
La même logique, hors de la Business Analyse
Un médecin ne prescrit pas avant de diagnostiquer : mêmes symptômes apparents, causes différentes, traitements différents. Un chef de projet, un entrepreneur ou un responsable marketing gagne à faire pareil : nommer précisément le problème avant de sortir la méthode. Le diagnostic vaut la moitié de la solution.
Ton diagnostic en trois gestes
- Écris le problème en une phrase qui commence par « le vrai problème, c'est… ».
- Range-le dans une famille : comprendre, prioriser, cadrer, décider, ou évaluer.
- Prends la technique de correspondance, applique-la, puis vérifie si un second problème apparaît derrière le premier.
Ce réflexe ne remplace pas l'expertise — mais il t'évite de traiter le mauvais problème avec le bon outil.
Questions fréquentes
Quelle technique utiliser quand le besoin est flou ?
Des techniques d'élicitation : entretiens ciblés et observation sur le terrain. Elles font émerger le vrai besoin au-delà de ce qui est dit spontanément, avant toute solution.
Quelle technique quand tout le monde veut tout, tout de suite ?
La priorisation — mais on nomme d'abord l'arbitre. Le métier arbitre des fonctionnalités et les compare en impact et en urgence ; l'équipe IT arbitre des tâches et les compare en impact et en effort. MoSCoW rend le même service en version grossière.
Comment savoir qui décide vraiment sur un projet ?
La cartographie des parties prenantes : on situe chaque personne selon son influence et son intérêt, pour repérer qui pèse réellement sur la décision.
Une technique suffit-elle par problème ?
Rarement seule sur toute la durée : on enchaîne souvent une technique pour comprendre, puis une autre pour structurer ou décider. C'est la mécanique des techniques liées.
Articles liés : Comment choisir la bonne technique de BA · Les techniques liées en Business Analyse · Prioriser ses tâches quand tout est « prioritaire »
