vers accueil ISSN 1661-1802

| Numéro courant| Présentation| Instructions aux auteurs| Anciens numéros|

Editorial Etudes et Recherches Comptes-rendus d'expériences Evenements Ouvrages parus


Eléments d’architecture pour une mémoire d’entreprise orientée processus métier

Par: Mahmoud Brahimi et Laid Bouzidi

Résumé

Les entreprises disposent d’un capital de connaissances (documents, données, référentiels, messages, …) souvent mal exploité notamment durant l’exécution des processus métiers. A cela, plusieurs raisons peuvent être invoquées : des workflows peu ou pas automatisés, une exploitation très réduite de ces connaissances car seules les données sont principalement utilisées, l’absence d’architecture qui pourraient fédérer ou intégrer tous ces connaissances en vue d’une utilisation efficace. En outre, on constate que ces connaissances sont très peu reliées aux processus métier. De nombreuses tentatives ont vu le jour pour tenter de juguler ce manque de gestion de ce capital, à travers des systèmes de gestion de connaissances, de portails (intranet), ou plus largement par des mémoires d’entreprises. Toutefois de nombreuses préoccupations restent encore en suspens. Quelles sont les connaissances liées à un processus métier ? Quel est l’apport d’une mémoire d’entreprise pour l’exécution des processus métiers ? Comment considérer les liens entre les connaissances ? Quelles architectures génériques est-il possible d’envisager pour la construction des mémoires d’entreprise ? Voilà les questions auxquelles cet article tente de répondre.

Mots-Clés : mémoire d’entreprise, processus métier, connaissances, architecture, documentation.

Abstract

Enterprises have got a huge amount of knowledge (documents, data, emails, …) which is often bad treated particularly when a business process is executed. Several reasons motivate this fact among them: few or no automated workflow, exploitation limited of this knowledge because only data are mainly used, the lack of framework capable to federate or integrate all kind of knowledge for an efficient use. . In addition we observe that knowledge is not really linked with business processes. Several temptations were made in order to reduce this insufficiency of capital management using knowledge management systems, intranet, or more generally corporate memories. However many problems still require new solutions. What is knowledge linked to business process? Which is the contribution of corporate memories in the processes execution? How to considerer the link between knowledge? What are the generic architectures that can be envisaged for corporate memory building? These are the questions that this paper attempts to answer.

Keywords : memory, business process, knowledge, architecture, documentation

I. Introduction :

« La gestion des connaissances désigne la gestion de l’ensemble des savoirs et savoir-faire en action mobilisés par les acteurs de l’entreprise pour lui permettre d’atteindre ses objectifs » (Charlet et al, 1999). Plusieurs étapes ont été identifiées dans un processus de gestion de connaissances : il s’agit de l’explicitation de connaissances tacites repérées comme cruciales pour l’entreprise, du partage du capital des connaissances rendu explicite sous forme de mémoire et de l’appropriation et de l’exploitation d’une partie de ces connaissances par les acteurs de l’entreprise (Nonaka et Takeuchi, 1995). L’architecture décisionnelle autour de laquelle sont bâtis les systèmes d’aide à la décision assure le processus de transformation des données en informations à usage décisionnelle (Lebraty, 2000). Ces informations à usage décisionnel contribuent à l’amélioration des performances des savoir-faire structurés sous forme de processus métiers, et la connaissance contenue dans les ressources utilisées apporte des moyens pour l’amélioration de la prise de décisions. Cette prise de décision est fortement dépendante des informations et des connaissances qui vont servir de support à cette décision et des outils et des méthodes entrant dans l’exécution des processus. En effet, une décision est le fruit de l’utilisation d’un ensemble d’informations et de connaissances interprétées dans un contexte bien précis. Aussi, certaines catégories de processus peuvent faire appel au même ensemble d’outils et de méthodes, dont la mise en œuvre comporte de nombreux paramètres. Elles nécessitent de prendre des décisions sur le choix des outils et des méthodes dont la qualité influera fortement sur celle du processus. L’amélioration du processus va alors reposer principalement sur l’amélioration des décisions dans l’application de ces outils et méthodes. Les acteurs s’appuient pour cela sur des connaissances acquises antérieurement par d’autres et matérialisées sous forme de mémoires d’entreprise.
Pour capitaliser et rendre explicite des connaissances dans une entreprise, des méthodes issues de l’ingénierie des connaissances (tel que MASK, REX, CommonKADS, KOD, etc.) et du travail assisté par ordinateur (tel que QOC, DIPA, etc.) (Dieng-Kuntz et al, 2001) ont été élaborées. Ces méthodes permettent de définir des mémoires d’entreprise. Une mémoire d’entreprise est définie comme la « représentation persistante, explicite, désincarnée, des connaissances et des informations dans une organisation, afin de faciliter leur accès, leur partage et leur réutilisation par les membres adéquats de l’organisation, dans le cadre de leurs tâches ». Particulièrement, une mémoire métier peut être définie comme l’explicitation des connaissances produites dans et pour un métier donné. Les méthodes de capitalisation des connaissances utilisent des techniques d’ingénierie de connaissances pour extraire les connaissances, que ce soit auprès des experts ou à partir des documents, afin de les formaliser avec des modèles conceptuels, où la connaissance (dans notre cas en rapport avec les processus métiers) qui guide la résolution de problèmes est rendue explicite. Par ailleurs, (Nagendra Prasad et Plaza, 1996) définissent la mémoire d’entreprise comme « l’ensemble des données collectives et des ressources de connaissances d’une entreprise ». La gestion des connaissances selon cette approche, peut être vue comme « la gestion d’un réservoir de taille plus au moins importante rassemblant les connaissances de l’entreprise. La taille la plus petite correspondant à une mémoire individuelle, celle d’un expert d’un domaine donné, la taille la plus grande correspondant à la mémoire de l’entreprise et rassemblant à ce titre l’ensemble des connaissances sur l’organisation, les activités, les produits, etc., de l’entreprise.» (Meingan, 2002).
Selon la typologie de la mémoire d’entreprise, celle-ci peut inclure des connaissances sur les produits, les procédés de production, les clients, les stratégies de ventes, les résultats financiers, les plans et buts stratégiques, etc. Elle peut également inclure des bases de données, des documents électroniques, des rapports, des spécifications de produits et de la logique de conception. En effet, il existe une variété de typologies de mémoire d’entreprises : mémoire de projet, mémoire métier, mémoire distribuée, mémoire documentaire, mémoire à base de cas, etc. Les caractéristiques de quelques unes de ces mémoires d’entreprise sont définies dans (Gandon, 2002).
Pour atteindre les objectifs définis par la stratégique globale de l’entreprise, les acteurs disposent d’un capital de connaissances souvent très important matérialisé à travers les documents et les données mais aussi les référentiels, les messages électroniques, etc. (figure 1) mais généralement mal exploité durant l’exécution des processus métiers. A cela, plusieurs raisons peuvent être invoquées : des workflows peu ou pas automatisés, une exploitation très réduite de ces connaissances car seules les données sont principalement utilisées, l’absence d’architecture qui pourraient fédérer ou intégrer toutes ces connaissances en vue d’une utilisation efficace.
Nous proposons dans ce papier de concevoir une architecture de mémoire d’entreprise orientée processus métier permettant de mettre à la disposition des acteurs les fonctionnalités nécessaires à l’intégration de nouvelles connaissances et tenant compte de l’obligation, pour les entreprises, de disposer d’un outil fédérateur capable de s’interfacer avec le système d’information de l’entreprise et d’interroger simultanément et « intelligemment » les ressources de connaissances via une interface d’accès centralisé.

