Modélisation des concepts

Objectif

Un modèle de concepts fixe le vocabulaire d'un domaine avant que quiconque écrive une exigence, une règle ou une spécification. Il répond à deux questions: comment l'organisation nomme les choses dont elle parle et ce qui est vrai à leur sujet. La première produit des termes définis, la seconde les formulations standard qui les relient et qui sont ensuite les briques des énoncés de règles.

Le modèle vaut là où les distinctions sont subtiles. Dans une caisse maladie soumise à la LAMal, le mot « client » désigne un prospect pour le service commercial et un assuré pour le service des sinistres. Tant que cette collision reste implicite, chaque règle écrite avec le mot « client » est ambiguë. Le modèle de concepts la rend visible, force la décision et inscrit le résultat dans un vocabulaire que les deux services acceptent.

Le livrable est ce vocabulaire: les concepts, leurs définitions, les types de faits qui les relient et, le plus souvent, un diagramme qui les montre ensemble. Il survit au remplacement du système d'information, parce qu'il n'a jamais dépendu de lui.

Usage

Quand l'utiliser

• Domaine riche en règles métier: des centaines de règles doivent rester cohérentes entre elles et sans ambiguïté.
• Terme contesté entre équipes: « bénéficiaire » désigne le titulaire du contrat au service des polices et la personne soignée au remboursement.
• Domaine réglementé: les définitions doivent tenir devant un régulateur, un auditeur ou un tribunal.
• Rejet du diagramme de classes: le métier écarte le vocabulaire technique, le modèle porte la même précision dans ses mots.
• Connaissance métier à capitaliser: l'organisation veut conserver et transmettre le savoir du domaine au-delà d'un projet.
• Réingénierie d'un processus: repartir du vocabulaire du métier plutôt que d'hériter des termes du système en place.

Quand ne pas l'utiliser

• Besoin de structure de stockage: cardinalités, clés et attributs relèvent du modèle de données.
• Petit périmètre sans conflit de vocabulaire: un glossaire suffit et coûte une fraction du temps.

Ce que contient un modèle de concepts

Concepts nominaux et instances

Les concepts nominaux sont les termes de base du domaine: l'assuré, la police d'assurance, le sinistre, la prestation, le physiothérapeute. Le BABOK les tient pour donnés: le modèle les recueille sans les construire.

Un concept nominal désigne une catégorie de choses dont chaque membre est une instance. SBVR réserve à celle-ci le terme de concept individuel (individual concept). « Assuré » est un concept nominal, Jean Dupont en est une instance; « police d'assurance » est un concept nominal, la police n° 4711 en est une. L'instance entre rarement dans le modèle: elle sert à l'éprouver. Une règle porte sur des concepts nominaux, un cas de test sur des instances; un modèle qui laisse une instance s'installer en boîte produit des règles qui ne valent que pour elle.

Concepts verbaux et types de faits

Les concepts verbaux, ou types de faits dans le vocabulaire de SBVR, relient des concepts nominaux par une formulation standard: « l'assuré détient une police », « la police couvre un sinistre », « le physiothérapeute fournit une prestation ». L'atelier arrête la formulation une fois, pour qu'on désigne ensuite le type de fait sans ambiguïté. Le BABOK en fait la brique des phrases, à commencer par les énoncés de règles.

Un concept verbal est parfois dérivé, inféré ou calculé par une règle de définition, et le BABOK y voit la manière dont une connaissance nouvelle se construit sur des faits plus élémentaires. Le fait « l'assuré relève du tarif enfant » ne s'observe nulle part: une règle le calcule depuis « l'assuré est né le… ». Il entre dans le modèle comme fait à part entière, accompagné de la règle qui le produit.

Les autres connexions

Les autres connexions ajoutent une couche sémantique au-dessus des termes et des faits. Les catégorisations rangent un concept sous un concept plus général: le sinistre se catégorise en accident et en maladie. Les classifications rangent une instance sous un concept: la police n° 4711 est une police d'assurance. Les connexions partitives relient un tout à ses parties: la police se compose de couvertures. Les rôles disent en quelle qualité un concept intervient dans un fait: le physiothérapeute agit comme fournisseur de prestations.

