De l’utilité d’une automatisation partielle

Il y a un cas où l'automatisation partielle est utile. C'est celui où vous n'êtes pas pleinement en mesure de formaliser toute votre logique d'une façon interprétable par la machine ou lorsque les experts ne sont pas vraiment des experts.
Dans ce cas, vous demandez à la machine d’être en mesure de déterminer le niveau de difficulté de la question posée. Si la question posée est un trop difficile la machine est alors capable de dire "je démissionne", si elle est facile, elle répond alors à la question posée, de manière partielle ou complète.
Par exemple, lorsque la couleur est le noir-noir, il est facile de dire que la couleur est noire, lorsque la couleur est le blanc-blanc, il est facile de décider que la couleur est blanche, lorsque la couleur est grise, il n'est pas facile de choisir entre le noir et blanc.
La capacité de dire "je renonce" est utile car vous pouvez commencer à automatiser une décision sans totalement maîtriser la logique de cette décision. Vous pouvez automatiser les réponses faciles et laisser les réponses les plus difficiles aux experts. Avec l'aide de ce modèle, vous pouvez ainsi avoir du temps pour améliorer vos systèmes en continu. Il vous laisse du temps pour formaliser des logiques complexes ou, plus raisonnablement, pour acquérir un peu plus d’expertise.

Automatisation partielle

Toutes les décisions ne peuvent pas être automatisées, mais beaucoup peuvent l’être. Entre ces deux extrêmes une frontière existe. Quelle est-elle ? Comment la caractériser ?

Raja Parasuraman et Thomas Seidon ont écrit un article il y a une dizaine d’’années pour tenter de modéliser cette frontière. Il est intitulé “A Model for Types and Levels of Human Intercation with Automation. Cet article est tout à fait intéressant et a d’ailleurs été récemment commenté par Vijay Pandiarajan et James Taylor.

Pour faire simple ce modèle identifie 10 niveaux d’automatisation, les voici :

10. L’ordinateur décide de tout.
9. L’ordinateur décide d’informer ou pas les humains.
8. L’ordinateur informe les humains si ceux-ci le lui demande
7. L’ordinateur informe de toute manière les humains.
6. L’ordinateur donne du temps aux humains pour mettre un veto
5. L’ordinateur fait des suggestions que l’humain approuve
4. L’ordinateur propose des alternatives
3. L’ordinateur restreint l’espace de recherche et propose un nombre réduit de possibilités
2. L’ordinateur propose la totalité des alternatives possibles
1. L’humain décide et agit sans l’aide de l’ordinateur

Cette liste est intéressante du fait que de prime abord quand on pense automatisation on pense surtout à une automatisation complète et peu à une automatisation partielle. Elle est donc un moyen simple pour exprimer qu’il existe beaucoup de possibilités entre ces deux extrêmes.

James Taylor propose deux autres cas :

1. le cas où le rôle de l’ordinateur se limite à sélectionner les données utiles à la prise de décision
2. et le cas où l’ordinateur propose différentes alternatives en mettant l’emphase sur celle qu’il préfère.

Je suggère un troisième cas. La formalisation de règles n’est pas toujours facile à réaliser comme en témoigne la note de  Ken Orr . Ken Orr a écrit de manière claire que la difficulté de formaliser des règles croit nettement plus vite que la difficulté du problème et donc qu’il existe bon nombre de problèmes dont la résolution automatique n’est pas pour demain soit parce que la logique de résolution est connue mais difficile à formaliser soit parce que cette logique n’est pas connue ou mal connue
L’automatisation partielle est une réponse à cette préoccupation.
Le troisième cas consiste à donner à l’ordinateur la mission de savoir déterminer s’il sait ou non résoudre le cas qui lui est présenté. A charge pour lui de résoudre les cas simples et à charge aux humains de traiter les cas difficiles.

Je terminerais cette note en signalant que dans de nombreux cas l’automatisation partielle n’est pas possible, il s’agit par exemple de cas où la décision doit être prise de manière extrêmement rapide ou, plus simplement, de cas où l’homme n’est pas joignable.

Ergonomie de visual rules modeler

