Les Erreurs qui Freinent une Carrière de Business Analyst

Sommaire

1. Erreur 1 : se contenter de rédiger des exigences
2. Erreur 2 : confondre son rôle avec celui du product owner
3. Erreur 3 : parler fonctionnalités au lieu de valeur
4. Erreur 4 : laisser l’IA redéfinir le métier sans vous
5. Erreur 5 : ne pas documenter son expérience
6. Erreur 6 : viser la mauvaise certification
7. Conclusion
8. FAQ

Le métier de business analyst n’a jamais été aussi recherché. En Suisse, l’intérêt pour ce terme dans Google a progressé de plus de 50 % en un an. Les banques, les assurances, l’industrie et les administrations publiques ouvrent des postes à Genève comme à Lausanne.

Pourtant, beaucoup d’analystes plafonnent après quelques années. Ils maîtrisent les outils, connaissent leur métier et livrent des spécifications propres. Malgré cela, on continue de les voir comme des exécutants, rarement comme des partenaires de la direction.

Ce blocage a presque toujours la même origine. En effet, il vient rarement d’un manque de technique. Il naît plutôt d’erreurs de posture et de parcours. Les six erreurs ci-dessous reviennent sans cesse dans nos sessions de formation. Chacune se corrige, à condition de la repérer tôt.

Erreur 1 : se contenter de rédiger des exigences

C’est l’erreur la plus répandue, et la plus coûteuse. Le métier demande une fonction, l’analyste la note, la reformule et la transmet à l’équipe technique. Sur le papier, le travail est fait. En réalité, personne n’a vérifié si cette fonction répondait au vrai problème.

Le réflexe du scribe

Un analyste qui se limite à transcrire devient vite interchangeable. De plus, il porte la responsabilité des mauvaises solutions sans avoir eu son mot à dire sur le besoin. Quand le projet déçoit, on lui reproche une spécification incomplète, alors que la demande initiale était déjà fausse.

Revenir au besoin réel

Le BABOK est le référentiel de l’International Institute of Business Analysis (IIBA). Il propose un outil simple pour sortir de ce piège : le BACCM, qui articule six concepts.

Ces six concepts sont les suivants :

• le changement à mener ;
• le besoin à satisfaire ;
• la solution envisagée ;
• les parties prenantes concernées ;
• la valeur attendue ;
• le contexte de l’organisation.

Concrètement, si une demande ne permet pas de remplir ces six cases, elle n’est pas prête. Posez donc les questions qui manquent avant d’écrire la moindre exigence. Vous passerez d’abord pour quelqu’un d’exigeant, puis pour quelqu’un de fiable.

Prenons un exemple courant. Le service clients demande un nouveau champ dans le formulaire de réclamation. Avant de le spécifier, l’analyste demande pourquoi. Il découvre alors que l’équipe veut en réalité trier les réclamations urgentes. Une règle de priorité automatique répond mieux à ce besoin qu’un champ de plus, et elle coûte moins cher à maintenir. Ce type de recadrage, répété projet après projet, construit votre crédibilité.

Erreur 2 : confondre son rôle avec celui du product owner

Avec la généralisation de Scrum, beaucoup d’entreprises ont renommé le business analyst en product owner. Certains analystes ont suivi le mouvement sans vraiment changer de rôle. D’autres, au contraire, se sont retrouvés à coordonner des sprints sans mandat clair.

Les deux rôles se ressemblent, mais ils ne portent pas la même responsabilité. Le product owner décide : il arbitre le backlog et répond de la valeur du produit. Le business analyst éclaire la décision : il analyse le besoin, modélise les processus et vérifie que la solution tient la route. Notre article sur le rôle du product owner dans Scrum détaille d’ailleurs ce périmètre.

Le piège consiste à cumuler les deux casquettes sans le dire. Vous arbitrez alors des priorités sans en avoir l’autorité. L’équipe, elle, ne sait plus à qui s’adresser. Clarifiez donc votre rôle par écrit dès le lancement du projet, surtout en mode agile.

Un partage des tâches explicite

Dans les équipes qui fonctionnent bien, la répartition ressemble souvent à ceci :