La catégorisation et le rôle se confondent en atelier. Une catégorie vaut hors de tout fait: un sinistre-accident reste un accident qu'il s'agisse de remboursement, de statistique ou de recours contre un tiers. Un rôle ne vaut qu'à l'intérieur d'un fait et change avec lui: le même physiothérapeute est fournisseur dans « le physiothérapeute fournit une prestation » et débiteur dans « le fournisseur restitue un montant facturé à tort ». Ranger un rôle parmi les catégories multiplie les concepts nominaux sans rien ajouter au sens.

Les définitions

Les définitions traversent ces trois éléments. Chaque terme et chaque type de fait porte une définition rédigée dans les mots du métier, indépendante de toute conception et exempte de tout biais de données ou d'implémentation. Un modèle dont les termes sont connectés mais sans définition déplace l'ambiguïté du texte vers le diagramme, où elle se voit moins.

Deux dérives

La première est le glissement vers le modèle de données: dès que des boîtes et des lignes apparaissent au tableau, quelqu'un demande si un assuré peut détenir plusieurs polices, et la séance bascule sur les cardinalités. La question est légitime, sa place est le modèle de données, le facilitateur la note et la renvoie. La seconde est la substitution du vocabulaire informatique au vocabulaire métier: le modèle finit par nommer les choses comme les nomment les tables du système, et il perd ce pour quoi il existe. Le test: un collaborateur métier qui n'a jamais vu la base de données doit reconnaître chaque terme du modèle comme le sien.

Les deux dérives trahissent une exigence de fond que le BABOK inscrit parmi les limites de la technique: elle demande de penser une connaissance de façon abstraite et non procédurale, ce que ni la formation ni l'habitude des participants ne prépare. Une salle qui décrit spontanément un enchaînement d'étapes ou un écran de saisie retourne au concret dès qu'on la laisse faire, et le facilitateur la ramène chaque fois à la question « qu'est-ce que ce mot désigne ».

Écrire et lire un type de fait

Un type de fait est capté une fois et se lit dans les deux sens. « L'assuré détient une police » est la lecture directe; « la police est détenue par un assuré » est la lecture inverse du même fait. Une règle doit se formuler sans contorsion quel que soit le concept par lequel elle commence. Une règle sur la validité de la couverture part de la police, une règle sur l'affiliation part de l'assuré et les deux s'appuient sur le même fait.

La convention vient de la modélisation orientée faits, que SBVR normalise et que l'Object-Role Modeling de Terry Halpin a outillée. Elle s'appelle verbalisation: le modèle se relit en phrases, à voix haute en atelier, et une phrase qu'un collaborateur métier ne prononcerait pas signale une formulation à reprendre.

Ce qu'une formulation doit respecter

Une formulation porte un fait élémentaire, un seul. « Le physiothérapeute agréé fournit une prestation remboursée » en contient trois et se découpe en « le physiothérapeute fournit une prestation », « le physiothérapeute est agréé » et « la prestation est remboursée ». Chacun des trois sert des règles différentes, et un fait composé oblige chacune d'elles à porter les deux autres.

Elle emploie le présent et la voix active pour la lecture directe, la voix passive servant la lecture inverse. Un futur ou un conditionnel trahit une règle qui s'est glissée dans le vocabulaire.

Elle ne quantifie pas. « Chaque », « au plus un », « au moins deux » appartiennent aux règles. Cette exclusion sépare un type de fait d'une relation de modèle de données. Le modèle de concepts établit que l'assuré détient une police. Le nombre de polices qu'il peut détenir est une contrainte du domaine: elle s'énonce comme règle (« un assuré ne détient qu'une police d'assurance obligatoire des soins à la fois ») et le modèle de données la reprendra sous forme de cardinalité.

Elle ne conditionne pas. « L'assuré détient une police lorsqu'il est domicilié en Suisse » est une règle déguisée en fait; le fait qu'elle contient est « l'assuré détient une police », et la condition rejoint les règles.

