UN ATELIER LOGICIEL D'ASSISTANCE A L'INGENIERIE DES BESOINS EN INTELLIGENCE ECONOMIQUE

Transcription

1 UN ATELIER LOGICIEL D'ASSISTANCE A L'INGENIERIE DES BESOINS EN INTELLIGENCE ECONOMIQUE Talel ZID zid@univ-tlse1.fr Maryse SALLES-COLLETIS Msalles@univ-tlse1.fr Université Toulouse I, UFR Informatique Place Anatole France, Toulouse Cedex FRANCE Mots-clés : Ingénierie des systèmes d'intelligence économique ; ingénierie du besoin ; méthode ; PME ; aide à la décision ; modélisation ; développement de produit d'intelligence Economique ; prototypage Keywords : Competitive intelligence systems engineering ; requirement engineering ; method ; SME ; decision support ; modelling ; competitive intelligence product design ; prototyping Palabras claves : Ingenieria de las sistemas de inteligencia economica ; ingenieria de las necesidades ; método ; pequeña mediana empresa ; ayuda decisión ; modelización ; desarrollo producto de inteligencia economica ; prototipage Abstract This work focuses on a proposal which integrates a set of models and a méta-model for the specification and the development of a software tool. This software tool is dedicated to the aid to the definition and analysis of the decision-makers requirements for Business Intelligence. The software tool aids also to the definition and prototyping of Business Intelligence products. This software tool represents a support to the implementation of the MEDESIIE method. MEDESIIE is a method of elicitation, analysis and definition of the decision-makers requirements for Business Intelligence. We present also a study about different additional domains which are characteristic of various modelling approaches. Le présent travail traite la proposition d'un ensemble de modèles et d'un méta-modèle pour la spécification et le développement d'un outil logiciel. Cet outil logiciel est dédié à l'aide à l'analyse et à la définition du besoin des décideurs en intelligence économique et à la définition et au prototypage de produit d'intelligence économique (I.E.). Il représente un support d'aide à la mise en œuvre d'une méthode de collecte, d'analyse et de définition du besoin des décideurs en intelligence économique. Nous abordons aussi dans ce papier l'ensemble des domaines complémentaires qui caractérisent assez bien les approches actuelles de modélisation. 1 Introduction Le présent travail rentre dans le cadre du projet MEDESIIE (Méthode de définition de système d'information pour l'intelligence économique), soutenu par la Région Midi-Pyrénées. MEDESIIE est un projet d'ingénierie du besoin pour l'intelligence Economique (I.E.). Il a pour objectif principal la définition d'une méthode, et la spécification des outils associés, pour l'analyse du besoin en I.E. des décideurs (principalement au sein des PME). Ce papier aborde les deux points suivants : La construction d'un ensemble de modèles pour la méthode MEDESIIE afin d'en faciliter l'utilisation. Le développement de l'outil logiciel qui constitue un support pour la méthode MEDESIIE. PAGE 1 SUR 13

