Aperçu du mode « contribuer » dans Agora

Nous ne détaillerons pas ici le fonctionnement de Agora en mode contribution ni en mode structuration sémantique. Ces points sont abordés de façon plus détaillée dans la suite, où nous profiterons du fait que l’interface de l’outil a été modernisée dans sa version générique actuelle Agoræ. Nous ne chercherons pas ici à décrire et discuter exhaustivement les interfaces mis en œuvre, qui ne présentent d’ailleurs pas forcément un grand intérêt scientifique, mais nous pouvons juste situer globalement, pour simplifier, que le fonctionnement des interfaces « contribuer » et « structurer » suit l’état de l’art en matière de portails informatiques et découle directement :

• des choix de structuration de la carte de thèmes découlant du modèle Hypertopic et des rôles KBM (consulter, contribuer, structurer),

• et de la nécessité de permettre aux différents rôles d’accomplir toutes les opérations nécessaires pour créer et maintenir en amont l’information nécessaire à la base d’informations en mode consultation.

Nous nous contenterons de montrer (Fig.1.8) l’un des écrans de l’interface en mode contribution, lorsqu’un membre de l’organisation autorisé à « contribuer » veut créer ou modifier la description d’une entité (ici, le projet « EPIC ») en parcourant la carte pour indexer ce projet à un nouveau thème. Pour cela, le contributeur dispose, sur la gauche de son écran, de l’arbre des points de vue et des thèmes, qu’il peut déplier ou replier pour sélectionner ou désélectionner à sa guise les thèmes d’index qu’il souhaite. L’interface a été conçue pour qu’il navigue dans la carte des thèmes exactement de la même façon qu’en mode consulter. Il effectue une opération de glisser-déposer du thème choisi dans la liste des thèmes du projet (au centre). Etant donné le nombre des thèmes, nous avions prévu une facilité de vision plus globale de la Carte (accessible via l’icône « map of topics » au dessus de l’arbre des Points de Vue, à gauche).

Pour le reste, outre les thèmes, le contributeur définit, pour toutes les entités dont il possède les droits d’accès, le contenu de la fiche ces entités: éléments textuels multilingues, (par exemple par copier-coller depuis des documents bureautique), liens vers des adresses universelles (URL) ou des documents en pièces jointes, valeur des champs d’attributs standards, en étant guidé par une liste de contrôle l’aidant à ordonnancer toutes les opérations à faire, obligatoires ou facultatives et à récapituler l’avancée de sa contribution. Cette liste de en forme de pense-bête définit une proposition d’ordonnancement de tâches (« workflow ») qui n’est pas impératif, car le contributeur peut très bien travailler dans l’ordre qui lui convient. L’ordre par défaut est simplement suggéré par le fléchage de la barre de tâches en bas de l’écran de la Fig.1.8 (où l’on voit la tâche en cours « Project Topics » mise en évidence en couleur).

Notons, à propos de ce détail d’interface, qu’il ne traduit pas seulement un souci d’ergonomie d’utilisation. Ce point illustre aussi un principe très important dans notre approche. Nous considérons en effet que la co-construction de la carte de thèmes s’inscrit dans une démarche de « conception participative » et de « modélisation engagée » (cf. §3.5.1). Les acteurs non seulement connaissent leur position dans les processus lorsque l’organisation en a été prescrite par d’autres, mais aussi (comme le montrera ensuite l’évolution du modèle Hypertopic et de l’outil) ils doivent pouvoir utiliser le modèle et la cartographie de thèmes pour prescrire eux-mêmes l’organisation ad hoc dont ils ont besoin pour la co-construction.

L’enjeu, qui va bien au delà de fonctionnalités avancées pour le paramétrage de collecticiel, est ici un enjeu fort pour le travail coopératif assisté par ordinateur (TCAO). Encore une fois, l’artefact doit donner des prises aux acteurs pour qu’ils puissent définir sémantiquement et faire évoluer facilement et de façon flexible le jeu complexe des rôles et des droits qu’impose la co-construction sémantique. Par exemple ils pourront prescrire les contours de la sous-communauté des membres, par exemple parce que plus compétents ou volontaires, qui seront autorisés à consulter ou à structurer les thèmes de tel ou tel Point de Vue. Une telle souplesse est nécessaire car en matière de co-construction les initiatives telles qu’Agora sont souvent sur un terrain sensible qui demande une réflexion particulière en matière de management. La co-construction sémantique porte sur des connaissances souvent stratégiques et ne peut réussir qu’en intégrant le fait que les cultures et les règles sont très différentes d’une organisation à l’autre. La façon du groupe de s’auto-organiser doit aussi pouvoir varier en fonction des différentes phases de la co-construction (« amorçage », « rythme de croisière »...), phases qui elles-mêmes vont varier suivant les cas et doivent pouvoir ne pas suivre un schéma unique et prévisible.

Fig.1.8 - Agora en mode contribution: choix d’un thème pour indexer une entité

Pour les tâches de structuration sémantique, vu l’option prise dans Agora de rendre possible une co-construction collective de la carte (au moins par l’ensemble des maîtres d’ouvrages, et certains maîtres d’oeuvre), il était clair que nous sortions du cercle rassurant des opérations somme toute courantes en gestion de contenus Web (dépôt de documents, indexation, création et maintenance des arborescences de navigation par un administrateur unique), nous obligeant clairement à nous poser des questions de recherche. Nous étions confrontés à résoudre les nombreux problèmes posés lorsque le contributeur ne trouve pas le thème qu’il souhaiterait sur la carte (donc à rechercher des solutions pour mieux visualiser ou parcourir la carte) ou encore, lorsqu’il a besoin que soit rajouté à la carte un certain thème qui n’existe pas déjà et qui lui semble bien adapté pour caractériser l’entité qu’il décrit. Déjà dans la première version d’Agora, comme on peut le voir sur la figure 1.8 (en haut à gauche, un bouton avec la mention « submit requests on topics »), nous avions imaginé des processus simples pour résoudre les besoins d’édition de la carte de thèmes ressentis par utilisateurs.

