Dans les dernières années, l’agilité est devenue à la mode. On dénombre plusieurs grandes entreprises qui requièrent la connaissance des principes Agile ou d’un cadre de travail (par exemple Scrum, Kanban, SAFe et Lean) ou d’un outil (notamment Jira et Confluence). Ce cadre de travail a profondément altéré le rôle de l’analyste d’affaires.
Avez-vous déjà suivi des cours sur l’agilité ou une certification et vous vous êtes rendus compte que le rôle d’analyste d’affaires n’est pas évoqué ? Il y a plusieurs raisons sous-jacentes à cela.
L’agilité prône la flexibilité des équipes de développement tant au niveau de leur façon de travailler, de collaborer et de livrer. Selon Ies douze principes dans le « Manifeste pour le développement Agile des logiciels », un manifeste rédigé par 17 experts en 2001, un analyste d’affaires devrait :
- Se concentrer sur la valeur délivrée pour l’organisation et les utilisateurs finaux ;
- Favoriser l’adaptabilité et faire évoluer les récits utilisateurs (user stories en anglais) ainsi que le backlog (qui au passage, n’est plus sous sa gouvernance depuis l’intégration du rôle Propriétaire de Produit – Product Owner en anglais)
- Faire le pont entre les équipes d’affaires et de développement
- Établir les critères d’acceptation pour valider chaque étape de développement (les incréments)
- Penser en termes d’amélioration continue concernant ses techniques utilisées
- Minimiser la documentation et privilégier des visuels quand cela est possible
- Privilégier les besoins qui améliorent l’expérience des utilisateurs finaux
Mais, saviez-vous que dans les différents cadres de travail agiles, le rôle d’analyste d’affaires n’existe pas ?
Il est mis au second plan visuellement, car il n’est pas cantonné à une seule équipe ; en effet, comme le décrivent Jérémie Guay et Étienne Lecours dans leur conférence intitulée « L’Analyse d’Affaires dans SAFe. Qui, Où, Quand et Pourquoi? » , l’analyste d’affaires peut aussi bien intervenir au niveau du Portefeuille et participer à la création des dossiers d’affaires qu’au niveau du Train de livraison en définissant la solution finale et en guidant la phase d’implémentation.
Alors quelle est la solution ? Selon l’organisation et la raison pour laquelle elle a embauché un analyste d’affaires, il y a plusieurs possibilités :
- Définir la place de l’analyste d’affaires dans les cadres de travail (framework en anglais) ou
- Renommer le rôle d’analyste d’affaires par « proxy Product Owner » et diviser les tâches d’analyse d’affaires et de propriétaire de produit ou
- Faire intervenir l’analyste d’affaires seulement sur un grand projet d’intégration et de transformation numérique pour maximiser son impact
La réalité sur le marché du travail
Pourquoi les entreprises adorent la pratique agile ?
Les budgets sont de plus en plus serrés. La priorisation devient un incontournable dans un contexte Agile. Rick Clare, dans son livre « Managing Business Analysts » explique précisément pourquoi : le but n’est plus de dire que tel requis est dans le périmètre ou hors périmètre comme en gestion de projet cascade, mais bien, dans quel ordre de priorité devons-nous réaliser le développement avec une gestion de projet agile ? L’agilité a donc cet avantage pour les entreprises qui intègrent une cadre de travail à l’échelle de l’entreprise.
Il y a deux différences entre le rôle de propriétaire de produit et celui d’analyste d’affaires :
- Le propriétaire de produit a un pouvoir décisionnel voire autoritaire alors que l’analyste d’affaires a un pouvoir d’influence
- Un analyste d’affaires peut devenir propriétaire de produit aisément en améliorant sa capacité à prendre des décisions stratégiques et en privilégiant la valeur délivrée alors que le propriétaire de produit ne peut pas devenir analyste d’affaires à moins de maîtriser les techniques et de maîtriser l’échange continuel qu’il devrait y avoir entre les équipes de développement et les équipes TI
Les prochaines années
Avec l’intégration du rôle de Propriétaire de Produit, le rôle d’Analyste d’Affaires n’est plus utilisé comme avant.
Sur un projet de petite envergure, que ce soit en termes de budget, de nombre de parties prenantes et de temps de développement où il y a un Propriétaire de Produit, la présence d’un analyste d’affaires n’est pas requise. Les deux risqueraient de se marcher sur les pieds et dédoubler plusieurs tâches.
Également, l’analyste d’affaires aurait probablement peu de pouvoir d’influence, car il faudrait, non pas convaincre l’utilisateur final, mais bien le Propriétaire de Produit. Or, ce dernier est supposé être un allié et vous êtes censés vous supporter mutuellement dans l’agilité et parfois même, vous partager des tâches.
Il convient donc d’utiliser les analystes d’affaires sur des projets complexes pour maximiser leur impact puis leur confier des tâches décisionnelles au fur et à mesure ou bien de définir les rôles et responsabilités pour éviter un dédoublement des tâches.
On pourrait imaginer un monde où les analystes d’affaires sont à la fois des propriétaires de produit et analyste d’affaires pour palier au fait que le rôle, à l’origine, octroie seulement un pouvoir d’influence et qu’il est toujours essentiel dans l’implémentation de solution technologique. Le gestionnaire de produit et le propriétaire de produit ont une charge de travail trop grande pour la réaliser seuls.
Sources
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., & Thomas, D. 2001. Manifeste pour le développement Agile de logiciels. Disponible à : https://agilemanifesto.org/iso/fr/manifesto.html (consulté le 12/03/2025).
Clare, R. 2011. Managing Business Analysts. Toronto : International Institute of Business Analysis.
Jérémie Guay & Étienne Lecours. L’Analyse d’Affaires dans SAFe. Qui, Où, Quand et Pourquoi? [en ligne]. YouTube, 18 janvier 2024. Disponible à l’adresse : https://www.youtube.com/watch?v=_Zi1VUZsFsI
