Business Analyst ou Chef de projet IT : quelle différence pour votre institution ?
- Les missions respectives de chaque profil
- Quand choisir l’un plutôt que l’autre
- Pourquoi la combinaison des deux compétences change tout
Deux rôles complémentaires, pas interchangeables
La confusion entre ces deux profils vient d’un raccourci fréquent : puisque les deux travaillent sur des projets SI, on suppose qu’ils font la même chose avec des niveaux d’expérience différents. C’est inexact.
Un chef de projet IT gère l’exécution : il pilote le planning, coordonne les ressources, suit les livrables, gère les risques opérationnels et rend compte à la direction. Son horizon est le respect des délais et du budget. Son outil principal est le plan de projet.
Un Business Analyst gère la compréhension : il analyse les besoins métier, traduit les exigences des parties prenantes en spécifications fonctionnelles précises, s’assure que ce qui sera livré correspond au besoin réel. Son horizon est la qualité fonctionnelle du livrable. Son outil principal est la relation avec les utilisateurs.
En résumé : le chef de projet répond à « comment livrons-nous ? ». Le Business Analyst répond à « quoi livrons-nous exactement et pourquoi ? ».
Comparaison concrète des responsabilités
| Activité | Chef de projet IT | Business Analyst |
|---|---|---|
| Planification | Construit et suit le plan de projet | Définit le périmètre fonctionnel initial |
| Besoins métier | Les reçoit et les intègre au planning | Les collecte, les analyse, les structure |
| Spécifications | S’appuie sur les specs existantes | Les rédige et les fait valider |
| Relation équipes métier | Communication et coordination | Analyse approfondie des pratiques réelles |
| Recette | Organise et suit le processus | Définit les critères d’acceptance |
| Risques | Risques de planning et de ressources | Risques fonctionnels et d’usage |
| Livrable principal | Rapport d’avancement, plan de projet | Cahier des charges, spécifications |
Pourquoi les projets sans BA dérivent
Dans les institutions où le projet SI est piloté uniquement par un chef de projet, un schéma récurrent apparaît. Le planning est respecté, les jalons sont atteints, les budgets sont tenus. Mais à la livraison, les équipes terrain constatent que le système ne correspond pas à leurs pratiques réelles.
Ce n’est pas un problème de chef de projet : c’est un problème de méthode. Sans phase d’analyse fonctionnelle rigoureuse en amont, les spécifications sont rédigées par les équipes IT sur la base de ce qu’elles comprennent des besoins, pas de ce que les utilisateurs font réellement. L’écart entre les deux peut être considérable, surtout dans des environnements complexes comme la santé ou la finance.
Exemple concret : Dans un projet de migration documentaire conduit dans une institution publique genevoise de 1 300 collaborateurs répartis sur 50 sites, la cartographie AS-IS menée par un Business Analyst a révélé 14 processus informels non couverts par les spécifications initiales. Ces processus, intégrés avant le début du développement, ont évité un taux d’échec estimé à 40% des flux documentaires.
Quand faire appel à un Business Analyst
Tous les projets SI ne nécessitent pas un Business Analyst. Un déploiement technique standard avec des besoins clairs et des utilisateurs expérimentés peut se piloter uniquement avec un chef de projet compétent.
Un BA apporte une valeur déterminante dans les situations suivantes :
- Environnements multi-parties prenantes : quand plusieurs services avec des pratiques différentes doivent converger vers un système commun (hôpitaux, institutions multi-sites)
- Projets à forte composante réglementaire : quand les spécifications doivent intégrer des contraintes légales précises (FINMA, LPD, normes hospitalières)
- Migration de systèmes legacy : quand il faut cartographier des pratiques existantes non documentées avant de les transposer dans le nouveau système
- Projets data et décisionnel : quand les indicateurs de pilotage doivent être définis avec les métiers avant d’être implémentés techniquement
La combinaison gagnante : pourquoi les deux profils se renforcent
Sur les projets de transformation institutionnelle d’envergure, la configuration optimale associe un chef de projet solide et un Business Analyst expérimenté. Le premier garantit l’exécution rigoureuse. Le second garantit que ce qui est exécuté correspond au besoin réel.
Quand les deux compétences sont portées par le même profil, comme c’est le cas dans le positionnement de pilotage de transformation SI, l’organisation bénéficie d’un interlocuteur unique capable de raisonner simultanément sur le « quoi » fonctionnel et le « comment » opérationnel. C’est plus rare sur le marché indépendant romand, et c’est précisément là que réside la valeur ajoutée d’un profil senior combinant les deux dimensions.
Questions fréquentes
Un chef de projet expérimenté peut-il jouer le rôle de Business Analyst ?
Partiellement. Un chef de projet senior développe souvent une sensibilité aux enjeux fonctionnels. Mais l’analyse structurée des besoins, la rédaction de spécifications fonctionnelles précises et la cartographie AS-IS des processus sont des compétences spécifiques qui s’acquièrent différemment. Sur des projets complexes, la confusion des rôles produit des livrables hybrides qui ne remplissent aucune des deux fonctions correctement.
Le Business Analyst intervient-il sur toute la durée du projet ?
Pas nécessairement. Une mission BA peut être ponctuelle : uniquement la phase de cadrage et de spécifications, avec remise d’un cahier des charges complet. Le chef de projet prend ensuite le relais pour l’exécution. C’est souvent la configuration la plus efficace pour les institutions qui disposent déjà d’une équipe projet interne.
Le Business Analyst travaille-t-il avec les équipes techniques ?
Oui, de façon intensive. Le BA fait le lien entre les équipes métier et les équipes IT. Il traduit les exigences fonctionnelles en contraintes compréhensibles pour les développeurs, et inversement, il explique aux métiers les contraintes techniques sans jargon. C’est le rôle de traducteur entre deux mondes qui parlent rarement le même langage.
Quelle est la durée typique d’une mission de Business Analysis ?
De deux semaines à plusieurs mois selon le périmètre. Un audit de cadrage avec cartographie AS-IS et recommandations peut se mener en deux à quatre semaines. La rédaction d’un cahier des charges complet pour un projet institutionnel prend généralement un à deux mois selon le nombre de parties prenantes impliquées.
Comment évaluer si un profil BA est adapté à mon contexte institutionnel ?
Deux critères principaux : les références sectorielles et la capacité à travailler sans outil imposé. Un BA expérimenté en milieu hospitalier ou bancaire comprend les contraintes réglementaires, les enjeux de confidentialité et les dynamiques multi-parties prenantes spécifiques à ces secteurs. Un premier échange de cadrage permet de qualifier rapidement l’adéquation.
Vous hésitez entre un chef de projet et un Business Analyst ?
Un échange de cadrage de 30 minutes permet de qualifier précisément quel type d’intervention correspond à votre situation. Sans engagement.
Prendre rendez-vous
