Dans cet article, nous allons nous intéresser aux motivations, au « pourquoi » il est utile de modéliser les données dans un cahier des charges.

« Un bon croquis vaut mieux qu’un long discours. » (Napoléon Bonaparte)

Un premier constat

Modéliser les données est difficile

Oui, la modélisation des données est une compétence difficile à acquérir. Mais postulons qu’une école telle que Supinfo, par exemple, trouve un intérêt à enseigner UML[1] à ses étudiants, notamment le diagramme de classe, ou que le témoignage suivant de Jean-Christophe Hurpea (responsable du développement d’Ortho-CLinical Diagnostics) a de la valeur :

« L’absence de modèle se faisait sentir. Le code était, en outre, faiblement documenté et nous n’étions pas à l’abri d’une perte de connaissances due au départ d’un développeur. UML nous a permis de décrire nos besoins et nos spécifications de façon très précise. Nos codes sont toujours en phase avec le modèle, ce qui fait qu’un nouveau technicien n’a besoin que de connaître UML pour comprendre tout de suite la structure du programme. UML nous apporte aussi une qualité certaine. Désormais, notre logiciel est très structuré[2]. »

Difficile donc, mais utile. Grâce à la modélisation des données, les gains pour un organisme seraient les suivants :

• les spécifications sont plus précises,
• le modèle et le code sont en adéquation,
• le logiciel est structuré,
• les nouveaux arrivants s’approprient plus rapidement le domaine fonctionnel.

L’utilisation des schémas semble donc avoir un fort potentiel de valeur ajoutée. Mais encore faut-il en être convaincu ! Et le plus difficile, lorsqu’on est convaincu de l’utilité de la modélisation des données, c’est d’arriver à en persuader les autres, particulièrement :

• s’ils exercent le même métier que vous,
• qu’ils pensent le faire au moins aussi bien que vous, sans modéliser.

Modélisation des données et qualité des cahiers des charges

Je ne connais pas de meilleure façon de convaincre que la démonstration par l’exemple. Ainsi, imaginons deux consultants devant réaliser, chacun de façon indépendante, un même projet de gestion des règlements clients, sur le même périmètre, en interviewant les mêmes interlocuteurs. L’un utilise des schémas (diagramme de classe, d’activité, de flux, d’état selon le besoin) et l’autre non.

D’après vous, lequel produira les spécifications les plus :

• complètes ?
• cohérentes ?
• pérennes ?

Si vous répondez « celui qui modélise les données » aux trois questions, alors c’est que vous êtes déjà convaincu de l’utilité de la modélisation des données dans les projets informatiques. Si vous ne l’utilisez pourtant pas, il faut vous demander pourquoi et identifier les actions qui permettront de mettre votre pensée en adéquation avec vos actes.

Sinon, il faut admettre que le terme « analyse » est en trop dans l’intitulé du métier que nous exerçons (Business Analysis) et le modifier, en « rapporteur du besoin » par exemple : nous collectons des besoins oraux que l’on transcrit et transmet aux développeurs, sans analyse approfondie préalable.

Pourquoi modéliser les données ?

Analyser, c’est modéliser les données (et inversement)

A priori, on ne modélise pas les données pour faire joli. Ni pour faire plaisir à son supérieur / commanditaire. Ni pour qu’il y ait des schémas dans un livrable. On modélise les données car, de la même façon qu’un maçon utilise un fil à plomb pour obtenir des verticales, on a besoin que le SI que l’on contribue à bâtir ou que l’on cherche à comprendre tienne droit. Et pour cela, il doit être logique, structuré et sans brèche.

Cas pratique de modélisation des données

Prenons la fonctionnalité suivante comme exemple :

« Les articles doivent être classés dans des gammes et proposées à la vente en fonction des types de client : professionnel, particulier et administration. »

De prime abord, il y a l’apparence de la clarté : en fonction de leur typologie, les clients accèdent à des gammes d’articles. Mais imaginons les questions qu’un développeur se poserait :

• Un article peut-il être dans une seule gamme ou dans plusieurs ?
• Un client est-il d’un seul type ou peut-il en avoir plusieurs ?
• Associe-t-on les articles ou bien les gammes aux types de client ? Ou les deux ?
• Un article et/ou une gamme peuvent-ils être associés à un seul type de client ou à plusieurs ?
• Veut -on avoir le choix de sélectionner unitairement les types de client ou ce choix doit-il être simplement binaire : soit un, soit tous ?
• Etc.

