Quels Points de vue considérer ?

Comme dans tous les cas où les entités manipulées sont complexes, comme ces « projets » ou leurs « livrables », la caractérisation d’une entité singulière3 par un acteur la considérant dans son activité est difficile à formuler. Par exemple, le maître ouvrage du projet POPI en parle, lorsqu’il tente de dégager ses caractéristiques intéressantes, en termes de thématique, de particularités des livrables, d’intérêt pour l’entreprise… En 10 minutes se trouvent énoncées des dizaines de caractérisations qui peuvent aider à faire comprendre le projet, à le retrouver dans une masse d’autres projets, à servir d’argument un jour pour un éventuel « client » intéressé par tout ou partie du Projet, etc.

Cette difficile caractérisation peut être facilitée à la fois en distinguant des sous-entités composantes « ingrédients » de l’entité considérée, comme nous nous venons de le mentionner, et aussi en faisant cohabiter de grands points de vue pour organiser les descriptions des entités selon des dimensions structurelles de l’activité, comme nous allons le voir maintenant.

On pourra chercher par ces points de vue à refléter les grandes « heuristiques » par exemple les heuristiques de métier ou les dimensions d’analyse fonctionnelle, servant à caractériser ces entités. Un

3 Nous préférons ce terme « d’entité singulière » (ou tout simplement celui « d’entité ») à celui « d’instance d’entité ». L’entité est ce que l’acteur considère dans le monde, qu’il va nommer (de son « nom propre ») et associer au type d’entité (son « nom commun ») en considérant de son point de vue sa distance plus ou moins grande avec un profil prototypal: « le projet POPI », « l’axe services Web». Le terme « instance d’entité » est trop attaché à une visée ensembliste de classe abstraite, qui correspondrait à une perspective de classification taxinomique. Par exemple, on peut parfaitement admettre que l’axe transversal «services Web » évoqué dans le paragraphe précédent, qui n’est pas a proprement parler un projet codifié, figure dans le catalogue en tant qu’entité « projet », si l’organisation ne trouve pas opportun de multiplier les sous-entités en rajoutant une sous-entité de type « axes ». Les contributeurs se serviront d’autres indices de type langagier (par exemple faire figurer dans son titre l’expression « axe transversal »), de sorte que les lecteurs rétablissent d’éventuels défauts de cohérence liés à cette distance de l’entité singulière avec le profil prototypal.

Fig.1

1500Thèmes (Topics) Application: Agora 1Association transversale nommée « see also» 3 Roles (figés) - consultation - contribution - structuration 7Points de Vue sur l’Entité et les sous-entités Association hiérarchique entre Thèmes Ressources: URL, PJ, etc 1 Sous-Entité 1000 livrables Attributs du livrable Attributs du projet - dates projet - statut -e-mail MOA- MOE Entité principale 300 projets

point de vue n’est donc pas (ou pas uniquement) une facette « remontant » d’une analyse impartiale de l’objet. C’est un point de vue d’un sujet (l’acteur, le groupe) dans un certain ensemble d’activités concernant l’objet. C’est souvent ce que l’on appelle un « point de vue métier », pour souligner cette dimensions heuristique des caractéristiques que ce type de point de vue met en évidence sur les objets.

Par exemple, nous avons eu parmi les quelques 1500 thèmes présents dans Agora après trois mois d’usage, des thèmes concernant les projets ou des livrables tels que « IPV6 », « synergie internationale améliorée », « brevet », « adolescence », « invite à consommer du trafic haut débit », « ROI du client » etc. Ces thèmes, portés par des expressions langagières groupant parfois plus d’une dizaine de mots, sont incompréhensibles si on les considère simplement comme attribut de « facette de projet », sans les contextualiser avec le point de vue et l’heuristique de métier qui les rend nécessaires.

Sur la figure 1.2a ci-dessous, le contexte du thème « assembler facilement des éléments de service » ne devient vraiment interprétable que si l’on connaît le point de vue dont il relève (« bénéfice pour le client final »).