Figure 1. Synoptique général des ressources nécessaires à l’exécution d’un processus métier
Figure 1. Synoptique général des ressources nécessaires à l’exécution d’un processus métier
II. Connaissances liées aux processus

La définition de référence des processus est aujourd’hui celle qui est donnée par la norme ISO9000 :2000. C’est « un ensemble d’activités corrélées ou interactives qui transforme des éléments d’entrée en éléments de sortie ». Cette définition est succincte, ce qui autorise une application très large. On peut donner la définition suivante dans le cadre d’un processus métier : « un processus métier est un ensemble d’activités, entreprises dans un objectif déterminé. La responsabilité d’exécution de tout ou partie des activités par un acteur correspond à un rôle. Le déroulement du processus utilise des ressources et peut être conditionné par des événements, d’origine interne ou externe. L’agencement des activités correspond à la structure du processus ».

Un processus métier organise le travail des acteurs pour répondre à des objectifs définis par la stratégie de l’organisation; l’objectif étant l’expression de la finalité du processus.
L’acteur est une personne physique, une entité organisationnelle ou une machine qui prend une part aux activités du processus. Ainsi, pour S.Alter (Information Systems : A Management perspective, 3eme éd., The Benjamin /Cummings Publishing Company, 1999), un processus est un ensemble coordonné d’activités, visant à produire un résultat pour des clients internes ou externes, et exécuté par des acteurs humains ou automates, utilisant des ressources.
L’activité est un ensemble de travaux correspondant à une unité d’évolution du système. Les activités décrivent comment l’objectif d’un processus pourra être atteint. Pour pouvoir maîtriser le déroulement d’un processus, on s’attache à faire apparaître différents états. On considère que les travaux de l’activité modifient l’état du système processus et permettent le passage d’un état stable à un autre.
L’acteur peut être interne ou externe à l’entreprise, et un processus peut ainsi être exécuté par plusieurs partenaires qui coopèrent. En général, les acteurs interviennent dans le cadre organisé du processus, c'est-à-dire que les activités ont été regroupées pour être confiées à un même acteur.
L’évaluation des processus entre généralement dans le cadre de l’évolution du système d’information de l’entreprise et permet de mesurer l’écart entre l’objectif du processus actuel, tel qu’il est perçu et vécu par les différents acteurs, et l’objectif tel qu’il découle de la stratégie de l’entreprise. L’évaluation peut être structurée en deux niveaux : dans un premier niveau, le processus existant est observé globalement par rapport à son apport au management et au fonctionnement de l’entreprise, ce qui permet entre autre d’estimer l’importance et la pérennité des connaissances mises en œuvre dans le processus existant et des savoir-faire acquis par les acteurs, et dans un deuxième niveau, le processus est analysé en détail et la mise en évidence de problèmes ou de carences prépare des améliorations, voire même des ruptures. C’est ainsi que les indicateurs de performance des processus doivent être améliorés en permanence et impliquent :

  • la réduction du temps de traitement des instances de processus (efficacité) ;
  • l’élimination des tâches ou activités non indispensables (contrôle, support, coordination,…) et la réduction du coût de celles que l’on conserve (efficience) ;
  • l’augmentation de la satisfaction du client en améliorant la qualité des processus (l’élimination des tâches ou activités jugées non indispensables ou n’ajoutant aucune valeur ne doit en aucun cas diminuer la qualité de la relation avec le client) ;
  • pouvoir répondre rapidement à des demandes de travaux inhabituelles en quantité ou en qualité et la possibilité de modifier facilement la structure et les activités du processus (flexibilité).

Cependant, les dispositions d’amélioration peuvent avoir des effets contradictoires. Ainsi, l’augmentation de la flexibilité est souvent coûteuse. Une plus grande efficacité entraîne parfois une rigidité accrue. Une focalisation sur les coûts et l’efficience peut se faire au détriment de la relation client, de l’efficacité et de la flexibilité. L’orientation du choix du vecteur d’amélioration et des actions conduisant à l’évolution du processus nécessite le ciblage sur une catégorie d’objectif considérée comme la plus importante pour l’organisation.
Le métier est l'ensemble des activités qui mobilisent des compétences et savoir-faire. Ces activités sont les unités élémentaires pour la décomposition des processus (les processus métier), et pour l’adaptation continue au changement.

II.1. Description des connaissances

La définition du processus métier telle qu’énoncée plus haut précise que l’exécution d’un processus par les acteurs de l’organisation nécessite le savoir-faire de ces derniers matérialisés sous forme de connaissances tacites ou explicites. Il nécessite aussi l’utilisation des ressources qui se résument en un ensemble de moyens, d’informations et d’outils nécessaires au déroulement des activités du processus. Ces ressources, matérialisées sous forme de documents, données du système d’information, e-mails, messages vidéo, messages audio, etc…, renferment des connaissances et des informations utiles et nécessaires pour l’exécution des processus et qu’il faudra capturer et intégrer dans des mémoires d’entreprise en utilisant les méthodes issues de l’ingénierie des connaissances. Une fois intégrées, ces informations et connaissances sont souvent diffuser via les intranets des entreprises et permettent ainsi d’être des sources importantes pour guider et orienter les acteurs de l’organisation tout au long de l’exécution du processus et améliorent, au fil du temps, les indicateurs de performance de ces derniers (figure 2).

Figure 2. Processus d’acquisition de connaissances et principaux concepts associés
Figure 2. Processus d’acquisition de connaissances et principaux concepts associés
II.2 Réseaux de connaissances et représentation

La perception de ce qu’est ou devrait être une représentation de connaissances s’est nettement affinée au cours des dernières années, voir synthèse dans [Davis 93]. Parmi les formalismes généraux de représentation des connaissances proposés dans la littérature :

  • le formalisme des réseaux sémantiques (Quilian ,1968),
  • le formalisme des frames est attribué à Marvin Minksy (Minsky, 1975),
  • les logiques de description, appelées aussi logiques terminologiques ou logiques de concepts, par exemple : KLONE (Brachman, 1977), logiques de description [Bläsius 89] ;
  • les graphes conceptuels, introduits par J. F. Sowa (Sowa, 1984) et muni d’une définition formelle grâce à des travaux tels que ceux de M. Chein et M-L. Mugnier [Chein 92, Mugnier 96].