La fonctionnalité ne répond pas à toutes ces questions. Le travail d’analyse n’est pas fait. Il y a donc matière à interprétation. Sans le modèle de données cible, sa description littéraire validée par le commanditaire et les fonctionnalités décrivant précisément le besoin, on s’en remet alors totalement à la vision du développeur qui, précisions-le, est rarement un spécialiste du domaine fonctionnel. Il fera donc des choix qui seront parfois justes d’un point de vue métier mais souvent erronés.

Par analogie, achèterait-on un appartement sans avoir validé les plans de l’architecte, sur la base d’un besoin exprimé ainsi :

« Le logis doit contenir des pièces de différents types et être accessibles par des portes et des escaliers. »

et en faisant confiance les yeux fermés au chef de chantier et à son équipe pour construire le bien de nos rêves ?

Désamorcer la complexité de la modélisation des données

De plus, pour revenir à l’exemple précédent (« les articles doivent être classés dans des gammes et être proposées à la vente en fonction des types de client : professionnel, particulier et administration »), sans schéma, l’analyse exhaustive d’un tel énoncé est quasiment impossible. En effet, nous identifions déjà à la lecture :

• 5 concepts métier : article, gamme, commande (du fait de la vente), client et type de client,
• 4 associations, en modélisant au plus simple,
• 16 multiplicités : 8 minimums et 8 maximums, le nombre augmentant à chaque fois de 4 pour chaque nouvelle association.

Rien qu’avec une prise de notes textuelle, il est difficile de garantir que vous couvrirez 100% des possibilités, sachant que chaque question pourrait apporter de nouveaux concepts, donc de nouvelles associations à tisser et de nouvelles multiplicités à clarifier.

Modéliser les données pour rendre la vie facile

Modéliser les données rend la vie facile. Mais pour la rendre facile, il faut se la compliquer un peu au début. En effet, dans les premiers temps d’un projet et / ou lorsqu’on découvre un nouveau domaine fonctionnel, modéliser sa compréhension prend du temps, cela demande d’importants efforts de réflexion, de faire et refaire son modèle, de mettre à jour régulièrement la description littéraire que l’on fait en parallèle du schéma, etc.

Les bénéfices de la modélisation des données

Alors pourquoi certains sont-ils prêts à faire cet effort ? Parce qu’ils sont persuadés que les bénéfices à le faire sont largement supérieurs aux inconvénients.

• Cela les aidera à comprendre plus rapidement le domaine fonctionnel. Plus rapidement que qui ? Que ceux qui ne modélisent pas les données, ce qui est un élément différenciateur fort dans un domaine hautement concurrentiel.
• Cela les forcera à aller au bout de leur compréhension sans rien omettre, et ce travail (compréhension et rédaction) les aidera à la mémorisation du fonctionnement métier et de ses règles. Notamment, la combinaison schéma plus texte favorise l’ancrage mémoriel. En cas d’oubli d’un détail, ils le retrouveront très rapidement dans le document grâce à une bonne mémorisation de la logique d’ensemble.
• Cela leur permettra de clarifier le vocabulaire métier, d’éliminer les synonymes et les différences d’interprétation d’un même terme tout en fédérant les parties prenantes autour d’un lexique commun, ce qui renforce la cohésion d’équipe.
• Cela permettra à tout nouvel arrivant sur un projet de monter en compétences beaucoup plus rapidement que sans modèle.

Ce dernier point me semble primordial et nous allons donc tâcher de l’illustrer en faisant appel à votre imagination ou à votre expérience : si vous deviez demain rejoindre une mission en cours, pour renforcer un collègue par exemple, qu’est-ce qui, selon vous, serait le plus utile pour vous approprier le sujet au mieux en amont de votre arrivée ?

• Lire l’intégralité des documents produits mais qui ne contiennent aucun schéma.
• Prendre connaissance uniquement du diagramme de classe et de sa description littéraire.

Modèle de données = clarté

Pour reprendre l’exemple précédent, préférez-vous lire uniquement du texte tel que celui-là :

« Les articles doivent être classés dans des gammes et être proposés à la vente en fonction des types de client : professionnel, particulier et administration. »

