La notion de modèle conceptuel

1.5.1.1 Des représentations en amont de la formalisation

La notion de modèle conceptuel a été utilisée en ingénierie des connaissances un peu avant 1990. Elle a succédé à des notions plus intuitives, qui répondaient à une vue du problème comme relevant de l’extraction de connaissances.

La première notion est celle de « mediating representation » (que l’on pourrait traduire par « représentation support » ou « intermédiaire ») utilisée vers 1989 pour désigner une forme intermédiaire matérialisant les connaissances recueillies auprès d’un expert (Gaines, 1980). Cette représentation devait favoriser les échanges, le dialogue avec les experts et l’expression de nouvelles connaissances. Elle précédait leur formalisation sous forme de règles dans une base de connaissances. Un exemple de « mediating representation » est la visualisation des classements effectués à l’aide de techniques, le plus souvent issues de la psychologie, comme les grilles répertoires (Boose, 1988) (Gaines & Shaw, 1989) ou le tri de cartes (Shadbolt, 1988).

Deux autres notions sont celles de « modèle de tâche » telle qu’elle est proposée par Chandrasekaran (Chandrasekaran, 1986) ou de « méthode de résolution de problème » utilisée par Clancey pour caractériser Mycin (1986) et que l’on retrouve dans les systèmes développés par l’équipe de Mc Dermott au MIT : MORE, MOLE ou SALT présentés dans (Marcus, 1988). Ces modèles sont des caractérisations de haut niveau, en terme « de connaissances », des capacités d’inférence du système construit. Ici, leur intérêt est de mettre à plat la manière dont le système va résoudre les problèmes de manière efficace.

Pour ces deux courants, l’opérationnalisation se fait ensuite sous forme de règles. Les modèles ont servi à caractériser la nature de ces règles, à localiser leur intervention au cours des inférences associées à la résolution d’un problème, ou encore à vérifier que toutes les règles requises ont bien été construites.

Dans la méthode KOD (1988), Vogel propose de mettre en place plusieurs modèles à partir d’entretiens d’experts. Le premier, linguistique, reflète un découpage proche de l’expression des connaissances en langage naturel. Le

43

second, le modèle cognitif du système, est à rapprocher de la notion de modèle conceptuel. Il se détache de l’aspect terminologique et linguistique pour organiser les connaissances à un niveau plus abstrait. Enfin, le troisième modèle est une opérationnalisation du précédent, pour laquelle Vogel est le premier à proposer d’adopter le paradigme objet.

Une hypothèse implicite forte est que ces modèles reflètent la manière dont l’expert résout le problème. Ainsi, à partir de cette période et jusqu’aux remises en questions de KADS débouchant sur CommonKADS, une confusion existe sur la nature des méthodes de résolution de problème. Par exemple, dans la bibliothèque de méthodes réutilisables proposées par KADS à partir de 1993, cohabitent des algorithmes de parcours de graphes propres à l’IA, comme hill-climbing ou A*, des méthodes renvoyant à des caractérisations vagues de résolution de problèmes (comme « la classification heuristique » de Clancey) ou encore des méthodes plus proches de la manière des experts de traiter certaines tâches (comme « model-based diagnosis »).

1.5.1.2 Définitions

À partir de 1991, il est clairement posé qu’acquérir des connaissances, c’est construire des modèles conceptuels (Krivine et David, 1991). J’insiste autant sur la définition donnée alors [RIA, 92]⁵ de ces modèles que sur les restrictions associées :

Un modèle est une abstraction qui permet de réduire la complexité en se focalisant sur certains aspects, en fonction de certains buts. MAIS un modèle devrait permettre plus : manipuler les objets et interpréter les résultats de la manipulation.

