Qui fait quoi dans un projet informatique ? Est-ce le Chef de projet qui définit les besoins, ou le Product Owner ? L’AMOA et le Business Analyst sont-ils deux noms différents pour un même rôle ? Quant au Sponsor, est-il un simple financeur ou le véritable porteur de vision ? Derrière ces intitulés parfois confus, se cachent en réalité des rôles complémentaires, plus ou moins visibles selon la taille et la méthode de conduite du projet.
Le schéma ci-dessous permet de visualiser la place des principaux rôles dans un projet informatique, en fonction de leur proximité avec la gouvernance, le métier et la solution.
En haut, le Sponsor incarne la vision stratégique et confie le pilotage et la coordination au Chef de projet fonctionnel, en lien direct avec l’AMOA côté métier et Product Owner (pour les projets en méthode agile) côté solution. Le Business Analyst fait le lien entre l’AMOA et Product Owner pour formaliser les besoins métier et les traduire au plus juste en solutions techniques.
Cette cartographie montre que ces rôles, parfois perçus comme proches ou redondants, se complètent en réalité dans la gouvernance et la réussite d’un projet. Mais plus concrètement, que cela veut dire ?
BUSINESS ANALYST (BA)
Mission principale : Recueille, analyse les besoins du métier / des utilisateurs et les formalise dans un langage compréhensible pour les équipes techniques. Il doit s’assurer que les exigences sont claires, complètes, cohérentes et testables.
Focus : Analyse, modélisation, communication entre métier et technique.
Activités clés :
Recueil et formalisation des besoins métier
Rédaction de spécifications fonctionnelles
Modélisation des processus
Conception de l’architecture fonctionnelle
Validation fonctionnelle avec les utilisateurs.
Vision : « Est-ce que la solution répond bien aux besoins exprimés ? »
AMOA (Assistance à la Maîtrise d’Ouvrage)
Mission principale : Conseiller et assister le métier dans la conduite du projet afin de s’assurer le projet réponde bien aux objectifs
Focus : Accompagnement global côté métier
Activités clés :
Définition du besoin global
Rédaction du cahier des charges (selon le périmètre)
Validation de l’architecture fonctionnelle
Animation d’ateliers utilisateurs
Pilotage de la recette métier
Conduite du changement (formation, communication).
Vision : « Est-ce que le projet, dans son ensemble, sert bien les objectifs métiers ? »
PRODUCT OWNER – rôle propre aux projets en mode agile que l’on retrouve notamment dans la méthodologie Scrum.
Mission : représenter la voix des utilisateurs au sein de l’équipe de Scrum et s’assurer que la solution livrée apporte de la valeur métier.
Focus : produit, délivrer de la valeur aux utilisateurs
Activités:
Recueille et formalise les besoins au plus juste dans le Product backlog
Rédaction des critères d’acceptation
Estimation de la charge du travail et priorisation des besoins
Collaboration au quotidien avec les équipes de développement
Validation de l’incrément du produit / fonctionnalités livrées à la fin de chaque itération
Vision : « Est-ce que le chaque évolution du produit apporte de la valeur aux utilisateurs ? «
SPONSOR
Mission: Une personne interne à l’organisation désignée dans la phase de démarrage du projet qui détient la vision stratégique et porte la responsabilité de la réussite globale du projet ou plusieurs projets.
Focus: Valeur business, prise de décision, vision haut niveau
Activités:
Etablissement du périmètre global et des objectifs business du projet
Promotion du projet dans l’organisation et allocation des ressources nécessaires à son exécution.
Prise de décision stratégique et arbitrage
Porte la vision et les objectifs business vers l’équipe projet
Garant de l’atteinte des objectifs du projet
Vision: « Est-ce que le projet contribue aux objectifs stratégiques de l’entreprise et dispose des moyens et ressources pour réussir? »
CHEF DE PROJET
Mission: C’est la personne responsable de la bonne réalisation du projet dans son ensemble : de l’approbation jusqu’à la clôture. Il assure le respect du planning, la maitrise des coûts et la conformité de la solution aux besoins exprimés. Selon les contextes, le chef de projet peut être plutôt technique (centré plutôt sur l’architecture) et l’infrastructure ou fonctionnel (centré sur les aspects métier).
Focus: Organisation, planification et coordination
Activités:
Planification : fait le découpage en tâches et livrables concrets, définit l’échéancier et les ressources (financières, humaines) nécessaires ; réalise un cahier des charges
Coordination des parties prenantes (équipes métier, techniques, sponsors..)
Suivi de l’avancement et reporting
Gestion de risque et leur intégration dans l’estimation des coûts et des délais
Garantir la livraison de la solution attendue en conformité avec le cahier des charges
Vision :
“Est-ce que le projet avance dans les délais, le budget et la qualité attendue ?”
Conclusion
On peut entendre une remarque de quelqu’un qui est loin du milieu des Projets SI qu’il ne voit toujours pas forcément la différence entre les acteurs listés ci-dessus. En réalité, dans de gros projets on pourrait retrouver la quasi-totalité de ces rôles, tous occupés par des personnes différentes, tandis que dans les projets de plus petite taille la même personne peut remplir plusieurs rôles dans la gestion de projet.
On notera que les responsabilités du BA et de l’AMOA sont assez proches, côté métier, avec l’AMOA qui exerce plus de responsabilités pour la partie accompagnement et pilotage.
Quant au Chef de projet, il peut être à la fois technique et fonctionnel, voire remplir les rôles d’AMOA et Business Analyst en parallèle des activités de pilotage et de planification.
Pour ce qui est du Product Owner, c’est une version du BA/AMOA dans un cadre Agile, mais avec plus de responsabilités de priorisation et de décision. Le PO est responsable du “quoi” (ce qui doit être développé et pourquoi), pas du “comment” ni du “quand précis”, contrairement au Chef de projet qui pilote le projet.
Bien qu’on entende beaucoup parler du cadre Agile, apportant plusieurs avantages aux projets tel que la flexibilité et l’adaptabilité au contexte qui évolue, les entreprises qui optent pour cette méthodologie pure ne sont pas nombreuses. On retrouve plus souvent des projets dits « hybrides » avec des notions de budget, de temporalité et de jalons, dans lesquels nous trouverons un découpage de fonctionnalités/évolutions à livrer en plusieurs itérations, chacune étant un mini-projet. Et il n’est pas rare de rencontres des rôles Agiles qui cohabitent avec des rôles « classiques ».
En définitive, qu’ils soient appelés AMOA, BA, Chef de projet, Product Owner ou Sponsor, ces rôles contribuent chacun à leur manière à la réussite d’un projet informatique. L’essentiel reste de savoir les articuler efficacement pour générer le plus de valeur, en fonction de la taille du projet et de la méthode choisie.
A propos de l’auteur :
Victoria Ivanova – Consultante IT Supply Chain
