Modéliser ses données avant d'écrire la première ligne
Un modèle de données bancal se paie pendant des années. C'est la seule partie d'un projet qu'on ne refactorise jamais vraiment : elle mérite les deux jours qu'on ne lui accorde pas.
Sommaire
Dans un projet informatique, presque tout se corrige. On réécrit du code, on redessine une interface, on remplace une bibliothèque, on change d’hébergeur. Ce sont des opérations désagréables, chiffrables, et sans mystère.
Une seule chose ne se corrige jamais vraiment : le modèle de données. Non pas parce qu’elle serait techniquement plus difficile, mais parce que le jour où l’on veut la changer, elle contient des données réelles, en production, que des clients consultent.
C’est pour cette raison qu’elle mérite les deux jours qu’on ne lui accorde presque jamais.
Pourquoi on saute cette étape
Parce qu’elle ne ressemble pas à du travail.
Un client qui finance un projet veut voir des écrans. Une équipe qui démarre veut produire quelque chose de visible. Une réunion consacrée à décider si une commande peut avoir plusieurs adresses de livraison paraît, au mieux, une préoccupation d’informaticien.
Le résultat est toujours le même : on part des maquettes, et les tables épousent les écrans. On obtient une structure qui reflète fidèlement l’interface de la version 1 — et qui ne connaît aucun des concepts du métier. Six mois plus tard, quand l’interface change, plus rien ne tient.
La méthode, en cinq questions
Elle n’exige aucun outil particulier. Elle exige les bonnes personnes dans la même pièce : quelqu’un du métier, quelqu’un du produit, quelqu’un de la technique.
1. Comment le métier appelle-t-il les choses ?
Commencez par le vocabulaire, littéralement. Notez les mots que le client emploie sans y penser : dossier, mandat, intervention, tournée, lot, bon d’apport.
Deux découvertes surviennent presque toujours à ce stade. Deux personnes appellent différemment la même chose — il faut trancher, et le faire une fois pour toutes. Ou bien deux personnes appellent pareillement deux choses différentes — et c’est plus grave : vous venez de trouver un concept qui manquait, et qu’aucun écran ne montrait.
2. Qu’est-ce qui identifie une entité, de façon stable ?
La question paraît triviale ; elle est piégeuse, parce qu’on répond spontanément par une donnée métier.
L’adresse électronique identifie un utilisateur — jusqu’au jour où il en change. Le numéro d’identification identifie une entreprise — jusqu’à un changement d’établissement. La référence identifie un produit — jusqu’à la refonte du catalogue.
Une donnée métier ne doit jamais servir d’identifiant technique. Elle doit être unique si le métier l’exige, mais l’identité de l’objet doit reposer sur une clé qui n’a aucune signification et ne changera donc jamais.
3. Est-ce que ça peut devenir plusieurs ?
C’est la question qui rapporte le plus, et elle se pose pour chaque relation.
Un client a une adresse. Jusqu’au jour où il en a deux — facturation et livraison. Un dossier a un responsable. Jusqu’au jour où il en a deux, pendant un congé. Une facture porte sur une commande. Jusqu’au jour où l’on regroupe.
Passer d’un lien simple à un lien multiple après la mise en production est l’une des migrations les plus coûteuses qui soient : elle touche la structure, le code, les écrans, les exports et l’historique. Posez la question pour chaque relation, et notez la réponse du métier. Parfois, la bonne décision est de rester simple — mais en connaissance de cause.
4. Qu’est-ce qui doit être figé dans le temps ?
L’erreur la plus répandue et la plus dommageable, celle qui ne se voit qu’à la première réclamation client.
Le prix d’une commande n’est pas le prix du produit aujourd’hui : c’est le prix au moment de la commande. Il en va de même du taux de taxe appliqué, de l’adresse de facturation, du nom du client, des conditions acceptées. Si la ligne de commande pointe simplement vers la fiche produit, une modification de tarif réécrit rétroactivement l’histoire de toutes les commandes passées.
La règle est simple : tout ce qui a une valeur juridique ou comptable au moment de l’événement doit être recopié, pas référencé.
5. Que se passe-t-il quand on supprime ?
Il y a rarement une seule bonne réponse, mais il faut en choisir une.
Supprimer un client supprime-t-il ses commandes ? Certainement pas : la comptabilité les exige. Faut-il alors les anonymiser, et où ? Une donnée personnelle recopiée dans huit tables et trois fichiers d’export rend le droit à l’effacement impraticable, ou du moins impossible à garantir.
C’est ici, et pas dans la politique de confidentialité, que se joue la conformité réelle.
Les cinq erreurs qui coûtent le plus
Le champ fourre-tout. Un statut en texte libre, une colonne de données non structurées où l’on range « ce qu’on ajoutera plus tard ». Deux ans après, elle contient quinze formats différents, aucun n’est documenté, et plus personne n’ose y toucher.
Les valeurs non contraintes. Un statut qui peut valoir n’importe quelle chaîne finira par valoir valide, validé, VALIDE et ok. La contrainte doit être dans la base, pas seulement dans le code : le code changera, la base restera.
L’identifiant métier en clé. Voir plus haut. C’est l’erreur la plus fréquente, et la plus douloureuse à corriger.
Les dates sans fuseau. Une date stockée sans information de fuseau est une bombe à retardement, qui explose au changement d’heure ou au premier utilisateur à l’étranger. Nous y avons consacré un article entier.
Les données personnelles dispersées. Recopiées « pour aller plus vite » dans les tables voisines, elles rendent tout exercice de droit incertain, et tout audit pénible.
Ce que ça coûte de ne pas le faire
Prenons un cas ordinaire : une relation simple qui doit devenir multiple, deux ans après la mise en service.
Il faut créer la nouvelle structure, écrire un script de reprise des données existantes, adapter chaque endroit du code qui lisait l’ancienne relation, corriger les écrans, reprendre les exports et les tableaux de bord qui s’appuyaient dessus, tester la bascule sur une copie, prévoir un retour arrière, et faire la migration sur un créneau où l’application est peu utilisée.
Aucune de ces étapes n’est héroïque. Mises bout à bout, elles représentent plusieurs semaines — pour une décision qui aurait pris dix minutes au départ.
C’est aussi ce qu’on retrouve dans presque tous les audits que nous menons avant une refonte : les douze points à vérifier comportent toujours une ligne sur le modèle, et c’est rarement la plus rassurante.
Ce que ça donne, concrètement
Le livrable d’une bonne séance de modélisation n’est ni un schéma complexe ni un document de quarante pages. C’est :
- une liste d’entités nommées, avec le mot que le métier emploie ;
- un identifiant explicite pour chacune ;
- les relations, avec leur cardinalité, et la mention de celles qui pourraient évoluer ;
- la liste de ce qui est figé au moment de l’événement ;
- la localisation des données personnelles, et la règle de suppression associée.
Cinq pages, lisibles par quelqu’un qui n’est pas informaticien. C’est le seul document du projet qui aura encore de la valeur dans cinq ans, et c’est celui qu’on rédige le moins.
Retrouvez nos articles en priorité dans vos résultats Google en nous ajoutant à vos sources préférées.
Ajouter aux sources préféréesQuestions fréquentes
Qu'est-ce que la modélisation des données ?
C'est le travail qui consiste à décrire les objets manipulés par un métier — leurs attributs, ce qui les identifie, et la façon dont ils se relient — avant d'écrire le code qui les manipulera. Ce n'est pas un exercice technique : c'est une mise au clair du vocabulaire et des règles du métier, dont la base de données n'est que la traduction.
Pourquoi ne peut-on pas corriger le modèle plus tard ?
On le peut, mais le coût n'a rien à voir. Changer une structure avant la mise en production revient à modifier un schéma vide. La changer deux ans plus tard suppose de migrer des données existantes sans en perdre, d'adapter tout le code qui les lit, de reprendre les exports et les statistiques, et de tenir les deux versions en parallèle le temps de la bascule.
Faut-il un schéma formel, ou un simple tableau suffit-il ?
Le formalisme importe peu : ce qui compte est que les entités soient nommées, que leurs identifiants soient explicites et que chaque relation porte sa cardinalité. Un tableau lisible par le métier vaut mieux qu'un diagramme que seule l'équipe technique comprend — car c'est le métier qui détient les réponses.
Combien de temps cela prend-il ?
Sur un projet de taille moyenne, un à deux jours réunissant une personne du métier, une du produit et une de la technique. C'est court, et c'est précisément parce que c'est court que l'étape se saute : elle ne ressemble pas à du travail.
Quel rapport entre modélisation et RGPD ?
Un rapport direct. La minimisation des données se décide au moment du modèle, pas dans la politique de confidentialité. De même, le droit à l'effacement suppose de savoir où se trouve chaque donnée personnelle : si elle est recopiée dans huit tables et trois exports, l'effacer devient une opération manuelle et incertaine.
Faut-il historiser toutes les données ?
Non, mais il faut décider explicitement lesquelles. La règle utile : tout ce qui a une valeur juridique ou comptable au moment où l'événement se produit doit être figé — le prix d'une commande, le taux de TVA appliqué, l'adresse de facturation. Le reste peut évoluer sans mémoire.