L’ensemble met en avant la place du modèle comme outil pour l’acquisition et la structuration des connaissances. Pour cela, le modèle doit tenir deux rôles presque orthogonaux. Le modèle doit pouvoir être interprété par un individu. Il doit aussi pouvoir être utilisé dans un système formel pour produire des résultats et être évalué. Toutes les facettes et toute la complexité du statut du modèle conceptuel sont ainsi posées. M. Linster évoque cette tension (Linster, 1992) à partir de son expérience de définition de la méthode et du langage OMOS, en identifiant deux facettes : modèle pour abstraire des connaissances, support au dialogue entre humains versus modèle pour permettre au système de raisonner, opérationnel et calculable. Le modèle a donc une double sémantique : interprétative à la lecture par des humains et formelle, pour une interprétation informatique.

Cette dichotomie reste tout à fait d’actualité bien que la nature des applications visée aujourd’hui se soit diversifiée. En effet, les interprétations formelles envisagées dans ces définitions peuvent correspondre à la résolution de problème, sens le plus communément entendu en 1992, mais aussi à d’autres types de traitement (classification, navigation, etc. ). Les modèles peuvent donc être utilisés plus largement pour ces autres types d’applications.

Ensuite, le modèle doit toujours être interprété par des humains : après la phase de construction, le modèle peut être désormais rendu lisible directement dans des applications d’aide à la navigation dans des documents ou dans la mise en œuvre de tâches.

5 Cette référence, et toutes celles de la forme [.., XX] citées dans ce chapitre, sont indiquées en fin de chapitre 4.

Des définitions plus orientées vers l’ingénierie et la gestion des connaissances ont été proposées par la suite. Je retiendrai la définition proposée dans le projet CommonKADS, qui tient lieu désormais de référence en la matière. “The results of knowledge analysis are documented in the

"knowledge model". It contains a specification of the information and knowledge structures and functions involved in a knowledge-intensive task.”

Les auteurs soulignent son double rôle pour la gestion du processus de modélisation et pour faciliter le développement du système. Ils insistent également sur la parenté de cette démarche avec celle du génie logiciel, l’ingénierie des connaissances s’intéressant à des logiciels particuliers, faisant appel essentiellement à des connaissances et soulevant donc des difficultés spécifiques. Le modèle de connaissances n’est alors qu’une des aides proposées parmi d’autres, au sein d’une démarche de gestion de projet qui définit un cycle de vie comparable à celui des logiciels classiques. Sont également explicités au niveau conceptuel (en s’affranchissant dans un premier temps des contraintes liées à la programmation) le contrôle sur les tâches à réaliser, la communication homme-système ainsi que le contexte organisationnel au sein duquel le couple système-utilisateur va réaliser la tâche.

Finalement, ces définitions convergent aujourd’hui, et tendent à fixer la nature des connaissances que couvre le modèle. Ainsi, je retiens la définition suivante de B. Bachimont :

Un modèle conceptuel d’IC exprime les connaissances d’un domaine relatives à une tâche dans un langage de modélisation … Une fois rendu opérationnel dans un système, il constitue un outil pour agir sur le monde, qui doit être pertinent en usage (Bachimont, 2004).

L’usage auquel il est fait référence ici est celui du modèle au sein du système opérationnel qui va assister l’utilisateur final. Or un autre usage à prendre en compte est celui du modèle pendant la phase de sa mise au point, comme support à la structuration. Il tient leu de « brouillon » pour tester, imaginer l’impact de différentes organisations des connaissances. Il aide aussi à repérer des connaissances manquantes à recueillir, à rechercher ou à faire expliciter, ou comme une métrique qui mesure la couverture de ce qui a été modélisé par rapport au rôle du système final. Le modèle conceptuel est donc tout d’abord un instrument du processus d’ingénierie des connaissances lui-même avant d’en être un résultat, c’est-à-dire une composante du système à base de connaissances en usage auprès d’utilisateurs.

1.5.1.3 Des modèles cognitifs aux modèles de systèmes

La nature du contenu d’un modèle conceptuel qualifie ce à quoi renvoient les connaissances que le modèle matérialise : connaissances expertes, système informatique, théorie du domaine étudié, ... Il s’agit des éléments de référence qui donnent sa validité, sa valeur de vérité au modèle.

