IREB et BABOK : deux boussoles pour structurer votre pratique d’analyse

On ne compte plus les projets qui déraillent non pas sur la technique, mais bien en amont : un besoin mal compris, une exigence jamais formulée, un « évidemment » que personne n’avait écrit. Le constat est documenté depuis les années 1980 et, si les multiplicateurs exacts font débat, la tendance ne s’est jamais démentie : plus une erreur d’exigence est détectée tard, plus elle coûte cher à corriger — en production, on parle d’un ordre de grandeur de plus qu’au cadrage. Et pourtant, l’analyse reste souvent pratiquée « à l’instinct », chacun avec son vocabulaire et ses habitudes.

La bonne nouvelle, c’est que ce travail a été balisé. Deux référentiels internationaux font autorité : l’IREB, côté ingénierie des exigences, et le BABOK, côté business analysis. Si vous débutez comme business analyst, product owner ou MOA, cet article vous donne une carte de ces deux territoires : ce qu’ils contiennent, ce qui les distingue, et par lequel commencer.

L’IREB : l’ingénierie des exigences

L’IREB (International Requirements Engineering Board) est une association à but non lucratif fondée en 2006 en Allemagne par des praticiens et des universitaires du génie logiciel. Son objet n’est pas de vendre une méthode, mais de définir un socle commun de connaissances pour l’ingénierie des exigences (requirements engineering), diffusé sous forme de syllabus publics et d’une certification, le CPRE (Certified Professional for Requirements Engineering).

La culture d’origine se sent : l’IREB vient du monde du logiciel et de l’ingénierie système, avec un goût prononcé pour la précision. Une exigence y est définie rigoureusement : un besoin ou une contrainte, documenté, qu’un système doit satisfaire. Le référentiel couvre l’ensemble du cycle de vie des exigences — le syllabus actuel l’aborde par neuf principes fondamentaux, les produits de travail et les pratiques associées — dont on peut retenir quatre activités centrales :

• L’élicitation : faire émerger les exigences. Le mot est choisi à dessein — on ne « recueille » pas des exigences comme on ramasse des champignons : on les fait naître par des techniques actives : interviews, observation, ateliers, prototypes, analyse de documents existants.
• La documentation : les formuler sans ambiguïté. L’IREB décrit les formes possibles — langage naturel contrôlé (les fameux gabarits de phrases), modèles graphiques, cas d’utilisation — et les critères de qualité d’une exigence : vérifiable, non ambiguë, nécessaire, faisable.
• La validation et la négociation : vérifier avec les parties prenantes que les exigences documentées sont les bonnes, arbitrer les conflits entre elles — car deux parties prenantes sincères peuvent vouloir des choses incompatibles.
• La gestion des exigences : les faire vivre dans le temps — priorisation, traçabilité, gestion des changements, versions.

Un exemple vaut mieux qu’un long discours. « Le système doit être rapide » n’est pas une exigence : rien n’y est vérifiable. Passée au filtre des critères de l’IREB, elle devient par exemple : « Pour 95 % des recherches, le système affiche les résultats en moins de deux secondes. » Toute la différence entre un vœu et un engagement testable tient dans cette reformulation.

La force de l’IREB tient dans cette rigueur de vocabulaire. Quand une équipe partage ces définitions, des familles entières de malentendus disparaissent : on ne confond plus un souhait avec une exigence, ni une solution avec un besoin.

Côté certification, une phrase suffit ici : le CPRE existe en trois niveaux (Foundation, Advanced, Expert), le Foundation étant tout à fait accessible en autoformation à partir du syllabus, téléchargeable gratuitement sur le site de l’IREB (en anglais et dans plusieurs autres langues).

Le BABOK : le corpus de la business analysis

Le BABOK (Business Analysis Body of Knowledge) est publié par l’IIBA (International Institute of Business Analysis), association fondée en 2003 au Canada. Sa version actuelle, le BABOK v3 (publié en 2015), est le corpus de référence du métier de business analyst.

