Le point d’entrée « par le système »

2.3.2.1. Définition du système comme système techno-organisationnel

Dans cette approche, nous visons l’élaboration et la validation d’un système, conçu de façon large comme un outil collecticiel accompagné de son modèle d’usage, autour duquel va être construit sur un terrain social un système à visée de gestion de connaissances dans un groupe, qui est un système techno-organisationnel. Nous avons donc affaire, avec une carte hypertopique co-construite dans un domaine, à un système technique qui est à la fois immergé dans un système d’usages et dans un système social, l’ensemble étant un système techno-organisationnel. Agora (cf. Chapitre 1) donne l’exemple d’un tel système. La spécification d’un tel système suppose l’émergence (très problématique) de l’expression d’un besoin, dans une optique d’ingénierie qui soit ouverte c’est à dire considérant la réalité sociale des acteurs concernés par la spécification et la complexité de leurs justifications8. Dans ce point d’entrée par le système, nous devons donc préciser comment nous envisageons d’étudier et de valider ce système, à la fois comme tout et en tenant compte de ces niveaux d’immersion dans les usages individuels et sociaux.

En tenant compte de la limite qui vient d’être posée (cf. §2.2.4) pour distinguer l’évaluation au sens de l’Ingénierie d’avec l’évaluation au sens des Sciences de Gestion, c’est à ce niveau d’ensemble qu’il faut prévoir un cadre méthodologique de conception et d’évaluation du système au sens de l’Ingénierie.

Nous allons maintenant détailler les conséquences méthodologiques de ce point d’entrée par le système, qui permet de poser dès le départ un cadre intégrant classiquement la façon de concevoir l’outil et d’interpréter les retours des expérimentations de terrain dans le sens d’une amélioration de cet outil.

2.3.2.2. Les quatre niveaux de validation du système

Comme on vise ici un système techno-organisationnel complexe, faisant appel avant tout à la communication d’acteurs sociaux dans des univers de connaissances qu’ils cherchent à expliciter en commun, il semble nécessaire de chercher à dépasser les approches de validation utilisées classiquement dans les domaines de l’informatique et des systèmes d’information, Nous pouvons pour cela nous appuyer sur les acquis de l’Ingénierie des connaissances. L’IC situe bien en effet les systèmes qu’elle étudie et propose, comme « des systèmes informatiques immergés dans des systèmes d’usage » [CHARLET 00].

8 La question d’une cartographie des justifications est un point que nous avons abordé dans un travail antérieur, concernant l’ingénierie de systèmes à base de connaissances [CAHIER 92]

Dans cet ordre d’idée, au dessus du socle que constitue le système technique, c’est le système d’usages proposé à l’utilisateur qui va beaucoup nous intéresser. On n’est plus seulement dans le cas d’une « application » avec une interface « homme-machine » au sens de l’ingénierie informatique classique. Le système d’usages est à considérer, en tant qu’il mobilise des notions d’emploi du système technique, mais aussi des connaissances de domaine portées par des acteurs, des documents porteurs de contenus de connaissances de domaine et demandant une interprétation, etc.

De plus l’utilisateur n’est pas isolé mais en interaction avec d’autres utilisateurs du système. La notion de système d’usage doit donc être étendue à l’ensemble du système techno-organisationnel que nous visons, et la notions d’utilisateur idéalisé doit s’effacer au profit de la notion d’acteurs individualisés et différenciés sur le plan social. Valider le système va donc alors mobiliser un vaste ensemble qui inclut des méthodes, des critères d’efficience et de validation par rapport à une organisation, des règles de gestion associées.

Donc dans cette approche d’ingénierie de système techno-organisationnel, compte tenu du fait qu’il inclut des aspects de connaissances et d’interactions entre les membres du groupe, il faut que l’ensemble « fonctionne » à quatre niveaux:

• 1) au niveau du système technique, car le logiciel doit fonctionner sans erreurs conformément aux spécification de son modèle de conception, et in fine l’instrumentation reposera sur des formes informatisées, susceptibles d’être implantées via les registres de machines Von Neumann.

• 2) au niveau de l’usage par un utilisateur solitaire et stéréotypé, suivant un modèle prenant en compte l’interface homme-machine: des notions d’ergonomie et d’utilisabilité seront notamment vérifiées à ce niveau ;

• 3) au niveau de l’acteur, considéré socialement, toujours de façon stéréotypée et idéalisée selon un modèle, comme participant à une activité et à des interactions intentionnelles avec les autres membres du groupe. C’est notamment à ce niveau que l’on va pouvoir prévoir, dans le cas des ontologies sémiotiques, les scénarios d’interaction « socio sémantique » par lesquels les membres échangent sur les points de vue, les thèmes et d’une façon générale leurs interprétations sur la sémantique du domaine ; c’est aussi à ce niveau que l’on va devoir prévoir des types d’essai permettant de prendre en compte les données volumétriques d’une application TCAO, supposant de nombreuses actions parallèles et accès concurrents (nous donnerons au §3.3.2 un ordre de grandeur de cette volumétrie fonctionnelle, qui est de nature à poser de réels problème dans l’optique de construire des solutions robustes)