Visual Rules édité par Bosch Software dispose d’un outil de modélisation dont l’ergonomie est particulièrement intéressante. Cette ergonomie permet de spécifier des raisonnements logiques de manière très intuitive c’est-à-dire sans nécessiter beaucoup de préalables techniques.
Vous n’avez ni besoin d’avoir préalablement formalisé votre vocabulaire, ni besoin d’avoir défini la structure de données, ni besoin d’avoir préalablement conçu votre modèle exécutable (XOM), ni non plus, besoin dans dans un premier temps, d’utiliser un langage formel prédéfini.

Dans une perspective de réappropriation de l’outil informatique par les métiers, le fait de  nécessiter peu de préalables est intéressant à plusieurs titres, il permet à de nombreux acteurs de démarrer sans beaucoup d’investissements intellectuels et  surtout il permet d’éviter ou de limiter le passage par des experts techniques souvent peu disponibles et pouvant, parfois, manquer d’expertise pédagogique.

Pour décrire votre logique vous utilisez une représentation arborescente et vous décrivez le sens de chaque noeud dans le langage de votre choix.
Un noeud de l’arbre équivaut à un test et une feuille à un résultat ou une action à lancer.
A tout moment vous pouvez écrire à côté du texte en clair un texte plus formel destiné à être interprété par la machine.

Bien que le formalisme “arbre de décisions” soit aussi utilisable avec jrules (ilog-ibm) ou de drools (red-hat). Cette approche est assez différente de celles de jrules (ilog-ibm) ou de drools (red-hat), elle est n’a pas que des avantages mais elle a celui de la simplicité. Les outils comme jrules ou drools ont plus tendance à nécessiter la mise en place préalable de domaines métiers (vocabulaire métier + structure objet ), sans pour autant d’ailleurs que ce soit indispensable.

Il faut signaler que visual rules n’utilise pas de moteur de règles à proprement parler, il permet d’éditer des règles sous des formes claires et lisibles, il permet de concevoir des logiques de décisions ou de raisonnement mais lorsque vous placez un test vous devez déterminer à l’avance où ce test ce déclenchera.



A titre d’exemple voici un arbre de décision qui permet de décider si une personne est ou n’est pas l’oncle d’une autre personne. La définition du concept “oncle” ou “tante” est réalisée à partir des relations de parenté “soeur”, frère, “fils” et fille.

Cette arborescence n’est pas exécutable au sens où les noeuds de l’arbre ne contiennent pas  encore de code formel (cet exercice sera réalisé dans un autre billet) mais elle constitue une première de familiarisation avec l’outil et avec la modélisation des logiques de raisonnement.

L’étape suivante est l’écriture d’expressions formelles avec son ensemble de préalables (structures de donnée, structures objets) exécutables par la machine. Cette deuxième étape aura tendance à remettre en cause, au moins partiellement une partie des travaux déjà réalisés. Que cela ne vous incite pas, pour autant,à sacrifier la première étape, elle est très utile pour éviter quelques allers-retours des plus ennuyeux !

Risques et arbre de décision

Les arbres de décisions, constituent un exemple de formalisme permettant de représenter des logiques de décisions.
S'ils sont réalisés à l'aide d'un BRMS ces arbres de décisions peuvent être directement exécutés par des machines au même titre qu'un programme informatique.

Voici un exemple simple d'arbre de décisions construit avec IBM Ilog jrules 7.1.

La logique présentée ici permet de décider si un particulier risque de se trouver en défaut de paiement.

Cette logique est une logique école et  n'a que peu d' intérêt en soi. La forme utilisée pour la représentée est le point qui nous intéresse.

La question qui mobilise notre attention est celle de l'intérêt de ce formalisme d'arbre par rapport  aux autres formalismes comme les tables ou de règles.

La logique de décisions présentée utilise ici trois conditions et aboutie à quatre conclusions.

Les trois conditions sont relatives :

- à l'ancienneté du client,

-  à la quantité d'incidents de paiement qu'il a rencontré,

- à son endettement.

Cet arbre équivaut à quatre règles :

1) Si le client est récent sa note est C.

2) Si le client est ancien et a connu beaucoup d'incidents sa note est B.

3) Si le client est ancien, n'a pas connu beaucoup d'incidents et est endetté sa note est A.

4) Si le client est ancien, n'a pas connu beaucoup d'incidents et n'est pas endetté sa note est AA.

Plus la note est proche de AAA plus la banque a confiance dans le particulier est une personne de confiance pour la banque.

Le formalisme d'arbre présenté a l'immense avantage sur le formalisme textuel d'être exécutable.

