“Data : attention à la panne de sens”

Joël Bizingre, associé chez Conix Consulting, publie un post en relation directe avec le chantier PxData. Il exprime une philosophie que nous partageons : l’exploitation de la technologie des x-data (où x vaut “big”, “open”, “smart”, etc.) suppose toujours un effort de “sémantisation”. Pour le dire plus clairement, la donnée n’est utile que quand on retrouve sa signification.

En pratique, on ne peut pas faire l’économie d’un modèle sémantique. L’idée sera même d’anticiper la disponibilité des données et d’enrichir le modèle sémantique de l’entreprise pour pouvoir accueillir plus facilement les données, quand elles se présenteront.

Les entreprises peuvent facilement acquérir des données externes, pour une dépense modique. Cette dépense est tout de même un gaspillage si l’entreprise ne sait pas comment exploiter ces données. La solution passe par un modèle sémantique qui intègre les concepts manifestés par ces données et qui les relie aux objets connus de l’entreprise.

Voir “Data : attention à la panne de sens“.

Ce papier fixe la philosophie qui préside au chantier PxData. Il mentionne, d’ailleurs, deux des procédés disponibles. Le chantier, accompagné par Praxademia, débouchera sur une contribution du cabinet Conix Consulting à Praxeme.

Site web de Conix Consulting

Formaliser la connaissance du métier

Terminologie, ontologie, sémantique

Quoi que l’on fasse – transformation, innovation, automatisation… -, le point de départ est toujours le même : la connaissance du métier. Non seulement nous devons posséder cette connaissance, mais aussi elle doit se présenter sous une forme telle qu’elle satisfasse à plusieurs critères. Elle doit être :

  • complète, pour éviter les surprises en cours de route,
  • sans ambiguïté, pour empêcher les conflits d’interprétation,
  • précise, pour appuyer une conception pertinente,
  • fidèle, conforme à la réalité,
  • économique, c’est-à-dire exprimée sans redondance, avec le minimum de termes pour dire le maximum de choses,
  • ouverte, affranchie des présupposés qui pourraient réduire sa portée.

Cette qualité d’expression ne se donne pas d’emblée. On ne l’obtient que par de grands efforts et une volonté constante. Elle ne se trouve ni du côté du “métier”, ni du côté de l’informatique. En effet, force est de constater qu’elle n’est pas immédiatement disponible dans l’entreprise. Il suffit de réunir deux experts du métier et de les faire travailler sur des définitions, pour s’apercevoir que les pratiques reposent sur beaucoup de non-dit et que la verbalisation fait voler en éclat l’apparent consensus.

Pour obtenir une bonne expression de la connaissance, nous disposons de plusieurs techniques : la terminologie, les ontologies, la modélisation sémantique. Chacune présente des avantages et des limites. Comment les utiliser ? Peut-on les articuler ? Quel niveau d’exigence viser, selon l’objectif que l’on se donne ?

Voilà quelques-unes des questions abordées dans l’article “Formuler la connaissance“, publié sur le wiki du Praxeme Institute.

Version anglaise : “Formulating Knowledge“.

 

 

Publication d’un article sur le référentiel de description de l’entreprise

Le référentiel de description de l’entreprise

Un dispositif central pour asseoir une approche rationnelle de la transformation d’entreprise

La notion de « référentiel de description de l’entreprise » (RDE) est centrale dans la méthode Praxeme. Elle traduit la volonté de tout dire de l’entreprise et d’encourager une approche interdisciplinaire de la transformation. On se doute que la mise en œuvre de ce concept, pourtant simple, rencontre de nombreux obstacles. Un moyen de les surmonter réside dans les architectures et modèles génériques, aujourd’hui à notre disposition.

 

La livraison n°99 de la Lettre de l’Adeli publie un article demandé à Dominique Vauquier. Cet article présente la notion de référentiel de description, son importance dans la transformation de l’entreprise, puis les modèles génériques qui permettent de construire rapidement ce référentiel et de mettre les projets sur les bons rails.