• le product owner fixe l’objectif du produit et ordonne le backlog ;
• le business analyst prépare les éléments du backlog, avec les règles métier, les critères d’acceptation et les modèles de processus ;
• ensemble, ils vérifient que chaque livraison répond au besoin de départ.

Ce partage n’a rien d’officiel dans le Scrum Guide. Cependant, il évite les doublons et donne à chacun un périmètre défendable devant sa hiérarchie.

Erreur 3 : parler fonctionnalités au lieu de valeur

Devant un comité de direction, un analyste présente souvent ce que la solution fera. Or, la direction veut savoir ce qu’elle rapportera. Cette différence de vocabulaire suffit à vous ranger parmi les techniciens plutôt que parmi les conseillers.

Traduire chaque besoin en résultat

Prenez l’habitude de rattacher chaque exigence à un objectif mesurable. Par exemple, « automatiser la saisie des factures » devient « réduire de moitié le délai de traitement des factures fournisseurs ». La fonction reste la même, mais la discussion change de niveau.

Parler le langage du comité

Avant chaque présentation, préparez trois chiffres : le coût du problème actuel, le gain attendu et le délai avant d’en voir les effets. Si vous ne les connaissez pas, demandez-les au contrôle de gestion ou au responsable métier. Ces chiffres seront imparfaits, et ce n’est pas grave. En effet, une estimation argumentée ouvre la discussion, alors qu’une liste de fonctions la referme.

Mesurer après la mise en service

La plupart des analystes disparaissent du projet le jour de la livraison. Pourtant, l’évaluation de la solution fait partie intégrante du métier selon le BABOK. Revenez donc trois mois plus tard avec des chiffres. Rien ne construit mieux une réputation qu’un bilan qui prouve la valeur promise.

Erreur 4 : laisser l’IA redéfinir le métier sans vous

L’intelligence artificielle sait déjà résumer un atelier, proposer des user stories ou dessiner un premier modèle de processus. Beaucoup d’analystes y voient une menace. D’autres l’ignorent, en espérant que la vague passera.

Les deux réactions vous freinent. En réalité, l’IA automatise surtout la partie du métier qui avait le moins de valeur : la mise en forme. En revanche, elle ne sait pas arbitrer entre deux directions rivales. Elle ne repère pas non plus le besoin que personne n’ose formuler. L’IIBA le souligne d’ailleurs sur sa page consacrée au CCBA. Face à l’IA, une expérience vérifiée selon un standard reconnu prend plus de poids.

Utilisez donc ces outils pour gagner du temps sur la rédaction. Ensuite, réinvestissez ce temps dans l’analyse et la relation avec le métier. Vérifiez cependant chaque résultat. Une user story générée peut sembler parfaite tout en reposant sur une hypothèse fausse.

Où l’IA fait vraiment gagner du temps

Dans la pratique, quatre usages reviennent chez les analystes qui en tirent profit :

• transformer les notes d’un atelier en compte rendu structuré ;
• proposer une première liste de cas limites à tester ;
• reformuler une exigence pour un public non technique ;
• comparer deux versions d’un document pour repérer les écarts.

Dans chaque cas, l’outil produit un brouillon et vous gardez la décision. Attention toutefois aux données : ne collez jamais d’informations clients ou confidentielles dans un outil que votre entreprise n’a pas validé.

Erreur 5 : ne pas documenter son expérience

Cette erreur passe inaperçue pendant des années. Puis elle coûte cher au moment de candidater à une certification. Les certifications avancées exigent en effet un nombre précis d’heures d’expérience, réparties sur une période donnée.

Des heures à justifier

Pour le CCBA, l’IIBA demande 3 750 heures d’analyse métier sur les sept dernières années, soit deux à trois ans de pratique. Pour le CBAP, il faut 7 500 heures sur les dix dernières années, soit plus de cinq ans. Dans les deux cas, vous déclarez aussi des heures de développement professionnel : 21 pour le CCBA et 35 pour le CBAP, sur les quatre dernières années.

Un journal simple suffit