Fig.1.2a - Exemple de Thèmes dans trois des Points de vue de l’application Agora

Si l’on veut vraiment rentrer dans le problème de métier, l’expression « client final » représente un élément clé de la signification: l’assemblage par un tiers spécialiste est classique, par contre le fait que cet assemblage soit effectué par le client lui-même est fortement innovant. La contextualisation implique le point de vue, puis le chemin qui mène au thème à l’intérieur de ce point de vue, et éventuellement les chemins qui partent de ce thème. Le visiteur qui ne comprend pas bien le thème peut toujours en savoir plus en allant regarder le détail du projet P1 ou des autres projets qui déclarent traiter de ce thème.

On voit en passant comment une telle carte de thèmes peut constituer un instrument de partage et de capitalisation de connaissance cruciale pour l’entreprise, ainsi qu’un outil de pilotage fin pour le management de la R&D et de l’innovation. Certes l’investissement au moment du travail d’amorçage n’est pas négligeable pour le groupe de co-construction, qui doit poser tous ces thèmes, les soupeser et les organiser. Mais nous pensons justement qu’avec des outils appropriés ce travail peut devenir moins

Technologies Applications et Usages

Systèmes d’informations et architecture logicielle

Les réseaux pour la sphère professionnelle

Les applications innovantes pour l'organisation du travail e-commerce

Back-Office du Commerce électronique

Les grandes fonctions du Système d'Informations de l'entreprise Portails

…

Gain en efficacité industrielle

Qualité de l’infrastructure du système d’informations Temps de réponse

Assembler facilement des éléments de service Avantages du haut débit pour les processus de l'entreprise Qualité du système d'informations

Entreprise multi-sites

Adaptabilité de l'infrastructure télécom de l'entreprise Personnalisation facile des services de téléphonie mobile Bon tuning du réseau

Fiabilité du système d'informations de l'entreprise au quotidien Sécurisation accrue du réseau indépendante du nombre d'utilisateurs Intégration à valeur ajoutée de services voix-données

…

Optimisation et aide à la décision Technologies de base du Commerce électronique Technologies du contenu Technologies IHM Usages en entreprise Projet P1 Projet P2 Ressources

Bénéfices pour le client final

fastidieux et davantage distribué dans le temps, dans l’espace et entre un nombre accru d’acteurs et de métiers. Ensuite il sera très intéressant, par exemple pour le marketing, de connaître tous les projets R&D en cours sur des technologies ou d’autres innovations « qui permettent au client d’assembler facilement des éléments de services » ou « d’améliorer la qualité de son infrastructure multi-sites » (ce sont deux thèmes de la figure 1.2a), etc. On peut aussi noter (hypothèse que nous développerons au chapitre 2.5 et que nous tenterons de vérifier au §8.3) que de telles recherches d’informations autour de ce genre de question métier, où il faut vraiment rentrer dans le problème, sont très difficiles à faire avec des requêtes (de types moteurs de recherche ou requêtes de « Web sémantique logique » basées sur des logiques de description), alors que dans notre hypothèse un système de navigation dans une carte de thèmes multipoints de vue améliore la réponse.

Il existe donc une relation quasiment organique entre le point de vue et l’entité que l’on considère: un point de vue est un point de vue du groupe en activité sur quelque chose, et pour nous cet objet du point de vue est l’entité. Cela s’explique en considérant que les entités ont des attributs standards très objectifs (pour un projet, un attribut standard est sa date de début, le nom du responsable, le budget total, etc.). Mais les entités ont aussi des caractéristiques plus fines propres aux heuristiques des acteurs qui vont avoir affaire à ces entités, par exemple comme corps de métiers, comme rôles intervenant à diverses étapes d’un processus, etc. Ce sont ces « attributs heuristiques », que nous avons ensuite appelés « thèmes » (topics, en référence aux topic maps, cf. [TM 99]), qui vont pouvoir être ainsi articulés assez naturellement en hiérarchies de thèmes différentes constituant autant de Points de Vue. Nous reviendrons longuement dans la suite de cette thèse sur cette notion de Point de Vue.

