Quand on demande à un chef de projet s’il fait de l’analyse métier, la réponse est souvent évasive. “Un peu, quand il n’y a pas de BA dédié.” Cette réponse trahit une méconnaissance: l’analyse métier (business analysis) n’est pas une tâche unique qu’on délègue ou qu’on absorbe en bloc. C’est un ensemble de six disciplines, chacune avec ses méthodes, ses livrables et ses compétences propres. Les connaître permet au chef de projet de mieux cadrer son intervention et de combler les lacunes quand l’équipe ne dispose pas de spécialistes.
Six disciplines sous une même étiquette
L’IIBA (International Institute of Business Analysis) a progressivement élargi sa cartographie des spécialisations au-delà de l’analyse métier classique. Le BABOK Guide, référentiel mondial de la discipline, couvre désormais l’analyse agile, l’analyse de données et l’architecture métier. Cette évolution reflète une réalité terrain: les projets modernes mobilisent des formes d’analyse variées, souvent sans que l’équipe en ait conscience.
Deux premiers profils relèvent du coeur de métier. L’analyste métier traduit les besoins des parties prenantes en exigences exploitables: cahier des charges, user stories, spécifications fonctionnelles. L’analyste systèmes prend le relais sur la dimension technique en spécifiant comment les systèmes d’information doivent évoluer pour répondre à ces besoins. La frontière entre les deux n’est pas toujours nette, mais la différence d’interlocuteur est réelle: l’un dialogue avec les utilisateurs finaux, l’autre avec les équipes de développement.
Deux autres profils portent sur l’optimisation. L’analyste processus cartographie les flux de travail existants, identifie les inefficacités et propose des améliorations à l’aide d’outils comme la notation BPMN (Business Process Model and Notation). L’analyste UX (user experience) adopte une approche similaire mais centrée sur l’utilisateur final: personas, parcours utilisateurs et wireframes guident la conception des interfaces et des services.
Les deux derniers profils concernent la transformation et la décision. L’analyste changement évalue l’impact des transformations sur les équipes et conçoit les dispositifs d’accompagnement; en contexte agile, ce rôle évolue vers la facilitation continue du backlog et des cérémonies. L’analyste données, quant à lui, explore les jeux de données pour en extraire des tendances, des corrélations et des indicateurs d’aide à la décision.
Ce que le chef de projet fait déjà sans le nommer
En pratique, le chef de projet exerce déjà plusieurs de ces fonctions analytiques, parfois sans s’en rendre compte. Lorsqu’il anime un atelier de cadrage et recueille les besoins des parties prenantes, il fait de l’analyse métier. Lorsqu’il évalue l’impact d’un changement sur les équipes et planifie l’accompagnement, il fait de l’analyse du changement. Lorsqu’il examine les indicateurs de performance du projet pour ajuster le plan, il fait de l’analyse de données.
Le problème n’est pas que le PM fasse ces activités, c’est qu’il les fasse souvent de manière informelle, sans les méthodes et les cadres que les spécialistes utilisent. Un analyste processus ne cartographie pas les flux “de tête”: il utilise la notation BPMN pour rendre les processus lisibles et auditables. Un analyste UX ne se contente pas de demander “est-ce que ça vous convient?”: il construit des personas et des parcours utilisateurs pour objectiver les besoins.
Savoir quand on atteint ses limites
L’enjeu n’est pas que le chef de projet devienne expert dans les six domaines, c’est qu’il sache reconnaître quand un projet nécessite une compétence analytique qu’il ne possède pas. Un projet de refonte de processus métier exige une analyse processus rigoureuse. Un projet avec une forte composante d’interface utilisateur ne peut pas se passer d’une analyse UX structurée. Un projet de transformation à grande échelle requiert une analyse du changement formelle, pas un plan de communication improvisé.
Cette lucidité est une compétence en soi. Trop de projets échouent non pas parce que l’équipe manquait d’analystes, mais parce que personne n’a identifié le type d’analyse qui faisait défaut. Le cadrage initial est le moment clé: c’est là que le chef de projet doit cartographier les besoins analytiques du projet au même titre que les ressources techniques ou le budget.
Développer sa culture analytique
Pour le chef de projet qui souhaite renforcer sa dimension analytique, la démarche ne consiste pas à accumuler des certifications dans chaque domaine. Elle passe par trois habitudes concrètes.
La première est de systématiser le questionnement analytique en phase de cadrage: quels processus ce projet va-t-il modifier? Quels systèmes sont impactés? Quels utilisateurs seront touchés? Quelles données seront nécessaires pour mesurer le succès? Ces questions permettent d’identifier les spécialisations analytiques requises avant qu’il ne soit trop tard pour les mobiliser.
La deuxième habitude est de formaliser les analyses qu’on réalise soi-même. Un PM qui recueille des exigences sans les structurer dans un format exploitable (user stories, cahier des charges, matrice de traçabilité) perd une partie de la valeur de son travail. Les outils existent, et ils n’exigent pas une expertise de spécialiste pour être utilisés de manière productive.
La troisième est de savoir lire les livrables des analystes spécialisés. Un chef de projet qui ne comprend pas une cartographie BPMN ou un rapport d’analyse de données ne peut pas challenger ces livrables ni les intégrer efficacement dans le pilotage du projet. Comprendre le vocabulaire et les conventions de chaque spécialisation permet de poser les bonnes questions lors des comités de pilotage et d’arbitrer plus efficacement entre les recommandations des différents analystes.