Sur le terrain, un technicien termine une intervention sans numéro d’équipement parce que la plaque est illisible. Un client change de site pendant un contrat. Une livraison part en deux fois. Le modèle initial exigeait pourtant un équipement, une adresse et une date uniques. Pour finir le travail, les utilisateurs saisissent « inconnu », remplacent l’adresse ou ajoutent l’explication dans un commentaire.
Ces contournements ne sont pas des détails d’interface. Ils effacent la différence entre une valeur absente, une information inconnue et une règle exceptionnellement dérogée. Le reporting compte de faux équipements, le support ne retrouve pas la décision et la migration future ne sait plus interpréter les données. La souffrance apparaît dans les corrections manuelles avant de devenir une panne.
Le vrai enjeu n’est pas de prévoir chaque cas futur. Il est de construire des objets capables de dire ce qui s’est passé, dans quel contexte, à quelle date et avec quelle décision. Un bon modèle ferme les invariants certains et donne une place explicite aux exceptions, sans transformer chaque table en liste de champs optionnels.
Dans une démarche de développement web sur mesure, cette rigueur relie base, domaine, API et run. Le modèle devient une mémoire exploitable plutôt qu’un miroir fragile du premier écran.
Observer les exceptions avant de modéliser
Rejouez cinq dossiers réels : nominal, donnée manquante, changement en cours, annulation et reprise. Suivez la valeur depuis la saisie jusqu’au document, à l’API et au reporting. Notez les décisions humaines, les calculs et les endroits où une information est recopiée ou interprétée.
Une exception répétée révèle souvent un concept absent. Plusieurs adresses dans un champ texte peuvent indiquer une relation temporelle entre contrat et site. Un statut « autre » peut cacher deux transitions différentes. Une note libre sur un matériel temporaire peut annoncer une relation d’affectation avec début et fin.
Distinguer cas rare et cas mal nommé
La fréquence ne décide pas seule. Un cas annuel peut être critique s’il porte une obligation ou une forte valeur. Demandez si l’exception change identité, droit, calcul, preuve ou seulement présentation. Le modèle traite en priorité ce qui modifie le sens des données.
Écrire un contre-exemple
Pour chaque règle, ajoutez un dossier qui ne la respecte pas légitimement. « Une intervention concerne toujours un équipement » est invalidée par un diagnostic de site. Le contre-exemple aide à reformuler l’invariant : toute intervention concerne un périmètre de service, qui peut être un équipement, une zone ou un site.
Fermer identité et contexte
Chaque objet possède un identifiant stable sans signification métier. Les codes externes sont des relations avec une source, un périmètre et une période. Un numéro de contrat peut être unique par société, pas globalement. Une référence fournisseur peut changer sans créer un nouvel équipement.
Le contexte n’est pas une colonne pays ajoutée partout. Il décrit l’entité d’autorité, le site, le canal, la période ou le contrat lorsque ces dimensions changent une règle. Les relations de partage sont explicites. Une donnée groupe et une donnée locale ne doivent pas se distinguer uniquement par la convention d’un identifiant.
Une clé métier candidate est protégée par une contrainte dans son vrai périmètre. L’absence temporaire de cette clé reçoit un statut et une procédure de complétion, plutôt qu’une valeur factice. L’objet interne peut exister avant son immatriculation externe sans prétendre que « 0000 » est une référence.
Séparer faits, décisions et projections
Un fait décrit une observation : température mesurée, document reçu, colis scanné. Une décision accepte, refuse, affecte ou calcule à partir de faits et d’une règle. Une projection prépare une lecture rapide. Mélanger les trois crée des champs dont la correction réécrit le passé.
Conservez la valeur source et la valeur normalisée lorsque la transformation compte. Enregistrez la règle et sa version pour un calcul opposable. La projection peut être reconstruite ; elle ne devient pas l’autorité parce qu’elle est visible dans le back-office.
Contre-intuitivement, stocker davantage de colonnes calculées peut réduire la connaissance. Sans provenance et version, elles vieillissent silencieusement. Il vaut mieux conserver l’entrée, la décision et une projection datée que trois « vérités » mises à jour par des chemins différents.
Modéliser absence et inconnue
NULL ne doit pas signifier à la fois non demandé, inconnu, non applicable et effacé. Lorsque la distinction modifie un workflow, utilisez un état ou une relation : information attendue, dispensée avec motif, impossible à obtenir ou expirée. La date et le responsable rendent la situation actionnable.
Évitez le champ « autre » accompagné d’un commentaire sans structure. Une catégorie ouverte peut conserver une valeur source, mais la décision utilise une classification validée. Les nouveaux motifs sont revus et peuvent enrichir le référentiel. Le texte reste preuve, pas moteur caché.
Les documents semi-structurés ont leur place pour une capture externe ou un attribut réellement variable. La spécification officielle JSON Schema 2020-12 Validation fournit des assertions de structure et de dépendance. Un document versionné et validé est différent d’une colonne JSON utilisée pour éviter toute décision de modèle.
Porter dates d’effet et intervalles
Une valeur métier a souvent une période de validité différente de sa date d’enregistrement. Un tarif signé aujourd’hui prend effet le mois prochain. Une adresse corrigée aujourd’hui était correcte au moment de la facture. Conservez date effective et date système lorsque l’historique ou la reprise l’exigent.
Les relations temporelles utilisent des intervalles avec bornes définies. Pour une affectation, adoptez par exemple début inclus et fin exclue afin d’éviter l’ambiguïté à minuit. La documentation PostgreSQL sur les types d’intervalle et contraintes d’exclusion montre comment empêcher deux plages qui se chevauchent lorsqu’elles doivent rester exclusives.
Un changement futur ne modifie pas le dossier en cours sans règle explicite. Le workflow capture la version applicable à son ouverture ou réévalue avec une migration. Cette décision est visible, surtout pour prix, droits, contrats et obligations.
Cas concret : intervention sans équipement
Une application de maintenance liait obligatoirement chaque intervention à un équipement. Les équipes terrain utilisent pourtant des interventions de diagnostic sur une zone, avant d’identifier la machine. Elles créaient donc un équipement « DIVERS » partagé, qui concentrait photos, historiques et coûts de plusieurs sites.
Le nouveau modèle introduit un périmètre d’intervention : équipement, zone ou site, avec une relation typée. L’intervention porte toujours un périmètre, ce qui préserve l’invariant. Lorsqu’un équipement est identifié, une transition associe la suite du dossier sans réécrire les observations initiales.
Les pièces consommées restent rattachées à l’intervention et au site. La décision d’imputer un coût à l’équipement intervient après identification, avec auteur et motif. Le reporting distingue diagnostics non attribués, interventions équipement et régularisations. Il ne répartit plus arbitrairement le coût de « DIVERS ».
Migrer les anciennes données sans inventer
L’équipe migre les lignes « DIVERS » vers le site connu et marque l’équipement comme non déterminé. Les dossiers possédant une photo ou une référence fiable sont proposés à la qualification. Une balance compare interventions, heures, pièces et montants avant et après. Aucun historique n’est effacé.
Le pilote couvre deux sites et quatre-vingts interventions. Le go exige zéro perte de pièce, moins de 5 % de diagnostics encore sans site et moins de dix minutes pour expliquer une imputation. Ces seuils sont locaux ; ils déclenchent correction ou réduction du périmètre.
Encadrer corrections et dérogations
Une correction change une donnée erronée et conserve avant, après, auteur, cause et date effective. Une dérogation autorise temporairement une décision différente sans prétendre que la donnée source était fausse. Les deux ne partagent pas le même workflow ni la même durée.
L’override est associé à un champ ou une décision, une source, un motif, une expiration et une priorité. La synchronisation n’écrase pas cet override ; elle signale la divergence. À l’expiration, la source redevient visible ou une revue est exigée. Un override sans fin crée un nouveau maître caché.
Les droits sont fins. Le support peut corriger une référence avec preuve, pas modifier un montant contractuel. Une élévation temporaire est auditée. La base et le domaine empêchent les transitions impossibles même si l’interface est contournée.
Faire évoluer le schéma sans rupture
Utilisez une séquence compatible : ajouter le nouveau modèle, backfiller, comparer, écrire, basculer les lectures, rendre obligatoire puis retirer l’ancien. Les anciens workers doivent fonctionner pendant la fenêtre. Une colonne n’est supprimée qu’après disparition observée de ses lecteurs.
La double écriture est temporaire et contrôlée par une balance. Une seule représentation reste autoritative. Les divergences vont dans une file, elles ne sont pas corrigées au hasard par « la dernière gagne ». Un lot idempotent peut reprendre après interruption.
Versionnez les contrats API et événements selon leur sémantique. Ajouter un champ optionnel est compatible seulement si son absence a un sens sûr. Changer « montant hors taxe » en « montant net » exige une nouvelle propriété ou une version, pas une note dans la documentation.
Instrumenter cohérence et reprise
La mise en œuvre décrit entrées, sorties, responsabilités, dépendances, seuils et journalisation. L’instrumentation relie donnée source, transformation, règle, version et décision. Le monitoring suit valeurs inconnues, overrides expirés, contraintes rejetées, divergences de double écriture et files de migration.
Le rollback suspend les nouvelles écritures sur le chemin cible, laisse les lots atteindre un point cohérent et réactive la lecture précédente. La sortie exige une balance et une qualification des nouvelles données. Le repli ne remplit pas les champs manquants avec un défaut fictif.
Les tests couvrent invariants, propriétés, concurrence, migrations et droits. Générez des cas limites : période vide, chevauchement, absence légitime, version future et reprise. Le support retrouve la provenance depuis l’identifiant métier sans requête manuelle dans la base.
Pour qui ce modèle devient nécessaire
Le sujet concerne les équipes produit, métier, data et technique qui maintiennent une application opérationnelle avec historique, workflows ou intégrations. Il devient prioritaire lors d’une croissance multi-entités, d’une migration, d’une refonte ou lorsque les commentaires libres pilotent des décisions.
Un formulaire ponctuel sans réutilisation peut accepter un document simple. Un modèle riche serait disproportionné. Dès que données, droits, argent ou preuve traversent plusieurs écrans et systèmes, les concepts et périodes doivent être explicites.
Le métier définit les invariants et contre-exemples. La technique choisit représentation et contraintes. La data valide les usages analytiques. Le run possède correction et reprise. Un modèle validé seulement par le diagramme reste incomplet.
Erreurs fréquentes de modélisation
Ajouter des booléens pour chaque cas
is_special, is_manual et legacy_case décrivent l’histoire du code. Modélisez la raison, la période et la décision. Un booléen temporaire reçoit une date de retrait et une métrique d’usage.
Transformer le JSON en tiroir
Un document sans schéma, version ni propriétaire empêche contraintes et recherches fiables. Utilisez-le pour une structure réellement variable, validez-le et extrayez les attributs qui deviennent métier.
Réécrire le passé
Mettre à jour l’adresse ou la règle sur tous les dossiers détruit la preuve. Séparez correction de référentiel et valeur appliquée au document. Une migration historique reste une décision tracée.
Décider colonne, relation ou document
Bloc de décision. Choisissez une colonne pour un attribut stable et interrogé. Choisissez une relation lorsque l’objet a identité, cardinalité, droits ou cycle de vie. Choisissez un document versionné pour une capture variable dont le schéma reste explicite. Choisissez un événement lorsque la chronologie et la cause sont essentielles.
Si l’exception modifie un invariant, alors refondez le concept plutôt que d’ajouter un drapeau. En revanche, une valeur locale bornée peut rester paramétrée. Préférez une absence qualifiée à une valeur factice. À éviter : une nouvelle table sans propriétaire uniquement pour contourner le schéma courant.
- Prioriser les concepts qui affectent droits, argent, preuve ou intégration.
- Différer la contrainte obligatoire tant que le backfill contient des inconnus.
- Refuser les valeurs génériques qui mélangent plusieurs objets.
- Accepter une extension seulement avec version, validation et stratégie de retrait.
Plan d’action sur cinq semaines
Semaines un et deux : caractériser le réel
Choisissez vingt dossiers, dont cinq exceptions. Suivez les données de la saisie au reporting et notez faits, décisions, projections et corrections. Écrivez invariants, contre-exemples, identités et périodes. Mesurez la fréquence et le coût des contournements.
Proposez le modèle le plus étroit et vérifiez-le avec métier, run et data. Fermez les absences, transitions, droits et erreurs. Écrivez des tests de caractérisation et une balance avant la migration. Les cas inconnus reçoivent une file de qualification.
Semaines trois à cinq : comparer et basculer
Ajoutez le nouveau schéma de manière compatible et backfillez par lots idempotents. Comparez les lectures anciennes et nouvelles. Provoquez chevauchement, valeur absente, override expiré et message hors ordre. Le support exécute correction et diagnostic.
Activez une écriture et un périmètre. Le rollback suspend ce chemin sans effacer les données nouvelles. Après deux cycles, contrôlez balance, inconnus, overrides et temps de reprise. Rendez les contraintes obligatoires seulement lorsque les anomalies sont traitées.
Le verdict documente aussi les lecteurs de l’ancien modèle, les versions d’API et les traitements planifiés. Chacun possède une date de migration. Une suppression est autorisée après une période d’observation sans appel et une restauration testée, pas simplement parce que le nouvel écran fonctionne.
La recette finale reprend cinq dossiers fermés et cinq dossiers encore actifs. Elle reconstruit pour chacun la valeur valable à une date donnée, la décision qui l’a produite et la projection présentée à l’utilisateur. Toute divergence reçoit une catégorie : défaut de schéma, règle métier incomplète, ordre d’événements, donnée source ou migration. Ce classement empêche de corriger indistinctement le modèle pour une erreur de flux. Le propriétaire accepte les inconnus résiduels, fixe leur délai de qualification et vérifie que la file ne grossit pas après l’ouverture.
- Observer les exceptions et écrire les invariants.
- Fermer identité, temps, absence et autorité.
- Backfiller, comparer et perturber le nouveau chemin.
- Basculer progressivement puis retirer l’implicite.
Approfondir doublons et historique
Un modèle vivant a aussi besoin d’un budget d’évolution. Pour chaque concept sensible, conservez les versions encore lues, le nombre de dossiers concernés, les consommateurs et le coût d’un retrait. Cette cartographie évite de maintenir éternellement une structure au nom d’un cas historique déjà clos. Elle empêche également de supprimer une forme ancienne qu’un export réglementaire doit encore interpréter. La compatibilité devient ainsi une décision datée, liée à un usage observable, plutôt qu’une promesse générale qui fige le schéma.
Retrouver une identité unique
Le guide traiter les données métier dupliquées complète les contraintes par les règles de fusion et les aliases.
Conserver les changements utiles
Pour choisir entre audit, version et événement, poursuivez avec l’historisation des changements de données. Ces lectures doivent être rejouées sur un dossier terrain.
Les équipes data peuvent ensuite bâtir leurs vues analytiques sans imposer leurs agrégats au modèle transactionnel. Le contrat publié précise unités, fuseau, granularité et règles de correction. Un indicateur reconstruit reste séparé du fait brut et de la décision opérationnelle. Cette distinction permet de recalculer un historique après correction sans réécrire ce qui a été effectivement décidé à l’époque. Elle donne aussi au support un chemin court : retrouver le dossier, sa période, la provenance et la version de règle, sans parcourir un entrepôt conçu pour le reporting.
Avant d’ajouter une extension, recherchez enfin le même besoin dans les incidents et demandes d’assistance des six derniers mois. Si plusieurs équipes ont inventé des valeurs différentes, le concept manque probablement au socle. Si un seul partenaire exige une donnée de présentation, un adaptateur en bordure suffit peut-être. Reliez le choix à une preuve : requêtes qui doivent rester possibles, règles qui doivent être garanties et scénarios de reprise. Cette discipline évite de confondre flexibilité du stockage et capacité du produit à expliquer ses décisions.
- Relier la structure aux décisions qu’elle protège.
- Conserver provenance et période sur les valeurs opposables.
- Tester migration et reprise avec des exceptions réelles.
Conclusion : rendre l’exception explicite
Un modèle robuste ne prédit pas tout. Il distingue les faits, les décisions et les projections, puis donne aux absences, périodes et dérogations un sens vérifiable. Les exceptions cessent alors de vivre dans des commentaires ou des valeurs factices.
La qualité se prouve pendant l’évolution : un lot peut reprendre, une contrainte explique son refus, une ancienne version reste interprétable et le support retrouve la provenance. Le schéma sert le run autant que l’écran.
Commencez par le concept que les utilisateurs contournent le plus. Écrivez son contre-exemple, fermez son identité et migrez une tranche. Cette discipline vaut davantage qu’un grand modèle abstrait jamais éprouvé sur le terrain.
- Un invariant nommé.
- Une exception qualifiée.
- Une migration réversible.
Dawap peut accompagner cette reprise de développement web sur mesure : audit du modèle, ateliers métier, schéma cible, migration incrémentale, tests et préparation du run.
