U1 · Modéliser les objets métier et leurs relations · Lecture · 22 min

Comprendre : Modéliser les objets métier et leurs relations

Tes objets existent depuis la fiche 3.3 — Client, Demande, Devis, Chantier. Cette fiche les durcit pour qu'ils survivent au passage dans un vrai outil de base de données au module 2.

Les cardinalités

Pour chaque relation, deux questions : combien au minimum, combien au maximum, dans chaque sens.

• Un client a zéro à plusieurs demandes. Une demande appartient à un seul client.
• Une demande donne zéro à plusieurs devis — zéro si elle n'aboutit pas, plusieurs si le client fait modifier. Un devis appartient à une seule demande.
• Un devis donne zéro ou un chantier. Un chantier vient d'un seul devis.

Le « zéro » est la partie qu'on oublie, et c'est celle qui casse les rapports. Si ton modèle suppose qu'une demande a toujours un devis, ton taux de transformation sera faux — puisque les demandes sans devis, précisément celles qu'on veut compter, n'existeront pas dans le calcul.

Trois questions qui révèlent les erreurs

• Peut-il y en avoir zéro ? Révèle les champs qu'on croyait obligatoires.
• Peut-il y en avoir deux ? Révèle les relations qu'on croyait uniques. Un chantier avec deux poseurs, un devis avec deux versions.
• Que se passe-t-il si on supprime le parent ? Supprimer un client doit-il supprimer ses demandes, les détacher, ou être interdit ? Trois réponses valables ; l'absence de réponse ne l'est pas.

La relation plusieurs-à-plusieurs cache un objet

Quand tu constates qu'un A peut avoir plusieurs B et qu'un B peut avoir plusieurs A, il manque presque toujours un objet entre les deux.

Chez Vermont : un chantier peut concerner plusieurs devis — la cuisine et la verrière commandées ensemble — et un devis peut se répartir sur plusieurs chantiers si la pose est étalée. La relation directe devient ingérable. L'objet manquant est le Lot : une portion de chantier, rattachée à un devis, planifiée sur une période. Il apparaît dès qu'on pose la question, et il n'apparaît jamais si on ne la pose pas.

L'identifiant métier

Chaque objet a besoin d'une référence stable, courte et lisible par un humain : DEV-2026-047, CHA-2026-012.

Ce n'est pas de la coquetterie. Karim au téléphone avec un client doit pouvoir dire « votre devis DEV-2026-047 » ; Sophie doit pouvoir le retrouver en trois secondes ; et l'identifiant technique interne à l'outil ne sert à aucun des deux — il est long, illisible, et il change si l'on migre d'outil un jour.

Ne jamais stocker ce qui se calcule

Le montant total d'un chantier se calcule depuis ses devis. Le nombre de demandes d'un client se compte. Stocker ces valeurs, c'est se garantir qu'un jour elles ne correspondront plus — parce qu'on aura modifié un devis sans repasser sur le total.

C'est le principe des agrégations de la fiche 1.6, énoncé comme règle d'architecture.

Le dictionnaire de données

Un tableau, un objet par section, une ligne par champ : nom, type, obligatoire, valeurs autorisées, qui le remplit, exemple.

Sa vraie fonction n'est pas la documentation : c'est de rendre ton cadrage exécutable par quelqu'un d'autre. Un prestataire qui reçoit ce document construit la base sans te poser de questions. Sans lui, il interprète — et il interprétera mal la colonne « qui le remplit », qui est celle que personne n'écrit jamais.