Glossaire de la Business Analyse (sans jargon)
Partager
En bref. La Business Analyse est la discipline qui permet le changement dans une organisation. Elle cerne le besoin réel — un problème à régler, ou une opportunité à saisir. Elle le traduit en exigences vérifiables : des phrases précises sur ce que la solution devra faire (mais aussi ne devra pas faire), et qu'on pourra contrôler une fois livrée. Puis elle compare les options et recommande celle qui apporte le plus de valeur aux parties prenantes, c'est-à-dire à tous ceux que le changement touche. Un glossaire partagé évite les malentendus coûteux : quand deux personnes disent « exigence » ou « backlog produit » sans parler de la même chose, le projet dérape. Les autres termes essentiels, et les titres de rôles qu'on croise, se définissent chacun en une phrase claire, sans jargon.
Chez Edelw'ice, le glacier artisanal lausannois fondé par Heidi en 1983, une réunion s'enlise : Heidi parle de « besoin », le prestataire répond « exigences », et Lexie réalise qu'ils ne parlent pas de la même chose depuis vingt minutes. Abby ouvre alors le document que toute équipe devrait avoir : un glossaire partagé. Le mot le plus dangereux d'un projet, c'est celui que chacun croit comprendre.
Pourquoi un glossaire évite les disputes coûteuses ?
Parce que la plupart des conflits de projet ne sont pas des désaccords : ce sont des malentendus de vocabulaire. « Livré » veut-il dire codé, testé, ou en production ? « Prioritaire » veut-il dire urgent ou important ? Tant que les mots flottent, les décisions flottent aussi.
Abby veut figer les définitions par écrit ; Lexie veut qu'elles restent simples et partagées. Les deux ont raison : un glossaire n'a de valeur que s'il est clair et vivant.
Le mot qui porte tous les autres
Un glossaire du métier commence par le nom du métier. C'est l'IIBA (International Institute of Business Analysis), l'association professionnelle qui publie le BABOK et délivre les certifications, qui en tient le cadre de référence. Voici la définition que nous utilisons dans toute la collection, et qu'on ne raccourcit jamais :
La Business Analyse est la discipline qui permet le changement dans une organisation. Elle cerne le besoin réel — un problème à régler, ou une opportunité à saisir. Elle le traduit en exigences vérifiables : des phrases précises sur ce que la solution devra faire (mais aussi ne devra pas faire), et qu'on pourra contrôler une fois livrée. Puis elle compare les options et recommande celle qui apporte le plus de valeur aux parties prenantes, c'est-à-dire à tous ceux que le changement touche.
Les termes essentiels, définis simplement
Voici le reste du vocabulaire de base, chaque terme en une phrase.
| Terme | Définition simple |
|---|---|
| Business Analyse | Définie en entier ci-dessus — c'est le seul terme de cette liste qu'on ne résume pas. |
| Business analyst | La personne qui porte cette discipline : elle fait émerger la bonne décision, elle ne l'impose pas. |
| Besoin | Le problème à résoudre — le pourquoi. |
| Exigence | Ce que la solution doit faire ou respecter pour répondre au besoin — le quoi, vérifiable. |
| Partie prenante (stakeholder) | Toute personne concernée par le sujet ou qui peut l'influencer. |
| Élicitation | L'art de faire émerger le vrai besoin (entretiens, ateliers, observation) — au-delà de ce qui est dit spontanément. |
| Périmètre (scope) | Ce qui est dans le projet — et surtout ce qui est dehors. |
| Backlog produit | La liste, ordonnée par valeur, de tout ce qui reste à faire sur un produit ; elle vit au-delà d'un projet et c'est le product owner qui la porte. |
| Priorisation | La méthode qui décide de l'ordre. Les axes dépendent de qui arbitre : le métier classe des fonctionnalités en impact × urgence, l'équipe qui réalise classe des tâches en impact × effort. |
| MoSCoW | Une priorisation en quatre paniers : Must (indispensable), Should (important), Could (souhaitable), Won't (pas cette fois). |
| Critère d'acceptation | La condition observable qui dit qu'une exigence est satisfaite. |
| User story (récit utilisateur) | Un besoin exprimé en une phrase du point de vue de l'utilisateur : « en tant que… je veux… afin de… ». |
| Cartographie des parties prenantes | Le repérage de qui pèse sur le projet, selon son influence et son intérêt. |
| Traçabilité | Le fil qui relie chaque exigence à son besoin d'origine et à ce qui la vérifie. |
| BABOK | Le guide de référence international de la Business Analyse, publié par l'IIBA : six domaines de connaissance, cinquante techniques, les compétences fondamentales du praticien et cinq perspectives de contexte. |
| IIBA | International Institute of Business Analysis : l'association professionnelle du métier, qui publie le BABOK et délivre les certifications (ECBA, CCBA, CBAP). |
| Domaine de connaissance | L'une des six grandes familles d'activité dans lesquelles le BABOK range le métier — dont la définition de la conception (ou du design). |
| nLPD / RGPD | Les lois de protection des données : la nLPD en Suisse, le RGPD dans l'Union européenne. |
Le réflexe d'Abby. « Un mot par sens, un sens par mot. » Dès qu'un terme porte deux sens dans l'équipe, elle l'inscrit au glossaire.
Les titres de rôles qu'on croise
Le titre « business analyst » ne couvre qu'une partie des personnes qui font ce travail. Quatre titres voisins reviennent sans cesse, et ils ne désignent pas la même chose.
| Titre | En une phrase |
|---|---|
| Product owner (PO) | La personne qui décide de l'ordre dans lequel une équipe construit, et qui porte le backlog produit. |
| AMOA (assistance à maîtrise d'ouvrage) | La personne qui représente le métier — le service qui a le besoin — face à un prestataire ou au service informatique interne ; le terme est courant en France, moins en Suisse. |
| Analyste data | La personne qui part des chiffres pour établir ce qui se passe réellement, avant qu'on décide quoi changer. |
| Pilote de processus | La personne qui veille à la façon dont le travail circule d'un service à l'autre, d'un bout à l'autre de la chaîne. |
Chacun de ces rôles fait de la Business Analyse sur son périmètre, avec des outils communs. Ce qui les distingue, c'est la portée de la décision qu'ils éclairent — pas la qualité du travail.
La même logique, hors de la Business Analyse
Toute équipe qui dure finit par créer son langage : une cuisine de restaurant, une salle d'opération, un club de sport ont leurs mots précis. Le glossaire ne complique pas la communication — il l'accélère, parce que plus personne ne perd de temps à vérifier « on parle bien de la même chose ? ». Que tu mènes un projet, une association ou une entreprise, l'idée tient.
Construire ton glossaire de projet en trois gestes
- Repère les 3–4 mots piégés : ceux qui reviennent et que chacun interprète autrement (« livré », « prioritaire », « client »…).
- Écris une définition d'une phrase par mot, validée par l'équipe, dans un document partagé.
- Tiens-le vivant : ajoute un terme dès qu'un nouveau malentendu apparaît. Un glossaire figé ne sert à rien.
Tu n'as pas besoin de tous les termes du métier — juste de ceux qui font trébucher ton projet.
Questions fréquentes
C'est quoi la Business Analyse ?
La Business Analyse est la discipline qui permet le changement dans une organisation. Elle cerne le besoin réel — un problème à régler, ou une opportunité à saisir. Elle le traduit en exigences vérifiables : des phrases précises sur ce que la solution devra faire (mais aussi ne devra pas faire), et qu'on pourra contrôler une fois livrée. Puis elle compare les options et recommande celle qui apporte le plus de valeur aux parties prenantes, c'est-à-dire à tous ceux que le changement touche.
Qu'est-ce qu'une exigence en Business Analyse ?
Une exigence est une chose que la solution doit faire ou respecter pour répondre au besoin. Elle décrit un « quoi » vérifiable, pas un « comment » technique.
Quelle différence entre besoin et exigence ?
Le besoin est le problème à résoudre (le pourquoi) ; l'exigence est ce que la solution doit faire pour y répondre (le quoi). On clarifie le besoin avant d'écrire des exigences.
C'est quoi MoSCoW ?
Une méthode de priorisation qui range les exigences en quatre paniers : Must (indispensable), Should (important), Could (souhaitable), Won't (pas cette fois). Elle force à distinguer le vital du confort.
Faut-il connaître tout ce vocabulaire pour travailler avec un business analyst ?
Non. Une dizaine de termes suffisent à collaborer : besoin, exigence, partie prenante, périmètre, backlog produit, priorisation. Le reste s'apprend au fil des projets.
Articles liés : La Business Analyse, et ce qu'elle apporte vraiment aux entreprises · Le BABOK expliqué simplement (sans jargon) · Comment choisir la bonne technique de BA