2 La problématique générique dans laquelle nous nous situons est celle de l'ingénierie de méthode pour la conception de systèmes d'information pour l'aide à la décision, en particulier concernant l'information sur l'environnement de l'entreprise. L'information sur l'environnement de l'entreprise présente un ensemble de spécificités qui entraînent un degré de complexité supérieur pour la conception de systèmes d'information [SALLES & al. 2000]. Ce volet se matérialise dans nos recherches par la proposition d'un formalisme pour la métamodélisation et la modélisation de produits d'i.e. Le formalisme proposé est composé de quatre concepts de base : un concept qui représente les éléments informationnels d'un produit d'i.e. Ce concept regroupe aussi les éléments de description du contenu. un concept qui représente les propriétés. Ces propriétés apportent des information complémentaires sur le texte et son contenu. un concept qui représente les liens. Ce concept regroupe essentiellement des éléments hypertextuel un concept fonction qui regroupe des fonctions d'aide à l'exploitation d'un produit d'i.e. n'utilisant pas de l'hypertexte. Dans ce papier nous nous attarderons essentiellement sur les modèles et le formalisme proposés pour la conception et la définition de produits d'i.e. Nous examinerons aussi de près l'outil logiciel qui s'appuie sur le formalisme en question. 2 L'intelligence économique : étude et constats Nous utilisons ici le terme Intelligence économique pour désigner un ensemble de pratiques communément admises dans le cadre des activités d'intelligence économique, et notamment la veille. Nous considérons un système d'intelligence économique comme un système produisant de l'information d'aide à la décision, à partir d'information sur l'environnement externe de l'entreprise [SALLES 2001]. Nous pouvons résumer les activités en intelligence économique en quatre grandes phases : Le recueil du besoin : il s'agit dans cette phase de recueillir les besoins informationnels de l'entreprise. Plusieurs méthodes peuvent être utilisées et notamment les méthodes d'ingénierie du besoin dont nous parlerons plus loin. La recherche de l'information : c'est une phase qui englobe les étapes d'identification des sources potentielles, d'évaluation de la pertinence de ces sources, et d'extraction des informations à partir des sources retenues. Le traitement de l'information : consiste à préparer l'information brute à des fins d'aide à la décision. Il s'agit entre autres opérations de traitement, de croisement, d'analyse et de synthèse. La diffusion des résultats : c'est la diffusion des informations traitées aux personnes concernées dans l'entreprise. L'étude que nous avons mené nous a permis de constater que la pratique de l intelligence économique a souvent été orientée outils. En effet, le développement et l exploitation d outils logiciels, dans la plupart des cas dédiés à une seule phase du processus d'i.e., ont toujours primé sur les autres activités de ce processus. La discipline s est tournée vers le tout outil et a notamment démarré avec l émergence des outils scientométriques et bibliométriques et les outils de recherche d information notamment sur Internet. Ces outils s'appuient sur les informations sur l environnement de l entreprise et ne concernent que les phases de recherche et d analyse de ces informations. Le processus global d intelligence économique, qu il soit sous forme de processus de renseignement ou de processus de définition et de mise en place de systèmes d'i.e., n est que partiellement représenté et supporté par les outils existants. D un autre coté, ces outils ne répondent généralement qu à une seule grande classe de besoin : quelle stratégie l entreprise doit-elle PAGE 2 SUR 13

3 adopter face à l état dans lequel se trouve son environnement concurrentiel au moment de l analyse? Dans la plupart des cas cette classe de besoins correspond essentiellement au niveau de pilotage stratégique. Sur un autre plan, il n'existe pas aujourd'hui de référentiel en matière de produit d I.E. ni d outils conceptuels pour décrire ce référentiel. Nous tenons aussi à souligner que peu de travaux affectent le caractère «aide à la décision» aux informations d intelligence économique et par conséquent les produits d I.E. existant n ont pas été conçus en tant que produits d aide à la décision. 3 Les domaines complémentaires : synthèse des apports 3.1 Les systèmes d'information L'étude de ce domaine a été conduite dans une optique d'exploration d'un domaine de référence. L'étude des méthodes, démarches et outils en matière de système d'information à permis de dresser la liste des éléments indispensables pour la construction d'une méthode et des outils associés. Le système d'information et le système d'intelligence économique traitent tous deux des informations utiles à l'entreprise. La différence majeure entre ces deux notions est l'étendue des informations. En intelligence économique l'information manipulée et traitée couvre un champ beaucoup plus large qu'en système d'information. Ainsi sa définition et sa délimitation deviennent beaucoup plus délicates, d où l utilité de l ingénierie de besoin [POHL 97]. Dans les méthodes de système d'information examinées nous avons pu constater la présence d'outils pour la modélisation de divers aspects du système : aspect statique, aspect traitement, etc. Le domaine des systèmes d'intelligence économique peut aussi être décliné en plusieurs aspects dont principalement l'aspect données (statique) et l'aspect traitements (dynamique). Dans les pratiques actuelles en intelligence économique on ne retrouve pas de trace d'outils pour la modélisation de ces éléments. Tous ce qu'on peut croiser dans la littérature se présente sous forme de typologies plus ou moins exhaustives. Nous pensons qu'il est très important dans un domaine comme celui de l'intelligence économique (où l'on manipule des données souvent stratégiques pour l'entreprise, on réalise des traitements et on exploite de différentes manières les résultats obtenus) de construire des méthodes (avec les outils nécessaires) permettant de modéliser tous les aspects du système. L'utilisation d'outils conceptuels adéquats est très enrichissante dans la mesure où ils permettent une description détaillée des éléments du système et une représentation visuelle qui facilite le dialogue entre client et fournisseur de service. 3.2 Les systèmes d'aide à la décision L'aide à la décision est la fonction essentielle de l'intelligence économique. Nous pensons que les trois niveaux de pilotage (stratégique, tactique et opérationnel) sont concernés, dans des proportions différentes, par les informations produites par un système d'intelligence économique. Signalons que le niveau de pilotage opérationnel est quasi absent dans les travaux en la matière. Sur le plan du processus décisionnel, les trois phases définies par Simon (Intelligence, Design, Choice) peuvent avoir recourt aux informations produites par un système d'i.e. Durant son existence, une entreprise est amenée assez fréquemment à construire diverses solutions (scénarios) alternatives pour la résolution d'un problème. La recherche d'informations, la construction des solutions et l'arbitrage qui s'opère pour choisir la solution la plus adéquate pour l'entreprise sont des exercices qui nécessitent le plus souvent des informations sur l'environnement de l'entreprise. Nous pensons que l'intelligence économique alimente donc tout le processus décisionnel avec des proportions différentes pour chacune des phases [CHECROUN 92]. Sur un autre plan, l'étude des fonctions types d'un SIAD nous à permis de faire un recoupement avec un certain nombre de stratégies de lecture d'un produit d'information et particulièrement d'un produit d'i.e. afin de PAGE 3 SUR 13

