Scorecard Business Analyst
Voici comment évaluer un Business Analyst en entretien : les compétences à noter, les questions à poser et les signaux d'alerte. Une grille de base, à ajuster selon votre contexte et vos priorités.
Un exemple à adapter. Cette scorecard est un modèle, pas une grille à appliquer telle quelle. Gardez les critères qui correspondent à votre poste et à votre équipe, ajustez ou retirez les autres. Le bon profil dépend de votre contexte.
Business Analyst
La mission en une phrase
Un besoin métier cadré et partagé
Recueillir la demande auprès des parties prenantes, la reformuler sans ambiguïté et obtenir l'accord du métier sur le périmètre avant tout développement.
Des spécifications fonctionnelles exploitables
Produire des documents de spécification clairs et complets que les équipes techniques peuvent prendre en main sans aller-retour permanent.
Des processus modélisés et compris
Cartographier les processus existants et cibles pour donner aux équipes une vision commune du fonctionnement attendu et des points de bascule.
Une recette maîtrisée jusqu'à la mise en production
Accompagner les phases de test, rédiger ou cadrer les cas de recette et veiller à ce que la solution livrée corresponde au besoin formalisé.
✗ Faible · Se contente de retranscrire la demande telle quelle, sans creuser ni reformuler, et reporte les ambiguïtés sur les équipes techniques.
✓ Excellent · Mène des ateliers de cadrage, sait poser les bonnes questions, distingue le besoin réel de la solution demandée et challenge les parties prenantes.
✗ Faible · Livre des documents flous ou incomplets qui obligent les développeurs à interpréter ou à revenir vers lui en continu.
✓ Excellent · Produit des spécifications structurées, lisibles et testables, avec règles de gestion explicites et cas limites traités.
✗ Faible · Ne sait pas formaliser un processus de bout en bout ou produit des schémas que personne ne s'approprie.
✓ Excellent · Représente clairement un processus métier, identifie acteurs, étapes et flux, et utilise un formalisme adapté à l'audience.
✗ Faible · Reste cantonné à un seul univers, transmet sans filtrer et laisse les incompréhensions s'installer entre métier et technique.
✓ Excellent · Traduit le langage métier en éléments exploitables par les développeurs et inversement, fluidifie les échanges entre les deux mondes.
✗ Faible · Se désengage après la rédaction des spécifications et n'assure pas le suivi jusqu'à la livraison.
✓ Excellent · Suit le besoin tout au long du projet, prépare les cas de recette, accompagne les utilisateurs et arbitre les écarts constatés.
✗ Faible · Dépend d'un seul outil ou improvise sa documentation hors de tout cadre partagé.
✓ Excellent · Manie les outils de schématisation et de gestion de tickets, structure son travail dans l'outillage de l'équipe.
✗ Faible · N'a aucune autonomie sur les données et dépend systématiquement d'un tiers pour la moindre vérification.
✓ Excellent · Comprend la structure des données manipulées, sait lire un modèle de données et formuler une requête simple pour vérifier une hypothèse.
Sens analytique
✗ Faible · Reste en surface, mélange les sujets et peine à structurer un raisonnement face à un besoin ambigu.
✓ Excellent · Décompose un problème complexe, hiérarchise les enjeux et remonte aux causes plutôt qu'aux symptômes.
Pédagogie
✗ Faible · Reste dans son jargon, perd son auditoire et laisse les incompréhensions s'accumuler.
✓ Excellent · Explique un sujet technique à un public métier et un sujet métier à des techniciens, adapte son niveau de détail à l'interlocuteur.
Rigueur et structuration
✗ Faible · Travaille de façon désordonnée, oublie des cas et laisse des trous dans la traçabilité.
✓ Excellent · Organise sa documentation, trace ses décisions et tient un fil clair entre besoin, spécification et recette.
Écoute et diplomatie
✗ Faible · Impose son point de vue, néglige certaines parties prenantes ou évite les sujets de tension.
✓ Excellent · Recueille des besoins parfois contradictoires, fait dialoguer des parties prenantes et trouve des arbitrages acceptés de tous.
Compétences techniques
À quoi ressemble une spécification fonctionnelle que vous considérez comme bien faite ?
→ Évalue la clarté de ses standards : règles de gestion explicites, cas limites, critères testables et lisibilité pour les équipes techniques.
Comment modélisez-vous un processus métier et comment choisissez-vous le niveau de détail ?
→ Mesure la maîtrise du formalisme et la capacité à adapter la représentation selon l'audience visée.
Réalisations & expérience
Racontez un projet où vous avez recueilli un besoin métier complexe. Comment avez-vous procédé pour le cadrer ?
→ Cherche une méthode de recueil structurée, des ateliers menés et une capacité à reformuler le besoin au-delà de la demande initiale.
Mise en situation
Le métier et les équipes techniques ne sont pas d'accord sur une solution. Comment gérez-vous ?
→ Vérifie le rôle de pont : écoute des deux parties, traduction, recherche d'un arbitrage et capacité à objectiver la décision.
Un écart apparaît en recette entre la solution livrée et le besoin exprimé. Quelle est votre démarche ?
→ Apprécie le suivi jusqu'à la livraison, la rigueur sur les cas de recette et la gestion factuelle de l'écart.
Motivation & fit
Qu'est-ce qui vous plaît dans le rôle d'analyste, par rapport à un poste plus orienté pilotage ou produit ?
→ Cherche un goût réel pour l'analyse, la formalisation et le lien métier et technique plutôt qu'une orientation par défaut.
Savoir-être & collaboration
Comment expliqueriez-vous une contrainte technique à un responsable métier qui ne la comprend pas ?
→ Teste la pédagogie et la capacité à vulgariser sans perdre l'interlocuteur ni le détail utile.
Reste centré sur la solution sans jamais interroger le besoin réel
Un analyste qui ne challenge pas la demande produit des spécifications qui passent à côté du problème de fond.
Spécifications floues assumées comme normales
Des documents ambigus génèrent des aller-retour permanents et reportent la charge d'interprétation sur les développeurs.
Se positionne d'un seul côté, métier ou technique
Le coeur du rôle est le lien entre les deux mondes ; un profil mono-orienté ne fluidifie pas les échanges.
Se désengage une fois les spécifications rédigées
Sans suivi en recette et jusqu'à la livraison, l'écart entre besoin et solution n'est jamais détecté ni corrigé.
Incapable de vulgariser un sujet technique ou métier
Un déficit de pédagogie laisse les incompréhensions s'installer et fragilise tout le projet.
Lecture du score
Notez chaque compétence et savoir-être de 1 à 5. Repère de décision : moyenne supérieure ou égale à 4 sur les must-have et aucun red flag majeur = go ; 3 à 4 avec réserves = à challenger en second tour ; un must-have sous 3 ou un red flag majeur = no-go. Un nice-to-have faible ne doit jamais éliminer un bon profil.
Qu'est-ce qu'une scorecard pour recruter un Business Analyst ?
Une scorecard business analyst est une grille d'évaluation structurée : elle liste les compétences et savoir-être à noter de 1 à 5, les questions d'entretien à poser et les signaux d'alerte. Elle permet de comparer les candidats sur des critères objectifs plutôt que sur une impression. On parle aussi de scorecard analyste métier, scorecard business analyst, scorecard consultant fonctionnel.
Comment utiliser cette scorecard Business Analyst ?
Téléchargez-la en PDF, Excel ou Notion, notez chaque critère de 1 à 5 pendant l'entretien, puis additionnez les scores du panel pour décider sur des faits. La version Excel calcule la moyenne et la décision automatiquement.
Quelle différence entre un Business Analyst et un Chef de projet AMOA ?
Le Business Analyst se concentre sur l'analyse du besoin, sa formalisation en spécifications et la modélisation des processus. Le Chef de projet AMOA pilote la démarche dans sa globalité : planning, budget, coordination des acteurs et tenue des jalons. Sur des structures plus petites, une même personne peut couvrir les deux, mais le centre de gravité diffère : l'un produit l'analyse, l'autre pilote la livraison côté maîtrise d'ouvrage.
Quelle différence entre un Business Analyst et un Product Owner ?
Le Business Analyst formalise le besoin métier et fait le lien avec la technique, souvent sur des projets cadrés et documentés. Le Product Owner porte la vision d'un produit, priorise un backlog et arbitre la valeur dans une logique itérative, avec une responsabilité sur le résultat livré. Le premier excelle dans l'analyse et la spécification, le second dans la décision produit et la priorisation continue. Selon l'organisation et son niveau de maturité agile, les deux rôles peuvent se recouvrir partiellement.