Reconstituer dix ans de projets de mémoire relève de l’exploit. Tenez plutôt un tableau à jour : nom du projet, dates, heures consacrées à l’analyse, techniques utilisées et responsable à contacter. Ce tableau vous servira également en entretien annuel, car il rend votre contribution visible.

Ce journal vous protège aussi lorsque vous changez d’employeur. Les outils de suivi internes disparaissent avec votre accès, et vos anciens responsables changent de poste. Un fichier personnel, tenu chaque mois en dix minutes, reste au contraire disponible au moment où vous en aurez besoin.

Erreur 6 : viser la mauvaise certification

Le marché propose plusieurs certifications, et beaucoup d’analystes choisissent la plus prestigieuse plutôt que la plus adaptée. Résultat : un dossier refusé, ou un titre qui ne reflète pas leur niveau réel. Le tableau ci-dessous reprend les exigences officielles de l’IIBA et du PMI.

Choisir selon votre parcours

Si vous débutez ou changez de métier, l’ECBA valide vos bases sans exiger d’expérience. Notez toutefois que sa nouvelle version n’existe pour l’instant qu’en anglais. L’IIBA maintient néanmoins l’ancienne version de l’examen en français. Après deux à trois ans de pratique, le CCBA devient l’étape logique.

Au-delà de cinq ans, le CBAP s’impose comme la référence. Selon l’IIBA, ses titulaires gagnent jusqu’à 19 % de plus que leurs pairs non certifiés. Enfin, si vous travaillez surtout dans un environnement de gestion de projet, le PMI-PBA parle le même langage que le PMP.

Le cas de la reconversion

Beaucoup d’analystes viennent du métier : comptabilité, gestion de sinistres, logistique ou ressources humaines. Ils connaissent les processus de l’intérieur, ce qui représente un atout réel. Pourtant, ils sous-estiment souvent cette expérience au moment de choisir leur certification. Si vous avez déjà mené des analyses sans en porter le titre, comptez ces heures. Elles peuvent en effet vous ouvrir directement le CCBA plutôt que l’ECBA.

Penser au maintien

Les certifications de l’IIBA se renouvellent tous les trois ans. Par ailleurs, un titulaire du CBAP et du CCBA voit son CCBA renouvelé automatiquement avec le CBAP. Si votre profil hésite encore entre gestion de projet et analyse, notre comparatif PMP ou CAPM vous aidera aussi : l’analyse métier pèse 27 % de l’examen CAPM.

Conclusion

La carrière d’un business analyst se joue rarement sur la technique. Elle se joue sur sa capacité à questionner le besoin, à parler de valeur et à occuper un rôle clair, y compris en agile. Ces trois réflexes transforment un rédacteur de spécifications en interlocuteur de la direction.

Le reste relève de l’organisation. Tenez votre journal d’expérience dès aujourd’hui, utilisez l’IA comme un assistant plutôt que comme un concurrent, et choisissez la certification qui correspond à votre niveau réel. D’ailleurs, selon le rapport 2026 de l’IIBA sur l’état de la profession, 70 % des employeurs financent la formation continue de leurs analystes : posez la question au vôtre.

FAQ

Quelle est la différence entre un business analyst et un product owner ?
Le product owner décide des priorités et répond de la valeur du produit. Le business analyst analyse le besoin, modélise les processus et éclaire ces décisions.

Quelle certification passer pour débuter comme business analyst ?
L’ECBA de l’IIBA ne demande aucune expérience. Elle valide les bases du métier et prépare la suite du parcours vers le CCBA puis le CBAP.

Combien d’expérience faut-il pour le CBAP ?
Il faut 7 500 heures d’analyse métier sur les dix dernières années, soit plus de cinq ans, ainsi que 35 heures de développement professionnel.

L’IA va-t-elle remplacer les business analysts ?
Non. Elle automatise surtout la rédaction et la mise en forme. En revanche, l’arbitrage entre parties prenantes et la compréhension du besoin réel restent humains.

Peut-on passer les certifications de l’IIBA en français ?
La nouvelle version de l’ECBA existe pour l’instant en anglais. L’IIBA propose toutefois encore l’ancienne version de l’examen ECBA en français.