Écrire les définitions

Genre et différence

ISO 704:2022 appelle définition par compréhension celle qui énonce le concept superordonné immédiat, le genre, puis les caractéristiques qui distinguent le concept de ses voisins sous ce même genre, la différence. Le patron: un X est un [genre] qui [différence].

Le genre se choisit au plus près. « Un sinistre est un événement » prend un genre si large que la différence doit tout porter. « Un sinistre-accident est un sinistre » prend le genre immédiat et laisse à la différence son travail propre. Deux concepts qui partagent un genre s'écrivent ensemble, parce que leurs différences doivent se répondre: si l'une déborde sur l'autre, la catégorisation qui les porte est fausse.

ISO 704 nomme une seconde forme, la définition par extension, qui énumère les sous-concepts ou les objets couverts: le sinistre y deviendrait « un sinistre-accident ou un sinistre-maladie ». Elle convient à une liste courte et close. Un vocabulaire métier s'en accommode mal, parce que l'énumération ne donne aucun critère pour ranger un cas nouveau et qu'un domaine qui s'étend la rend fausse.

Les définitions déficientes

ISO 704 nomme trois défauts que la relecture d'un vocabulaire doit chercher, et sa liste s'arrête là.

La définition circulaire renvoie le lecteur au terme qu'il cherchait. Sa forme directe se voit (« un sinistre est un événement de sinistre »), sa forme mutuelle beaucoup moins: « prestation: ce que l'assureur verse au titre d'un sinistre » et « sinistre: l'événement qui ouvre droit à une prestation » tiennent chacune debout et ne définissent rien ensemble. Le test est la substitution. On remplace le terme par sa définition dans un énoncé de règle, puis on recommence sur les termes que la définition vient d'introduire; une boucle se referme en deux ou trois passes.

La définition inexacte se trompe de genre ou de différence. Un genre trop large laisse entrer ce qui devrait rester dehors: « un sinistre est un événement qui concerne l'assuré » admet un déménagement. Un genre trop étroit exclut ce qui devrait entrer, et il se repère au premier cas réel qu'on essaie d'y ranger. Une différence qui ne délimite rien est le cas le plus fréquent: « un sinistre-accident est un sinistre de nature accidentelle » répète le terme au lieu de dire à quoi on le reconnaît.

La définition négative dit ce que le concept n'est pas. Elle satisfait la salle sur le moment, parce qu'elle tranche le cas dont on discutait, et elle laisse le lecteur suivant sans critère. Le droit suisse s'autorise pourtant cette forme: la LPGA pose la maladie comme une atteinte à la santé qui n'est pas due à un accident, et elle le peut parce qu'elle a rendu la paire exhaustive par ailleurs. Un vocabulaire métier a rarement cette garantie, et la sortie consiste à écrire la caractéristique positive que l'exclusion supposait: ici une atteinte d'origine interne.

Synonymie et polysémie

Tout vocabulaire partagé produit deux situations qu'ISO 704 nomme synonymie et polysémie.

La synonymie met deux termes sur un concept. « Fournisseur de prestations » et « prestataire de soins » désignent la même chose dans une caisse maladie. Le modèle en retient un comme terme préférentiel puis enregistre l'autre comme variante admise. Supprimer la variante coûte plus qu'elle ne rapporte: elle circule dans les documents existants, et une recherche sur la variante ramène alors au bon concept.

La polysémie met deux concepts sur un terme. « Client » désigne un prospect au commerce et un assuré aux sinistres. Les deux sens partagent une caractéristique, puisque le prospect comme l'assuré est une personne avec laquelle l'assureur traite; ISO 704 réserve l'homonymie aux sens que seule la forme du mot rapproche. Scinder donne deux termes distincts, chacun avec sa définition, et impose de reprendre les documents où le mot ambigu figure. Qualifier conserve le mot et lui adjoint son contexte, « client commercial » et « client assuré », ce qui coûte moins et laisse le mot nu continuer à circuler. Le choix appartient à l'organisation; l'analyste en pose les termes et en montre le prix.