Plus récemment, d’autres langages, associés à une syntaxe XML, sont apparus avec l’émergence du web sémantique [Dieng 02] : RDF, RDFS, OWL, XTM…
Il existe des liens entre les différentes sources d’information. Ces liens sont le plus souvent d’ordre sémantique. Par exemple, entre un message électronique d’un client et un référentiel client, il existe un lien permettant de dire que le message a été envoyé par un client enregistré dans le système d’information de l’entreprise dans lequel il est possible de retrouver les coordonnées détaillées du client. Les liens entre les documents et les autres sources de données est un peu plus complexe. Selon le degré de précision souhaité, les liens entre les documents et les autres sources se fera par rapport à des unités de documents les plus fines possibles (il peut s’agir du paragraphe ou de la section dans le cas d’un document de type rapport par exemple). Les liens entre les sources multimédia et les autres sources de données sont des liens qui peuvent permettre de retrouver des composants multimédias à partir d’éléments ou fragments textuels se trouvant dans des sources d’information documentaire ou de données. Ces fragments constituent alors des éléments d’indexation et de recherche. Toute source d’information peut être représentée par un graphe. C’est ainsi que :

  • les données du système d’information peuvent être représentées par des graphes de dépendances fonctionnelles et/ou d’inclusion,
  • les documents ou messages peuvent être représentés par des graphes où les sommets représentent des unités documentaires et les nœuds terminaux des contenus. Les arcs désignent les liens sémantiques ou de structuration entre éléments documentaires,
  • les sources multimédia seront représentées par des graphes dans lesquels les sommets sont des unités d’indexation et les arcs des liens entre ces unités.

L’intérêt d’une représentation en graphe est de pouvoir effectuer le même type de raisonnement sur les différentes sources de données (recherche de chemin, recherche d’éléments, vérification de propriétés, recherche de similarité, etc.) et de pouvoir exprimer les liens entre les sources de manière uniforme. Nous obtenons ainsi un réseau de graphe dans lequel les liens permettent le passage d’un graphe d’une source à un autre graphe d’une autre source. Formellement, soit G1={S1, T1} et G2={S2,T2}, 2 graphes pour 2 sources de données, alors on peut définir un réseau R={Sr, Tr} construit tel que P1(Sr) ⊆ S1 et P2(Sr) ⊆ S2, Pi est une partie de R. Tr est l’ensemble des liens Lr tel que une élément de Lr relie 2 sommets de G1 et G2.

Le réseau de connaissances ainsi construit est alors un support pour les processus métier en vue d’accéder aux informations nécessaires à son exécution. L’accès à un élément d’information appartenant à une source quelconque va entraîner la recherche d’autres informations appartenant à d’autres sources grâce à une navigation dans le réseau de connaissances. Parmi de nombreuses approches de modélisation des connaissances les ontologies sont apparues comme un outil incontestable de modélisation des connaissances du domaine. Rappelons qu'une ontologie est une description des concepts et des relations caractérisant un domaine. Plusieurs ontologies de domaine ont été développées dans différents secteurs d'activité. Ainsi, l'utilisation des ontologies pour la modélisation des connaissances du domaine s'est vue croître ces dernières années notamment dans les domaines suivants: médecine, biologie, environnement, tourisme et domaine juridique. D’un point de vue formel, une ontologie de ramène à une représentation et manipulation de graphes (ou de réseaux).

II.3. Représentation des processus métier

La description des processus métiers peut se faire sous forme de texte et/ou sous forme d’illustrations. Cependant, la communication, est un enjeu important dans les études sur les processus à tous les stades des travaux. Plusieurs acteurs ayant des cultures et des préoccupations différentes sont impliqués dans ces travaux. L’utilisation de formalismes partagés par une communauté d’acteurs facilite la communication, épargne l’effort d’explicitation des termes méthodologiques employés et guide le modélisateur dans la sélection d’éléments clés à faire figurer. Chaque méthode fournit une collection de modèles, de digrammes et une démarche plus ou moins adaptée aux besoins d’un projet particulier. L’application stricte des méthodes a laissé la place à une utilisation plus pragmatique des modèles et diagrammes en fonction des besoins rencontrés. Les acteurs chargés de décrire et d’améliorer un système, ont maintenant une « boite à outil » dans laquelle ils peuvent trouver le formalisme adapté à la réalisation de leur tâche.
Différentes techniques permettent de décrire les processus. Elles sont proposées à travers des ensembles méthodologiques plus larges. Certains ont fait l’objet d’une normalisation telle que IDEFO et UML, d’autres sont le résultat de projets publics et ont reçu un appui officiel telle que OSSAD et MERISE.
Les diagrammes d’activités de UML ou les modèles conceptuels de traitements de MERISE sont des techniques de représentation des processus souvent utilisés. Toutefois, les réseaux de Pétri (RdP) sur lequel ces techniques s’appuient fournissent une représentation plus formelle des processus. Le réseau de Pétri (RdP) est une spécification mathématique qui se base sur des outils graphiques permettant de modéliser et analyser les systèmes discrets, plus particulièrement les systèmes concurrents et parallèles [Petri62]. Le succès des RdP est dû à plusieurs facteurs. Grâce à son rôle d’outil graphique, il est possible de produire une compréhension facile du système modélisé. Il permet également de simuler les activités dynamiques et concurrentes. De plus, son rôle d’outil mathématique permet d’analyser le système modélisé grâce aux modèles de graphes et aux propriétés algébriques (borné, vivacité du réseau, absence de blocage, etc...). Un RdP est un graphe biparti comprenant deux sortes de nœuds : les places et les transitions. Les arcs de ce graphe relient les transitions aux places ou les places aux transitions. Les places contiennent des jetons qui vont de place en place en franchissant les transitions suivant des règles de franchissement [Reisig98].

L’avantage de tels réseaux est de pouvoir effectuer un certain nombre de vérifications qui pourraient mettre en avant des dysfonctionnements des processus tel que les inter-blocages par exemple. Par ailleurs, l’extension des RdP pour préciser les conditions de déclenchement des transitions est possible. En l’occurrence, pour un processus métier, le déclenchement d’une de ses transitions peut être soumis à un déclenchement manuel que réaliserait un acteur lorsqu’il aura pris connaissance des informations nécessaires à l’exécution de la transition. Des expressions logiques peuvent également être attachées aux transitions. Leur évaluation peut être élaborée à partir de l’agrégation d’information multi-sources.

II.4. Connexion processus – connaissances

L’exécution du processus nécessite des informations provenant de sources hétérogènes. Le déclenchement d’une activité est toujours conditionnel. Il nécessite l’arrivée d’évènements, représentée par la production de jetons dans les places, mais doit être validé par l’expert lorsqu’il prend connaissances des informations provenant des sources de données, de documents, de messages, etc. Cette validation est représentée par des liens (arcs du RdP) que l’on peut qualifié d’exogènes, par rapport aux arcs (natifs) du RdP que nous qualifierons d’endogènes. Dans la figure 3, on notera que le processus représenté par une activité (la transition du RdP) nécessite un jeton sur la place en entrée mais également la validation des informations provenant du réseau de connaissances constitué :

Figure 3. Connaissances nécessaires à l’exécution du processus représenté par un RdP. Le processus est décrit par un réseau de Pétri (à 2 places pour simplifier l’illustration). La transition correspond à l’exécution d’une activité. Les flèches en pointillés symbolisent le fait que l’activité a besoin d’information de type données, documentaires, mail, …
Figure 3. Connaissances nécessaires à l’exécution du processus représenté par un RdP. Le processus est décrit par un réseau de Pétri (à 2 places pour simplifier l’illustration). La transition correspond à l’exécution d’une activité. Les flèches en pointillés symbolisent le fait que l’activité a besoin d’information de type données, documentaires, mail, …
III. Proposition d’une architecture d’une mémoire d’entreprise

