Quel problème métier cherchons-nous réellement à résoudre ?
Avec le recul, je me rends compte que les projets SI qui ont le plus dérapé dans ma carrière ne sont pas ceux qui manquaient de méthode, d’outils ou de compétences. Bien au contraire. Ils étaient souvent bien dotés, bien organisés, parfois même exemplaires sur le papier. Les livrables existaient, les comités se tenaient, les plannings étaient suivis, et chacun faisait sincèrement de son mieux.
Et pourtant, quelque chose se déséquilibrait progressivement.
Pas de crise ouverte au départ. Pas de signal fort. Juste une accumulation de petits renoncements, de compromis implicites, de décisions prises à moitié, souvent dans l’urgence, parfois par défaut. On avançait, mais sans vraiment se poser certaines questions pourtant fondamentales. Et quand ces questions finissaient par émerger, c’était souvent trop tard, dans un contexte déjà tendu, où chaque remise en question était perçue comme une menace.
Si j’ai voulu écrire cet article, ce n’est pas pour proposer une nouvelle méthode, ni une checklist miracle. C’est parce que, en tant que Business Analyst senior, puis coach et formatrice, j’observe depuis des années les mêmes schémas se répéter. Chez mes clients, chez mes élèves, chez des BA pourtant compétents, engagés, consciencieux, mais souvent fatigués et désorientés.
Pour approfondir le rôle et la posture du Business Analyst sur le terrain cliquez ici.
Les dix questions qui suivent ne sont pas théoriques. Je les ai forgées à partir de ma propre pratique et de celle des centaines de professionnels que j’accompagne. Elles ne garantissent pas le succès d’un projet, mais leur absence explique très souvent pourquoi un projet finit par perdre en stabilité.
1. Quel problème métier cherchons-nous réellement à résoudre ?
C’est sans doute la question la plus évidente en apparence, et pourtant l’une des plus mal traitées. Dans la majorité des projets SI, le besoin arrive déjà formulé sous forme de solution : refaire un outil, moderniser un système, déployer une nouvelle plateforme, automatiser un processus. Ces demandes sont rarement absurdes, mais elles court-circuitent une étape essentielle : comprendre le problème réel.
La réussite d’un projet SI repose d’abord sur les bonnes analyses, au bon moment.
Téléchargez la checklist des 10 analyses indispensables pour réussir vos projets SI
Avec l’expérience, j’ai appris à me méfier des besoins trop clairs, trop rapides, trop bien emballés. Ils masquent souvent un symptôme, pas la cause. Or, travailler sérieusement sur le mauvais problème reste du travail sérieux, mais c’est du travail perdu.
Cette question n’a pas vocation à remettre en cause le métier ou à ralentir le projet. Elle sert à éviter que l’on investisse des mois d’efforts dans une solution qui ne fera que déplacer le problème ailleurs.
3. Comment saura-t-on que le projet est un succès, et pour qui ?
Cette question révèle presque toujours des divergences profondes. Ce qui constitue un succès pour l’IT n’est pas nécessairement un succès pour le métier. Ce qui rassure la direction financière ne correspond pas toujours à ce que vivent les équipes opérationnelles.
Dans beaucoup de projets, les critères de succès restent flous, implicites, consensuels en surface, mais contradictoires en profondeur. Tant que tout va bien, ce flou est supportable. Dès que la pression monte, il devient explosif.
Clarifier les critères de succès ne supprime pas les tensions, mais cela permet de les rendre visibles et donc arbitrables. Un projet sans définition claire de sa réussite est condamné à des décisions au feeling.
4. Qui peut réellement dire non ?
Le rôle réel du Business Analyst
Les organigrammes donnent une illusion de clarté. La réalité du pouvoir est souvent ailleurs. Dans les projets complexes, certaines personnes, parfois peu visibles, ont une capacité réelle à bloquer, ralentir ou remettre en cause des décisions pourtant validées formellement.
Découvrez les différences de rôles et responsabilités projet.
Le rôle du Business Analyst n’est pas de décider à la place des autres, mais de rendre visibles les circuits de décision réels, pas seulement théoriques.
5. Quelles décisions sont prises par défaut ?
Avec le temps, j’ai appris que les décisions les plus structurantes d’un projet ne sont pas toujours celles qui font l’objet de longs débats. Ce sont souvent celles qui sont prises par défaut, faute de temps, de cadre ou de responsable clairement identifié.
Ne pas décider est une décision. Continuer sans validation explicite est un choix. Et ces choix, lorsqu’ils ne sont pas nommés, deviennent des bombes à retardement.
Quand un projet commence à dériver, on constate presque toujours que personne ne se sent responsable de certaines orientations pourtant déterminantes.
6. Qu’est-ce qui est explicitement hors périmètre ?
Tant que ce qui est exclu n’est pas clairement nommé, chacun projette ses propres attentes sur le projet. Et ce flou alimente les frustrations, les incompréhensions et les dérives de périmètre.
Découvrez la gestion du périmètre et des attentes.
Dire qu’un sujet est hors périmètre ne signifie pas qu’il est sans importance. Cela signifie qu’il ne sera pas traité maintenant, dans ce cadre précis. Les projets les plus matures sont ceux qui savent renoncer proprement, sans ambiguïté.
7. Où vivent réellement les règles métier ?
Sur le papier, les règles métier sont souvent censées être “dans les spécifications”. Sur le terrain, elles sont disséminées : dans plusieurs systèmes, dans des paramétrages anciens, dans des traitements spécifiques, parfois même dans des fichiers Excel maintenus en parallèle.
Cette dispersion crée une fragilité structurelle. Plus un SI est ancien, plus certaines règles critiques sont dupliquées ou implicites. Clarifier où vivent réellement ces règles, et ce qui se passe lorsqu’elles divergent, est essentiel pour éviter des régressions graves.
8. Quels scénarios métier n’avons-nous pas le droit de rater ?
Les tests arrivent presque toujours sous contrainte. Le temps manque, les équipes sont fatiguées, les environnements instables. Dans ce contexte, vouloir tout tester est illusoire.
Ce qui fait la différence, c’est la capacité à identifier les scénarios réellement critiques : ceux qui, s’ils échouent, ont des conséquences financières, légales ou opérationnelles majeures. Tester moins, mais tester ce qui fait vraiment peur, est souvent beaucoup plus efficace qu’une couverture de tests artificiellement exhaustive.
9. Sur quels critères arbitrons-nous quand tout devient urgent ?
Lorsque la pression monte, les projets ont tendance à arbitrer selon des critères implicites : le poids hiérarchique, le volume sonore, la facilité technique, ou l’ordre d’arrivée des demandes. Ces arbitrages ne sont pas neutres et orientent durablement le projet.
Mettre à plat des critères de priorisation explicites — objectifs, risques, dépendances, effort — ne supprime pas les tensions, mais permet de sortir d’une logique purement réactive.
10. Qu’est-ce qui empêche aujourd’hui les équipes de travailler proprement ?
La fatigue des équipes est souvent traitée comme un problème individuel. Dans la réalité, elle est presque toujours le symptôme d’un problème systémique. Quand les équipes prennent des raccourcis ou bricolent des solutions temporaires, ce n’est généralement pas par manque de professionnalisme, mais parce que le cadre ne leur permet plus de travailler sereinement.
Un projet qui épuise ses équipes est un projet en déséquilibre, même si ses indicateurs semblent encore acceptables.
Conclusion
Avec le temps, j’ai compris que les projets SI ne dérivent pas parce que les équipes sont incompétentes ou de mauvaise volonté. Ils dérivent parce que certaines questions sont jugées trop dérangeantes pour être posées tôt, et finissent par s’imposer quand il n’y a plus beaucoup de marge de manœuvre.
Le rôle du Business Analyst, tel que je le conçois aujourd’hui, n’est pas de produire des livrables rassurants ou de faire avancer un projet coûte que coûte. Il est de rendre visibles les zones floues, les décisions implicites et les déséquilibres naissants, tant qu’il est encore possible d’agir sans crise.
La vraie question n’est donc pas de savoir si ces dix questions sont pertinentes. Elle est beaucoup plus simple, et beaucoup plus inconfortable : laquelle n’a pas encore été posée sur votre projet actuel, et qu’est-ce que cela dit de la trajectoire que vous êtes en train de prendre ?