4 définir les fonctions nécessaires pour l'exploitation d'un produit d'i.e. en tant que support pour l'aide à la décision. L'étude de certaines méthodes et outils (dont notamment ROMC [SPRAGUE et al. 82] et les SIAD spécifiques) ont permis de constater les moyens (démarches, outils, techniques, ) mis en œuvre pour la conception et la réalisation de SIAD avec toutes les caractéristiques nécessaires. La prise en compte de ces moyens est nécessaire lors de la définition d'une méthode pour la conception et la réalisation de produits d'i.e. 3.3 Les produits d'information Cette partie occupe une place centrale dans notre travail. En effet, afin d'apporter les éléments nécessaires pour la métamodélisation de produits d'i.e., une étude exploratoire de l'existant en matière de produits d'information et de tout ce qui s'y rapporte a été menée. Cette étude nous a permis de traiter les points suivants [STOCKINGER 99]: Typologies de produits : L'étude des caractéristiques des typologies dégagées a permis de distinguer des configurations types pouvant être utilisées dans le cadre des produits d'i.e. Les configurations types permettent de disposer d'un ensemble de définitions de solutions prédéfinies lors de l'analyse d'une entreprise. Composants des produits d'information : ceci a permit de dégager un ensemble de constituants suffisamment élémentaires pour être utilisés de manière générique. Les constituants élémentaires portent sur plusieurs aspects du produit dont notamment les informations signalétiques, le type de contenu informationnel, la mise en forme du contenu, les informations d'aide à l'exploitation ainsi que les liens qui peuvent exister entre constituants d'un produit d'information. Conception d'un produit d'information : nous avons abordé cette activité en mettant l'accent sur les aspects dont la prise en compte nous a semblé nécessaire lors de la conception d'un produit d'i.e. Ainsi nous avons étudié la notion de support, d'organisation des composants, d'existence de plusieurs utilisateurs et des buts et des stratégies de lecture [OHARA 96]. L'étude des trois thèmes décrits ci-dessus a permis essentiellement de dégager les éléments génériques en matière de définition de produits d'i.e. et ainsi de construire le formalisme (présenté dans le paragraphe suivant) pour la modélisation de ce type de produits. 4 Formalisme de modélisation de produits d'i.e. 4.1 Le formalisme Le formalisme proposé est composé de plusieurs concepts comme le montre la figure ci-dessous : + - n Relations Liaison orientée Composition Drill Down Drill Accros Approfondissement Parcours Figure 1 : Concepts du formalisme. Le concept Modèle est utilisé pour la représentation des modèles de produits d'i.e. réalisés avec la méthode. Ce concept est utilisé uniquement au niveau de la méta-modélisation. Il permet de représenter par une seule entité l'ensemble du modèle. Le concept Elément d'information permet de représenter tous les types d'éléments informationnels traités dans le produit d'i.e. Nous avons pu distinguer 3 catégories d'objets : Unité informationnelle : c'est un concept qui représente dans un produit d'i.e. une unité du contenu informationnel tel un article scientifique, une étude marché, le texte d'un brevet, PAGE 4 SUR 13