Cette section consacrée au cœur de notre proposition commence par présenter une étude de cas qui met en évidence la nécessité, pour les entreprises, de disposer d’un outil fédérateur capable d’interroger simultanément et « intelligemment » les sources de connaissances d’une entreprise à travers divers supports que sont les bases de données, les serveurs de messageries, les bases de documents, etc. La proposition d’architecture d’une mémoire d’entreprise orientée processus métier que nous faisons vise à prendre en charge les outils qui permettent d’offrir la « bonne information » aux acteurs des processus.

III.1. Etude de cas

Une société de négoce international en produits agricoles et alimentaires, qui assure deux métiers principaux : le négoce et le courtage Ces deux métiers, aux finalités très différentes, sont effectués par un même intervenant au sein de la société. En effet, dans une même journée, il peut être à la fois courtier et négociant. Cette situation peut aller jusqu'à "convertir" un contrat de courtage en contrat de négoce. La société est donc extrêmement souple au niveau de son activité. La finalité majeure est :

  • Acheter des produits a des fournisseurs dans l'intention de les revendre,
  • Gérer des stocks virtuels; ceux-ci sont présents sous la forme de lots réserves chez les fournisseurs, ou en cours de transfert vers les clients
  • Financer les opérations d'achat et de vente,
  • Assurer la marchandise et les transports,

Nous considérons ici le processus d’affrètement qui consiste à établir les contrats de transport (fixant le prix, la quantité, le point d'enlèvement, le point de destination, la date d'enlèvement, etc,).

Les messages
  • appel client : Il s'agit d'une demande de produit en termes de qualité, quantité et date faite par le client, ou bien une proposition faite par le vendeur à un client dans les mêmes termes.
  • proposition : C'est une proposition ferme faite à un client suite à une demande; le client approuve en effectuant une confirmation de contrat.
Les documents
  • contrat (vente ou achat) : C'est le document qui engage les deux parties d'une manière contractuelle. Il ne concerne qu'un seul produit. On y consigne des informations telles que le produit, la quantité, la qualité, la marque, le prix, le mode de conditionnement, le mode de paiement, la date d'exécution, le lieu de livraison, les clauses particulières.
  • avis de réception : Cet avis confirme le transfert de propriété; le produit livré correspond bien aux attentes du client et aux termes du contrat. Le client est désormais propriétaire de la marchandise livrée.
  • contrat de transport : document contractuel qui engage la société et un transporteur. On y consigne des informations telles que le produit, la quantité, le mode de conditionnement, le prix, les dates d'enlèvement et de livraison, les points d'enlèvement et de livraison, les points de dédouanement. Plusieurs transporteurs pouvant intervenir pour une même livraison (terre, mer, air).
  • ordre de transport : C'est la demande de confirmation de l'exécution d'un contrat de transport. Cet ordre est généralement accompagné de la demande d'identification transport afin de retransmettre cet identificateur au fournisseur et aux transitaires en douane.
  • avis d'expédition : C'est un message avisant le fournisseur de l'enlèvement d'une certaine quantité de produit établie lors d'un contrat d'achat. Ce message indique la date d'enlèvement, l'identificateur du transporteur et le moyen de transport.
  • bon d'enlèvement : C'est un document remis au fournisseur par le transporteur lorsqu'il se présente au point d'enlèvement. (idem pour les enlèvements intermédiaires)
  • facture proforma : C'est une facture donnée à titre indicatif afin d'identifier une transaction qui s'est effectuée entre ALIX et un client; celle-ci est surtout utile aux transitaires afin de répertorier le passage en douane.
  • documents douaniers: Ce sont les documents de dédouanement établis par les transitaires, indiquant la nature du passage en douane en termes de produits, quantité, valeur monétaire. Ces documents sont visés par le service des douanes et ils attestent du passage conformément au règlement des douanes.
  • certificats vétérinaires : Ce sont des certificats visés par des organismes agréés attestant de la conformité du produit par rapport aux normes européennes et internationales en terme qualitatif et sanitaire.
  • bon de livraison : C'est la confirmation vis-à-vis d'un client de la livraison d'une certaine quantité de produit à une certaine date. Cette livraison est en rapport avec un contrat de vente. Il est également mentionné l'identificateur du transport. Ce bon est en général apporté au client par le transporteur.
Les données Cette société s’appuie sur le modèle de données suivant (figure 4), illustré par son modèle logique, pour gérer les données de gestion et les données métiers.
Figure 4. Modèle logique de données pour une entreprise de négoce internationale
Figure 4. Modèle logique de données pour une entreprise de négoce internationale

Le processus de gestion de l’affrètement est illustré au travers un enchainement d’activités. On notera que ces activités nécessitent données et documents pour être exécutées le plus efficacement possible, ce qui implique une structuration robuste des informations nécessaires, une gestion rigoureuse et une répartition des responsabilités de mise à jour. A titre d’exemple, pour négocier des contrats de transports, outre l’intérêt de connaitre les données sur les transporteurs, les livraisons, les clients et fournisseurs, il est utile de connaître les règlements, les conventions et avoir accès aux informations juridiques nécessaires à une bonne négociation. Aussi, lors de l’exécution de l’activité « choix/appel transporteur/négociation » (figure 5) qui permet, entre autre, de choisir le transporteur pour la négociation, l’acteur de l’entreprise doit-il disposer des moyens lui permettant de consulter toutes les ressources d’information de son entreprise pour rechercher touts documents, informations ou autres types de données provenant de ces transporteurs les rendants indisponibles pour le transport. Ce contrôle peut augmenter la durée du cycle de vie du processus mais garantira la qualité du résultat de ce dernier et améliorera son efficacité. Nous nous appuyons sur l’hypothèse qu’il est préférable de ralentir un processus pour garantir la qualité des résultats produits. L’accès se fait, généralement, par le biais d’une multitude d’outils. L’absence d’un moteur de recherche permettant l’interrogation simultanée des sources d’informations (serveur GED, serveur mail, serveur multimédias, serveur de données, etc.) amène l’acteur de l’entreprise à interroger plusieurs outils (tous les serveurs de l’entreprise) séparément avant de réunir les informations répondant à la même requête, à savoir « y a-t-il eu des informations, non encore prises en compte par le système, qui peuvent modifier la liste-transport après son établissement par l’activité précédente? ». Du point de vue des acteurs de l’entreprise, pour des raisons de gain de temps et d’amélioration de l’efficacité des processus, il serait souhaitable de n’avoir qu’une seule interface permettant d’interroger plusieurs sources d’information et de disposer, ainsi, d’un outil fédérateur capable d’interroger simultanément toutes les sources de connaissances. Cet outil fédérateur met à la disposition de l’acteur de l’entreprise des documents et des données qui lui permettent de distinguer les documents et données utiles en fonction du contexte. Ce dernier pouvant être défini par rapport au client, fournisseur et transporteur. En effet, l’acteur peut mener des négociations différentes selon qu’il s’agit d’un transporteur aérien ou routier, d’un fournisseur de denrées biologiques ou de produits carnés, ou encore d’un client local et un client international. Les différences d’appréciations relèvent des contrats qui sont le plus souvent individualisés. La sous-section III-3 répond à ces questionnements en proposant une architecture de mémoire d’entreprise orientée processus métier et s’appuyant sur une approche hybride basée sur l’ingénierie des connaissances, l’ingénierie documentaire et la médiation sémantique et exploitant le référentiel processus comme ontologie de domaine.

