La Business Analyse, et ce qu'elle apporte vraiment aux entreprises

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. Son résultat est souvent un coût évité — et c'est précisément pour ça qu'on la voit si peu.

J'ai commencé ma carrière professionnelle en tant que développeuse. Je livrais du code propre, testé, dans les délais, et pourtant mes clients n'étaient jamais vraiment satisfaits. Ça m'a agacée longtemps avant que je me décide finalement à leur demander pourquoi. La réponse a été sensiblement la même à chaque fois, presque avec les mêmes mots : « L'outil est très bien. Mais ce n'est pas ce que je voulais. »

Rien ne s'était mal passé pendant la réalisation. Le problème, c'est ce qui s'était — ou ne s'était pas — passé avant.

C'est quoi la Business Analyse, concrètement ?

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.

Dit autrement : la personne qui fait de la Business Analyse ne construit pas la solution. Elle s'assure qu'on construit la bonne.

Ce n'est pas de la traduction. Traduire, ce serait prendre la demande du métier et la reformuler pour l'équipe technique — utile mais insuffisant. Quand quelqu'un te demande une Ferrari rouge, transmettre la demande telle quelle est le plus sûr moyen de livrer une magnifique Ferrari rouge dont personne ne se servira. Le travail commence aux questions que l'on va poser : pour aller où ? avec qui ? combien de fois par semaine ? Très souvent, ce dont la personne a besoin, ce n'est finalement que d'une trottinette bleue — et elle le découvre en te répondant.

Ce que ce n'est pas. Ce n'est pas d'abord rédiger un cahier des charges de cent pages, ni organiser des ateliers. Les deux sont bien de la Business Analyse — l'atelier est même l'un des meilleurs moyens de faire émerger un besoin — mais ils viennent après la question, pas à sa place. Et surtout ce n'est pas réservé aux grandes organisations. La Business Analyse c'est une série de gestes, dont n'importe qui peut poser le premier dès demain.

Pourquoi la phase d'analyse est-elle si facile à couper ?

Mars 2020 — début du COVID. En quelques semaines, les entreprises ont dû modifier leur stratégie et la façon dont elles allaient dépenser leur budget informatique. Et ce qu'elles ont gardé est aussi parlant que ce qu'elles ont coupé.

Le matériel est resté : il fallait équiper tous les collaborateurs en ordinateurs portables. L'infrastructure aussi : il fallait que les applications tournent à distance. Les logiciels également : il fallait continuer à maintenir les applications métier. Trois postes conservés — et trois postes dont le résultat se voit.

Dans la plupart des entreprises que je côtoyais, deux postes ont sauté : l'analyse et l'accompagnement du changement. Parce que ça coûte, et que ça ne rapporte rien — du moins, rien qui se voie. Exactement les deux phases qui font qu'un projet sert à quelque chose et qu'il est utilisé correctement.

Ce n'était pas un accident. C'est la conséquence logique de la façon dont on mesure.

La phase de développement produit quelque chose qui se voit : un outil, une application, un logiciel. L'analyse, elle, produit un « coût évité » : le projet qu'on n'a pas lancé, la fonctionnalité qu'on n'a pas construite, la refonte qu'on a arrêtée à temps. Or un coût évité ne figure sur aucun tableau de bord. Personne ne se lève en comité de direction pour annoncer les six mois qu'on n'a pas perdus. Une ligne budgétaire qui coûte et dont le bénéfice est invisible : l'arbitrage est vite fait.

Ce qui suit coûte plus cher que la coupe elle-même, parce que le travail, lui, ne disparaît pas vraiment. Quelqu'un finit toujours par recueillir le besoin, arbitrer le périmètre — ce qui est dans le projet et ce qui n'y est pas — et trancher entre deux options. Sauf que ce quelqu'un est un chef de projet déjà à 120 %, un expert métier à qui personne n'a appris à formuler une exigence, ou un prestataire dont ce n'est simplement pas le mandat. Aucun d'eux ne fait mal son travail : on leur a confié un travail qui n'est pas le leur, sans le leur dire — et on en découvre la facture à la livraison.

À quoi ça ressemble quand personne ne le fait

Edelw'ice, le glacier artisanal lausannois fondé par Heidi en 1983, lance en 2024 la refonte de sa vente en ligne. Un prestataire, DigitEra, arrive avec une promesse simple : une plateforme moderne, « on est agiles, on ajustera en route ». Personne ne lui demande ce qu'il sait de l'existant. Personne n'écrit ce que le projet doit régler. Le contrat se signe sur une démo.

Six mois plus tard, la plateforme existe — et le problème aussi. Les commandes arrivent, la chaîne du froid ne suit pas, et les clients qui ont attendu deux jours leur glace ne repassent pas commande.