Les premiers modèles sont le fruit d’une démarche visant à restituer les connaissances et modes de raisonnement des experts. Ils correspondent à une modélisation cognitiviste qui fait l’hypothèse que l’intelligence du système pour traiter une classe de problèmes donnée sera d’autant plus grande que ce modèle sera proche des connaissances et processus mis en œuvre par des individus experts. Cette vision est retenue dans les méthodes KOD (Vogel, 1988), dans des systèmes d’enrichissement de base de règles comme TEIRESIAS (Davis, 1979), ou encore à la base de techniques comme les grilles

45

répertoires (système ETS de J. Bradshaw et J. Boose, 1988). Pour que ces modèles aient le statut de modèles cognitifs, les techniques de recueil et d’organisation des connaissances doivent faire appel à l’étude des phénomènes cognitifs humains. Elles sont donc empruntées des techniques, des méthodes, des hypothèses de fonctionnement et de représentations des connaissances en mémoire proposés en psychologie cognitive et en psychologie du travail. Cette vue cognitiviste a correspondu à l’hypothèse de développement des systèmes experts, dont la validité est jugée par comparaison tant aux performances qu’aux modes de raisonnement humain.

Elle continue de prévaloir dans des contextes particuliers de simulation cognitive en vue de modéliser et agencer des situations de travail en ergonomie par exemple, ou encore en vue de transmettre des pratiques ou des modes particuliers de résolution dans des systèmes de formation.

À l’opposé, le modèle conceptuel peut être vu comme une pure construction artificielle. On parle dans la littérature d’approche constructiviste.

Ainsi, construire des modèles à partir de méthodes génériques de résolution de problèmes relève d’une approche constructiviste. Des exemples de méthodes génériques sont les Generic Tasks de Chadrasekaran (1989) ou les Role Limiting Methods de Mc Dermott (1988). Dans les deux cas, la manière dont le système va traiter un problème s’appuie sur des modèles de résolution standardisés, adaptés à une classe de problèmes. Par exemple, la méthode

« cover and differentiate » au sein du système MOLE guide la mise au point de système d’aide au diagnostic. Pour être adapté à une application particulière, chacun des systèmes utilisant une Role Limiting Method (MORE, MOLE, SALT

…) suit le déroulement de la méthode pour interroger un expert, qui fournit les connaissances heuristiques propres au domaine concerné et requises par la méthode choisie. L’intérêt de la réutilisation de cadres génériques a été souligné encore plus fortement avec les méthodes KADS puis CommonKADS.

Or, l’approche constructiviste ne clôt pas le débat sur la distance à prendre avec les modes de raisonnement des individus. L’éventail des réponses possibles est large, et le choix dépend du type d’application. Ce débat rejaillit sur la manière de construire ces modèles, et la part de la réutilisation de modèles génériques. Le changement de point de vue entre les méthodes KADS et CommonKADS à ce sujet reflète les limites de propositions méthodologiques s’appuyant sur des modèles génériques relativement figés, et pas toujours bien identifiés. Ainsi, KADS suggérait de décrire l’organisation des tâches réalisées par le système à concevoir ainsi que la méthode de résolution de problème en reprenant des parties entières de modèles génériques. Ceci sous-entend que le modèle au sein du système peut être arbitrairement défini du moment qu’il est efficace. Or les applications de KADS ont souligné l’impact fondamental du modèle choisi et de son adaptation au contexte de l’application pour parvenir à un système utilisé. La méthode CommonKADS s’est donc enrichie d’indications précises, sous forme de questions et de critères, pour choisir puis adapter des modèles prédéfinis. Le modèle conceptuel est bien construit non pas pour rendre compte des processus de raisonnement d’experts, mais pour s’intégrer efficacement dans (et donc être adapté à) la pratique d’utilisateurs effectuant une tâche.

Actuellement, les modèles construits tirent leur légitimité de l’adéquation du système, ou même du couple système-utilisateur, à la tâche prévue. Ce sont les fonctionnalités du futur système, les problèmes à résoudre ou les tâches à traiter avec ce système qui déterminent le contenu du modèle. Ainsi, les modes de résolution de problème implémentés peuvent être relativement