Figure 5. Processus illustrant de l’affrètement pour une société de négoce. Les activités sont symbolisées par des ovales
Figure 5. Processus illustrant de l’affrètement pour une société de négoce. Les activités sont symbolisées par des ovales
III-2. Architecture générale pour une mémoire d’entreprise orientée-métier

Causannel (Caussanel, 1999) distingue au travers des différents travaux qui ont été réalisés dans le domaine de la gestion des connaissances, l’approche orientée information de l’approche orientée connaissances. Selon l’auteur, l’approche orientée information pour la gestion des connaissances se concentre sur l’amélioration de la gestion et de l’échange d’informations en essayant d’éviter les frontières organisationnelles ou professionnelles. Elle se fonde sur l’élaboration d’outils informatiques facilitant le travail coopératif et la communication entre les différents collaborateurs de l’entreprise (ex : outils de groupware). Elle permet également l’échange de connaissances explicites au moyen d’outils de type workflow ou gestion documentaire. L’approche orientée connaissances, très liée aux recherches effectuées en Ingénierie des Connaissances, se base sur une étape de capitalisation qui consiste à recenser puis à modéliser les connaissances (Abecker, 1998). Les connaissances sont alors modélisées (i.e. représentées sous forme d’informations) tout en intégrant une sémantique et un contexte pour former une Base de Connaissances. L’élaboration d’un tel système correspond à une phase de capitalisation d’un sous-ensemble ou de l’ensemble des connaissances de l’organisation.

C’est dans la première approche que s’inscrit notre contribution. Pour tenter une définition de la mémoire d’entreprise sur le plan technique, nous dirons qu’une mémoire d’entreprise est l’ensemble des outils permettant de rechercher et d’exploiter l’ensemble des ressources de l’organisation ou de l’entreprise en vue de reproduire des savoir-faire, de rendre efficace des processus, et de capitaliser les connaissances. Pour concevoir une telle mémoire d’entreprise, il est important d’en définir une architecture. Celle que nous proposons ici vise à fournir l’infrastructure modulaire nécessaire à l’élaboration d’un système de gestion des connaissances qui s’interface avec le SIE tout en s’appuyant sur les techniques du Web sémantique et les standards des technologies de l’information et de la communication. Au sein de cette architecture (figure 6), trois niveaux sont distingués :

  • le niveau exploration de la mémoire d’entreprise qui fournit des services directement destinés aux différentes catégories d’utilisateurs de la mémoire en s’appuyant sur l’infrastructure de gestion ;
  • le niveau gestion de la mémoire d’entreprise qui est doté d’un ensemble de modules et de composants qui fournissent les fonctionnalités élémentaires de la gestion de la mémoire d’entreprise ;
  • le niveau sources d’information de l’entreprise au sein duquel sont localisées les ressources de connaissances.

Cette architecture permet de mettre en œuvre un processus d’intégration (voir section IV) qui vise à aider un acteur d’une entreprise dans la recherche d’informations utiles à l’exécution des processus métier. Cette architecture nous permet donc d’envisager un mémoire d’entreprise orientée processus métier car elle peut être sollicitée à chaque exécution d’une activité qui nécessite des données complexes provenant de sources hétérogènes.

Figure 6. Architecture technique générale pour une mémoire d’entreprise orientée-métier
A noter qu’un wrapper est un traducteur qui, dédié à une base de données en particulier, traduit les informations venant du médiateur en un langage compréhensible par les bases de données à laquelle il est attaché, et inversement. Un médiateur quant à lui est chargé d'interroger une ou plusieurs bases de données et est donc relié à un ou plusieurs wrappers
Figure 6. Architecture technique générale pour une mémoire d’entreprise orientée-métier A noter qu’un wrapper est un traducteur qui, dédié à une base de données en particulier, traduit les informations venant du médiateur en un langage compréhensible par les bases de données à laquelle il est attaché, et inversement. Un médiateur quant à lui est chargé d'interroger une ou plusieurs bases de données et est donc relié à un ou plusieurs wrappers
III.2.1. La couche exploration

L’exploration de la mémoire d’entreprise comprend un nombre de services permettant à des acteurs différents de l’entreprise d’accéder à des informations pour optimiser les processus qu’ils exécutent. Les services offerts par la couche exploration doivent donc être tournés vers les acteurs. Ils permettent la gestion des profiles, des contextes et des interfaces. On peut y trouver des fonctions d’adaptation des interfaces aux contenus selon qu’il s’agisse de pocket PC, de téléphone portable, etc. La gestion des profils permet de prendre en compte l’organisation des responsabilités des acteurs au sein de l’entreprise. En effet la mémoire d’entreprise doit s’adapter à l’acteur. Par exemple, un décideur a besoin de connaissances synthétiques, un acteur lambda a besoin de connaissances opérationnelles. La gestion du profil s’appuie sur la description, le plus souvent hiérarchique des acteurs. La mémoire d’entreprise doit également prendre en compte le contexte qui peut se déterminer par rapport à un ensemble de tâches effectuées par l’acteur. Le contexte se définit alors par la trace d’exploitation de la mémoire d’entreprise dans un intervalle de temps. La combinaison du profil des acteurs et des contextes d’utilisation permet d’affiner les attentes des acteurs et de rendre pertinent les processus de recherche de l’information. Faciliter la mise en contexte de l’information est également un objectif de la couche d’exploration car une information est d’autant plus vite assimilée qu’elle est présentée dans un contexte proche de celui que l’acteur connaît bien.

III.2.2. La couche gestion de la mémoire

La couche de gestion de connaissances réutilisables est chargée de mettre à la disposition des utilisateurs, en particulier les experts du domaine, des fonctionnalités nécessaires à l’intégration de nouvelles connaissances dans le système. Grâce à ces fonctionnalités l’expert doit pouvoir saisir les connaissances implicites selon le formalisme du référentiel des processus préalablement prédéfini et transformer ainsi les savoir-faire en une matière utilisable. Cela passe souvent par la mise en œuvre d’ontologies de processus métier. Une solution pratique est ensuite de générer les éléments de connaissances introduits par l’expert, en documents XML selon des structures prédéfinies par les DTDs ou de schéma XML par exemple. Les principales fonctionnalités des modules de modélisation, de gestion, et de simulation des processus concernent :

  • l’intégration et la validation des connaissances sous forme de ressources documentaires générées en format XML ;
  • l’association de métadonnées aux ressources documentaires;
  • l’enregistrement et la pérennité des connaissances nouvellement intégrées dans le serveur ;
  • la recherche des ressources documentaires selon des métadonnées.