Le changement de perspective par rapport à l’IREB est immédiat : là où l’ingénierie des exigences part d’un système à spécifier, la business analysis part d’une entreprise qui cherche à créer de la valeur. Le logiciel n’est qu’une des réponses possibles ; parfois la bonne solution est un changement d’organisation, de processus, ou… ne rien faire.

Le BABOK organise le métier en six domaines de connaissance :

1. Planification et suivi de la business analysis — organiser son propre travail d’analyse : quelles parties prenantes, quelle gouvernance, quels livrables.
2. Élicitation et collaboration — obtenir l’information et maintenir l’engagement des parties prenantes (on retrouve l’élicitation de l’IREB, élargie à toute la collaboration).
3. Gestion du cycle de vie des exigences — tracer, prioriser, approuver, réutiliser les exigences dans le temps.
4. Analyse de la stratégie — comprendre l’état actuel, définir l’état futur, évaluer les risques : c’est le domaine le plus « amont », celui qui relie l’analyse aux objectifs de l’entreprise.
5. Analyse des exigences et définition de la conception — structurer, modéliser, spécifier les exigences et esquisser les solutions.
6. Évaluation de la solution — mesurer si la solution livrée produit réellement la valeur attendue, et recommander des améliorations.

À quoi s’ajoutent une galerie d’une cinquantaine de techniques (SWOT, modélisation de processus, ateliers, user stories, analyse des règles métier…) et un modèle transversal, le Business Analysis Core Concept Model, qui relie six concepts : changement, besoin, solution, partie prenante, valeur, contexte.

Là aussi, une phrase sur les certifications : l’IIBA en propose trois, échelonnées selon l’expérience — ECBA pour les débutants, CCBA puis CBAP pour les praticiens confirmés.

Le pont : deux focales sur le même travail

Ces deux référentiels ne sont pas concurrents : ils regardent le même travail avec deux focales différentes. Le BABOK cadre large — de la stratégie d’entreprise à l’évaluation de la valeur livrée. L’IREB zoome sur le segment central — transformer des besoins en exigences exploitables par une équipe de réalisation — et le traite avec une profondeur que le BABOK n’atteint pas.

Sur le cycle d’un projet, leurs zones d’intervention se recouvrent au centre :

flowchart LR
    A[Strategy] --> B[Needs analysis]
    B --> C[Requirements]
    C --> D[Solution design]
    D --> E[Delivery]
    E --> F[Value evaluation]
    subgraph BABOK
      A
      B
      F
    end
    subgraph SHARED[BABOK + IREB]
      C
    end
    subgraph IREB
      D
    end

En pratique, les deux vocabulaires cohabitent très bien : on peut cadrer un programme avec les domaines du BABOK et, au moment de spécifier, appliquer les critères de qualité et les gabarits de l’IREB. C’est même la combinaison la plus confortable que je connaisse : le BABOK vous dit quoi regarder et pourquoi, l’IREB vous dit comment l’écrire sans ambiguïté.

Par où commencer ?

Si vous débutez, mon conseil tient en trois temps :

1. Commencez par le syllabus CPRE Foundation de l’IREB. Il est gratuit, court, et il installe le vocabulaire de base — la différence entre besoin, exigence et solution vaut à elle seule la lecture.
2. Poursuivez avec le BABOK en diagonale. Ne le lisez pas comme un roman : parcourez les six domaines pour situer votre poste actuel, puis piochez dans les techniques quand un besoin concret se présente.
3. Appliquez immédiatement sur un vrai sujet. Prenez une demande en cours dans votre équipe et reformulez-la avec les critères de qualité de l’IREB : l’exercice est plus instructif que n’importe quelle lecture.

Les certifications viendront ensuite, si votre contexte les valorise — elles sont un bon prétexte pour étudier sérieusement, pas une fin en soi.

Ces référentiels ont une vingtaine d’années, mais ils n’ont jamais été aussi actuels : formuler un besoin sans ambiguïté est exactement la compétence que demande aussi le travail avec les IA génératives. C’est d’ailleurs le fil d’un autre billet de ce blog, où l’IREB sert de garde-fou à une IA qui code trop vite — BiblioCQRS – Épisode 2 : Remettre l’IA à l’école du métier (IREB).