Une conséquence de ce lien «organique» entre point de vue et entité est qu’il va exister un jeu de points de vue qui va prendre sens, comme « schéma de classification » pour le type d’entité considéré (et pour ses éventuelles sous-entités).

Cependant avec l’approche de sous-entité composante que nous rencontrons dans l’application Agora, il peut y avoir des difficultés, qui vont par exemple amener à affiner les Points de vue comme un compromis devant tenir compte à la fois de l’entité et de ses composants.4

Dans tous les cas les acteurs sont libres (cf. Fig.1.2b) de relier une entité singulière (P1) ou une de ses sous-entités (L2) à tout thème du jeu points de vue qui considère cette entité. Les thèmes de L1 et de P2 diffèrent, et s’il existe en général certains recouvrements, on ne peut considérer qu’il existe un héritage de thèmes entre P1 et L2, ni dans un sens ni dans l’autre.

4 Dans l’application Agora, comme tout « livrable » est un ingrédient de « projet », les sept points de vue proposés pour les projets et pour les livrables pouvaient donc, en gros, être les mêmes (cf. Fig1.2b). Cependant, le lien d’indexation d’une entité avec un thème (par exemple avec le thème « brique blanche » du point de vue n°7 « types de livrable »), n’a pas tout à fait le même sens si c’est un projet ou un livrable qui est relié: dans le cas d’un projet, le lien va être interprété comme « ce thème qualifie au moins un livrable du projet » ( ce projet a des livrables de type « brique blanche ») alors que dans le cas d’un livrable le lien va être interprété comme « ce thème qualifie exactement ce livrable » ( ce livrable est une « brique blanche »). Mais l’utilisateur est dans ce cas en mesure de rétablir la signification manquante, car la relation est contextualisée par le fait que son objet est marqué ou « légendisé » (typé par le modèle Hypertopic) comme projet ou comme livrable. De nombreux autres problèmes survenant dans la catégorisation collective peuvent d’ailleurs être résolus en se servant ainsi de marques, par légendisation ou par thématisation. Celles-ci constituent un « co-texte » aidant l’acteur en situation à compléter la sémiotisation des associations que la carte lui donne à voir. Nous eûmes notamment dans le groupe de référence d’Agora des discussions longues parce que, lorsque chacun devait indexer ses projets, le point de vue n°1 « Technologie » était équivoque: s’agissait-il des technologies développées

dans les projets ou des technologies utilisées par le projet, par exemple pour réaliser un livrable logiciel ? Ce problème aurait pu par exemple conduire à dédoubler le point de vue « 1.Technologie » entre « 1.1-Technologies visées » et «1.2-Technologies utilisées » (aide à la sémiotisation en utilisant la marque « point de vue »). Mais cette fois nous n’avons pas pris cette voie pour ne pas multiplier trop le nombre de points de vue et parce que, s’il existait effectivement des possibilités de contresens, une majorité des acteurs nous semblait capable de les déjouer grâce à leur l’expérience qui les rendait capables de sémiotiser avec justesse, au coup par coup, la relation entité-thème comme « P

Fig.1.2b - La relation entité/sous-entité n’implique pas l’héritage des thèmes rattachés

Les contributeurs d’Agora effectuant les descriptions en termes de thèmes ont intérêt à les décliner selon le plus grand nombre de points de vue possibles pour augmenter l’exposition des objets qu’ils décrivent. Ce principe du modèle KBM (Knowledge-Based Marketplace) qui reprend l’esprit général de la relation commerciale, notamment telle qu’elle apparaît dans les places de marché virtuelles ayant inspiré au départ ce modèle (cf. §6.2), permet d’augmenter l’exposition de « produits » en favorisant la rencontre des différents langages croisant différents usages, objectifs et rôles d’acteurs (client, fournisseur, concepteur, réalisateur, tiers régulateurs, client du client…). Cette recommandation « d’exposition maximale » en démultipliant5 les thèmes était d’ailleurs faite aux contributeurs d’Agora.