Le formalisme textuel a l'immense avantage d'être plus accessible et plus clair.

Il reste à prendre en compte le fait que je n'ai formalisé les règles sous forme de texte qu'après avoir formalisé l'arbre et que cet ordre de travail a très favorablement facilité l'écriture de règles simple à comprendre et logiquement ordonnées.

Il peut être intéressant de constater que les conditions utilisées pour évaluer le risque du particulier sont restées très floues : qu'est-ce qu'un client ancien ? à partir de combien les incidents sont nombreux ? à partir de quels critères doit-on considérer que qu'une personne est endettée ?

La réponse à chacune de ces questions est en soi un problème complexe que l'on peut ou non choisir d'automatiser. Et si l'on choisit de l'automatiser on peut à nouveau se poser la question du bon formalisme à utiliser.

Voeux et table de décisions

Voici un simple exemple de table de décision.

Elle a été conçue dans le cadre de la réalisation d’un générateur de voeux pour la nouvelle année qui permet d’envoyer automatiquement des voeux (un peu) personnalisé par mail électronique.

L’objet de cet exemple est de démontrer l’intérêt de ce formalisme pour un cas où la logique de décision est simple.

Voici la table de décision. Elle a été réalisée à l’aide du logiciel d’IBM Ilog jrules.
La plupart des BRMS permettent des réalisations similaires.


Cette table peut être maintenu par n’importe qui sait légèrement utilisé un tableur. Chaque case est éditable.

Les colonnes A et B expriment des conditions. Ces deux critéres caractérisent le destinataire du voeu. Le texte du voeu sera personnalisé en fonction du caractère professionnel ou amical de la relation et et en fonction du genre du destinataire..
Les colonnes C,D et E présentent le texte du voeu décomposé en trois parties : 1) la salutation, 2) le corps et 3) la signature.

Cette table de décision a ensuite été intégrée à un programme java qui fait l’interface avec un répertoire et un générateur de mail.

L’utilisateur de cette petite application doit gérer son répertoire et ajouter ces deux caractérisques à côté de leur adresse mail.

Chaque année il peut modifier le texte présentée à sa guise. Cet utiliaire très simple est cependant limité à du simple texte sans images et sans mise en forme sophistiquée.

Séparer logiques et données

Je vais vous parler d’une manière de coder des logiques de décisions qui peut dans certains cas s’avérer vraiment désastreuse.

Beaucoup de développeurs ont constaté qu’il esit très pratique d’utiliser des tables de base de données relationnelles pour stocker des paramètres d’une application. Ainsi un simple script écrit par exemple en SQL suffit pour les mettre à jour. Il est bien sûr préférable, plutôt que de se satisfaire de scripts SQL de mettre au point une IHM dédiée à l’administration de ces paramètres, mais ce n’est pas toujours indispensable.

Cette pratique peut parfois être la cause de difficultés insoupçonnées et insoupçonnables et être la cause d’incidents qui peuvent rester mystérieux durant des années, jusqu’à que la situation devienne insupportable.

Il se trouve d’ailleurs que lorsque mes clients me demandent un état des lieux ou un diagnostic cette pratique est souvent à l’origine des difficultés rencontrées.

Par exemple, j’ai évalué, il y a quelques années, un système informatique ou une dizaine d’applications différentes partageaient la même base de données.  Cette base comportait plusieurs centaines de tables et certaines de ces tables étaient des tables de paramétrage. Ces paramètres servaient en particulier pour paramétrer deux décisions prises par l’application. La première était relative à la tarification de produits et l’autre à la segmentation des clients. L’intérêt de cette base est d’être unique et cela devait en principe garantir la non duplication des données de référence ce qui peut parfois être une très bonne chose et ce qui dans ce cas s’est avéré particulièrement néfaste.

Dans notre cas, les IHM d’administration fonctionnelle étaient insuffisantes et de nombreux scripts SQL devaient être mis fréquemment en production pour corriger des incidents. Ces scripts SQL pouvaient être élaborés soit par les études informatiques, soit par les équipes d’exploitation informatiques en charge de la supervision et du support des utilisateurs.