5 Table/Index : c'est un concept qui représente toute sorte de table ou d'index permettant de grouper des références à des éléments du produit d'i.e. Ce concept regroupe les notions de table de matière, d'index, de glossaire, d'index annuel, de table des figures, Gisement d'information : ce concept illustre les différents types de renvois pouvant exister dans un élément informationnel et donnant accès à une source d'information permettant d'approfondir d'éventuelles recherches sur le thème concerné par le renvoi. Le concept Relation modélise les différents types de liens existants entre des composants. Nous avons pu dégager sept catégories de lien (Figure 2): Figure 2 : Types de relations (suite du formalisme). Les liens de type Liaison orientée permettent de représenter des liens entre concepts où le sens de parcours du lien est important. Les liens de type Composition permettent d'exprimer qu'un concept est composé d'autres concepts. Ainsi un concept Modèle est composé de concepts de type Elément d'information, de Relations, Les liens de type Drill Down représentent les liens vers des concepts de type Unité informationnelle contenant des synthèses sous forme d'agrégation d'une information détaillée. L'Agrégation est une représentation condensée d'un élément informationnel permettant d'accéder à l'essentiel de l'information sans s'attarder sur le détail. Les liens de type Drill Accros expriment des liens vers des concepts de type Unité informationnelle contenant une information détaillée. L'information détaillée permet d'approfondir l'étude de l'unité informationnelle de départ. Les liens de type Approfondissement représentent tous les liens qui partent vers des concepts de type Gisement d'information. Les liens de type Parcours représentent les parcours de lecture qui sont inclus dans le modèle de produit. Un lien de type Parcours relie deux concepts de type Unité informationnelle. Ce lien possède la propriété n qui représente l'identifiant du parcours. Les liens de type permettent de lier deux concepts de type Unité informationnelle. L'un de ces deux concepts doit contenir le résumé de l'autre. Le concept Propriété représente les attributs que possèdent les concepts Elément d'information et Modèle. Le concept Propriété regroupe des attributs qui peuvent être affectés à l'ensemble d'un produit d'i.e. ou bien à un concept de type Elément d'information. Les propriétés d'un produit d'i.e. sont les attributs qui s'appliquent à la totalité du produit en tant qu'objet indivisible. Ces propriétés sont rattachées au concept Modèle en métamodélisation et en modélisation générique. Les propriétés que nous avons retenues sont les suivantes : Nom Type du modèle : cette propriété permet d'identifier les modèles selon deux critères, générique ou de produit concret. Gamme de produits : cette propriété permet d'attribuer le modèle à une gamme de produits dans une liste d'éléments prédéfinis. Périodicité : peut être exprimée en semaines ou en mois. Support : peut être soit numérique, soit papier. Les propriétés des concepts de type Elément d'information regroupent des attributs qui permettent essentiellement de mettre en forme le contenu informationnel. Nous avons retenu les propriétés suivantes: Nom Police de caractère Taille de la police Couleur des caractères Numéro d'ordre : cette propriété permet de donner la position du concept de type Elément d'information au sein du produit d'i.e. Nous désignons par position l'emplacement physique de l'élément dans le produit. PAGE 5 SUR 13

6 Catégorie du contenu : grâce à cette propriété, le contenu du concept de type Elément d'information est catégorisé. Un ensemble de catégories types est défini. Visible : cette propriété peut avoir l'une des deux valeurs Vrai ou Faux. Lorsque la propriété a la valeur Vrai, l'élément d'information est inclus dans le produit. Lorsque la propriété a la valeur Faux, l'élément d'information n'est pas inclus dans le produit. Cette propriété permet de prendre en compte l'existence de plusieurs utilisateurs. Ainsi lors de la génération d'un prototype de produit d'i.e. pour un utilisateur ou groupe d'utilisateurs défini, il suffit d'affecter la valeur Vrai à cette propriété dans les éléments informationnels concernant l'utilisateur en question. Pour générer un prototype pour un deuxième utilisateur ou groupe d'utilisateurs on utilise le même modèle de produit et on intervient uniquement au niveau de la propriété Visible de ses constituants. Le concept Fonction modélise les fonctions dont peuvent disposer les concepts Elément d'information et Modèle. Ce sont des traitements standards qu'on peut appliquer à un concept de type Unité informationnelle. On peut assimiler ce concept à la notion de méthode en orienté objet. A ce stade de notre recherche, nous avons retenu deux fonctions : La fonction résumé intégré : c'est une fonction qui permet d'afficher un résumé à l'intérieur même d'un concept Unité informationnelle. Le résumé intégré est l'ensemble des fragments de texte pris dans le texte principal pour constituer un résumé. La différence majeure avec un résumé classique est que le résumé intégré n'est pas détaché du texte principal. La fonction mots clés : permet de mettre en évidence les mots clés d'un texte en utilisant des techniques de différentiation des caractéristiques du texte tels que la couleur et la surbrillance. 4.2 Méta-modèle de produits d'i.e. Le méta-modèle peut être considérée comme une représentation en langage semi-formel avec laquelle nous décrivons tous les modèles de produits d'i.e. pouvant être réalisés à l'aide de la méthode et du formalisme proposés. De plus le méta-modèle représente la référence sur laquelle nous nous sommes basés pour la construction de l'environnement de modélisation de l'outil logiciel décrit dans la suite de ce papier. Le fonctionnement de l'environnement de modélisation traduit les règles qui sont posées dans le méta-modèle du produit d'i.e [ZID et al. 2001]. Unité informa- -tionnelle Unité informa- -tionnelle Modèle_Produit intégré Parcours Parcours Unité informa- -tionnelle Figure 3 : Extrait du méta-modèle. La figure ci-dessus représente un extrait très réduit du méta-modèle proposé. Cet extrait montre qu'un concept de type Modèle appelé "Modèle_Produit" a deux relations de type Composition avec les concepts de type Unité informationnelle et de type Parcours. Les concepts de type Unité informationnelle ont une relation de type Composition avec les concepts Fonction de type " intégré". De plus l'extrait ci-dessus exprime la possibilité de lier deux concepts de type Unité informationnelle par une relation de type Parcours. Nous avons aussi employé la notion de cardinalité afin d'apporter plus de richesse au méta-modèle. 4.3 La modélisation de produits d'i.e. Un modèle de produit d'i.e. est une représentation semi-formelle qui utilise les concepts du formalisme et qui respecte les règles décrites dans le méta-modèle. On distingue deux types de modèles qui correspondent à deux niveaux différents : le PAGE 6 SUR 13