Ou bien cela :

Bien entendu accompagné de la description littéraire qui vous apportera toutes les définitions nécessaires à la compréhension, des exemples d’articles, de gammes, de gammes associées à un seul type de client, à plusieurs, etc.

Si l’on opte pour le second choix, il va falloir faire à l’avenir preuve d’empathie : vais-je laisser mes successeurs ou la personne qui viendrait me renforcer déployer au moins autant d’effort que j’en ai mis pour m’approprier le sujet ou vais-je lui simplifier la tâche en lui fournissant des schémas facilitateurs ? Dit autrement, suis-je dans une optique de construction et de pérennisation de la connaissance ou « après moi, le déluge » ?

Modéliser les données pour marquer les esprits

Ce que l’on constate, tant en formation que sur le terrain, c’est que les personnes qui utilisent la modélisation posent globalement des questions plus pertinentes et ont un questionnement plus structuré que ceux qui ne modélisent pas.

Pour ce qui est de la structure, c’est assez logique : le schéma donne le cheminement du questionnement pour se construire pas à pas, brique après brique, selon le principe d’une approche incrémentale : chercher à étendre sa compréhension selon que l’on travaille sur le périmètre du sujet (l’horizontalité) ou que l’on creuse (détaille) un seul élément du périmètre (la verticalité.)

Augmenter le nombre de questions pertinentes

En revanche, pour ce qui est de la pertinence, nous allons tenter d’illustrer cela par un exemple. Ainsi, prenons l’énoncé suivant :

« Nous nous approvisionnons en articles auprès de fournisseurs et nous les stockons ensuite dans différents sites où les services consommateurs s’assurent de leur distribution. »

L’usage de la modélisation face à une problématique de ce genre va permettre de maximiser le taux de questions utiles, c’est-à-dire d’avoir une réelle compréhension du sujet. Grâce au diagramme de classe, voilà les questions que nous ne poserions pas (du moins dans un premier temps) :

• De combien de sites disposez-vous ?
• Vos fournisseurs sont-ils en France ou également à l’international ?
• Les services consommateurs font-ils autre chose que distribuer les articles ?
• Qui se charge du référencement des articles ?
• Etc.

Les réponses obtenues ne permettront pas de comprendre la logique des choses. En revanche, l’usage d’un diagramme amènerait les interrogations suivantes :

• Un article est-il acheté auprès d’un seul fournisseur ou potentiellement auprès de plusieurs pour faire jouer la concurrence ?
• Les fournisseurs sont-ils des spécialistes d’un seul article ou des généralistes ?
• Un service consommateur est-il affilié à un seul site où travaille-t-il avec plusieurs ?
• Etc.

Dans ce cas, le fonctionnement de l’organisme nous apparaîtra beaucoup plus clairement, bien plus que si l’on sait qu’il dispose de dix sites et que les fournisseurs sont européens.

Vis-à-vis de notre interlocuteur, ces questions structurelles marquent fortement les esprits car elles mettent immédiatement le doigt sur les fondements même de l’organisme et poussent à clarifier le propos. C’est aussi une très bonne façon de donner une image positive de soi car l’interlocuteur sentira notre engagement et notre volonté de réellement comprendre son activité.

Modéliser les données pour ne jamais être à court de questions

L’usage de la modélisation réduit très fortement les chances de se retrouver à sec de questions et de laisser un long blanc s’installer.

En effet, quelle que soit la complexité du sujet, vous arriverez toujours à identifier aux moins deux concepts métier qui sont fortement liés entre eux. Agrippez-vous y car ils sont votre planche de salut !

Cas pratique

Pour illustrer cela, prenons l’exemple suivant :

« Les ouvrants-droits et leurs ayants-droits peuvent bénéficier de séjours-vacances. »

Rien qu’avec le diagramme de classe et le besoin de le décrire, nous allons compter ensemble le nombre de questions que l’on pourrait poser pour clarifier la relation entre l’ouvrant-droit et l’ayant-droit.