Mais le vrai problème ne venait pas de là, le vrai problème est que le sens des paramètres fonctionnel s’est disloqué dans le temps au gré de la correction d’incidents toujours plus prioritaires les uns que les autres et au gré de la personne qui les corrigeait. Il faut préciser que les bases de données relationnelles ne sont pas spécialement conçues pour stocker des paramètres. Il faut aussi préciser que la valeur de certains de ces paramètres était codée sous forme numérique assez obscure au lieu d’utiliser un mot plus explicite issu du  jargon métier.
Pour comble de malheur, certains paramètres pouvaient avoir plusieurs sens variables soit en fonction du contexte utilisateur, soit en fonction de la plage de valeurs utilisée. Certaines tentatives de rétro-documentations ont été réalisées mais, devant une telle complexité, elles ont échouées.
Au bout de quelques années, l’application est devenue très difficile à maintenir et les recettes quasiment impossibles à réaliser. La correction d’un incident engendrant  systématiquement de nouvelles anomalies.
J’ai déjà évoqué le fait que cette base de données était partagées entre une dizaine d’applications c’est-à-dire qu’il était difficile de la modifier sans impacter l’ensemble des dix applications utilisatrices, autrement dit il était difficile de la modifier sans impacter la totalité des applications de l’entreprise utilisatrice.

Du fait de cette douteuse mutualisation et du fait de la longue durée de dégradation il n’y avait pas d’autre solution que des refontes coûteuses et assez longues à mettre en oeuvre.

Toute la difficulté a été de convaincre la direction de cette entreprise à investir dans une rénovation coûteuse et risquée. Elle avait tendance a préférer tout laisser en état.

Maintenant revenons à nos logiques de décisions et passons à la phase moralisatrice de cette fable, la morale étant toujours plus facile à écrire qu’à réaliser.

Que se serait-il passé si les logiques de décisions des tarifs et les logiques de décisions des segmentations clientèles avaient été codées sous forme de règles ou de tables de décisions ?

Tout d’abord cela aurait facilité la séparation entre les données et les logiques.

Le premier gain aurait été une meilleure lisibilité du paramétrage. Les bases de données sont faites pour stocker et retrouver des données, les bases de règles sont faites pour stocker et retrouver des règles. Quand on essaie d’utiliser une base de données pour stocker de la logique cela oblige à certaines circonvolutions qui rendent cette logique incompréhensible sauf pour la personne qui a créé ces circonvolutions et encore…

Cette séparation permet de simplifier la base de données en limitant le nombre de tables et le nombre de colonnes. Cela n’a l’air de rien mais quand la base de données devient un fourre-tout qui mélange logique et données, données de référence et données opérationnelles et qui multiplient les relations peu utiles la base de données devient vite lourde à gérer. Donc, deuxième gain une base relationnelle simplifiée plus facile à gérer et à partager.

Troisième gain, un peu plus difficile à comprendre et à admettre, la séparation logique et données permet de mieux gérer les exceptions. Je m’explique, il est  plus sûr de rajouter une règle que de rajouter une colonne dans une table relationnelle. Quand vous ajouter une colonne dans une table vous devez détecter et inspecter l’ensemble des requêtes qui utilisent cette table pour être sûr des conséquences de votre acte. Quand vous ajouter une règle vous pouvez lui adjoindre toutes les conditions utiles pour restreindre sa portée d’utilisation. Plus vous ajoutez de conditions plus vous diminuez le risque que cette règle soit exploitée à mauvais escient.

Le quatrième gain est une meilleure séparation des responsabilités, les personnes chargées des données s'occupent des données et les personnes chargées des logiques de décisions s'occupent des logiques décisions. Dès que le logiciel est un peu complexe ou un peu appelé à durer ou nécessite un niveau honnête de fiabilité, cette séparation des responsabilités prend tout son sens.

Pour résumé et en règle générale, mieux vaut séparer données et logiques. Si vous vous rappelez Edsger W.Djikstra et les principes de la programmation structurée cela vous dit sûrement quelque chose. Après, reste à traiter la question de comment cette logique aurait du être codée, cette question feraitr l’objet d’un autre billet.

The trick is knowing.......

Je ne résiste pas à le tentation de soumettre à vos réflexions cette citation de Ken Orr  (Cf. photo) :

There are some things that computers  do better than people and some things that people do better than computers : the trick is knowing which is which. Given the right set  of consistent business rules, computers can come up with the same answer time after time, and do so not in months or years (or sometimes decades), but in microseconds. Clearly one of the reasons that computer systems have become so important in advanced organizations elsewhere is this ability to get the right answer instantly. But getting the right answer is only possible if one has a consistent  way to define and develop a simple business rule or a small set of business rules; as the number of rules and decisions grows, the problem gets exponentialyy more difficult.