éloignés des pratiques des experts, ou encore le domaine peut être décrit de manière optimale par rapport à cette résolution, et non comme se le représentent des individus.

De ce fait, la distance entre les méthodes adoptées par l’utilisateur et celles qui sont implémentées dans le système n’est jamais grande pour deux raisons. Premièrement, le modèle sert de repère, de grille pour interroger les pratiques ou les savoirs dont il sera le support, et à ce titre, le cogniticien se doit d’argumenter et justifier les choix qui conduisent à faire traiter certaines tâches selon des méthodes différentes de celles des individus. Deuxièmement, en phase d’utilisation, le système doit interagir avec ses utilisateurs, et donc être acceptable. Certains traitements peuvent être effectués de manière transparente à l’utilisateur, et donc éloignée des pratiques. En revanche, le niveau de résolution perceptible par l’utilisateur et le faisant intervenir doit être acceptable et adapté. Finalement, même si seul le comportement du modèle opérationnel, ou même du système utilisant le modèle, sert à juger sa validité, cette évaluation suppose également l’acceptabilité du système par ses utilisateurs, et ne permet pas de plaquer des méthodes de résolution choisies uniquement pour des raisons de performance qui ne seraient pas compatibles avec les usages.

1.5.1.4 Des modèles formels à des modèles pragmatiques

On peut se demander alors quelle est la part d’arbitraire dans la manière de fixer le contenu de tels modèles, et ce qui va finalement leur donner une validité. Là encore, des courants différents privilégient soit une validation opératoire ou formelle (vue formaliste), soit la fidélité au système de connaissances tel que la langue l’exprime (vue normalisatrice), soit encore des aspects pragmatiques liés à l’acceptabilité par les utilisateurs (vue pragmatique). Ces divergences de vue se retrouvent actuellement dans les travaux sur les ontologies mais aussi sur les modèles de tâches.

Ainsi, les ontologies peuvent, pour certains chercheurs, tenir lieu de théorie formelle d’un domaine ou des connaissances en général. Il s’agit par exemple des travaux sur les ontologies formelles inspirés de la philosophie comme ceux de (Guarino et Welty, 2002). Cette option est aussi implicitement retenue pour argumenter la définition d’ontologies réutilisables et partagées dans de nombreuses recherches, en particulier dans la perspective du web sémantique (Gómez-Pérez et al., 2004).

L’autre point de vue est de tradition linguistique. Il pose le modèle conceptuel comme rendant compte d’un système linguistique supposé stable, partagé et pouvant être explicité au travers de définitions et de relations sémantiques. Cette hypothèse est à l’origine de structures de données lexicales ou terminologiques (comme WordNet ou MicroCosmos) qui comportent un noyau conceptuel unique pour rendre compte du sens de mots dans une ou plusieurs langues, ce noyau étant bâti sur une étude fine de la langue générale.

Enfin, le dernier type de modèles conceptuels, évoqué dans la partie précédente, décrit des connaissances telles qu’elles sont utiles à la réalisation d’une tâche et validées par la pratique. Ces modèles peuvent s’appuyer sur les pratiques des individus, leurs savoirs explicités dans des formations ou sur des documents contenant des traces de ces pratiques. Mais ils peuvent aussi être enrichis de nouvelles connaissances, adaptés en fonction des contextes, plus

47

ou moins fidèles à ces pratiques en fonction du rôle du système final auprès des utilisateurs.

1.5.1.5 Rôles d’un modèle conceptuel

Le type de contenu d’un modèle lui confère un statut particulier, qui induit un mode de construction et de validation propre. Prendre l’un de ces partis cache un ensemble d’implications et de présupposés qui, d’une part, sont parfois discutables, et d’autre part, expliquent de nombreuses hypothèses sur la construction, l’utilisation ou la réutilisation des modèles. Par exemple, des modèles d’un domaine reflétant des connaissances théoriques de spécialistes de ce domaine, dans un objectif normatif de réutilisation et de représentation formelle du monde, justifient des approches privilégiant la réutilisation de connaissances génériques. Je récapitule ici les différents rôles que peut jouer un modèle conceptuel :