1. « Dans un premier temps, je ne comprends pas bien la différence entre un ouvrant-droit et un ayant-droit, pourriez-vous m’expliquer davantage cela ? »
2. « Un ouvrant-droit peut donc déclarer plusieurs ayants-droits, c’est bien cela ? »
3. « Un ayant-droit peut-il être désigné par plusieurs ouvrants-droits ou uniquement par un seul ? »
4. « Un ouvrant-droit doit-il obligatoirement déclarer au moins un ayant-droit ou est-ce que cela n’est pas nécessaire ? »
5. « J’imagine qu’un ayant-droit n’a pas de raison d’être s’il ne dépend pas d’un ouvrant-droit ? »
6. « Pourriez-vous me donner un exemple d’un même ayant-droit désigné par plusieurs ouvrants-droits ? Dans quel cas est-ce que cela arrive ? »
7. « Pourriez-vous me donner un exemple d’un ayant-droit qui ne dépendrait d’aucun ouvrant-droit ? Dans quel cas est-ce que cela arrive ? »

Et l’on pourrait encore continuer à creuser en s’intéressant aux informations renseignées dans le système lorsqu’on crée un ouvrant-droit et un ayant-droit. Ce qui fait qu’avec les sept questions ci-dessus, plus les reformulations des réponses, plus le creusage éventuel des attributs, on peut arriver très facilement à une douzaine de prises de paroles, et l’on ne s’est pas encore intéressé aux « séjours-vacances ». Difficile de se retrouver en panne de questions utiles…

Modélisation des données et professionnalisme

Pour percer, l’ouvrier utiliser une perceuse, avec une mèche adaptée au support. Il n’utilise pas un tournevis pour faire un trou grossier. De même, pour ouvrir une bouteille de vin, le sommelier ne tape pas sur le « cul » de la bouteille avec une chaussure jusqu’à ce que le bouchon saute : il a les bons outils et réalise les bons gestes. L’architecte transforme les besoins du maître d’ouvrage dans des plans qui respectent les conventions graphiques du métier, il ne fait pas « à sa sauce. » Le dessin industriel a également son langage graphique et toutes ces personnes ont au moins une chose en commun : elles ne décident pas de se passer des techniques propres à leur métier pour aller plus vite ou parce qu’elles sont trop compliquées. C’est leur travail, elles sont formées à utiliser ces pratiques et les utilisent à bon escient.

Maîtriser les outils de son métier

Le métier de BA a lui aussi ses outils graphiques qui permettent de construire des maisons (des SI) structurées qui répondent exactement à des besoins. Pas de fenêtres qui s’ouvrent sur un mur, pas d’escaliers qui ne mènent nulle part, pas de salles de bain sans canalisation d’eau, pas d’oubli d’une pièce, pas d’oubli des VLC, etc.

Le professionnalisme chez un BA pourrait donc se mesurer à l’aune de sa maîtrise des outils qui sont à sa disposition et à sa capacité à savoir lesquels lui seraient les plus utiles sur le moment.

Par « maîtrise », nous entendons notamment d’utiliser les standards du marché, des modèles de schéma, et non pas des schémas « personnels » où les clés de lectures ne sont pas claires (pour le rédacteur comme pour le lecteur) et ne servent pas de guide à une approche structurée.

Mieux penser la structure des sites web

Pour sortir de l’analogie avec le bâtiment et se recentrer sur l’informatique :

• Qu’ont en commun les meilleur(e)s sites/applications ?
• Qu’ont en commun les mauvais sites, peu intuitifs, où il faut saisir plusieurs fois les mêmes données, où l’on ne sait pas où chercher l’information, etc. ?

Généralement, tout se joue dans la conception, et donc la modélisation, c’est-à-dire l’architecture du site.

Vous vous dites peut-être que, dans le cas de droite, l’ergonome était en vacances et que cela ne présuppose en rien de la qualité de la base de données. Certes, mais il sera extrêmement compliqué d’avoir en front office un site ordonné, performant et assurant une excellente expérience utilisateur si la base de données qui le fait fonctionner ne l’est pas, ordonnée.

La modélisation des données dans un contexte Agile

La modélisation des données dans Scrum

Même s’il est vrai que le Scrum Guide[1] ne fait à aucun moment référence à la modélisation, il ne faudrait pas hâtivement en déduire qu’il y a une incompatibilité entre l’agilité et UML, par exemple. En effet, l’ingénieur Scott Ambler[2] est l’un des promoteurs de la « modélisation agile[3] », soit une adaptation des valeurs et principes de XP à la modélisation.

La modélisation des données collaborative