Article “Le référentiel de description de l’entreprise”

Big data : la nécessaire sémantisation des données

En exploitant les nouvelles sources de données, à un moment ou à un autre, se pose la question de la signification de ces données. Également, pour tirer un plus grand profit de la connaissance acquise, la donnée doit être rapportée à un concept, c’est-à-dire à l’objet (physique ou abstrait) qui la porte. Elle doit s’articuler aux autres facettes de cet objet.
C’est le rôle de la modélisation sémantique de dégager la signification des données, de les formaliser en tant que propriétés du concept et de les inscrire dans une structure manipulable.

La modélisation sémantique apparaît donc comme un outil incontournable pour bénéficier des techniques X-data. En retour, les X-data influent sur la modélisation sémantique – sinon sur ses procédés, du moins sur son contenu. Notamment :

  • assimilation de nouvelles propriétés dans le modèle sémantique (complétant les classes sémantiques, déjà identifiées, avec des “détails” issus des big data), particulièrement des propriétés de portée classe (valeurs agrégées, indicateurs issus des open data),
  • extension du modèle à des notions nouvelles (par exemple, meilleure description des objets appartenant à l’environnement de l’entreprise, les personnes, leurs relations, leurs comportements, les événements externes…),
  • évolution vers un “style” de modèle qui ménage leur place aux comportements, aux corrélations et aux anticipations (des catégories de propriétés que l’on peut considérer comme nouvelles ou, en tout cas, d’usage rare dans la modélisation classique), avec un enrichissement conséquent des automates à états et de la propagation des changements d’états.

Praxeme exhorte le modélisateur à ne pas réduire la connaissance du métier à celle des données. Le choix du terme “sémantique” en lieu et place de “conceptuel” découle de cette position, ce dernier terme évoquant fortement le modèle conceptuel des données alors que le modèle sémantique prend en charge le concept, tout le concept, sous ses trois facettes réconciliées dans l’unité de la classe : information, action, transformation.

Un modèle de données n’est pas un modèle sémantique

On change plus facilement les appellations que les pratiques. Aujourd’hui, il est de bon ton d’insister sur les objets métier. C’est une très bonne chose… à condition d’en faire des modèles qui ne soient pas que des modèles de données “à l’ancienne”. Je réponds ci-dessous à une question qui m’a été posée sur ce que change l’utilisation d’UML par rapport à Merise.

Qu’est-ce qui fait, fondamentalement, que les entités de Merise sont distinctes de ce que l’on nomme “objets métier” ? En dehors de la notion d’héritage (et donc de spécialisation dans UML), qu’est-ce qui fait, dans le formalisme et dans les principes, qu’UML est plus adapté que Merise pour représenter les objets métier ? Est-ce-qu’en pratique, ce sont les notions d’agrégation et de composition qui changent tout ?

 

Tout d’abord, Merise – méthode de conception informatique – ne nous enseigne pas à représenter la connaissance métier mais impose, dès l’abord, la séparation données-traitements. Le MCD est un modèle de données : c’est dire qu’il ne peut pas représenter toute la connaissance des fondamentaux du métier. Conséquence pratique : certaines informations ne peuvent pas être inscrites sur le modèle, sous prétexte qu’elles sont calculées (ex. l’âge de la personne alors que l’on a la date de naissance). C’est tout à fait justifié pour un modèle de données, ça ne l’est pas pour un modèle sémantique. Du point de vue de l’acteur métier, ces distinctions entre données brutes et données calculées n’ont pas cours : il voit des informations qui font partie du concept.

Plus important encore : la sémantique d’un concept ou d’un objet métier ne s’arrête pas aux propriétés informatives : elle comporte également des propriétés actives (ce que l’objet peut “faire”) et des propriétés transformatives (comment il se comporte ?). Si nous voulons exprimer toute la sémantique, nous devons associer à l’objet métier : les opérations et leurs conditions d’emploi, les contraintes (règles métier), les états (cycles de vie)… bref tout ce qui complique dangereusement nos solutions informatiques faute d’une approche appropriée.

