Comment évaluer la qualité d’un modèle de données ?

Dernière modification le 24 janvier 2023

La chaîne de modèles

Elaborer un modèle de données fait partie des quelques points critiques de la chaîne d’élaboration d’un produit logiciel.

Pour rappel une chaîne d’élaboration logicielle va s’attacher à produire des modèles de plus en plus formels, en partant d’une description informelle souvent en langage naturel de l’univers du problème pour arriver à un code exécutable (formel). Le tout en passant par des modèles intermédiaires bien connus – dans le cas des données : volet données des spécifications, modèle sémantique ou conceptuel de données, modèle logique, modèle physique. Et cela que l’on soit en processus de développement agile ou classique.

L’instant magique

La production du premier modèle est le moment où l’on va passer d’un univers du discours, de textes, de définitions, d’exemples exprimées en langage naturel à une représentation plus formelle s’appuyant sur un langage dédié (UML par exemple). Ce moment peut être appelé un instant magique. Il cristallise le passage de l’informelle au formel. Et il conditionne naturellement toute la suite de la chaîne de déclinaison des modèles, jusqu’aux choix d’implémentation physique des données (sous une représentation relationnelle, clé-valeur, graphe ou encore objet).

Le modèle parfait n’existe pas

Un modèle de données n’est jamais unique, ni la vérité absolue, ni parfait[1]. C’est le meilleur modèle obtenu après une démarche (souvent collective de préférence) pour « expliquer » l’univers du problème (définir une application de santé, bancaire, d’aide à la maîtrise de l’énergie…). Modéliser est un exercice sans fin[2]. Savoir quand s’arrêter est un instant important. Le modèle est constamment raffiné. Il est soumis à l’épreuve :

De la connaissance du problème. Un nouveau cas d’usage, une nouvelle définition d’une partie prenante… le fera évoluer,
De qualités attendues auxquels il doit répondre,
Et de son implémentation et test en condition d’usage.

La suite de cet article s’intéresse à l’épreuve des qualités attendues du premier modèle de données qui sera extrait de l’univers du problème (un modèle conceptuel de données, un modèle sémantique). C’est-à-dire le modèle « au contact » de l’univers du problème. NB : toutefois la majorité des qualités décrites s’appliquent également aux modèles en aval (suivants dans la chaîne de modèles, jusqu’au modèle physique des données).

L’épreuve des qualités

NB : Les qualités décrites ci-après, se recouvrent, sont redondantes, se croisent, se consolident entres elles… et c’est volontaire, un modèle doit être secoué et resecoué.

Dans la suite de cet article, on emploiera indifféremment la notion d’entité, d’objet pour désigner les éléments d’un modèle de données. En sachant que les qualités décrites s’appliquent à l’ensemble des éléments de modélisation des données, avec également : les attributs, les domaines de valeur, les relations…

Les qualités d’un modèle de données

1. Représentativité
2. On parle aussi d’alignement
3. Stabilité
4. Lisibilité
5. Non ambiguïté
6. « Atechnique »
7. Sobriété et simplicité
8. Evolutivité
9. Historicité
10. Modularité
11. Standardisation – respect des conventions
12. Interopérabilité

1. Représentativité : c’est une porte ouverte, un modèle doit être fidèle à l’univers du problème, aux objets d’étude. Même si c’est une évidence, il arrive parfois de se retrouver avec des objets dans un modèle dont le sens est sujet à caution (dans lequel les acteurs métier ne se retrouve pas explicitement … mais font confiance au modélisateur !). Exemple chercher à représenter les intervenants externes-prestataires dans l’objet personnel-salariés d’un modèle RH[3].

Dans la représentativité, on peut inclure le respect de la portée du modèle (périmètre valide d’instances) et sa compatibilité avec des modèles plus larges (exemple de la conformité d’un modèle pour un problème local avec le modèle d’objets métier d’une entreprise ou d’un EDM – Enterprise Data Model. Ou encore l’exemple d’un modèle support à un système de formation à rendre compatible avec le modèle RH plus global).