1) Langage partagé par les acteurs de la modélisation, en particulier le cogniticien et l'expert. Le modèle sert alors de support à la négociation pour spécifier comment le système va fonctionner, sur la base de quelles connaissances. Les enjeux de la définition d’un langage de modélisation touchent alors à la lisibilité, la présentation explicite et claire du contenu.

L’interprétation étant faite par des individus, l’utilisation d’une terminologie proche de celle des acteurs du domaine est fondamentale. Ce sont eux qui donnent sa validité au modèle à ce niveau, quitte à ce qu’elle soit revue par l’opérationnalisation. Un autre point important selon ce rôle est la capacité de modifier, retoucher, faire évoluer facilement ce modèle, autant que celle de le commenter pour mieux en faciliter la lecture et en justifier la structuration auprès d’autres personnes. La définition du langage CML au sein du projet CommonKADS cherche à privilégier ce rôle.

2) Cadre d'expression des connaissances. Le modèle rassemble en général de manière inédite des connaissances identifiées comme pertinentes pour une pratique, un usage ou la réalisation d’une tâche. Il est le support qui sert à les expliciter et en assure une vérification syntaxique. Il doit donc assurer une expression précise, riche et non ambiguë des connaissances, en s’appuyant sur un langage structuré disposant d’une syntaxe bien définie.

Ainsi dans ASTREE (Tort, 1996), logiciel de modélisation de connaissances du domaine, un langage inspiré des modèles Entité/Association permet de vérifier, par la syntaxe, des propriétés comme l’unicité de définition des concepts ou la présence de relations pour les différencier.

3) Trait d’union entre connaissances mises en oeuvre et connaissances calculables. Le modèle ayant vocation de déboucher sur un système opérationnel, il doit être finalement interprétable par le système informatique, « compréhensible par l'artefact ». Suivant les approches, le passage à un modèle opérationnel peut suivre un continuum où le modèle formel reprend une formalisation logique de chacun des éléments du modèle conceptuel, ou bien correspondre à un changement qualitatif, une traduction des éléments conceptuels en nouvelles primitives opérationnelles. Dans tous les cas, les enjeux portent sur la non-ambiguïté sémantique du langage et sa calculabilité (capacité à produire des raisonnements - classification, déduction, etc. - ou à produire le comportement prévu pour l’application finale en un temps fini). Par exemple, la classification de concepts est souvent un des objectifs qui justifient l’utilisation d'une logique de descriptions. Ou encore, les

opérations possibles sur les graphes justifient une formalisation en graphes conceptuels dans des applications de recherche d’information et d’annotation sémantique par exemple (comme avec le système CORESE (Corby et al., 2002). L’opérationnalisation est aussi un moyen de valider la sémantique du modèle.

4) Langage de méta-niveau permettant de s’adapter à différentes applications.

Ce point de vue concerne plus le langage de modélisation lui-même que les modèles produits à l’aide de ce langage. Il correspond à la volonté d’adapter ou de spécialiser des primitives conceptuelles de haut niveau.

L’objectif est de les agencer dans de nouveaux modèles de manière à répondre à des besoins particuliers en matière de gestion du raisonnement ou des tâches réalisées par le système, ou bien des interactions entre le système et l’utilisateur. Dans cet esprit, les langages ZOLA (Isténès, 1996) et DSTM (Trichet et al., 1997) permettent de redéfinir les structures de tâche et méthode ainsi que la manière de les exploiter pour développer des systèmes dont le contrôle de la résolution de problème possède des propriétés particulières.

En dissociant différentes fonctions d’un modèle, on peut mieux caractériser la nature des structures et des langages permettant de les réaliser.

L’intégration de l’ensemble des points de vue est ensuite un problème de

L’intégration de l’ensemble des points de vue est ensuite un problème de