Le rôle de l’analyste d’affaires dans les projets TI : relier besoins et technologie

Le directeur des opérations d’un distributeur de Laval arrive à la première rencontre avec la solution déjà choisie : « Il nous faut un module de gestion d’entrepôt, comme chez notre concurrent. » Personne n’a encore décrit le problème. Trois mois plus tard, on découvre que les ruptures de stock venaient des prévisions de ventes, pas de l’entrepôt.

C’est précisément pour éviter ce scénario qu’existe le rôle de l’analyste d’affaires dans les projets TI.

Les statistiques citées proviennent de rapports publics de PMI, de l’IIBA, de Gartner et de McKinsey; les repères d’effort sont des observations de PlanAxion.

Selon l’étude Pulse of the Profession de PMI sur la gestion des exigences, près de la moitié (47 %) des projets qui échouent ratent leurs objectifs à cause d’une gestion inexacte des exigences.

Quel est le rôle de l’analyste d’affaires dans un projet TI ?

Le rôle de l’analyste d’affaires dans un projet TI consiste à comprendre le problème d’affaires, à en formuler les besoins et les exigences, puis à guider le client et l’équipe technique vers une solution qui règle ce problème plutôt qu’un symptôme. Il se situe entre deux mondes, celui des affaires et celui de l’informatique, et ses tâches naviguent constamment entre les deux.

Concrètement, il pose les bonnes questions. Il documente les hypothèses, les contraintes, l’essentiel des besoins d’affaires, les exigences fonctionnelles et non fonctionnelles, et il cible les objectifs du client. L’IIBA définit d’ailleurs l’analyse d’affaires comme la pratique qui permet le changement en définissant les besoins et en recommandant des solutions qui créent de la valeur pour les parties prenantes.

Ce rôle s’insère dans une équipe. Il complète celui du gestionnaire de projet, de l’architecte et des experts fonctionnels décrits dans notre article sur les rôles clés d’une équipe de projet.

Pourquoi l’analyste d’affaires commence-t-il par le problème et non par la solution ?

L’analyste d’affaires évalue le problème avant toute solution parce qu’un client pressé privilégie presque toujours la solution qu’il connaît, et qu’une solution appliquée au mauvais problème produit un retour de bâton prévisible à moyen terme. C’est d’abord un spécialiste, et son mandat tient malgré l’empressement du client.

Par son expertise, il est l’allié des utilisateurs. Il délimite précisément le domaine d’affaires dans lequel ils évoluent, puis il met son savoir-faire à leur service. Il instaure aussi un climat de collaboration dans son équipe. Généraliste outillé, il a ce qu’il faut pour mener sa mission.

Les chiffres justifient cette insistance. Gartner rapporte que 75 % des stratégies ERP ne sont pas fortement alignées sur la stratégie d’entreprise, ce qui mène à la confusion et à des résultats décevants. Sans quelqu’un dont le métier est de relier le besoin d’affaires à la solution, cet alignement ne se fait pas tout seul.

Comment l’analyste d’affaires choisit-il la méthode de travail : itératif, agile ou cascade ?

L’analyste d’affaires choisit la méthode selon sa compréhension du domaine d’affaires et des exigences du client, car itératif, agile et cascade produisent essentiellement les mêmes livrables, mais par des chemins différents. Le contenu reste à peu près le même; la façon d’atteindre l’objectif change.

Quand il élabore un système TI, l’analyste s’appuie avant tout sur l’étude des fonctions et des données, c’est-à-dire sur ce que l’utilisateur fait réellement dans le système. Ses outils servent à dégager les règles, les contraintes et les attentes envers le système. Trois méthodes reviennent dans sa pratique.

Le mode itératif. On livre les parties d’un système à intervalles réguliers. Chaque itération enchaîne analyse des besoins et activités menant à des solutions approximatives, qui construisent graduellement le produit final.

Le mode agile. Bâti sur un cycle itératif, il reprend plusieurs artefacts du mode précédent et met l’accent sur la capacité à s’adapter aux exigences qui bougent. Les noms changent, mais il s’agit toujours de décrire ce que l’utilisateur accomplit avec le système.

Le mode cascade. Une succession d’étapes où chaque phase doit être validée avant de passer à la suivante. Moins à la mode que l’agile, il reste adapté aux projets d’envergure et offre une vision précise des délais de réalisation.

Quelques repères chiffrés pour situer l’enjeu :