2. On parle aussi d’alignement (avec l’amont – l’univers du problème et avec l’aval – les modèles d’implémentation). Le modèle doit être le reflet d’écarts maîtrisés (reflet de choix) avec l’univers du problème. Rappel : un modèle est toujours une sélection simplificatrice (une perte) d’une représentation de l’univers du problème. Il n’est jamais complet … sinon ce n’est plus un modèle. L’alignement est aussi valable pour l’aval. Dans le cas des modèles en aval, ceux-ci ne doivent pas avoir d’écart / perte par rapport au premier modèle. Même si ce n’est pas son rôle, ce dernier doit s’assurer qu’il porte bien toutes les attentes des modèles en aval – pour leur efficacité (Exemples : les dimensions attendues d’un modèle décisionnel, la capacité à être questionner par des requêtes relationnelles – SQL).

3. Stabilité : le cœur d’un modèle doit répondre à des définitions stables

Le cœur métier correspond aux entités indépendantes du modèle organisationnel qui va consommer ces entités (des clients, des contrats, des produits, des matériels, des événements…),
Ce cœur stable est structuré à partir des concepts communs entre les finalités portées par le modèle. Si on change la définition d’un objet du modèle alors les fondamentaux (finalités) métier sont impactés. D’autre part son processus de gestion est solide (l’administration des données relève d’une gouvernance identifiée et opérationnelle),
Les données d’organisation sont isolées (les objets de stabilités différentes sont séparés).

4. Lisibilité : c’est une qualité clé – le modèle est de fait par son objectif et son mode de construction un lieu de langage et de partage entre tous les acteurs (les métiers, l’IT, les parties prenantes externes…). C’est un objet frontière[4] pour des acteurs, des finalités, des usages, des univers sémantiques différents. Le vocabulaire doit être explicite (Exemples bateau : nommer un attribut « type_de_logement » plutôt que d’en rester à un attribut seulement nommé « type », préférer « capacité installée » plutôt que simplement parler de « capacité »), la représentation du modèle doit être lisible même pour un acteur non spécialiste de la représentation par modèle (à éviter le célèbre modèle plat de spaghetti, en vrac sans organisation, avec des liens dans tous les sens), une vue de synthèse globale est indispensable pour appréhender l’ensemble du modèle, des exemples instanciés doivent appuyer la lecture du modèle, etc. De fait un modèle est nécessairement documenté.

5. Non ambiguïté : un modèle est le résultat d’un exercice de nommage précis (en évitant des termes généraux, non contextualisé…). Les définitions doivent être le plus formel possible, c’est-à-dire lorsqu’elles seront implémentées dans les modèles suivants, manipulables / exécutables par des traitements (à l’exemple de traitements via des langages d’interrogation de données – ex de la programmation SQL[5]).

6. « Atechnique » : on ne doit retrouver dans ce premier modèle de la chaîne, des concepts et caractéristiques dépendants de choix et d’environnements techniques (comme par exemples : le nom de systèmes, des dates ou identifiants techniques, des indicateurs de mise à jour).

7. Sobriété et simplicité

Même si cela relève des modèles relationnels, l’application des règles liées aux formes normales est un principe vertueux (a minima le respect des 2 premières formes normales est à considérer et avec également le but : d’éliminer les redondances, de limiter les dépendances, d’assurer l’unité de sens des objets, de factoriser au maximum les unités de sens en un seul endroit – exemple simple ne pas répéter N fois la notion de contact (mail, adresse, téléphones…) pour différents objets …)[6],
Un modèle qui dépasse quelques dizaines d’objets n’est pas normal pour la majorité des univers de problème traités (hormis si on modélise le monde … et encore si on pense aux finalités en charge d’un tel périmètre !).

8. Evolutivité : c’est ici l’exercice délicat de la place du curseur entre un modèle spécifique figé au moment où l’univers du problème est traité (strictement dédié aux cas d’usage connus) et un modèle trop générique vis-à-vis de l’univers du problème[7]. Anticiper les évolutions est nécessaire (les usages évolueront), mais n’est pas un exercice facile voire parfois non réaliste. Cependant prévoir des espaces / lieux d’évolution est possible pour accueillir – faciliter des évolutions (ouvrir le champ d’application du modèle)[8]. Quelques pistes d’espaces d’évolution dans un modèle :