Le BABOK range parmi les déclencheurs d'une entrée de glossaire le fait qu'un terme porte plusieurs définitions dans l'organisation. Le glossaire enregistre le signal, le modèle de concepts le traite.

Dessiner un modèle de concepts

Une notation sans attributs

Un modèle de concepts n'a pas de notation normalisée. Un usage largement partagé s'est imposé: une boîte par concept nominal, un trait nommé par type de fait, une marque distincte pour la catégorisation. Un modèle dessiné ainsi se lit sans apprentissage. Cet usage ne porte ni attribut, ni clé, ni type de données, ni cardinalité.

Le motif vient de la modélisation orientée faits. L'Object-Role Modeling de Terry Halpin, héritier de NIAM, est sans attribut par construction: tout fait élémentaire y est une relation, un rôle joué par un type d'objet. Halpin et Morgan en donnent la raison pratique dans Information Modeling and Relational Databases: décider qu'une information est un attribut ou une relation est un choix de représentation, révisable dès que le domaine évolue, et un modèle qui l'a figé tôt se refait.

Le type de fait prend la place de ces constructions. Une date de début de couverture entre dans le modèle comme concept nominal, puis comme type de fait: « la police porte une date de début de couverture ». Le détour paraît lourd jusqu'au jour où une police porte deux dates de début parce qu'une couverture a été suspendue: le modèle n'a alors rien à défaire. L'identifiant disparaît par le même raisonnement, comme le format d'une date et ses valeurs admises: ce sont des décisions de stockage.

Les notations que l'on rencontre

Une liste tenue de formulations et de définitions se lit dans la langue même où les règles seront écrites, et elle supporte une revue ligne à ligne qu'aucun diagramme ne permet. SBVR est textuel dans son principe; sa notation graphique est un profil UML facultatif. Le diagramme garde un emploi que le texte n'a pas: montrer d'un coup d'œil qu'un concept est isolé, qu'un autre concentre huit types de faits, qu'une branche de catégorisation n'a qu'un seul membre.

La carte de concepts de Novak et Gowin porte un nom voisin et vient d'ailleurs, de la pédagogie et des sciences cognitives des années 1970. Elle relie deux concepts quelconques par une phrase de liaison quelconque, sans la discipline du type de fait, ce qui la rend utile en élicitation, où l'on cherche la carte mentale d'un interlocuteur avant de la corriger. Nommer « carte de concepts » le livrable d'un atelier de modélisation des concepts coûte une réunion de clarification.

Le diagramme de classes sans attributs est la solution que l'outillage rend la plus facile. Le dessin est correct tant que personne n'y touche. Puis quelqu'un ajoute une multiplicité sur une association, un stéréotype sur une classe, un compartiment d'attributs sur deux boîtes pour faire complet, et le modèle est devenu un modèle de données que le métier ne relira plus. Le BABOK range la résistance des parties prenantes au caractère technique perçu des modèles de données et des diagrammes de classes parmi les situations où un modèle de concepts s'impose: employer la notation qui a produit cette résistance demande une raison.

L'ORM est enseigné et outillé comme une méthode de modélisation conceptuelle de données qui dérive mécaniquement un schéma relationnel, ce qui le range du côté des données. Un modèle de concepts lui doit la verbalisation et l'absence d'attributs, sans son jeu de contraintes d'unicité et de participation.

Modèle de concepts et modèle de données

Un modèle de concepts porte le sens. Un modèle de données porte la structure: les entités, leurs attributs, les clés et les cardinalités qui rendent l'information stockable et interrogeable. Ronald G. Ross, l'un des auteurs de référence de la discipline des règles métier, résume la frontière: les modèles de concepts sont centrés sur le concept, les modèles de données sur la chose, l'entité ou la classe. Il ajoute qu'un modèle de données se dérive assez aisément d'un modèle de concepts, alors que le chemin inverse est beaucoup plus difficile. La descente part d'un vocabulaire, de liens et de définitions déjà arbitrés; la remontée bute sur un schéma qui ne dit pas lesquels de ses choix relevaient du sens et lesquels du stockage. C'est l'argument pratique pour commencer par le vocabulaire quand le domaine est dense en règles ou que ses termes sont disputés.