Dans Agora il était donc important pour nos interlocuteurs de ne pas être prisonniers d’une logique trop formelle et de faire en sorte que dans le système, même lorsqu’un projet est lié à un (ou plusieurs) livrables, les thèmes indexant les uns et les autres puissent être différents. Pour en donner un exemple plus détaillé, le projet POPI présenté sur la figure 1.7 est rattaché entre autres au thème « voyages », mais les responsables de ce projet peuvent estimer que ce thème, déjà un peu trop général pour caractériser le projet, n’est plus du tout opportun pour caractériser ses livrables, par exemple pour le troisième, qui concerne des essais de technologies logicielles avancées pour la gestion de déplacements d’équipes de maintenance. Les arrière-plans thématiques du livrable sont la gestion et l’informatique, et non plus l’activité des équipes de maintenance : le thème « gestion par contraintes » que recevra ce livrable, ne conviendra pas forcément au projet dans son ensemble, puisque s’il est vrai que la « gestion par contrainte » est une technique utilisée pour ce livrable, qui illustre seulement une

5 Démultiplier signifie ici précisément que l’on multiplie les thèmes, tout en divisant la complexité puisque un niveau de « rapport » intermédiaire est introduit par les points de vue. Cette division permet de considérer l’ensemble tout en ayant à l’esprit moins de thèmes à la fois, à la façon des « rapports » dans une boîte de vitesse (lesquelles en augmentant le nombre total de dents optimisent l’utilisation de la puissance du moteur en fonctions de genres de parcours particuliers : démarrage, côte, croisière, dépassement, etc.)

« Technologies»s « Applications et Usages » « Bénéfice Client » Systèmes d’informations et architecture logicielle

Les réseaux pour la sphère professionnelle

Les applications innovantes pour l'organisation du travail E-commerce

Back-Office du Commerce électronique

Les grandes fonctions du Système d'Informations de l'entreprise Portails

…

Gain en efficacité industrielle

Qualité de l’infrastructure du système d’informations Temps de réponse

Assembler facilement des éléments de service

Avantages du haut débit pour les processus de l'entreprise Qualité du système d'informations

Adaptabilité de l'infrastructure télécom de l'entreprise Personnalisation facile des services de téléphonie mobile Bon tuning du réseau

…

Technologies de base du Commerce électronique Technologies du contenu Technologies IHM Usages en entreprise Livrable L2 du Projet P1 WWW

Fig.1.2b-Exemple AGORA avec le livrable

…

Terminaux ^{Assistants portables} Mobiles WAP

… …

Projet P1

des voies expérimentales suivies, il est faux que ce thème caractérise la thématique du projet dans son ensemble, et encore moins les autres voies expérimentales suivies par les autres livrables.

Dans le cas de Agora, après l’examen d’une première centaine de projets, une première série d’environ 1000 thèmes, comme on peut le voir très variés, se trouvait au bout de quelques semaines « sur la table ». Il s’agissait de trouver pour eux le meilleur schéma de classification en Points de vues, par rapport aux objectifs d’usage d’Agora de déposer et retrouver l’information. Le schéma de classification qui finit par se stabiliser et fut en vigueur au moins pendant les premiers mois de l’application comporta finalement 7 points de vue, dans cet ordre (l’ordre était important car il reflétait des priorités et allait faciliter l’apprentissage et l’appropriation « mnémotechnique » de la carte):

• 1 - technologie

• 2 - applications et usages

• 3 - produits et services

• 4 - bénéfices pour le client final

• 5 - bénéfices pour le client interne

• 6 - apports en termes d’innovation

• 7 - types de livrables

1.2.4. Aperçu méthodologique concernant l’émergence des

Dans le document Ontologies sémiotique pour le Web socio sémantique (Page 30-34)