Business analyst : les compétences data qui font vraiment la différence en mission

Quand on change de projet ou de secteur, les premières semaines sont souvent révélatrices. Pas forcément sur le plan métier, la plupart des BAs s'adaptent vite à un nouveau domaine. Là où les lacunes apparaissent parfois, c'est sur la data.

Un architecte partage un modèle de données en réunion de cadrage. Un développeur pose une question sur les cardinalités d'une relation. Un product owner demande si une règle de gestion doit figurer dans le modèle conceptuel ou dans le modèle physique. Ces situations ne sont pas exceptionnelles. Elles sont courantes. Et un BA qui ne sait pas y répondre, ou même simplement y participer, perd en crédibilité rapidement.

Ce n'est pas une question de niveau technique. C'est une question de vocabulaire commun avec l'équipe data et IT. Et ce vocabulaire s'acquiert.

Pourquoi la data est devenue incontournable pour un BA

Il y a dix ans, un business analyst pouvait travailler sur des projets IT sans jamais toucher à un modèle de données. Ce temps est révolu. Les projets sont de plus en plus orientés données : digitalisation des processus, intégration de systèmes, BI, CRM, MDM… Dans la quasi-totalité de ces projets, la donnée n'est pas un sujet périphérique. Elle est centrale.

Le BA qui ne comprend pas comment les données sont structurées devient un intermédiaire qui ralentit. Il reformule des besoins métier sans être capable de vérifier leur cohérence avec le modèle existant. Il rédige des user stories que les développeurs doivent retravailler parce que les règles de gestion ne tiennent pas compte des contraintes du modèle. Il pose des questions auxquelles l'équipe IT ne peut pas répondre, parce qu'elles ne sont pas formulées dans le bon registre.

À l'inverse, un BA qui maîtrise quelques compétences data clés devient un vrai pont entre le métier et l'IT. Il comprend les deux langues. Et ça se voit dès les premières semaines.

Compétence 1 : lire un modèle de données

C'est la compétence la plus fondamentale, et paradoxalement celle qu'on enseigne le moins dans les formations BA. Savoir lire un modèle de données, qu'il soit en ERD, en Merise ou en UML, permet de comprendre trois choses essentielles sans avoir à interroger constamment l'équipe technique.

D'abord, le périmètre fonctionnel du projet. Les entités présentes dans le modèle vous disent ce que le système connaît et manipule. Si une entité est absente, soit elle est hors périmètre, soit elle a été oubliée, et c'est une information précieuse à remonter.

Ensuite, les règles de gestion encodées dans les relations. Chaque cardinalité traduit une décision métier. Un client peut-il exister sans commande ? Une commande peut-elle contenir un seul produit, ou plusieurs ? Ces règles ne sont pas toujours documentées explicitement, elles sont dans le modèle.

Enfin, les zones d'ambiguïté. Une relation mal définie, une entité au nom flou, une cardinalité qui ne correspond pas à ce que le métier décrit : ce sont des signaux que seul quelqu'un capable de lire le modèle peut détecter.

Lire un modèle de données ne demande pas de savoir le construire, ni de connaître SQL. C'est une compétence de lecture, pas de conception.

Compétence 2 : poser les bonnes questions sur la donnée

Il y a une erreur que beaucoup de BAs commettent face à un modèle ou à une problématique data : ils posent des questions techniques. "C'est quoi cette table ?", "Pourquoi il y a une clé étrangère ici ?", "Est-ce qu'on utilise un index ?"

Ces questions ne sont pas les leurs. Elles n'apportent pas de valeur à l'analyse fonctionnelle, et elles donnent l'impression que le BA cherche à faire le travail du développeur, sans en avoir les outils.

Les bonnes questions sont des questions métier formulées à partir de la structure des données. La différence est subtile mais importante :

• Une question technique : "Pourquoi la table Commande a un champ statut ?"

• Une question métier : "Quels sont les différents états qu'une commande peut traverser, et quelles règles déclenchent le passage de l'un à l'autre ?"

La seconde question part d'une observation sur le modèle, mais elle interroge le processus métier. C'est exactement le registre d'un BA. Et c'est ce type d'échange que les équipes IT apprécient, parce qu'il force la formalisation de règles qui étaient jusqu'alors implicites.

Compétence 3 : distinguer le modèle conceptuel du modèle physique

C'est probablement la compétence la plus différenciante, et la moins connue des BAs qui n'ont pas eu de formation data.

Un modèle conceptuel représente les concepts métier et leurs relations, indépendamment de tout choix technique. Il dit quoi : quelles entités existent, quelles règles les lient. C'est le territoire du business analyst.

Un modèle physique, lui, représente comment ces concepts sont implémentés dans une base de données. Il dit comment : quelles tables, quels types de données, quelles contraintes techniques. C'est le territoire du développeur ou de l'architecte.

En pratique, on reçoit souvent des modèles physiques en début de mission. Ils sont plus difficiles à lire, plus chargés, plus techniques. Savoir reconnaître ce qu'on a sous les yeux, et savoir qu'il existe un niveau de lecture plus accessible, change beaucoup de choses.

Mais surtout, comprendre que le modèle conceptuel est la responsabilité du BA change le positionnement. Ce n'est pas un livrable technique qu'on sous-traite à l'IT. C'est un outil d'analyse et de communication que le BA est censé maîtriser, et souvent produire.

Ce que vous n'avez pas besoin de savoir

Pour être clair sur ce que ces compétences impliquent, et ce qu'elles n'impliquent pas.

Vous n'avez pas besoin de savoir écrire du SQL. Vous n'avez pas besoin de comprendre comment une base de données stocke physiquement l'information. Vous n'avez pas besoin de connaître les formes normales, les index, les procédures stockées ou les triggers.

Ces sujets appartiennent à l'équipe technique. Votre valeur ajoutée n'est pas là.

Elle est dans la capacité à lire ce que le modèle dit sur le métier, à formuler des exigences cohérentes avec la structure des données, et à produire un modèle conceptuel qui traduit fidèlement la réalité de l'organisation. C'est un périmètre précis, accessible, et très utile en mission.

Pour aller plus loin

Si vous souhaitez développer la première de ces compétences — lire un modèle de données — j'ai créé une formation gratuite de 2 heures spécialement conçue pour les Business Analysts et Product Owners.

Elle vous donne une méthode concrète pour lire et comprendre un modèle en ERD, Merise ou UML, sans formation technique préalable. Déjà suivie par plus de 1 000 participants, notée 4,5/5 pour sa clarté et son utilité pratique.

👉 Accéder gratuitement à la formation "Les Modèles de Données pour Product Owner et Business Analyst"

Clément Fiocre — Data Rosetta Stone