7 modèle générique et le modèle de produit concret. Le modèle générique représente la définition d'une configuration type d'un produit d'i.e. qui peut être utilisée par la suite pour produire plusieurs produits d'i.e. concrets. C'est la définition de l'ensemble des éléments stables. On appelle élément stable, une composante ou une caractéristique du produit qu'on retrouve inchangée dans toutes les instanciations du modèle (ex. la page de couverture, la police de caractère utilisé pour les éléments informationnels, ). Le modèle générique de produit d'i.e. peut correspondre essentiellement à deux cas de figure : un produit à livraison périodique : les instanciations de ce type de modèle sont les livraisons successives et à intervalle de temps régulier du produit d'i.e. défini comme étant un produit périodique. Les lettres périodiques d'information financière sont un exemple de ce type de produit. une gamme de produits : c'est une catégorie de produits nécessitant une définition particulière de son contenu et de son contenant. Les gammes de produits peuvent être définies selon plusieurs critères. Ainsi, on peut avoir une gamme de produits par secteur d'activité, une gamme de produits par thème (analyse de brevets, état de l'art d'une technologie, étude de marché, ), Le modèle de produit concret est un autre niveau d'instanciation d'un modèle. Il représente une définition complète d'un produit d'i.e. Cette définition n'est pas limitée à l'ensemble des éléments stables. Elle englobe toutes les composantes du produit, éléments spécifiques inclus. Ainsi, un modèle de produit concret doit contenir la définition de tous les éléments d'information sur le plan contenu et contenant. Il doit aussi contenir la définition de toutes les relations spécifiques au produit (parcours de lecture, Drill Down, ). Le modèle de produit concret est utilisé pour deux types de représentations : 1. La représentation de produits ponctuels uniques 2. La représentation d'une livraison d'un produit périodique ou d'une gamme de produits. La figure 4 et la figure 5 représentent respectivement un exemple de modèle générique et un exemple de modèle concret basé sur le modèle générique. Le modèle générique (Figure 4) implémente les spécifications suivantes : Le produit doit avoir une table des matières et un index. Le produit doit inclure au moins un parcours de lecture. Une Unité informationnelle doit avoir : un un Gisement d'information la fonction Mots clés Les éléments entourés d'un cadre en trait continu représentent la portion du modèle générée automatiquement au démarrage de l'environnement de modélisation. On note la présence de l'unité informationnelle nécessaire pour satisfaire la condition exprimée dans le modèle générique (au moins une Unité informationnelle doit composer le produit). On note aussi la présence d'une Unité informationnelle de type et d'un Gisement d'information liés à l'unité informationnelle Elément1. Dans la portion générée au démarrage, la table des matières et l'index sont aussi inclus dans le modèle selon les recommandations du modèle générique. Les éléments entourés d'un cadre en pointillé sont les éléments générés automatiquement par l'outil suite à l'insertion par l'utilisateur de nouvelles Unités informationnelles. En effet, à chaque fois qu'une Unité informationnelle est rajoutée au modèle, une Unité informationnelle de type et un Gisement d'information lui sont associées. Le parcours de lecture qui relie les s des Unités informationnelles est rajouté manuellement par l'utilisateur. PAGE 7 SUR 13