C'est là qu'Abby et Lexie, les deux analystes appelées en renfort, posent la question que personne n'avait posée : qu'est-ce qu'on essayait de régler ? Abby, la méthodique, reconstitue ce que chacun attendait vraiment et met côte à côte trois attentes qui n'avaient jamais été comparées — elles sont incompatibles. Lexie, elle, va voir : une journée au dépôt lui suffit pour constater que le goulet d'étranglement n'est pas le site, c'est le créneau de livraison.

Le projet n'avait pas échoué à la construction. Il avait échoué à la question de départ. Six mois de développement avaient été engagés sans que personne la pose ; quand elle l'a enfin été, la réponse a tenu dans une journée au dépôt.

Ce qu'Edelw'ice a gagné ce jour-là ne figure sur aucun tableau de bord : c'est le deuxième cycle de développement qu'il n'a pas fallu financer pour « améliorer le site ».

Qui en fait, alors ?

Le titre « Business Analyst » ne couvre qu'une partie des gens qui font ce travail. Un pilote de processus veille à la façon dont le travail circule d'un service à l'autre. Une personne en AMOA (assistance à maîtrise d'ouvrage) 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. Un product owner décide de l'ordre dans lequel une équipe construit. Un analyste data part des chiffres pour établir ce qui se passe réellement. Tous en font aussi, sur des périmètres différents, mais avec des outils communs.

C'est ce que montre cette carte. De gauche à droite, la portée de la décision : d'une seule fonctionnalité jusqu'à l'entreprise entière. De haut en bas, la question à laquelle le rôle répond — pourquoi on fait ça, quoi on construit, comment on le construit.

Tous les rôles de la zone en pointillé font de la Business Analyse. Un seul en porte le nom — sous deux appellations : « Business Analyst » en Suisse romande et dans les offres rédigées en anglais, « analyste métier » en France et dans le secteur public. C'est le même métier, et il apparaît deux fois sur la carte : à l'échelle d'une équipe, et à l'échelle de l'entreprise.

Cette carte aide aussi à comprendre la coupe. Quand la ligne « analyse » disparaît du budget, le travail glisse vers les rôles voisins : un peu vers le haut, vers ceux qui décident — beaucoup vers le bas, vers ceux qui construisent. Les gestes restent à faire, mais plus personne n'en a le mandat, ni le temps, ni la formation.

Si un terme de cet article t'est étranger, le glossaire de la Business Analyse en explique l'essentiel, un par phrase.

La même chose, hors des projets informatiques

Une entreprise débordée recrute « un profil senior » : la raison qu'on se donne, c'est qu'il manque des bras. Six mois plus tard, on découvre que le problème n'était pas le nombre de personnes mais la façon dont le travail était réparti — la raison réelle. Une commune construit un parking parce qu'en interne, on a résumé les remontées des habitants par « les gens n'arrivent plus à se garer » : là encore, la raison qu'on se donne est qu'il manque des places. Le parking restera à moitié vide — la plainte de départ portait sur vingt minutes de bouchon le matin.

Dans les deux cas, la solution demandée était cohérente. Et la question à poser n'avait rien de compliqué : « qu'est-ce que ça règle ? ». Le problème, c'est que personne ne l'a posée.

Par où commencer, sans changer de métier

Trois gestes, applicables à la prochaine demande qui arrive sur ton bureau.

1. Demande quel est le problème, ne te satisfais pas d'une demande de solution. Quand on te réclame un outil, une réunion ou un recrutement, pose la question : « qu'est-ce que ça règle ? » Note la réponse. Si personne ne sait la formuler, tu viens de trouver le vrai travail.
2. Écris ce à quoi on verra que c'est réussi, avant de commencer. Une phrase vérifiable, pas une intention. Par exemple, on ne note pas « le site sera plus rapide », mais « une commande se termine en moins de deux minutes ». C'est cette phrase qui remplace le débat d'opinions à la livraison.
3. Liste qui est concerné, et coche ceux à qui personne n'a parlé. Ce sont eux qui bloqueront le projet à un moment ou à un autre — rarement au début.

Aucun des trois ne demande une certification. Ils demandent de résister à l'envie d'aller vite, ce qui, en pratique, est nettement plus difficile.

Pour aller plus loin. Ces gestes portent des noms et forment une discipline outillée. Le référentiel international du métier, le BABOK® (Business Analysis Body of Knowledge), publié par l'IIBA (International Institute of Business Analysis, l'association professionnelle des Business Analysts), range ce travail en six domaines de connaissance et décrit une cinquantaine de techniques. Il dit quelle technique et pourquoi ; BA Toolkit la déroule sur ton cas, lundi matin.

Articles liés : Glossaire de la Business Analyse · Comment choisir la bonne technique de BA · Prioriser ses tâches quand tout est « prioritaire »