Débat : qui doit maintenir les règles métiers ?

Hier j'ai participé à un débat intéressant sur les BRMS et leur utilité pour changer la relation MOA-MOE. Il y avait là des DSI de sociétés utilisatrices de BRMS, des éditeurs de BRMS et des SSII qui mettent les BRMS en oeuvre. Nous étions une vingtaine. Les échanges ont été vifs et ont portés en particulier sur la possibilité donnée aux experts métiers, aux experts opérationnels d'éditer des règles métiers alors qu'ils n'ont pas été formé pour. 

Tout le monde dans la salle était d'accord pour dire que la tendance technique permet que les experts métiers soient de plus en plus autonomes. Tout le monde n'est pas forcément d'accord pour dire que c'est une bonne tendance tout en admettant que les frontières entre MOA et MOE sont de plus en plus floues et mouvantes.

Le premier débat a porté sur l'existence de deux familles de règles, appellons-les des règles MOA et des règles MOE. Les règles MOA seraient des règles que les experts métiers doivent maîtriser et les règles MOE des règles que les experts informatiques doivent maîtriser.

Ce point soulignerait un travers naturel, lorsque l'on dispose d'un BRMS on a tendance a mettre une trop grande partie de la logique sous forme de règles que ces règles soient des règles techniques ou des règles métiers. Je ne suis vraiment pas sûr que ce soit une bonne pratique, j'ai tendance à penser qu'il vaut mieux mettre sous une forme déclarative ce qui est de la logique métier et sous une forme impérative ce qui est de la logique technique. Ainsi on isole mieux les parties métiers et les parties techniques, si tant est que cela soit possible et que le contexte s'y prête.

Au fur et à mesure de ce débat, le monde s'est complexifié il est passé d'un monde binaire MOA-MOE  à un monde où les responsabilités sont multiples : il y a dans tout système plusieurs expertises métiers et plusieurs expertises pour interfacer ces bases de règles avec les systèmes existants. 

Fort de ce constat, nous avons plus ou moins unanimement conclu que ce qui comptait c'était bien un partage clair des responsabilités et que ce partage clair soit cohérent avec le découpage informatique.

C'est ce point qu'il convient de clarifier.  Il y a plusieurs expertises métiers, cela signifie soit qu'il y a plusieurs experts qui partagent la même expertise ou cela signifie qu'il y a plusieurs domaines d'expertise. 

Dans le cas où il y a plusieurs domaines d'expertise cela signifie que chaque expert à en charge la maintenance de son paquet de règles. Dans l'autre cas où il y a partage d'expertise cela signifie que chaque expert peut valider le travail d'un autre expert.

Dans le premier cas les droits de modification des règles sont liés à des bases différentes, dans l'autre cas les droits de modification concernent le même type de base.

Si le découpage technique n'est pas cohérent avec le découpage organisationnel, le risque est que chacun puisse changer n'importe quelle règle n'importe quand, là est le début de la fin ! 

Dependency and duplication

Steve Freeman pointed out that the problem with the test and code as it sits is not duplication. The problem is the dependency between the code and the test - you can't change one without changing the other. Our goal is to be able to write another test that "makes sense" to us, without having to change the code, something that is not possible with the current implementation.
Dependency is the key problem in software development at all scales. If you have details of vendor's implementation of SQL scattered throughout the the code and you decide to change to another vendor, then you will discover that your code is dependent on the database vendor. You can't change the database without changing the code.
If dependency is the problem, duplication is the sympton. Duplication most often takes the form of duplicate logic - the same expression appearing in multiple places in the code. Objects are excellent for abstracting away the duplication of logic.
Unlike most problem in life,where eliminating the symptons only makes the problem pops up elsewhere in worse form, eliminating the duplication in programs eliminates dependency. That's
why the second rule appears in TDD. By eliminating duplication before we go on to the next test, we maximize our chance of being able to get the next test running with one and only one change.


Kent Beck - 2004

Drools 5.1 and Eclipse 3.6 Installation

Here is how I have installed Drools 5.1 and Eclipse 3.6.

It’s just like it is described in the drools documentation.

There are few differences :