• 47 % des projets qui échouent ratent leurs objectifs à cause d’une gestion inexacte des exigences (PMI, Pulse of the Profession, 2014).
• 75 % des stratégies ERP ne sont pas fortement alignées sur la stratégie d’entreprise (Gartner, 2026).
• 45 % de dépassement budgétaire moyen pour les grands projets TI, dont la cause première est la gestion de la stratégie et des parties prenantes (McKinsey et Université d’Oxford, 2012).
• Jusqu’à 100 % d’amélioration de la performance d’un projet grâce aux bons experts, capables d’interpréter les données et de juger (McKinsey et Université d’Oxford, 2012).
• Six domaines de connaissance structurent le BABOK Guide, la norme mondiale de l’analyse d’affaires (IIBA).
• 1 analyste d’affaires pour 2 à 3 processus majeurs dans une implantation de progiciel de taille intermédiaire, selon les observations de PlanAxion.

Pourquoi faut-il comprendre le présent avant de concevoir le futur ?

Il faut comprendre la situation d’affaires actuelle avant de penser aux solutions, parce que chaque client et chaque utilisateur ont des particularités que l’analyste doit déchiffrer pour adapter l’outil et en tirer le maximum. Envisager le futur sans avoir examiné le processus d’affaires actuel est déconseillé, et c’est pourtant la tentation de tout projet pressé.

La clé est d’impliquer le client et d’écouter ses besoins jusqu’à ce qu’il confie ses véritables attentes. L’analyste enquête, élabore des scénarios et en mesure les effets. Il fouille aussi les systèmes existants pour en trouver les exceptions et les limites, celles que personne ne mentionne en atelier parce qu’elles sont devenues invisibles.

Cette démarche a une méthode. Nous l’avons décrite dans notre guide sur l’évaluation des besoins d’affaires à partir des meilleures pratiques de l’industrie. McKinsey note d’ailleurs que les équipes intégrées affaires et TI, présentes de la définition des exigences jusqu’aux tests, évitent les malentendus aux transitions de phase.

Un client sait presque toujours quelle solution il veut; le travail de l’analyste d’affaires est de découvrir quel problème il a.

Qu’est-ce qu’un bon analyste d’affaires ?

Un bon analyste d’affaires est un spécialiste qui aime décortiquer les problèmes pour trouver des solutions, qui maîtrise à la fois les affaires et les technologies de l’information, et qui sait expliquer des notions techniques à un public non technique. Il fait preuve de leadership en se tenant entre le client et l’équipe TI.

Il parle la langue des deux camps, interprète ce que chacun dit, comprend les limites et les contraintes du système. Il travaille étroitement avec l’architecte, dont nous avons décrit le rôle de l’architecte de solutions en 2026 : l’un formule le besoin, l’autre conçoit la réponse technique.

Son défi ultime : amener le client à envisager la solution adéquate sans perdre de vue la source du problème. C’est ce qui évite le cas classique où l’on livre exactement ce qui a été demandé, et où le problème est toujours là.

Faut-il un analyste d’affaires dans chaque projet TI ?

Oui, dès que le projet touche un processus d’affaires, parce que la gestion des exigences est en cause dans près de la moitié des échecs selon PMI, et que personne d’autre dans l’équipe n’a ce mandat à temps plein. Un gestionnaire de projet gère le calendrier; un architecte conçoit la solution. Traduire le besoin, c’est un métier à part.

Questions fréquentes

Quelle est la différence entre un analyste d’affaires et un gestionnaire de projet ?

Le gestionnaire de projet est responsable du calendrier, du budget, des ressources et des risques. L’analyste d’affaires est responsable du contenu : comprendre le problème, formuler les besoins et les exigences, et s’assurer que la solution y répond. Les deux collaborent constamment, mais confier les deux rôles à la même personne affaiblit généralement le second.

Quelles compétences doit posséder un analyste d’affaires en projet TI ?

Une double compétence en affaires et en technologies de l’information, la capacité d’expliquer des notions techniques à un public non technique, et du leadership pour tenir sa position entre le client et l’équipe TI. L’IIBA structure ces compétences dans le BABOK Guide, la norme mondiale de la pratique, autour de six domaines de connaissance.

L’analyste d’affaires doit-il choisir entre agile et cascade ?

Non. Il choisit la méthode selon le contexte du client, la stabilité des exigences et l’envergure du projet. Itératif, agile et cascade produisent essentiellement les mêmes livrables, décrire ce que l’utilisateur fait dans le système, mais par des chemins différents. Un bon analyste maîtrise les trois et sait expliquer pourquoi il en recommande une.

Pourquoi les projets échouent-ils à cause des exigences ?

Selon PMI, 47 % des projets qui échouent ratent leurs objectifs à cause d’une gestion inexacte des exigences, un problème lié au glissement de portée, à la communication déficiente et au manque d’implication des parties prenantes. Un analyste d’affaires dédié réduit ce risque en cadrant le problème avant la solution et en documentant les hypothèses.