Dans la suite, nous avons cherché à aller beaucoup plus loin et l’interface permettant de « structurer » a visé à permettre aux membres de la communauté munis du rôle de structuration sémantique de pouvoir eux-mêmes ajouter ou modifier les termes en les plaçant au meilleur endroit: ce rôle « éditeur » permet de créer ou modifier le nom du thème, les commentaires associés (ex: définition, traduction), sa position dans l’arbre. Comme nous le verrons au §6.4 dans l’examen du système Agoræ, dans un mode graphique analogue au mode précédent, l’éditeur pour créer un thème dans la carte coche le thème parent (un seul thème-père possible, à choisir dans l’arborescence) et éventuellement en cas de relations transversales il indique tous les thèmes associés à ce thème dans la carte. Ce rôle humain d’éditeur sémantique, lui-même inséré dans une communauté de pairs également éditeurs sémantique, sur lequel nous aurons l’occasion de beaucoup revenir, est à l’évidence un rôle dont la responsabilité est grande dans un collectif métier, à la fois sur le plan épistémique et sur le plan relationnel, ce qui nous a amenés à réfléchir à ce qui était nécessaire au niveau de nos modèles pour que les personnes endossant ce rôle soient convenablement outillées:

• en pouvant « signer », assumer toutes les opérations qu’elles effectuent et éventuellement les simuler, les poser à titre provisoire, les justifier par des commentaires ou les accompagner de questions ou de demandes (destinés à d’autres membres concernés ou émis à la cantonade) ;

• en ayant sous les yeux l’historique et toutes les informations nécessaires pour peser leurs décisions (par exemple quelles sont les conséquences de la suppression d’un thème, en termes de thèmes-fils, d’entités rattachées, et de relations avec les personnes impliquées) ;

• et surtout, comme un éditeur n’est pas seul à pouvoir structurer le système, et a des comptes à rendre aux cercles encore plus nombreux de ceux qui interviennent en mode « contribuer » et « consulter », l’éditeur sémantique doit être capable de connaître via le système les autres membres concernés par son action, leurs remarques et réactions. Il doit pouvoir échanger des arguments sur toutes les opérations effectuées, et coopérer de façon organisée avec eux.

En fait la liste des problèmes et contraintes à résoudre est beaucoup plus longue. Nous en avons cité certains, à l’occasion de cette « visite guidée » d’Agora, pour introduire plus facilement le lecteur dans les problèmes scientifiques qui vont suivre. Les problèmes liés aux ontologies sémiotiques sont en effet plongés dans la dimension techno-organisationnelle des univers de co-construction sémantique sur le terrain, avec leur cortège de termes (acteurs, rôles, thèmes, opérations, points de vue…) qu’il est nécessaire d’intégrer pour pouvoir parler de ces problèmes et les reformuler sur le plan des disciplines scientifiques concernées, d’où l’importance de ce chapitre de préambule pour mettre ces termes de notre modèle « en situation ».

Nous ne prolongerons pas davantage dans ce chapitre l’évocation des fonctionnalités d’outil, préférant rester à une vison encore assez vague des modèles Hypertopic et KBM que l’on voit ici à l’oeuvre. Il sera plus intéressant d’y revenir de façon approfondie au chapitre 6 lorsque le cadre théorique aura mieux été posé, pour étayer une réflexion approfondie sur les modèles et sur l’outil Agoræ, qui à la date d’aujourd’hui est plus abouti que l’application Agora que nous venons de montrer.

Ce bref aperçu de l’interface de l’outil et des processus et activités qu’il suppose nous a semblé cependant utile pour comprendre à grands traits la structure d’une carte de thème, sa « légende » si l’on préfère. Car pour en revenir au terrain de notre entreprise de télécoms, il est frappant de voir comment les acteurs se sont emparés des éléments du modèle. « Schéma de classification », « points de vue », thèmes » « sous-thème de », « relation transverse vers », « entités-projets », « composants », ont assez vite fait partie du vocabulaire de nos interlocuteurs. Pour ces acteurs du système, qui ne possédaient pas de formation particulière pour la gestion des connaissances, ces éléments du modèle ont pu être rapidement assimilés et sont devenus des supports à l’expression des enjeux dans les discussions internes du groupe de référence.

Ce n’est pas la moindre leçon de cette expérience autour de la genèse de l’application Agora: avant d’être un modèle de conception à but informatique, le modèle a d’abord servi comme un outil pédagogique et comme une grille organisatrice du travail de conception collective qui était en jeu. Il représente alors, ainsi que nous le verrons au chapitre suivant, une base pour un « modèle de l’activité », instrumentée ou non, c’est à dire que le modèle peut même avoir de l’effet ensuite, y compris s’il n’y a pas d’outil informatisé. C’est un modèle conceptuel qui a servi aussi pour parler

dans le « groupe de référence », permettant un minimum de langage commun pour exprimer ce que nous nommerons « l’activité socio sémantique explicite » (cf. §3.3.5). A ce titre, les éléments du modèle ont servi de guides dans les discussions sur les choix fondamentaux (Quelles entités ? Quels points de vue ? Quels acteurs vont avoir le rôle « structurer » ? Etc.). Indépendamment de l’outil Agora qui allait rendre l’artefact résultant disponible sur l’extranet, c’est ce qui se passait en arrière-plan, en termes co-construction et de gestion collective de connaissances, qui était le principal enjeu.

1.4. L’importance du modèle dans les discussions de