• Zip file names to download are given
• At each step a test is given in order to check how things are going
• Only one way of installation is given in order to simplify the installation process

1. Java
1. check java -version (java 1.5 is required)
2. Drools documentation

1. go to jboss.org/drools/downloads.html
2. download drools documentation (50.8MB)
3. read chapter 3 from drools introduction
1. Eclipse modeling tools 3.6 (Helios)
1. go to www.eclipse.org/downloads/
2. download and extract eclipse modeling tools (249 MB)
3. run eclipse
4. check if you can find GEF 3.4 or greater
5. exit eclipse
2. Drools 3.5 Eclipse Workbench
1. go to jboss.org/drools/downloads.html
2. download Drools 3.5 Eclipse Workbench
3. unzip this file in eclipse directory
4. run eclipse
5. it’s ok if you can open the drools perspectice
3. Download Drools binaries 5.1
1. go to jboss.org/drools/downloads.html
2. download and extract the binaries
3. run eclipse
4. click windows/preferences/drools/drools runtime and enter the path where the downloaded file has been extracted
5. click files/new/drools project
6. enter a project  name
7. click next and choose to add a  hello word test sample and to add a sample java class to load and run the hello world
8. check : compile and run this project  as a java application

Glossaire versus ontologie

Il est naturel de chercher à écrire des règles métiers qui soient faciles à lire et à comprendre à la fois par des dirigeants, des experts métiers et des informaticiens.

Pour que ces règles soient facile à lire et à comprendre, il est au moins nécessaire d’utiliser des termes et une syntaxe bien connus de l’ensemble de ces trois catégories de lecteurs.

Il ne suffit d’ailleurs pas que ces termes soient connus par tous mais il faut aussi qu’ils évoquent à chacun le même sens, autant éviter quiproquos et autres malentendus, ils sont parfois amusants mais génèrent surtout beaucoup d’inefficacités.

L’outil le plus couramment utilisé pour faire connaître et unifier le sens des termes s’appelle un glossaire. La rédaction d’un glossaire est une tâche difficile à réaliser, en tous cas souvent plus difficile que l’on ne se l’imagine. Seul ou à deux tout va à peu près bien, mais dès que le nombre de participants à l’élaboration de ces définitions augmentent, les discussions sans grand intérêt s’éternisent et se multiplient. Le groupe finit presque toujours par s’entendre, chacun peut sortir la tête haute, mais souvent au prix de définitions ambiguës et peu expressives.

L’utilisation d’ontologies est un bon moyen pour aboutir efficacement à des définitions qui parlent, c’est-à-dire plutôt que de rechercher à directement définir des termes, il s’agit d’identifier les concepts structurants, puis à les relier avec des relations explicites. Ces relations étant d’ordre sémantique ou taxinomique.

En pratique, cela consiste à établir un graphe orienté. Les noeuds du graphe sont les concepts et les flèches les relations. Une relation “exemple-de” peut clarifier facilement un concept. Ou autre exemple, les concepts peuvent être des classes ou des objets, les relations peuvent être des relations d’héritage ou d’instanciation, ces instances peuvent être des exemples servant à clarifier le sens de la classe.

Ce type de graphe, s’avère à la fois plus facile à faire valider par le plus grand nombre et plus pédagogique qu’un glossaire.

En effet, un terme est plus facile à expliquer lorsqu’il est plongé dans un contexte clair.
La proximité géographique des concepts les uns avec les autres est un excellent moyen pour exprimer du sens.
Elle permet d’ailleurs de différencier des homonymes sans nécessiter de longues explications.
Ces diagrammes permettent d’exprimer plus de sens avec moins de mots.

A l’inverse lorsque le contexte d’utilisation d’un terme n’est pas connu, chacun plonge ce terme dans le contexte qui lui est le plus naturel, contexte qui n’a que peu de chance d’être compatible avec celui pour lequel la définition a été conçue. Ce non-partage de contexte engendre souvent incompréhensions et quiproquos.

Il faut bien noter que ce type de graphe ne remplace pas un glossaire quand des définitions précises sont nécessaires mais il en facilite grandement la réalisation.

En résumé : plutôt que de se lancer directement dans la rédaction d’un glossaire mieux vaut d’abord passer par la réalisation d’une ontologie. C’est une manière simple et efficace pour donner du sens aux termes et le partager avec d’autres. Quand c’est nécessaire, elle peut être complétée par un glossaire.