8 5 L'outil de prototypage de produits d'i.e. Nous présentons ici l'outil logiciel qui constitue le support de la méthode et qui met en œuvre le formalisme et le méta-modèle développés plus haut. Par analogie avec le domaine des systèmes d'information, nous pouvons classer cet outil dans la catégorie AGL. En effet, les différents modules de l'outil offrent des fonctionnalités permettant de faciliter l'utilisation de la méthode. Certaines étapes sont automatisées ou semi-automatisées grâce à l'utilisation des modèles décrits précédemment. Nous tenons à préciser ici que l'outil est essentiellement destiné à des entreprises (ou organismes) de conseil en intelligence économique. Le terme utilisateur (de l'outil) est donc employé pour désigner l'ensemble des intervenants potentiels dans le cadre de la définition, de la conception et de la mise en place de produits d'i.e. dans des entreprises. Les utilisateurs de l'outil (comme de la méthode) représentent la population de consultants spécialistes en matière de services en intelligence économique. Le fonctionnement de l outil est basé sur trois modules principaux : Le module d'aide à l'analyse de l'entreprise et de son environnement Le module d'aide au recueil et à l'analyse des besoins Le module d'aide à la définition de produits d'i.e. 5.1 Module d'aide à l'analyse de l'entreprise et de son environnement Dans cette étape il s'agit d'abord d'affecter l'entreprise à un type prédéfini. Les types sont définis dans une base de données. Cette affectation se fait à l'aide de techniques de calcul de distance entre l'entreprise étudiée et les types existants. Les calculs effectués dans ce cadre permettent de situer l'entreprise par rapport aux différents types. Il en résulte l'affectation de l'entreprise au type le plus proche en terme de caractéristiques. Les types d'entreprise sont définis à l aide d'un ensemble de caractéristiques. Parmi les caractéristiques qui définissent un type nous citons : la taille de l entreprise, le chiffre d affaire, le secteur (industrie, service), les fonctions internes, la capacité d innovation, Chaque caractéristique joue un rôle plus ou moins important dans la définition d un type, d où la nécessité d affecter un poids à chacune des caractéristiques. Le poids est un coefficient qui permet d augmenter ou de diminuer l importance d une caractéristique par rapport aux autres. La méthode de calcul choisie est celle de Minkowski. Dans l'outil logiciel nous proposons une représentation tridimensionnelle. Chacun des trois axes permet de regrouper un ensemble de caractéristiques. Figure 4 : Cartographie des types d'entreprises. L'exemple de la figure 6 illustre la cartographie d'une entreprise (représentée par un cercle) par rapport à trois types d'entreprises (Type 1, Type 2 et Type 3). Pour simplifier, nous avons supposé que l'entreprise et les types sont définis à l'aide de quatre caractéristiques : Chiffre d'affaire, Fonctions internes, statut juridique et taille. Deux caractéristiques sont encore inutilisées par l'utilisateur : Chiffre d'affaire et Fonctions internes. Les deux autres caractéristiques sont déjà positionnées par l'utilisateur sur les axes X et Y. L'activation d'une caractéristique sur l'un des axes se fait par une opération de glisser-déplacer. PAGE 8 SUR 13

9 Table/ index 11 1N Produit_Test 1N 1N 11 Parcours 11 Unité informa- -tionnelle Unité informa- -tionnelle Gisement d'information 11 Mots clés Figure 5 : Exemple de modèle générique de produit. Table des matières de l'élément1 de l'élément2 de l'élément de l'élément4 Elément 1 Elément 2 Elément 3 Elément 4 Index Gisement pour l'élément1 Gisement pour l'élément2 Gisement pour l'élément3 Gisement pour l'élément4 Figure 6 : Exemple de modèle concret basé sur le modèle générique ci-dessus. PAGE 9 SUR 13

10 Le menu contextuel que nous avons volontairement affiché au milieu de la fenêtre permet essentiellement de voir les fonctions de visualisation. Notons par exemple la possibilité de faire une rotation des trois axes ou encore de basculer sur un affichage en une seule dimension (appelée aussi représentation linéaire). 5.2 Module d aide au recueil et à l'analyse du besoin Ce module de l'outil utilise la banque de besoins décrite plus haut. Il s'agit essentiellement dans cette partie de recueillir les besoins de l'entreprise à étudier et de les confronter avec les besoins stockés dans la base de données et qui sont utilisés comme modèle de référence (besoin cible). Cette comparaison est rendue possible grâce au codage des besoins (le modèle de codage des besoins a été présenté plus haut dans ce papier). Ce module de l'outil permet la génération d une grille de recueil des besoins adaptée à une entreprise donnée. La génération s effectue à l aide de sélections automatiques de thèmes dans la base de données. Ces sélections sont conditionnées par une correspondance entre les caractéristiques de l entreprise et les descripteurs des thèmes [ZID et al. 99]. Cette partie de l outil permet aussi de personnaliser la grille générée en donnant la possibilité à l utilisateur d accéder à la totalité des thèmes qui figurent dans la base de données. La grille générée est organisée sur deux niveaux : Le niveau rubrique : permet d'organiser les thèmes sous forme de groupes prédéfinies. Le niveau thème : permet de représenter un aspect particulier d'une rubrique. Un thème est composé d'une question et de quelques exemples de situations concrètes destinées à clarifier la question. Les exemples de situations concrètes ont été inspirés de la notion de scénario développée par [ROLLAND et al. 2001] dans le cadre de la définition des différentes approches pour l'ingénierie du besoin. Un scénario est définit comme étant un propos qui peut être descriptif, explicatif ou exploratoire. Les scénarios descriptifs permettent la capture des besoins en proposant aux utilisateurs et à l'analyste de décrire un processus afin d'identifier ses opérations. Les scénarios explicatifs proposent d'identifier pourquoi un événement a eu lieu dans la réalité, ce qui l'a causé, ses conséquences, etc. les scénarios exploratoires sont utiles lorsque plusieurs systèmes alternatifs sont envisageables. Ses alternatives doivent être examinées et évaluées afin de déterminer la meilleure solution. L'analyse des besoins est une phase délicate en raison du nombre de caractéristiques et de besoins qu'il faut traiter pour affecter l'entreprise à un type en particulier. Nous avons donc essayé d'automatiser au mieux cette tâche. L'automatisation de l'analyse des besoins nécessite que ceux-ci soient représentés de manière formelle ou du moins semi-formelle. La fonction de codage offre à l'utilisateur la possibilité d'indexer les besoins selon le format présenté plus haut. Ce format permet à l'outil de prendre en charge l'analyse des besoins et l'affectation de l'entreprise à un type. Ainsi, un besoin peut être indexé sur les quatre dimensions : catégorie, dimension géographique, niveau de pilotage et processus de décision. Le besoin est aussi stocké par l'outil sous deux autres formats : une interprétation donnée par l'utilisateur qui résume l'objet du besoin ainsi que le texte complet du besoin qui le présente tel qu'il a été exprimé par le décideur. L'étape suivante consiste en une évaluation de la correspondance entre les besoins de l'entreprise étudiée et le besoin cible (celui du type retenu). L'affectation de l'entreprise à un type étant effectuée, l'outil procède à une analyse des besoins collectés. Cette analyse consiste en une comparaison des besoins collectés avec le besoin cible. Les deux éléments étudiés par ce composant de l'outil sont donc les besoins exprimés de l'entreprise et les besoins définis pour le type retenu comme étant le plus proche de PAGE 10 SUR 13

11 l'entreprise. Les écarts entre les deux groupes de besoins (exprimés et cible) peuvent être interprétés de plusieurs manières : les éléments du besoin cible qui n ont pas été exprimés peuvent représenter des omissions de la part des personnes interrogées ou aussi des besoins cachés (non identifiés par la personne interrogée et par l équipe qui a mené l analyse). la partie des besoins exprimés qui n apparaît pas au niveau du besoin cible représente soit : des besoins exceptionnels qui ne peuvent pas être généralisés et qu on ne peut donc pas ajouter au besoin cible. de nouveaux besoins qui doivent être pris en charge par le besoin cible et qui doivent donc figurer dans le type de l entreprise correspondante. de "faux besoins" que l on décide de ne pas retenir. 5.3 Module d'aide à la définition de produits d'i.e. L'outil offre un environnement permettant une définition graphique du modèle du produit. Cet environnement est dédié au formalisme et au méta-modèle de produit d'i.e. définis précédemment. L'utilisation de cet environnement se fait à deux niveaux différents : le niveau modélisation générique et le niveau modélisation de produit concret. La modélisation générique permet de créer des modèles qui seront repris lors de la modélisation de produits concrets. La modélisation de produits concrets peut être guidée par l'utilisation d'un modèle générique préalablement définit. En effet, les éléments stables définis dans le modèle générique sont inclus automatiquement dans le modèle de produit concret. Il en est de même pour les contraintes. Elles sont rappelées à l'utilisateur à chaque fois que ce dernier omet de les respecter lors de la création de son modèle. Ainsi, si au niveau du modèle générique on dispose d'une relation du type résumé, alors lors de la création du modèle de produit concret, à chaque insertion d'un nouveau concept de type Unité informationnelle, une relation de type et une unité informationnelle (prévue pour accueillir le résumé) sont automatiquement ajoutées au modèle. L'environnement de modélisation permet aussi de définir pour chacun des éléments qui composent le modèle (générique ou de produit concret) un ensemble de propriétés (des exemples de propriétés ont été citées dans la partie qui expose le formalisme). Les fonctions sont assignées aux éléments qui composent le modèle de la même manière que les propriétés. A une Unité informationnelle on peut par exemple associer la fonction Mots clés. La phase de prototypage consiste à instancier le modèle de produit et à réaliser une partie ou la totalité du produit pour des fins de validation. L'utilisateur est invité dans cette phase à alimenter le squelette du prototype par des informations en réponse aux besoins informationnels retenus. Le prototype ainsi réalisé constitue un support pour la validation des deux aspects principaux d'un produit d'i.e.: le contenu informationnel qui découle des besoins retenus lors de la phase d'analyse le support et la mise en forme du contenu (utilisation de propriétés et de fonctions) 6 Conclusion L ensemble des modules de l atelier présenté dans ce papier offrent un environnement de type AGL. Son fonctionnement est basé sur l'utilisation d'un formalisme pour la définition de modèles de produit d'i.e. L'utilisation des techniques citées pour la définition de produits d'i.e. offre des avantages considérables : Les produits d'i.e. sont considérés comme étant des entités modélisables. Les conséquences qui en résultent sont nombreuses. Notons en particulier les possibilités de décomposition élémentaire et l'utilisation de composantes types (concepts). La tâche des concepteurs de ce type de produit serait alors grandement facilitée par l'utilisation de bibliothèques d'éléments. PAGE 11 SUR 13

12 L'automatisation du prototypage et de la réalisation des produits d'i.e. est simplifiée. Il devient alors possible de créer et de stocker des modèles types de produit d'i.e. Plusieurs niveaux de modèles types sont envisageables. Les modèles types peuvent constituer une base de connaissances dont les éléments sont réutilisables. Bibliographie sélective [ROLLAND et al. 2001] Rolland Colette, Grosz Georges, De la modélisation conceptuelle à l'ingénierie des besoins, Ouvrage collectif : Ingénierie des systèmes d'information, Edition Hermès, Paris, [SALLES 2001] Maryse SALLES, Les besoins des PME en information d'intelligence Economique : présentation des résultats d'une enquête en Midi-Pyrénées, Colloque veille stratégique scientifique et technologique (VSST'2001), Barcelone, [SALLES et al. 2000] Maryse SALLES, Philippe CLERMONT, Bernard DOUSSET, MEDESIIE : une méthode de conception de systèmes d'intelligence économique, Integrated Design and Manufacturing in Mechanical Engineering 2000, MONTRÉAL (QUÉBEC) Canada, [SPRAGUE et al. 82] Sprague R., Carlson E., Building effective decision support systems, Prentice-Hall, Inc., [ZID et al. 2001] Talel ZID, Maryse SALLES, Modélisation de produits d'intelligence économique, Colloque veille stratégique scientifique et technologique (VSST'2001), Barcelone, [ZID et al. 99] Talel ZID, Maryse SALLES, La génération de grille d entretien pour le recueil du besoin en I.E., Colloque Ile Rousse'99, Ile Rousse, [STOCKINGER 99] Peter Stockinger, Les nouveaux produits d'information, Dunod, Paris, [CHECROUN 92] CHECROUN A. Comprendre, concevoir et utiliser les SIAD. Paris : Masson, [OHARA 96] OHARA K., Towards a typology of reading goals, XRCE Technical report No. EPC Xerox Research Centre Europe, Cambridge, UK. [POHL 97] Klaus Pohl, Requirements engineering : an overview, Encyclopedia of Computer Science and Technology, A. Kent, J. Williams (editors), Volume 36, Supplement 21, Marcel Dekker, Inc., New York, PAGE 12 SUR 13

13 PAGE 13 SUR 13