L'indexation étant l'étape préparatoire pour la recherche dans la mémoire d’entreprise, le module d’indexation se connecte systématiquement à la base de connaissance via le module de traitement de requêtes. Le module de traitement des requêtes (médiateur) est responsable de fournir les résultats pertinents aux requêtes des utilisateurs de la mémoire d’entreprise. Il est chargé d’analyser et de traiter les requêtes exprimées par l’utilisateur afin de construire des requêtes précises. Ces traitements reposent sur la base de connaissances, où le module permet l’interrogation du schéma de l’ontologie à la fois pour l’explorer et pour s’assurer de sa cohérence. L’interrogation de l’ontologie se caractérise donc par deux aspects importants :

  • la possibilité d’interroger ou explorer le schéma aussi bien que le contenu de l’ontologie, et ;
  • le raisonnement sur les concepts et les instances de l’ontologie.
III.2.3. La couche source d’information

Le principe de l'architecture du système à mettre en place consiste à autoriser un accès centralisé et structuré à des sources d’information multiples et hétérogènes. Une des approches les plus usuelles est d’utiliser la notion de « médiateur ». Dans cette approche, les données restent stockées et réparties au niveau des sources d’information, ce qui est fort intéressant dans le cadre de la mise en place de mémoires d’entreprise autour d’un existant. Le médiateur joue alors le rôle d’interface entre l’utilisateur et les sources d’information en lui donnant l’impression qu’il interroge un système centralisé et homogène. Les programmes à écrire doivent pouvoir permettre :

  • L’extraction des données et informations des bases sources (selon les requêtes prédéfinies) ;
  • La comparaison de ces informations avec les requêtes des acteurs (matching) ;
  • La conversion de ces information sous forme exploitable (documents xml ou html) ;

Lorsque l'on doit interroger différentes bases de données, plusieurs problèmes sont à prendre en compte dont les suivants :

  • la disparité des types de données
  • la différence entre les langages d’interrogation des divers systèmes
  • l’hétérogénéité des schémas de données.

Lorsqu'un utilisateur émet une requête vers une interface centrale, cette interface doit déterminer vers quelle(s) source(s) envoyer la requête, et doit aussi être capable de modifier la requête si nécessaire avant de l'envoyer à une source. Cette requête doit arriver au système gérant la source de données dans un langage compréhensible par ce système. Pour réaliser l’interprétation aussi bien des requêtes que des résultats, il est nécessaire de disposer d’un système capable de réaliser ces deux fonctions. On parle alors de « médiateur ». Un médiateur peut donc "dialoguer" avec plusieurs wrappers (qui, de plus, peuvent aussi être interrogé par différents médiateurs). Un wrapper sera en revanche dédié à une seule source de données.
Le rôle du médiateur est donc "d'aiguiller" la requête vers la bonne base de données. Ensuite, un wrapper va être chargé de traduire la requête dans le langage compréhensible par le système gérant la base de données en question. Le wrapper récupère ensuite la réponse du système et la renvoie au médiateur après l'avoir traduite dans le langage compréhensible par le médiateur. Les wrappers ont également pour rôle de transformer les sources de données de « la couche source de données » en documents XML pour faciliter la fusion des résultats. On a ainsi les transformations suivantes :

  • système GED -> document XML GED
  • serveur mail -> document XML mail
  • référentiel données -> document XML référentiel données
  • données de gestion -> document XML données de gestion
III.3. Complémentarité entre l’Ingénierie documentaire et l’Ingénierie des connaissances

La conception et la réalisation d’une telle architecture se doit de combiner différentes approches et techniques. Les dimensions « document » et « connaissance » sont centrales dans une mémoire d’entreprise et nécessite donc aussi bien l’usage de techniques documentaires que de technique de gestion de connaissances. En effet :

  • L’ingénierie documentaire désigne « le projet de recourir à des éléments de structuration du contenu des documents et à des métadonnées de description pour faciliter la gestion des documents à travers tout leur cycle de vie » (Parent et Boulet, 1998). S’agissant des ressources électroniques, ces métadonnées ont pour rôle d’offrir la possibilité d’accéder à des parties d’un document à travers sa structure et de pouvoir y naviguer intelligemment (Le Maitre et al, 2004).
  • L’ingénierie des connaissances correspond, quand à elle, à l’étude des concepts, méthodes et techniques permettant de modéliser et/ou d’acquérir les connaissances. De fait, les méthodes et techniques utilisées dans ce domaine sont utiles notamment pour « construire une mémoire d’entreprise basée sur le recueil et la modélisation explicite des connaissances de certains experts ou spécialistes de l’entreprise. Elle peut aussi servir pour une représentation formelle des connaissances sous-jacentes à un document ». (Dieng et al, 2000). « L’ingénierie des connaissances modélise les connaissances d’un domaine pour les opérationnaliser dans un système destiné à assister une tâche ou le travail intellectuel dans ce domaine (résolution de problème, aide à la décision, consultation documentaire, etc.) » (Bachimont, 2004).

Les techniques de l’ingénierie documentaire qui s’appuient sur des langages de description SGML, XML, RDF, RDFS, etc. offrent un bon niveau dans l’indexation, le stockage et la recherche d’informations. Par exemple, RDF permet d’annoter des documents avec un formalisme permettant de faire référence à des connaissances terminologiques sous formes d’ontologies. De cette manière, une requête de recherche d’information peut faire l’objet de raisonnements élémentaires reposant sur les connaissances modélisées. XML étant amené à jouer le rôle de standard international pour les documents structurés, cela permet d’assurer la pérennité des documents et des informations à long terme, dans le cadre de la mémoire d’entreprise. Cela ménage la possibilité de migrer vers de nouveaux outils de gestion documentaire en conservant le patrimoine d’information.
C’est ainsi que pour atteindre l’objectif visé par cet article et décrit dans l’introduction, le recours à l’ingénierie documentaire nous parait évident et l’avantage de combiner différentes méthodes et techniques issues de l’ingénierie des connaissances et l’ingénierie documentaire est de bénéficier des solutions complémentaires que fournissent ces deux domaines pour la gestion des connaissances ainsi que l’usage des méthodes associées de représentation des connaissances qui incluent le raisonnement et l’inférence.

IV. Processus d’intégration

Dans notre architecture, les couches interagissent entre elles. Le principe repose sur la notion de services ; aussi la couche n s’appuie t-elle les services de la couche n+1. C’est ainsi que la couche exploration sollicite la couche de gestion pour pouvoir répondre aux acteurs sur des besoins de d’interrogation, de recherche, de modélisation, d’indexation, etc. La couche de gestion sollicite la couche de données pour des besoins de restitution de connaissances issues de différents serveurs (données, GED, serveur de mails, …), mais aussi des besoins de stockage et d’accès au données. Sur la figure 6, on note, en guise d’illustration, que la couche exploration peut solliciter la couche de gestion pour assurer toutes les tâches liées à la manipulation des processus (création, stockage dans le référentiel, etc.). La couche exploration peut solliciter la couche de gestion pour interroger la mémoire d’entreprise en termes de connaissances (sur la figure 6, le message correspondant à la requête d’un acteur illustre ce fait). On notera qu’une bonne partie des échanges entre les couches doit se faire à travers l’utilisation de XML pour assurer la pérennité nécessaire à ce type de mémoire. Le principe de fonctionnement et d’articulation des couches, illustré par la figure 7, se fait selon un certain nombre d’étapes qui organise en séquence des processus décrits en section IV.2.

IV.1. Liste des processus d’intégration des sources hétérogènes

