Questions d'entretien Analyste business

Je commence toujours par comprendre le problème qu'elles cherchent à résoudre, pas la solution qu'elles imaginent. Si une partie prenante dit 'j'ai besoin d'un nouveau rapport', ma première question est 'quelle décision ce rapport vous aidera-t-il à prendre ?' J'utilise un mix de techniques : entretiens structurés pour les décideurs, walkthroughs de processus pour les équipes opérationnelles, et facilitation d'ateliers quand les exigences couvrent plusieurs équipes. Je documente sous forme de user stories et je les soumets à validation, car les parties prenantes découvrent souvent des lacunes ou des conflits en voyant leurs exigences écrites. Je fais également émerger la distinction 'indispensable' versus 'souhaitable' tôt dans le processus, car le glissement de périmètre vient presque toujours de la confusion entre les deux.

Les exigences contradictoires sont presque toujours le signe de priorités qui s'opposent, pas d'un problème de documentation. Je commence par rendre le conflit explicite : je présente les deux exigences côte à côte et montre pourquoi elles sont en tension. Cela fait souvent émerger des hypothèses que ni l'une ni l'autre des parties n'avait formulées. Je facilite ensuite une décision sur la priorité, sur la base de l'impact business et de l'alignement stratégique, et je documente cette décision avec son rationnel. Si le conflit ne peut pas être résolu au niveau des parties prenantes, j'escalade au décideur approprié avec un résumé clair du compromis et une recommandation.

J'utilise une approche en couches. Au niveau le plus haut, je capture le cas d'usage business et les objectifs : pourquoi faisons-nous cela et à quoi ressemble le succès ? En dessous, je documente les exigences fonctionnelles sous forme de user stories avec des critères d'acceptation, et les exigences non fonctionnelles séparément. Je maintiens une matrice de traçabilité des exigences pour montrer quelles fonctionnalités système correspondent à quelles exigences business. Je versionne toute la documentation et je communique les changements formellement. Je fais également une revue des exigences avec l'équipe de développement avant validation pour détecter tout ce qui est ambigu.

L'IA s'est avérée utile à plusieurs étapes de mon travail d'analyste métier. Pour la documentation des exigences, je l'utilise pour convertir les notes brutes des parties prenantes en user stories structurées et critères d'acceptation : le format est bon, bien que je valide toujours la logique par rapport à ce que le métier a réellement dit. Pour la cartographie des processus, j'ai utilisé l'IA pour identifier les lacunes ou redondances en décrivant un processus en texte libre et en demandant une analyse, ce qui fait ressortir des éléments que je n'aurais peut-être pas repérés. Pour le travail de données ad hoc, je l'utilise pour aider à rédiger et déboguer des requêtes SQL ou des scripts Python. Pour présenter les résultats à des parties prenantes non techniques, j'utilise l'IA pour simplifier et structurer des informations complexes dans un langage clair. Là où je suis plus prudente, c'est pour tout ce qui nécessite une connaissance approfondie de nos systèmes et processus spécifiques : le modèle n'a pas ce contexte.

Lors d'un atelier de recueil des exigences pour un nouveau portail client, j'ai cartographié le processus actuel de bout en bout et j'ai remarqué que deux équipes maintenaient séparément les mêmes données clients dans des systèmes différents, sans processus de synchronisation. Aucune des deux équipes n'avait signalé le problème car chacune pensait que l'autre était le système de référence. J'ai réuni les deux équipes avec la carte de processus et documenté l'incohérence des données comme un problème central à résoudre. La solution finale a inclus une étape de consolidation des données qu'aucune des deux équipes n'avait mise dans le périmètre initial. Sans cela, le portail aurait affiché des informations contradictoires aux clients.

À mi-parcours d'une implémentation CRM de six mois, l'entreprise a acquis une société plus petite dont les processus étaient substantiellement différents des exigences initiales. J'ai conduit une analyse d'impact rapide : j'ai identifié quelles exigences restaient inchangées, lesquelles nécessitaient une modification et quelles nouvelles exigences devaient être ajoutées. J'ai présenté cela au sponsor du projet comme une demande de changement structurée avec une estimation de temps et de coûts supplémentaires. Il a choisi d'étendre le calendrier de six semaines et d'ajuster le périmètre. J'ai ensuite refacilité les ateliers d'exigences pour intégrer les parties prenantes de la société acquise. Le projet a livré selon le plan révisé.

J'ai rencontré cette situation avec une équipe de développement qui avait souffert de documents d'exigences trop prescriptifs qui contraignaient leurs décisions techniques sans apporter de valeur. J'ai changé d'approche : au lieu de leur remettre une spécification de 40 pages, j'ai commencé à organiser des sessions courtes de travail conjoint pour explorer les exigences ensemble, en rendant explicite que le design de la solution était de leur ressort. Je me suis concentré sur le 'quoi' et le 'pourquoi' et je me suis abstenu du 'comment'. J'ai aussi adopté des user stories plus courtes avec des critères d'acceptation clairs, que l'équipe trouvait bien plus utiles pour la planification de sprint. En deux mois, les développeurs m'intégraient proactivement dans leurs conversations de design.

J'utilise les modèles de processus à différents niveaux d'abstraction selon le public et l'objectif. Pour les parties prenantes senior, j'utilise un diagramme en couloirs de haut niveau pour montrer qui fait quoi et où se font les transferts. Pour les équipes opérationnelles, j'entre dans le détail avec des flux qui capturent les points de décision, les exceptions et les interactions système. J'utilise la notation BPMN quand l'organisation a un standard, ou des organigrammes plus simples quand le public n'est pas technique. La valeur clé d'un modèle de processus est de rendre explicite la connaissance tacite : je trouve presque toujours des étapes que les gens effectuent mais n'ont pas mentionnées.

Je rédige les critères d'acceptation au format Étant donné / Quand / Alors ou sous forme de liste de conditions vérifiables. Le principe clé est que chaque critère doit être vérifiable indépendamment : quelqu'un qui n'a pas participé à la rédaction de l'exigence doit pouvoir regarder le système et dire clairement s'il passe ou échoue. 'Le système doit être rapide' n'est pas un critère d'acceptation. 'La page se charge en moins de 2 secondes sur une connexion 4G pour 95% des requêtes' en est un. Je m'assure aussi que les critères couvrent les cas limites et les chemins d'erreur, pas seulement le cas nominal. C'est crucial car les critères ambigus sont la principale cause de litiges entre le métier et le développement en fin de sprint.

L'analyse de données intervient de plusieurs façons dans mon travail. En phase de découverte, j'analyse les données existantes pour comprendre l'état actuel : volumes, qualité des données, et patterns qui remettent en question les hypothèses des parties prenantes. Lors de la définition des exigences, je documente les exigences en matière de données : quelles données chaque fonction a besoin, d'où elles proviennent et quelles transformations sont nécessaires. J'utilise aussi les données pour valider les hypothèses : si une partie prenante dit 'la plupart des clients font X', j'essaie de le vérifier avant de construire une exigence autour de cela. J'utilise SQL pour les requêtes structurées et Excel pour les analyses ad hoc.