• 4) au niveau de l’acteur social non idéalisé dans le groupe réel. Le système techno-organisationnel joue le rôle attendu dans l’accomplissement des buts d’activité de la communauté, suivant les critères (relationnels, épistémiques, critères de gestion…) dont la communauté se dote pour apprécier son développement.

Nous avons proposé au §2.2.4 de laisser ce quatrième point particulièrement délicat aux méthodes des Sciences de Gestion (ou d’autres Sciences Humaines et Sociales qui seraient candidates), en suggérant notamment dans le Tableau 2.1 une grille d’interface permettant une approche constructive entre la Gestion et l’Ingénierie.

Restent les trois points précédents, pour lequel nous pouvons proposer la représentation systémique suivante reposant classiquement sur un empilement de « couches ».

Fig.2.1 - Les niveaux d’évaluation dans le point d’entrée par le système

2.3.2.3. Limites de ce point d’entrée et explorations

Dans le point d’entrée par le système, nous nous appuierons donc sur ce schéma pour valider le système techno-organisationnel, selon une conception assez courante en Ingénierie.

Cependant, ce schéma n’est pas complètement satisfaisant. Certes on peut considérer que le contenu du bloc « fonctionnnement technique » renvoie directement au logiciel et à la validation de son modèle de conception. Mais la situation est moins claire quand à la nature exacte des blocs exprimant le fonctionnement en terme « d’usages », en particulier si l’on considère notre sujet d’étude. En effet nous savons par l’exemple d’Agora que ces usages recouvrent une activité très complexe impliquant la mise en oeuvre d’un modèle de représentation de connaissances, d’un modèle d’interactions et d’une communication par lesquels les acteurs vont notamment discuter et modifier un artefact. Le schéma de la Figure 2.1 fait l’hypothèse qu’il existerait au niveau 3 un répertoire d’usages sociaux relevant d’un modèle d’activité prescrit, et que ces usages sociaux font appel à des scénarios d’usages nominaux au niveau 2 du schéma. Mais cette grille d’analyse ne nous permet pas de prendre en compte de façon très détaillée la nature des scénarios qui découlent de cette hypothèse.

En d’autres termes, nous devrions aussi pouvoir prendre en compte, dans la validation du système techno-organisationnel complet au sens de l’Ingénierie, certains aspects d’interaction et de communication. Il faudrait s’assurer dans les tests que, par exemple, le système a bien prévu pour un rôle donné la façon de faire des remarques, d’y répondre et de réaliser les discussions nécessaires, quand il s’agit se mettre d’accord sur le bon libellé d’un Thème ou de marquer un conflit non résolu sur son emplacement, etc. Il faudra aussi vérifier que ces annotations et ces discussions peuvent être

Fig.2.1 - Les niveaux d’évaluation dans le point d’entrée par le système

Fonctionnement technique Usages sociaux prescrits

Usages nominaux Fonctionnement technique

Fonctionnement technique Usages nominaux

1) Test/amélioration du système informatique suivant les critères techniques (conformité aux spécifications):

2) Test/amélioration du système d’usage suivant les critères d’usage « nominaux » pour un utilisateur individuel, ou pour un contexte « multi-utilisateurs » hors socialisation

3) Test du système vu comme système techno-organisationnel, dans le modèle d’activité prescrit

Exécution du jeu d’essais techniques par l’équipe d’informaticiens Activité (conforme à un modèle) d’ utilisateurs socialisés stéréotypés Scénarios de participation à cette activité dans le cadre d’ interactions intentionnelles entre membres.

Le modèle prend en compte le fait que les connaissances ne sont pas forcément explicites ni consensuelles) Exécution de scénarios d’usage ou de cas d’utili-sation avec contenus et multi-utilisateurs

- sans intercations sociales

-« de bonne volonté »

-connaissances cohérentes

-(peu de possibilité à ce niveau de conflits d’interprétation) Qualitfication technique du système Utilisabilité, convivialité, ergonomie en contexte d’usage nominal

Le système joue le rôle attendu pour le modèle d’activité et de connaissances considéré Boucle d’amélioration Boucle d’amélioration Boucle d’amélioration

réalisées avec efficacité via l’outil. C’est ce que nous entendons par « prendre en compte de façon plus détaillée la nature de ces scénarios » d’interaction et de communication, afin de valider que le modèle et l’outil rendent bien le service attendu.