Le curseur porte sur la définition d’objets génériques (avec une part d’abstraction commune et une part adaptable par héritage). La généricité fixe la portée du modèle et le cadre d’enchâssement de nouveaux objets : c’est-à-dire sa capacité à dériver de nouveaux types d’objets en bénéficiant d’objets génériques établis. Exemple : un objet générique est défini pour matérialiser l’engagement entre deux parties (entre une autorité et une personne morale par exemple). A un instant T, le modèle est en mesure de gérer la déclinaison suivante d’engagement : un décret, une instruction. Dans le futur, via cet objet générique, il pourra intégrer d’autres formes d’engagement, comme une convention, un type de contrat particulier, tout en bénéficiant des éléments de modélisation (attributs, relations) portés par l’objet générique,
Les objets modélisés doivent être polyvalents en répondant à un champ de d’activités, de pratiques voire de finalités (objectif de base dans le cas du modèle de données d’un référentiel),
Certains éléments de modélisation peuvent être systématisés, réutilisables. Par défaut tout nouvel objet du modèle peut s’appuyer sur ces éléments de modélisation : gestion de commentaires, gestion de contacts, gestion de preuves, catégorisable par des nomenclatures…,
La paramétrisation de règles de gestion fixant une relation, un domaine de valeur permet de gérer dynamiquement le champ des possibles d’un attribut (exemple : en fonction de tel paramétrage, seuls tels couples de codes nomenclatures sont autorisés (exemple simple Pays/Devises pour une transaction financière),
Des relations entre objets peuvent être « sorties » des objets pour faciliter l’ajout de nouveaux types de relation et éliminer des redondances. L’exemple classique est l’objet « rôle », qui permet d’ouvrir le modèle à de nouveaux contextes de relations (rôles) entre entités. Exemple : la relation d’une personne physique vis-à-vis d’un produit financier géré par une banque peut être vue suivant différents rôles : la personne est prospect, client, garant, contrepartie, bénéficiaire… Une même adresse peut être, l’adresse de l’accueil, de livraison, de contact administratif…

9. Historicité : le modèle peut[9] permettre de recueillir les éléments qui forment l’histoire des objets (la vision du passé, en termes de caractéristiques et de relations qui ont changé dans le temps et d’événements).

Le modèle doit être capable de tracer la valorisation des concepts/attributs dans le temps (valeur avant, valeur après),
Le modèle peut intégrer la notion d’événements liés aux cycles de vie des objets et de leurs relations (une description via des diagrammes d’état peut être utilisée ici). Cette intégration, peut passer, par les célèbres attributs « état » associés aux objets. Mieux, on peut introduire un objet générique Evénement, qui pourra être spécialisé suivant l’objet concerné (ce qui est aussi un exemple de qualité d’évolutivité). Exemples : dans un modèle qui permet de décrire les activités d’entreprises soumises à autorisation, connaître les différents événements qui vont toucher l’entreprise et son activité (création, autorisation de l’activité, suspension, cession de l’activité, caducité, fermeture…), avoir la capacité de suivre ces événements (date, contexte…) permet de reconstituer l’histoire de l’entreprise,
La référence à dates de versions d’objets est parfois à considérer (Exemple des objets Produits dans un modèle de données commerciales),
Un modèle peut avoir besoin d’intégrer la gestion de dates d’effet, de validité (Une alerte sur ce dernier point, l’expérience montre que la prise en compte de ces notions est délicate et couteuse. S’en passer est le premier réflexe à avoir … de nombreux projets se sont mis en difficulté en les introduisant).

Attention aux besoins exprimés sur ce sujet. Par exemple les besoins de simulation dans le passé, de rétropolation ou d’extrapolation ne sont pas nécessairement à la charge de ce premier modèle (ils relèvent de modèles en aval par exemple dédiés à des statisticiens).

10. Modularité – un modèle doit être organisé en « paquets » cohérents, dont le découplage et les interdépendances sont bien identifiés et contrôlés (limités).

Ces « paquets » font partie l’architecture du modèle (sa décomposition en « paquets » et les relations entre « paquets »).
Exemples d’axes de structuration / décomposition :
- L’axe structurel – définis les paquets par objets répondant à une famille ontologique – structurel de l’univers modélisé : les individus, les personnes morales, les produits (on ne mélange pas les choux et les carottes !),
- Autres axes possibles (suivant les finalités auxquelles doit répondre le modèle) : l’axe fonctionnel – exemple description d’un catalogue de services, l’axe contractuel – exemple description de contrats, transactions, d’engagements entre parties.

On ne mélange pas dans un paquet des objets de stabilité différente. La dépendance entre paquets doit être minimale et maîtrisée (les relations modélisées doivent être minimales entres objets de différents « paquets »)

A noter qu’une bonne organisation en « paquets » est un facteur d’évolutivité du modèle. L’impact d’une évolution pouvant se limiter au « paquet » concerné.

La modularité est également un facteur de lisibilité.

NB : cette qualité s’inscrit dans la logique de décomposition en domaines des approches de type Domain Driven Design (DDD).

11. Standardisation – respect de conventions : le modèle doit respecter les normes officielles ou de fait de l’univers d’étude. Pour certains univers, il existe des modèles de données préétablis qui font foi.

Sur ce volet de la standardisation et des conventions, les nomenclatures jouent un rôle clé.

La description des nomenclatures est un incontournable dans un modèle de données. Majoritairement il s’agit de s’assurer de la bonne prise en compte des nomenclatures existantes. Il est plus rare que l’exercice de modélisation amène à définir de nouvelles nomenclatures. Nous n’abordons pas ici, ce que doit être la bonne qualité d’une nomenclature (le sujet à lui tout seul mérite un développement complet[10] – en raccourci on peut se référer à des exemples de gestion de nomenclatures, dans le monde de la santé, gérées par l’Insee…). A minima au niveau du modèle de données, à s’assurer :

Qu’il existe un paquet de représentation des nomenclatures (gérées par le futur système, ou récupérées d’un système dédié de gestion des nomenclatures),
Que les attributs du modèle se réfèrent bien en termes de domaines de valeurs aux nomenclatures identifiées (c’est encore une porte ouverte, mais l’exercice de modélisation demande de la rigueur, et l’expérience montre parfois que ce sujet est reporté trop tard au moment des développements).

12. Interopérabilité : un modèle de données isolé est très rare. Il devra nécessairement porter des données qui interviendront dans des échanges avec d’autres systèmes. Pour cela :

Des normes de l’univers du problème peuvent être à respecter (Exemple : norme Health Level 7 (HL7), OMOP Common Data Model[11] dans l’univers médical, voir aussi les nombreuses normes ISO disponibles – cas du marché de l’automobile, des services financiers, du secteur du bâtiment et aussi autour du BIM – Building Information Modelling avec la norme XP P07-150, les IFC…),
Le modèle doit tenir compte des référentiels de données du domaine du problème et être compatible (pour adossement) à ces référentiels. Exemple classique de l’adossement à la base SIRENE de l’Insee pour les modèles gérant des clients, des personnes morales, des entreprises…[12],
Les frontières avec d’autres univers / domaine d’étude doivent être bien identifiées. Ce qui est de la responsabilité du modèle doit être clairement identifié et ne pas déborder sur d’autres domaine de responsabilité tout en étant capable de faciliter les adhérences. Exemple : un modèle de données d’un univers de la relation avec des clients Professionnels (organisation / personnes morales), n’a pas à introduire dans son modèle la description de clients Particuliers (ce n’est pas son domaine de responsabilité), mais une articulation est peut-être nécessaire entre les deux univers au travers d’un lien du type tel client Particulier est aussi membre de telle organisation. Les deux modèles de chaque univers doivent permettre ce lien[13],
Le modèle doit être conforme à des normes d’échange[14]. Des objets dédiés aux échanges avec d’autres domaines peuvent être nécessaires – comme pour le support de transcodifications à la charge du modèle. Ces objets sont à isoler et à ne pas mélanger aux autres objets.

NB : dans cette liste déjà longue, nous avons volontairement laissé de côté les qualités liées au processus de construction d’un modèle comme la traçabilité des choix de modélisation, la qualité de la documentation associée, la qualité de vérification du modèle (les preuves de validation : CR des sessions de validation, démonstrations du support des cas métier, réserves à traiter…).

Conclusion et ouverture :

A la question pourquoi l’exercice de modélisation ne produit pas un modèle unique, parfait ?

La réponse est parce que cet exercice est le résultat du croisement :

De la représentation de l’univers du problème et des points de vue des différentes parties prenantes,
De choix de modélisation : ce qu’on garde, ce qu’on élimine,
Des qualités visées.

Tout l’art (magique de l’extérieur !) consiste donc à produire un meilleur modèle en se confrontant à cet exercice et mobilisant le juste effort[15].

Dans cet article on a parlé modèle de données, on aurait pu aussi parler de modèle sémantique (le modèle de données est un des produits du modèle sémantique). Sur ce sujet on ne peut que conseiller de se rapprocher de la méthode Praxeme d’architecture d’entreprise et de son guide de l’aspect sémantique. Où outre les qualités de modélisation (partie 3.5 Qualité de la modélisation sémantique), on y trouve comment mener à bien une démarche de modélisation avec de nombreux exemples, et le tout en cohérence avec une démarche d’architecture d’entreprise.

Enfin pour terminer et cela restera une ouverture, élaborer un modèle c’est nécessairement se confronter à des biais de modélisation. Vaste sujet à développer dans un prochain article.

Si cet article vous a intéressé, vous pouvez me contacter pour approfondir son contenu.

[1] Un modèle étant une simplification choisie de la réalité, porté par une vision, une théorie, des finalités. Par nature il n’est donc pas parfait par rapport à cette réalité. On parle ici de perfection par rapport à son processus de construction.

[2] Retenir, écarter, structurer des entités, identifier des relations … réifier au final.

[3] Exemple vécu de pression de modélisation, où une finalité hors RH (ici gérer la planification d’équipes de travail mixte internes et externes) qui s’insinue dans les finalités RH (qui ne concernent que les internes-salariés).

[4] Voir https://www.cairn.info/revue-anthropologie-des-connaissances-2009-1-page-5.htm

[5] Qui n’est qu’un exemple (majoritaire) de programmation, et un sujet d’attention par exemple dans la définition de requêtes exploitants des bases NOSQL (type clé-valeur)

[6] Voir pour cela la référence initiale – principe décrit par E.F. Codd « « A Relational Model of Data for Large Shared Data Banks », Mais aussi l’ouvrage de 1983 de C. Delobel et M. Adiba « bases de données et systèmes relationnels ». Attention bien entendu, dans le cas de modèles dédiés par exemple à la business intelligence, la redondance est parfois nécessaire. Mais de fait ces modèles ne sont jamais premiers comme ceux que l’on évoque dans cet article.

[7] Il s’agit juste d’une illusion. Un modèle totalement générique, devra finalement être instancié et rendu conforme à l’univers du problème au travers des traitements qui l’exploiteront.

[8] On peut aussi parler de plasticité du modèle, c’est-à-dire suffisamment stable tout en étant adaptable.

[9] La gestion de l’historicité n’est pas obligatoire dans un modèle.

[10] Exemple de bons principes :

Une nomenclature doit être univoque et non répétitive : elle décrit un seul axe, une seule dimension de façon non ambiguë
De fait, elle doit être exhaustive pour l’univers du problème traité.
Ses valeurs doivent être de la granularité la plus fine (non décomposables pour le problème traité, et re-combinables en agrégats si besoin).

Voir sur ce sujet aussi le chapitre 2 « Répertoires et nomenclatures » de l’ouvrage « Les référentiels du Système d’Information » – données de référence et architecture d’entreprise paru chez Dunod J. Bizingre, J. Paumier, P. Rivière.

[11] https://www.ohdsi.org/data-standardization/

[12] Référentiels externes mais bien entendu aussi internes au Système d’Information qui accueille le modèle (exemples : référentiels d’organisation, produit, d’asset…).

[13] Via le partage d’une définition commune des objets de part et d’autre de la relation (la notion d’organisation de l’univers de la relation client Professionnel et bien la même que celle utilisée lorsqu’on désigne un membre d’une organisation dans l’univers de la relation client Particulier. Via la gestion d’identifiants correctement posés.

[14] Une autre perspective peut être adoptée sur ce sujet. Le modèle de donnée est vu au travers d’une problématique de communication. Une part du modèle de données est support aux messages à destination d’autres acteurs (humain ou système). La qualité du modèle de données est alors vue comme en élément de la qualité de la communication. Et cette qualité de la communication dépend de la qualité sémantique des messages – signification des messages (lisibilité – encodage limité de façon à être lu sans décodage, compréhensible et formel – aligné sur les termes standard métier, juste et complet…).

[15] La sélection Darwinienne entre modèles n’est pas loin dans cet exercice.