Si la notation UML est bien utilisée, elle peut outiller la modélisation sémantique. Les classes portent les trois types de propriétés : informatives (sous la forme d’attributs, y compris attributs calculés et attributs de portée classe) ; actives (les opérations) ; transformatives (les contraintes et les automates à états).

Évidemment UML est connotée “logiciel” (et est, d’ailleurs, largement sous-exploitée par les informaticiens dont les pratiques de modélisation ont considérablement régressé au cours de ces dernières décennies). Mais il ne faut pas oublier que les notions et axiomes qui forment la logique objet proviennent de la philosophie de la connaissance (de là le terme “classe”) : ce n’est donc pas un hasard si cette logique et les notations qui l’expriment se prêtent aussi facilement à la représentation des connaissances. A noter aussi que l’élargissement des possibilités de modélisation (dans un modèle sémantique par rapport à un MCD) n’aboutit pas à un simple ajout de propriétés sur le modèle : il en change la structure. Ce que je veux dire par là, ce n’est pas seulement les éléments visibles qu’apporte UML par exemple (héritage, agrégation…) : ces éléments pouvaient être, en partie, restitués dans l’approche classique. C’est qu’en prenant en compte toutes les propriétés des objets métier et en suivant les exigences de généricité et de factorisation, le modélisateur est conduit à arranger différemment l’ensemble des propriétés. Les conséquences de ces changements de structure sont énormes : si on les suit sur toute la chaîne de transformation (conception des processus, automatisation…) l’enjeu se chiffre en millions d’euros. L’exemple d’école est la notion de Personne (ou client, employé, etc.). En appliquant rigoureusement cette approche, on peut diviser le volume des SI par 2, facilement ! Tout en augmentant le confort d’utilisation parce que l’on aura construit des solutions plus proches des représentations naturelles.

En conclusion, un modèle sémantique est bien plus qu’un modèle conceptuel des données (il le contient et on peut, à tout moment, extraire le modèle des données d’un modèle sémantique. Praxeme propose plusieurs filières de dérivation à partir du modèle sémantique, dont celle qui produit le modèle logique des données).
L’appellation “Business Object Model” a servi un peu trop à désigner des MCD (et parfois, même pas bons : on en a de lamentables exemples sur le marché). Ce qu’on appelle un BOM (par exemple celui d’IBM) ou l’Information Model d’ACORD ne sont que des modèles de données (même pas normalisés). Les conséquences sont dramatiques. Mais c’est une autre histoire…

Ce commentaire ne remet pas en cause l’héritage de Merise. UML est une notation, pas une méthode. Merise est une méthode et beaucoup de ses recommandations non seulement restent d’d’actualité mais encore sont nettement supérieures à ce que l’on trouve dans les méthodes orientées objet et dans les pratiques courantes. Donc, nous avons tout intérêt à faire fructifier notre héritage. Praxeme reconnaît bien volontiers sa filiation avec Merise.

Formaliser la connaissance

En réponse à la demande d’un client, Dominique VAUQUIER tire au clair les différents moyens d’exprimer la connaissance. C’est l’occasion pour formuler des réflexions qui traînaient au sein du Praxeme Institute, surtout depuis les ateliers des professeurs Loïc DEPECKER sur la terminologie et Christophe ROCHE sur les ontologies.

L’article repose sur l’idée que les techniques à notre disposition pour exprimer les connaissances s’échelonnent selon le niveau de formalisation. Plus l’effort consenti est important, plus grandes sont les possibilités d’automatisation.

En pratique, les entreprises que le sujet préoccupe pourront arrêter une démarche progressive, mettant à profit différentes techniques : le classement de documents à l’aide de taxinomies, l’élaboration de la terminologie d’entreprise, le développement d”ontologies, la modélisation – particulièrement la modélisation sémantique.

Télécharger l’article