Pour cela, il est peut-être plus utile de penser les formes de validation dont nous aurions besoin en les rapprochant d’une représentation, non plus en termes de couches empilées, mais en termes de flux de communication. Nous proposons donc à titre exploratoire une telle représentation, pour mettre en discussion le diagramme à trois niveaux précédent. Une représentation en flux nous semble justifiée par l’idée qu’une vue « processuelle », mettant en avant la communication des acteurs en raffinant leurs rôles, permet d’approcher plus finement les notions de pertinence et de performance que l’on cherche à évaluer.

Pour communiquer en effet dans ce contexte médiatisé, les acteurs traversent des « couches » de langages, de modèles ou de logiciel, chacune s’interposant comme un médium supplémentaire opérant sur un plan sémiotique. Cela permet de considérer qu’il y a de très nombreuses sortes et configurations de rôles et d’acteurs, réunis par leurs actions intentionnelles au sein d’un modèle d’activité assez complexe.

C’est pourquoi, là où le diagramme en couches de la Figure 2.1 se révélait trop simplificateur, le diagramme en flux de communication de la Figure 2.2 dans lequel nous le réinterprétons ouvre les possibilités pour asseoir une méthodologie plus conforme à notre approche sémiotique. Même si la validation du système ne peut prévoir toutes les configurations singulières d’acteurs particuliers, au plan méthodologique nous pouvons ainsi mieux approcher cette diversité, par des scénarii prenant en compte les différents rôles et le fait que des univers sémantiques hétérogènes sont en interactions. La validation va demander des scénarii de communication entre acteurs à ce niveau fin.

Fig.2.2 - Les trois niveaux d’évaluation précédents avec une représentation en flux réel de communication

Si l’on « réinterprète » la figure 2.1 en terme de flux de communications:

• Au niveau 1, l’informaticien sans avoir besoin de se servir du modèle d’activité améliore et valide le système suivant ses critères technique habituels.

Fig.2..2 – Rapprochement des 3 niveaux d’évaluation précédents avec une représentation en flux réel de communication

Acteur 1 -rôle r -connaissances {K} Acteur 2 -rôle r’ -connaissances {K’} Utilisateur idéal 1 Utilisateur idéal 2 Informaticien 1) Validation du système informatique suivant les critères techniques intrinsèques 2) Validation du système d’usage théorique suivant les critères d’usage « nominaux » 3) Test du système vu comme système techno-organisatinnel, dans le modèle d’activité prescrit Les niveaux d’évaluation dans le point d’entrée « par le système » (cf. fig.2.1) modèle d’activité

Au niveau 2, « l’utilisateur idéal » que l’on fait intervenir pour vérifier l’utilisabilité et l’ergonomie du logiciel, est amené à agir selon une partie du modèle d’activité prescrit. Son rôle est d’ailleurs souvent joué par l’informaticien ou des membres de son entourage à qui il demande ce service. Les actions attendues de sa part relèvent de scénarios d’usage prescrits, en monde mono-utilisateur (chemins en noir) ou en mode incluant éventuellement ses fonctions « multi-mono-utilisateurs », ou d’interaction (chemins en rouge). C’est par rapport à cet usage nominal que sont décidées les améliorations et que sont sanctionnés au final les tests de recette de la plupart des systèmes que considère l’ingénierie informatique. S’agissant d’un système gérant des contenus de connaissances, ce niveau prend en compte des jeux d’essais de domaines réalistes et des configurations d’activités simples. Par exemple, l’acteur 1 dans le rôle éditeur supprime un thème. Ou l’acteur 1 dans le rôle éditeur prévient le contributeur 2 qu’il veut supprimer un thème qui concerne des entités que le contributeur 2 a déposé. Dans ce deuxième mode, l’interlocuteur (« utilisateur idéal 2 ») est présent juste pour exprimer des scénarios attendus dans ces cas d’utilisation génériques.

Le niveau 3 permet de franchir un cran dans le réalisme de la communication: même s’il reste stéréotypé, l’acteur est maintenant l’utilisateur socialisé du système et se rapproche davantage de l’acteur réel. Son interlocuteur (acteur 2) n’est pas seulement un répondant réflexe. Son univers de connaissances est différent, il prend tout autant des initiatives et amène des contradictions9. La validation prend donc en compte des scénarios prescrits de conflits épistémiques ou relationnels. En conséquence, comme nous le verrons, dans la méthodologie que nous préconisons, notre approche de la validation à ce 3^ème niveau inclura un nombre important de scénarii correspondant au modèle d’activité. Ces scénarii en rapport avec le modèle d’activité permettront d’instrumenter la trace de l’activité et de l’analyser. Nous développerons ultérieurement une telle approche (cf. §8.2.2).

Ces dernières remarques tombent à point pour nous permettre d’effectuer la transition «du « point d’entrée par le système » que nous avons exploré jusqu’ici, vers le cadre méthodologique plus développé, correspondant alors au « point d’entrée par le modèle », que nous estimons davantage apte à servir notre projet scientifique.