Ambler n’est pas le seul à promouvoir la modélisation au sein des méthodes agiles. Ainsi, Craig Larman[4], expert des méthodes agiles et de Scrum en particulier, propose une utilisation collaborative d’UML selon cinq grands principes[5]:

1. « Ne modélisez pas seul » : la modélisation est collaborative et participative.

2. « Des outils simples qui encouragent la créativité » : C. Larman encourage l’utilisation de feutres et de paperboards.

3. « Des modèles multiples et en parallèle » : par exemple, diagramme de classe et de séquence.

4. « Les modèles ne sont pas de la documentation » : la modélisation sert à développer une compréhension commune.

5. « Tout modèle est faux ! Et c’est OK » : le modèle est provisoire, seul le code fait foi à la fin du projet.

En synthèse

Nous n’allons pas détailler plus que cela le rapport entre agilité et modélisation mais il apparaît donc qu’un courant de spécialistes préconise l’usage des schémas dans un « esprit agile » et ceci afin de favoriser :

• la collaboration : l’équipe est responsable du modèle et des choix faits,
• le pratique, le rapide (pas de logiciel lourd d’utilisation),
• la complétude, l’exhaustivité, du fait de l’usage de plusieurs schémas en adéquation avec le sujet traité et permettant d’étudier un même sujet sous différents angles,
• le partage de la connaissance.

Tout cela sans avoir à se soucier que le modèle soit juste !

Les risques à ne pas modéliser les données

On peut faire le choix, volontairement, dans un cycle en V comme en Agile, de ne pas représenter graphiquement les choses. Il faut alors en accepter les risques en toute connaissance de cause. L’idée n’est pas de les détailler longuement ici, beaucoup ont déjà été vus dans les chapitres précédents, mais plutôt de les synthétiser.

Risques organisationnels

Concernant le projet et/ou l’organisme dans son ensemble, sans modéliser les données :

• il est très difficile d’assurer la complétude et la cohérence des besoins collectés, ce qui peut avoir un impact fort et coûteux en phase de recette par exemple,
• les documents produits sont peu pérennes, ils ne facilitent pas la montée en compétences des futurs collaborateurs,
• l’écart se creuse inexorablement entre le code et la documentation fonctionnelle,
• tous les outils contribuant au succès ne sont pas mis en œuvre.

Risques personnels

Pour nous-même, sans modélisation, nous :

• pourrions plafonner dans notre carrière car, passé un certain seuil de complexité, nous risquons de proposer uniquement des analyses partielles et donc des solutions inadaptées,
• ne permettons pas aux autres collaborateurs de progresser et nous ne leur permettons pas non plus de nous aider à progresser dans notre métier, ce qui ne va pas dans le sens de l’esprit collaboratif de l’agilité notamment,
• ne reflétons pas l’état de l’art.

Que faire si vous n’êtes pas à l’aise avec la modélisation des données ?

Vous trouverez ci-dessous une liste de propositions d’exercices, à faire seul ou en groupe, qui vous aideront à apprendre à modéliser les données ou à vous améliorer dans ce domaine.

• Livre : « L’essentiel sur Merise », de Dominique Dionisi (Broché, 1998).
• S’entraîner à modéliser à partir :
  • de vidéos didactiques de logiciels (Youtube en regorge),
  • de sites web (modéliser une location sur Airbnb, un virement depuis votre application de banque en ligne, une fiche article de la Fnac, etc.),
  • d’énoncés audios,
  • en interviewant un proche sur son travail.
• Ne pas hésiter à soumettre ses schémas à un pair plus compétent et à demander des feedbacks.

En espérant que cet article vous sera utile…

[1] https://www.scrum.org/resources/scrum-guide?gclid=EAIaIQobChMI-7q8qabg6AIVhIjVCh37owwgEAAYASAAEgJN3PD_BwE

[2] https://fr.wikipedia.org/wiki/Scott_Ambler

[3] Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, Scott Ambler, Wiley, 2002

[4] https://www.craiglarman.com/wiki/index.php?title=Main_Page

[5] https://valtech.developpez.com/articles/modelisation/uml/agile/

[1] https://www.supinfo.com/articles/single/2594-bases-uml

[2] https://manurenaux.wp.imt.fr/2013/09/27/interet-de-luml-dans-un-projet-informatique/