L’agilité promet des livraisons rapides, un feedback constant et une adaptation continue aux besoins réels. Pourtant, de nombreuses équipes agiles se retrouvent face à un problème qu’aucun sprint ne résout à lui seul: les exigences restent floues, les parties prenantes se contredisent et le produit livré ne correspond pas aux attentes du métier. C’est précisément là qu’intervient la business analysis (BA), c’est-à-dire l’ensemble des pratiques qui visent à comprendre, structurer et valider les besoins métier avant et pendant le développement.
Pourquoi l’agilité ne supprime pas le besoin d’analyse
Le Manifeste agile valorise le logiciel fonctionnel plutôt que la documentation exhaustive, ce qui a parfois été interprété comme une invitation à supprimer toute activité d’analyse en amont. En pratique, cette interprétation conduit à des malentendus coûteux. Selon une étude compilée par David Rico, les projets agiles affichent des délais réduits de 37% et une productivité accrue de 16%, mais ces gains ne se matérialisent que lorsque les exigences sont correctement comprises et priorisées. Sans cette rigueur, les itérations se succèdent sans que le produit converge vers un résultat utile.
Howard Podeswa, dans un article publié par l’IREB, avance que les organisations dont les pratiques de BA sont déficientes subissent en moyenne 62% de dépassements de coûts. Ce chiffre ne concerne pas uniquement les projets traditionnels: les équipes agiles qui négligent l’analyse des exigences reproduisent les mêmes erreurs sous une forme différente.
Le Product Owner peut-il tout faire seul?
En Scrum, le Product Owner (PO) est responsable du backlog et de la priorisation des fonctionnalités. En théorie, cette personne représente le métier et traduit les besoins en user stories exploitables. En pratique, le PO cumule souvent plusieurs responsabilités: négociation avec les parties prenantes, arbitrage budgétaire, validation des livrables et communication interne. La charge devient rapidement excessive, surtout dans les projets complexes qui impliquent plusieurs équipes ou des contraintes réglementaires.
C’est dans ce contexte que l’analyste métier (business analyst, ou BA) apporte une contribution distincte. Le BA ne remplace pas le PO, il le complète en prenant en charge le travail d’investigation approfondie: interviews des utilisateurs, modélisation des processus, analyse d’impact et documentation des règles métier. Podeswa utilise la métaphore du “Polyfilla” pour décrire ce rôle: le BA agile comble les écarts entre les conditions idéales décrites dans les manuels agiles et la réalité des organisations.
Quand intégrer un analyste métier dans une équipe agile?
Tous les projets agiles n’ont pas besoin d’un BA dédié. Sur un projet simple avec un PO disponible et compétent, des parties prenantes alignées et un périmètre bien délimité, l’équipe peut fonctionner sans analyste distinct. En revanche, plusieurs situations justifient cette intégration:
- Complexité métier élevée. Quand les règles métier sont nombreuses, interdépendantes ou mal documentées, un travail d’analyse structuré évite de découvrir les contradictions en fin de sprint.
- Équipes distribuées. La distance géographique réduit les échanges informels qui permettent normalement de clarifier les exigences au fil de l’eau, ce qui rend nécessaire une documentation minimale mais rigoureuse.
- Dépendances entre équipes. Dès que plusieurs équipes travaillent sur le même produit, la traçabilité des exigences devient indispensable pour éviter les incohérences.
- Contexte contractuel. Dans les relations client-fournisseur, les engagements doivent être formalisés, ce qui requiert un niveau de documentation que le backlog seul ne fournit pas.
Comment fonctionne la BA agile en pratique?
La BA agile ne ressemble pas à la rédaction d’un cahier des charges de 200 pages en amont du projet. Elle s’inscrit dans le rythme itératif de l’équipe, et le BA travaille en avance de phase par rapport aux développeurs: pendant que l’équipe réalise le sprint en cours, le BA prépare les éléments du sprint suivant en clarifiant les exigences avec les parties prenantes.
Concrètement, le BA facilite les ateliers de découverte (story mapping, impact mapping) qui permettent de structurer le backlog autour de la valeur métier plutôt que de la technique. Il rédige les critères d’acceptation en collaboration avec le PO et les utilisateurs. Il maintient un registre des exigences, c’est-à-dire un document vivant qui trace l’évolution des besoins au fil des itérations. Et il participe aux revues de sprint pour vérifier que le livrable correspond aux exigences identifiées.
L’IIBA a formalisé ces pratiques dans l’Agile Extension du BABOK (Business Analysis Body of Knowledge), un référentiel qui décrit les compétences et techniques spécifiques à la BA en contexte agile.
Une compétence à distribuer, pas un poste à pourvoir
Selon les données rapportées par Podeswa, le taux de succès des projets agiles double lorsque les équipes atteignent une maturité élevée en gestion des exigences. Ce constat pose une question pratique: faut-il systématiquement recruter un analyste métier dédié?
Pas nécessairement. Dans les petites équipes ou les projets à périmètre restreint, la business analysis agile fonctionne mieux comme une compétence partagée que comme un rôle attitré. Un PO formé aux techniques d’élicitation, un développeur senior capable de modéliser un processus ou un Scrum Master sensibilisé à la gestion des exigences peuvent assurer collectivement ce travail d’analyse. L’essentiel est que quelqu’un dans l’équipe pose les bonnes questions aux parties prenantes, vérifie la cohérence des besoins exprimés et maintienne la traçabilité entre les exigences et le backlog.
Pour les organisations qui découvrent l’agilité, la tentation est souvent de supprimer toute forme d’analyse préalable au nom de la vitesse, ce qui constitue un raccourci risqué. Le dosage dépend de la complexité du projet: une équipe produit de cinq personnes sur une application interne n’a pas les mêmes besoins analytiques qu’un programme de transformation impliquant dix équipes et des contraintes réglementaires. Dans tous les cas, l’analyse des exigences s’intègre dans le rythme itératif plutôt que de s’isoler en phase amont.