Ce que le modèle de données ajoute

Chaque attribut reçoit un nom, une définition, ses valeurs ou formats admis et le type d'information qu'il porte. Chaque occurrence d'entité reçoit un identifiant unique, et les clés primaires et étrangères font tenir les liens. Chaque relation reçoit une cardinalité, un minimum et un maximum d'occurrences de part et d'autre, que le BABOK fait lire dans les deux sens sur le patron « chaque occurrence de cette entité est en relation avec (minimum, maximum) de cette autre entité ». La lecture bidirectionnelle est l'habitude du type de fait, avec un nombre en plus.

Le diagramme entités-relations dessine entités, attributs et relations, et ses jeux de symboles courants sont les pattes-de-corbeau (crow's foot) et la notation de Chen. Le diagramme de classes UML fait le même travail dans le vocabulaire objet, où la relation devient association et la cardinalité multiplicité. Les classes y portent en plus des opérations.

Le modèle de données se décline en trois niveaux. Le conceptuel est indépendant de toute technologie. Le logique applique les règles de normalisation pour préserver l'intégrité des données et de leurs relations. Le physique décrit l'organisation réelle d'une base et traite la performance, la concurrence et la sécurité. Ces objets relèvent de la modélisation des données.

Le mot « conceptuel »

Le premier de ces trois niveaux crée une collision de vocabulaire. Le modèle conceptuel de données porte déjà des entités, des relations et des cardinalités. Les praticiens de Merise le connaissent sous le sigle MCD. L'édition française officielle du BABOK v3 nomme « modèle conceptuel » le modèle de concepts lui-même, si bien que le terme désigne l'un ou l'autre selon le livre ouvert. Un modèle de concepts se situe plusieurs pas en amont, sans entité ni cardinalité. Quand un interlocuteur propose « un modèle conceptuel », une question économise une réunion: parle-t-il de vocabulaire ou d'entités et de cardinalités?

Les correspondances vers le modèle de données

Les concepts nominaux deviennent des entités ou des classes candidates, et tous n'y arrivent pas: certains finissent attributs d'une autre entité, d'autres sortent parce que l'organisation ne conserve rien à leur sujet. Les types de faits deviennent des relations candidates, dont chacune appelle la décision de cardinalité que le modèle de concepts avait laissée ouverte. Les catégorisations deviennent des structures de sous-type et de sur-type ou un attribut discriminant, selon la façon dont l'implémentation les traite. Les définitions passent telles quelles en descriptions d'entités et d'attributs, et elles sont les seules à traverser sans perte.

Les attributs n'ont aucune source dans le modèle de concepts: ils naissent à ce passage, quand l'organisation décide quelles informations elle conserve sur chaque entité.

Rapport aux règles métier et au glossaire

Le modèle de concepts fournit le vocabulaire dans lequel les règles métier sont écrites. Une règle telle que « un sinistre ouvre droit à une prestation lorsque sa date survient dans la période de validité de la police » ne devient vérifiable que si sinistre, prestation, police et période de validité sont définis et acceptés. La norme SBVR de l'OMG formalise ce couplage: un vocabulaire de concepts nominaux et verbaux et des règles construites dessus en langage naturel contrôlé.

Le glossaire est le point de départ du modèle et sa forme la plus simple: une liste de termes et de définitions. Le modèle de concepts lui ajoute la couche des types de faits et des autres connexions.

Le modèle de concepts dans une initiative analytique

Dans le Guide to Business Data Analytics de l'IIBA, le modèle de concepts décrit une solution de données du point de vue métier, avant que la moindre source ne soit choisie. L'équipe le construit tôt, au moment où elle formule sa question de recherche. Il délimite le périmètre en nommant les entités métier dont il faudra capter des données. Il valide ce périmètre auprès des parties prenantes dans leur propre vocabulaire, ce qu'aucun modèle technique ne permet. Il devient enfin le socle des modèles logiques et physiques qui suivent, puis le document que l'on rouvre lorsque la solution doit changer.

Considérations IA

Un modèle de langue balaie les sources écrites du domaine, conditions générales, réglementation, glossaires existants, comptes rendus d'entretiens, et il en fait remonter des concepts nominaux et des formulations de types de faits. L'atelier part alors d'un brouillon à corriger, ce qui est un gain sur un domaine dense. La limite tient à la nature de la technique: le métier est propriétaire du sens de ses termes. Aucune machine ne peut arbitrer laquelle des deux acceptions de « client » fait foi, parce que c'est une décision de l'organisation sur sa manière de parler. Toute définition rédigée par l'IA est une proposition que doivent valider les parties prenantes qui vivront ensuite avec elle.

Un contrôle échappe à cette limite parce qu'il est formel: la recherche de circularité dans un jeu de définitions. Suivre les renvois jusqu'à la boucle est une vérification exacte, répétitive et ingrate, celle que la relecture humaine rate en fatiguant sur deux cents entrées. Le repérage de deux définitions concurrentes attachées au même terme relève du même registre.

Coût

Outils

Le tableau blanc et le paperboard suffisent à l'atelier: les termes s'écrivent, se déplacent et se raturent devant les participants, et chaque décision attend que le groupe la prenne. Le tableur recueille le résultat à la sortie de séance, une ligne par terme, une colonne pour le genre, une pour la différence, une pour la personne qui répond du terme. Il se trie, se filtre et se partage sans licence.

Un wiki d'entreprise ou un outil de diagrammes convient à un modèle léger: quelques dizaines de termes, un fragment dessiné pour la revue, un historique des versions. La limite apparaît le jour où une définition change et où il faut retrouver toutes les règles écrites avec le terme, parce que le wiki n'enregistre pas ce lien.

Les outils de gestion de vocabulaire et de règles métier l'enregistrent. Ils réunissent dans un même référentiel le terme, sa définition, ses variantes admises et les règles qui l'emploient, puis ils signalent ce qu'un changement de définition met en cause. Certains lisent et produisent du SBVR, ce qui rend le vocabulaire transportable d'un outil à l'autre. Ils se justifient quand le modèle doit rester vivant et alimenter l'écriture des règles, et un vocabulaire de trente termes reste dans le tableur.

L'outillage ORM occupe une place à part. Il impose la verbalisation, vérifie les contraintes d'unicité et de participation, puis dérive un schéma relationnel. Il vise donc les domaines denses où ce schéma sera produit. Il demande en retour un modélisateur formé, et sa notation se lit mal sans apprentissage.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.11 Concept Modelling.
• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.15 Data Modelling et §10.23 Glossary: les deux techniques dont ce modèle marque la frontière et l'origine.
• OMG, Semantics of Business Vocabulary and Business Rules (SBVR): la formalisation normalisée du vocabulaire métier, concepts nominaux, concepts verbaux, formulations standard des types de faits et règles construites dessus.
• Ronald G. Ross, « What Is a Concept Model? », Business Rules Journal, vol. 15, n° 10 (2014): l'énoncé de référence de la frontière entre modèle de concepts et modèle de données.
• ISO, ISO 704:2022, Travail terminologique - Principes et méthodes, 4e édition: la définition par compréhension au format genre et différence, puis les trois définitions déficientes qu'elle nomme: circulaire, inexacte et négative.
• Terry Halpin et Tony Morgan, Information Modeling and Relational Databases, 2e édition, Morgan Kaufmann, 2008: la modélisation orientée faits, la verbalisation et la raison pour laquelle un modèle orienté faits se passe d'attributs.
• IIBA, Guide to Business Data Analytics, §3.3 Concept Modelling: le modèle de concepts comme description métier d'une solution de données, construit au moment où la question de recherche est formulée.