Processus de formulation : ce processus est déclenché par un acteur externe. Dans ce processus :

  • l’acteur se positionne comme utilisateur de la « couche exploration » ;
  • l’acteur formule une requête de type : quelles sont les informations nécessaires pour exécuter ma requête et améliorer la performance de mon processus ? ;

Processus de transformation : ce processus se charge de construire des requêtes suite aux exigences de l’acteur. Il se base notamment sur la transformation de demandes des acteurs sous une forme compréhensible par la « couche de gestion ». Il soumet la requête au médiateur.

Processus de médiation : ce processus se déroule selon les étapes suivantes :

  • réception des requêtes par « la couche de gestion » ;
  • le médiateur de « la couche de gestion » contient les schémas de tous les documents XML de « la couche source de données ». Il sollicite les « wrapper » en prenant le soin de transformer la requête qu’il reçoit en autant de services d’exécution des requêtes que de sources de données (service d’exécution des requêtes « mail », service d’exécution des requêtes « GED », service d’exécution des requêtes « référentiels données », service d’exécution des requêtes « données de gestion ») ;

Processus d’extraction : à travers les wrappers, les services d’exécution des requêtes (mails, GED, référentiels données, données de gestion) interrogent respectivement les documents XML correspondants dans la « couche source de données » ; les résultats des interrogations sont stockés respectivement dans :

  • « document résultat XML mails » correspondant au résultat de l’interrogation des documents XML mail de « la couche source de données » ;
  • « document résultat XML GED» correspondant au résultat de l’interrogation des documents XML GED de la « couche source de données » ;
  • « document résultat XML données » correspondant au résultat de l’interrogation des documents XML données de « la couche source de données » ;
  • « document résultat XML données de gestion » correspondant au résultat de l’interrogation des documents XML données de gestion de « la couche source de données ».

Processus de restitution : c’est le processus qui est exécuté en fin de séquence en ordonnant les étapes suivantes :

  • fusion de ces résultats en un seul « document XML résultat » ;
  • application de feuille de style XSL au « document XML résultat » et retour vers l’utilisateur;
  • visualisation du « document XML résultat » par l’utilisateur.
Figure 7. Processus d’intégration qui met en œuvre les grandes fonctions de la mémoire d’entreprise
Figure 7. Processus d’intégration qui met en œuvre les grandes fonctions de la mémoire d’entreprise

Il est à noter qu’une tâche récurrente est exécutée par le système indépendamment des accès explicites des utilisateurs. Cette étape permet d’indexer toute nouvelle source d’information et alimenter la base de connaissances. L’indexation est une tâche cruciale qui nécessite des experts du domaine pour le choix des termes du corpus à indexer. Dans notre solution, le système d’indexation permet en outre d’établir des liens entre sources hétérogènes dans le cadre de processus métier clairement définis en termes d’activités, d’acteurs et de ressources.

IV.2. Illustration : aide à la négociation de contrats

Lors du processus d’affrètement d’une entreprise de négoce international présenté dans la section III.1, un acteur est amené, lors de la négociation de contrats avec des transporteurs, à solliciter des informations pouvant provenir des bases de données et des référentiels, des messageries et du système documentaire. La première source va permettre à l’acteur d’accéder à des informations factuelles des clients, des fournisseurs et des transporteurs telles que ses coordonnées mais aussi leurs chiffres d’affaire. La deuxième source permet à l’acteur d’accéder à une information qui lui fournit des connaissances sur les échanges qu’il a eus avec ces partenaires avant la négociation. La troisième source d’information lui permettra d’avoir une sorte de best-practise sur la gestion de contrats puisqu’il peut avoir accès soit aux derniers contrats qu’il a négociés avec ces partenaires mais aussi des guides de négociation de contrats similaires. Plus précisément, lors de son activité de « choix de transporteur », un acteur du département « Affrètement » déroule un scénario qui s’appuie sur un algorithme visant à choisir le « meilleur » transporteur, en termes de coût, pour assurer des livraisons d’un point à un autre tout en respectant les délais. Pour cela, il contacte chacun des transporteurs d’une liste préalable et négocie avec chacun d’eux. Il s’appuie pour cela sur les informations suivantes :

  • Les clients à livrer : distributeur et grandes surfaces par exemple. Les clients sont décrits par leurs adresses, leur chiffre d’affaire, le domaine d’activité, leur organisation (sièges, magasins).
  • Les fournisseurs des produits classés selon la nature des produits et décrits par des attributs similaires à ceux des clients.
  • Le transporteur est décrit pas ses coordonnées mais également ses moyens de transport tel que aérien, maritime, routier, ferroviaire.
  • Les messages qui ont été envoyés
    • par le service commercial des clients, qui précisaient les points de livraisons, les produits et les quantités ainsi que les livraisons devant être réalisées au niveau des magasins.
    • par le service commercial des fournisseurs pour indiquer les lieux d’enlèvement qui sont des entrepôts,
  • Le guide du contrat de transport sous forme de document word.
  • Les derniers contrats de transport déjà négociés.

Une fois le transporteur sélectionné comme étant celui qui répond le mieux aux critères et contraintes de coûts, de délais et de fiabilité, un contrat de transport est élaboré et signé. Les données sur les clients, fournisseurs et livraisons y sont consignés. Le guide de rédaction des contrats permet à l’acteur de négocier les différentes clauses du contrat.
Une mémoire d’entreprise doit fournir à cet acteur la possibilité d’accéder à tout instant à l’ensemble des informations nécessaires pour réaliser son activité. Notre architecture est conçue de sorte à ce que ce type d’information soit rendu disponible à travers des interfaces appropriées pour faciliter à l’acteur des navigations dans des structures d’information complexes. Les liens entre les informations sont exploités au niveau des interfaces pour permettre à l’acteur une navigation sémantique et passer d’un espace à un autre, par exemple passer d’un espace numérique (qui présentent des données factuelles ou statistiques) à un espace documentaire contenant des hyperliens de navigation dans des sommaires ou des contenus.

Dans un tel scénario, on peut imaginer que l’acteur formule la requête : « retrouvez toute l’information utile pour négocier un contrat de transport avec tels clients et tels fournisseurs ». La mémoire d’entreprise doit permettre de restituer, sous forme lisible, les informations nécessaires. Pour cela, elle s’appuie sur le type d’activité que l’acteur est entrain d’exécuter, en explorant le référentiel des processus métier de la mémoire d’entreprise pour établir les liens entre informations.

La mise en œuvre du mécanisme de fonctionnement de l’architecture que nous proposons pour cet exemple est illustrée par le tableau Tab 1.

Tab 1. Exemple de coordination entre les couches de l’architecture dans le cadre du processus d’intégration.
Processus Objectif/buts Information / Connaissance
Formulation
L’acteur formule une requête pour  l’obtention d’une information qui l’aiderait à mieux gérer le contrat avec le client. Il demande donc à la mémoire d’entreprise de mettre à sa disposition les informations en relation avec le client.

 

Retrouver mails, contrats et données sur le client.
Transformation

La couche exploration fournit à la couche de données la requête de l’acteur et s’attend à un document XML qui correspond aux résultats trouvés. La couche de gestion traduit cette requête dans le langage du médiateur.

 

Rechercher données clients (coordonnées, chiffres d’affaires) + messages dont l’expéditeur et/ou le destinataire correspondent au client + le guide contrat de vente + les contrats du client ; soit Q cette requête.
Médiation

