Vous êtes curieux de savoir de quoi a l’air l’analyse d’affaires chez nos cousins les Français ? Vous vous apprêtez à vivre une expérience à l’étranger au Québec ou en France ? Vous souhaitez postuler à un poste d’analyste d’affaires ? Vous travaillez avec un québécois analyste d’affaires et vous êtes confus ou vice-versa. Je pense que cet article peut vous aiguiller. J’ai eu la chance d’échanger avec Louise, présentement analyste d’affaires en France et dont le partage d’expérience m’a permis de vous expliquer les similitudes et les différences entre les deux pays pour un rôle ayant le même titre.
Première surprise : la dénomination est différente
Le titre « analyste d’affaires » est récent en France. Encore à ce jour, on trouve des maîtres d’ouvrage (MOA) et des chefs de produit dans les entreprises même si la dénomination tend à être remplacée par « analyste d’affaires » voire à disparaître depuis l’adoption de l’agilité dans les entreprises. En effet, les MOA et les chefs de produit avaient plus leur place dans des méthodes en cascade tel que le cycle en V ce que les québécois nomment Waterfall. Les deux méthodologies de gestion de projet/de développement logiciel sont similaires tout en comportant leurs propres caractéristiques.
Autre point intéressant : en France, le titre « analyste d’affaires » est en anglais. Ils sont donc nommés « business analyst ». Au Québec, si le titre du poste est en anglais, cela signifie que l’entreprise pour laquelle vous postuler accorde une grande importance à l’anglais et que le bilinguisme sera requis de la part du candidat.
Les similitudes
Commençons par le plus simple. Tout comme ici au Québec, l’analyste d’affaires en France fait le pont entre le fonctionnel et la technique. J’ai dû en perdre certains à la lecture. Le fonctionnel, c’est la solution finale dont l’utilisateur va pouvoir bénéficier. Autrement dit, c’est le résultat final, ce que vous voyez et ce que vous pouvez utiliser. La technique, c’est le moyen qui va être utilisé pour créer cette solution. Le fonctionnel, c’est l’équivalent du secteur d’affaires et la technique, c’est l’équipe TI d’où la raison pour laquelle on dit que l’analyste d’affaires fait le pont entre les affaires et les TI au Québec.
Fait important : Louise travaille dans un environnement agile où des concepts comme « daily », « sprint planning », « retro planning », etc. sont ancrés dans son quotidien. Elle travaille donc étroitement avec un propriétaire de produit (PO) et agit même en tant que Proxy PO. Ce serait a priori très courant dans son entreprise que les analystes d’affaires jouent ce rôle et par le fait même, partagent les tâches avec le propriétaire de produit. Après tout, un propriétaire de produit est un analyste d’affaires agile ! Au Québec et de mon expérience, nous avons davantage cette délimitation entre analyste d’affaires et propriétaire de produit de sorte à ce que lorsque l’entreprise adopte une approche agile, le rôle d’analyste d’affaires tend à disparaître ou à être utilisé pour des expertises spécifiques comme la gestion des processus d’affaires par exemple.
Autre similarité que nous aimerions évoquer : le fait qu’on demande souvent à l’analyste d’affaires d’occuper un rôle hybride. Or, la ligne est pourtant bien définie entre analyse d’affaires et analyse technique. Toutefois, on demande à l’analyste d’affaires d’être à l’aise dans les deux, mais évidemment pas autant que le business owner (côté affaire) ni autant que le développeur (côté technique). Malgré tout, cette ligne entre les deux n’est pas définie clairement et c’est souvent à l’analyste d’affaires de mettre ses propres limites.
Avec l’agilité vient des outils spécifiques et il se trouve que Louise utilise également JIRA et Confluence. Pour ceux qui ne les connaissent pas, ce sont deux outils à maîtriser à l’ère de l’agilité. Ils sont simples d’utilisation et permettent facilement de mettre en pratique le cadre de référence, l’état d’esprit et la méthodologie de l’agilité.
Les différences
Alors que nous entendons et lisons sans cesse le mot « exigence » ou encore « requis » dans la description de poste d’un analyste d’affaires ayant à exercer dans un environnement agile au Québec, il en est tout autrement en France. On parle de user stories. Nous assumons que l’approche agile a été adoptée à 100% et ce, même dans le langage. L’agilité ayant son propre cadre de référence, cela a du sens.
Par ailleurs, alors qu’un des aspects techniques les plus importants à maîtriser ici est la cartographie de processus, cela ne fait pas partie des responsabilités d’un analyste d’affaires en France où les architectes sont généralement responsables de cette partie. D’ailleurs, on parle de processus métier en France alors qu’on parle de processus d’affaires au Québec.
Nous parlions des compétences techniques qui sont souvent requises. Louise nous explique qu’elle travaille étroitement avec l’équipe technique (TI) en amont de la réalisation du projet lors d’un event modeling. Louise nous fait part qu’elle peut même parfois être amenée à écrire des technical stories. Les compétences fonctionnelles sont d’ailleurs souvent demandées pour des propriétaires de produit. Nous avons plus l’habitude au Québec d’avoir des architectes de données et de solution qui réalisent ce type d’activités puis qui collaborent avec l’équipe TI.
Dernier point dont nous aimerions parler : l’amalgagme avec le titre. Louise nous mentionnait l’assumation que certaines personnes dans son environnement de travail peuvent avoir par rapport au titre. En effet, le titre comportant le mot « analyse », plusieurs personnes s’attendent à ce que l’analyste d’affaires fasse uniquement des analyses et, de tout type. Quand vient le moment de faire une analyse technique, l’analyste d’affaires n’a pas nécessairement cette compétence ce qui engendre des malentendus.
Si cet article vous parle, que vous avez vécu la même chose ou que vous souhaiteriez partager votre expérience, n’hésitez pas à laisser un commentaire. Sur ce, chères lectrices et chers lecteurs, je vous remercie pour votre attention !
