Modéliser les données métier avant de coder

Modéliser, c'est décrire le métier avant de décrire l'outil. On cherche les objets qui comptent pour vous. Un client, un chantier, une intervention, un échantillon, un contrat. Pour chacun on se demande ce qui le définit, ce qu'il contient et avec quoi il est relié.

On regarde ensuite les règles. Un devis peut-il être modifié après signature ? Une intervention peut-elle exister sans site ? Qui a le droit de valider ? Ces questions paraissent simples. Ce sont elles qui remplissent le code plus tard, et mal posées elles le remplissent d'exceptions.

Les développeurs parlent de modèle conceptuel de données ou de modèle du domaine. Le nom impressionne mais l'idée est simple. C'est une carte de votre métier que vous devez pouvoir lire et corriger sans être technicien.

Le premier travail porte sur les mots. Dans une même entreprise le mot client n'a pas toujours le même sens. Pour le commercial c'est une personne à rappeler. Pour la comptabilité c'est une société qui reçoit des factures. Pour le service technique c'est un site où l'on intervient.

Si le logiciel mélange ces sens, chaque équipe finit par le contourner. On fixe donc une définition pour chaque mot important et on l'écrit. Eric Evans appelle cela un langage omniprésent dans son livre Domain-Driven Design. Les mêmes mots servent ensuite en réunion, dans le cahier des charges, à l'écran et dans le code.

Quand deux sens ne se réconcilient pas, on ne force pas. On sépare les deux notions. Un contact commercial et un compte client deviennent deux objets distincts reliés entre eux. Martin Fowler décrit ce découpage sous le nom de contexte délimité. Le logiciel devient plus clair et chaque équipe y retrouve son métier.

Ces exemples reviennent dans beaucoup de projets. Ils montrent qu'une demande d'écran cache souvent une question de modèle.

Sans modèle on part des écrans. On dessine un formulaire, puis un tableau, puis un autre formulaire. Chaque écran crée ses propres données. Quelques mois plus tard la même information existe à trois endroits et personne ne sait laquelle est juste.

Les règles se cachent dans le code. Une condition ajoutée pour un cas particulier, puis une deuxième, puis une dizaine. Le logiciel fonctionne encore mais chaque évolution devient risquée parce que personne n'a plus la vue d'ensemble.

Et un jour il faut changer la structure. Séparer deux notions qu'on avait confondues, ajouter un niveau dans une hiérarchie, reprendre des années d'historique. C'est une migration de données. Sur un logiciel en production avec de vraies données, c'est souvent la partie la plus coûteuse d'un projet. C'est aussi ce qui rend certaines reprises de code si délicates.

Chez nous la modélisation n'est pas une étape à part. Elle se fait pendant le cadrage, qui est offert. Le déroulé complet est décrit dans notre méthode en 3 rendez-vous.

Au premier rendez-vous, environ une heure, on écoute. Vous racontez votre métier avec vos mots. On note les objets qui reviennent, les étapes, les exceptions et les mots qui ont plusieurs sens. Vous n'avez rien à préparer.

Entre les deux rendez-vous on découpe votre idée en un tableau de fonctionnalités. Chaque ligne s'appuie sur le modèle. Créer une intervention, la planifier, la clôturer, la facturer. On voit tout de suite si un objet manque ou si une règle n'est pas claire.

Au deuxième rendez-vous, environ deux heures, on vous présente le cahier des charges. On le relit ligne par ligne avec vous. C'est là que vous corrigez le modèle, souvent sans vous en rendre compte. Vous nous dites que ça ne se passe pas comme ça chez vous, qu'un autre cas arrive aussi ou qu'un mot veut dire autre chose. Chaque remarque change une ligne du tableau et parfois un objet du modèle.

On prend ensuite une demi-journée pour chiffrer et planifier. Au troisième rendez-vous, une trentaine de minutes, on vous présente le prix au forfait, le planning et les jalons.

On ne peut pas s'engager sur un prix fixe pour un logiciel qu'on ne comprend pas. Le modèle est ce qui nous permet de le faire. Quand chaque objet, chaque état et chaque règle sont écrits, on sait ce qu'il faut construire et on peut l'estimer sérieusement.

Il protège aussi le projet pendant la réalisation. Si votre besoin évolue, on regarde ce que l'évolution change dans le modèle. Un nouveau champ sur un objet existant reste simple. Un nouvel objet relié à plusieurs autres demande plus de travail. On chiffre l'évolution avant de la lancer et vous décidez en connaissance de cause.

Le planning devient plus lisible lui aussi. Pour un logiciel sur mesure on compte en général 2 à 3 mois pour une première version et 4 à 8 mois pour un projet complet. Un modèle posé dès le départ aide le projet à rester dans ces fourchettes.

Modéliser ne veut pas dire tout figer. Un bon modèle sépare ce qui est stable de ce qui change souvent. Les grands objets du métier bougent peu. Les règles, les statuts et les droits évoluent beaucoup plus vite. On les range de façon à pouvoir les modifier sans casser le reste.

C'est ce qui nous a guidés sur Diaglibs, un logiciel d'échantillonnage pour le bâtiment. Missions, campagnes de prélèvements, échantillons et traçabilité des mesures y sont des objets distincts et reliés. Le logiciel continue d'évoluer avec les retours du terrain.

Sur FUUZ, la plateforme de formation construite pour Mosh, ce sont les organisations, les équipes, les rôles et les parcours qui structurent tout. Le même modèle sert à plusieurs organisations qui ont chacune leur espace.

Certains métiers sont surtout faits de liens. Des droits qui passent par plusieurs niveaux, des équipements qui dépendent les uns des autres, des processus qui contiennent des sous-processus. Dans ces cas une base de données graphe représente le modèle plus fidèlement qu'un ensemble de tables.

On explique ce choix et ses limites dans notre article sur Neo4j. Le principe reste le même. Le modèle passe d'abord et la technologie vient ensuite le servir.

Vous n'avez rien à préparer pour le premier rendez-vous. Mais si vous voulez commencer à y penser, trois questions suffisent. Les réponses n'ont pas besoin d'être justes. Elles nous donnent un point de départ et on construit le modèle avec vous à partir de là.