La couche de gestion, à travers le médiateur, éclate la requête en autant de requêtes que de type de sources de données.

 

La requête Q est décomposée en Q1 (vers les référentiels et données), Q2 (vers la messagerie), Q3 (vers la GED).
Extraction
La couche de données de l’architecture est sollicitée par le biais des wrappers qui permettent d’extraire les informations demandées.

Chacune des requêtes Q1, Q2 et Q3 est traité par le wrapper approprié. W1 pour lancer des requêtes de types SQL à des SGBD relationnels, W2 à travers des protocoles de messageries SMTP permet de collecter les messages utiles et enfin W3 charger de récupérer des documents correspondants aux contrats ou guide de contrats.

 

Restitution

La couche de gestion, à travers le médiateur, reçoit les réponses de la couche de données. Celles-ci sont transformées, fusionnées et transmises à la couche exploration.

 

La couche exploration applique une feuille de style pour présenter les informations fournies sous forme XML par la couche de données. Elle permet de simplifier la complexité due à l’hétérogénéité des informations.

 

V. Conclusion et discussions

L’enjeu de toute entreprise est d’atteindre ses objectifs planifiés dans sa stratégie globale. Nous avons montré que pour atteindre les objectifs de l’entreprise, les acteurs doivent prendre les bonnes décisions lors de l’exécution des processus métiers et l’amélioration, en continue, des performances de ces derniers, nécessite l’exploitation des mémoires d’entreprise dont il faudra définir l’architecture. Concernant l’architecture d’une mémoire d’entreprise, l’ingénierie documentaire peut fournir un levier pour la concrétisation de la mise en œuvre de la mémoire d’entreprise. Ainsi, l’indexation documentaire peut-elle se révéler particulièrement intéressante dans le contexte d’une mémoire d’entreprise. L’ingénierie documentaire peut également être exploitée, pour la formalisation des savoir-faire d’experts. Ceci consiste à transcrire les connaissances sous une forme exploitable et échangeable entre les individus mais aussi, entre des applications hétérogènes. L’utilisation d’XML comme support de formalisation et d’explicitation des savoir-faire offre l’avantage de structurer les connaissances selon des balises. Ces dernières sont fournies par les métadonnées et les concepts préalablement créés à partir de l’ontologie.
L’enjeu premier en gestion des connaissances réside non pas seulement dans l’implantation d’outils de gestion des connaissances, mais aussi dans l’implantation d’une habitude d’entrée des connaissances dans les outils par les membres de l’organisation et d’établir une arborescence de fonctions et de tâches à faire une fois que la connaissance a été acquise. Cependant, l’objectif d’une capitalisation des connaissances est bien le partage des connaissances dans le but de leur réutilisation par les membres adéquats de l’entreprise. Les technologies de l’information et de la communication peuvent constituer un support de diffusion intéressant pour favoriser le partage. Cependant, la diffusion doit être guidée si l’on veut fournir la bonne information au bon moment et éviter la surinformation. De plus, la diffusion d’une information ne suffit pas à garantir la réutilisation de la connaissance qu’elle est susceptible de transmettre. En effet, pour qu’une connaissance soit réutilisée, il est nécessaire qu’elle soit assimilée par l’acteur c'est-à-dire l’intégrer à sa base d’expérience et de connaissances propres et mobilisée à tout moment dans l’action (Tounkara et al, 2001). C’est dans ce sens qu’elle contribue à l’acquisition des compétences par les acteurs dans l’organisation.

Bibliographie

ABECKER A., BERNARDI A., HINKELMANN K., KUHN O., et SINTEK M. (1998). Toward a technology for organizational memories. IEEE Intelligent Systems, May/June. http://citeseer.nj.nec.com/abecker98toward.html

BACHIMONT B. Pourquoi n’y a-t-il pas d’experience en ingénierie des connaissances ? In Actes de la conférence (Ingénierie des connaissances IC2004), N. MATTA (ed), Lyon. Presses Universitaires de Grenoble.

BLASIUS K.H., HEDSTUCK U., ROLLINGER C-R. (1989). Sorts and Types in Artificial Intelligence, volume 418 of Lecture Notes in Artificial Intelligence. Springer Verlag, Berlin. 307 p.

BRACHMAN R. (1977). A Structural Paradigm for Representing Knwoledge. Thèese : Harvard University, USA,.

CAUSSANEL J., CHOURAQUI E. (1999). Information et Connaissances : quelles implications pour les projets de Capitalisation des Connaissances, in: Revue Document numérique - Gestion des documents et Gestion des connaissances, vol. 3-4, pp. 101-119.

CHARLET, J. (2002). L’ingénierie des connaissances : développement, résultats et perspectives pour la gestion des connaissances médicales. HDR. Paris : Université Pierre et Marie Curie, 142p

CHEIN Michel et MUGNIER Marie-Laure (1992). Conceptual Graphs : Fundamental Notions. Revue d’Intelligence Artificielle, vol 6, n°4, p. 365-406.

DAVIS, R., SHROBE, H., SZOLOVITS, P., (1993). What Is a Knowledge Representation ? AI Magazine, vol 14, n°1, p 17-33.

DIENG, R., CORBY O., GANDON F., GIBOIN A., GOLEBIOWSKA J., MATTA N., RIBIERE M. (2005). Knowledge Management: Méthodes et outils pour la gestion des connaissances. 3ème éd. Paris, Dunod. P 450. ISBN 2 10 049635 2

LEBRATY J.F, (2000). Les systèmes décisionnels, Encyclopédie des systèmes d'information, Vuibert.

Le MAITRE J., MURISASCO E., BRUNO E. (2004). Recherche d’informations sur les documents XML, In : Méthodes avancées pour les systèmes de recherche d’informations, Traité STI, Hermès, pp. 35-44, M.Ihadjadene.

MINSKY, M. (1975). A Framework for Representing Knowledge. The Psychology of Computer Vision. Edited by Winston P.H., p 245–262. McGraw-Hill, New York.

MORLEY C., HUGUES J., LEBLANC B., HUGIES O. (2005). Processus métiers et S.I: Evaluation, modélisation, mise en œuvre. Paris, Dunod. P 237. ISBN 2 10 007099 1

MUGNIER M-L, CHEIN M. (1996). Représenter des connaissances et raisonner avec des graphes. Revue d’intelligence artificielle, vol 10, n°1, p 7-56.

NONAKA I., TAKEUCHI H. (1995). The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation. Oxford University Press, 304 p.

PARENT R., BOULET N. (1998). Rôle des professionnels et l’ingénierie documentaire. Rapport issu de la journée de réflexion portant sur les rôles professionnels et l’ingénierie documentaire. Quebec, (www.services.gouv.qc.ac/fr/publications/enligne/administration/ingenierie/role_prof.pdf).

QUILIAN M. (1968). Semantic Memory. Semantic Information Processing, pp 227–270. MIT Press, Cambridge,MA, US.

SOWA J.F. (1984). Conceptual Structures : Information Processing in Mind and Machine. The system programming series. Addison-Wesley. 481 p.

© Ressi, no.7, avril 2008, ISSN 1661-1802

Date de dernière mise à jour : 30.04.2007