Espaces Collaboratifs Ubiquitaires sur une infrastructure à ressources distribuées

Fondements

   L’intelligence collective est une vaste notion qui trouve ses fondements dans divers domaines. En philosophie sociale, elle se définit comme « une intelligence partout distribuée, sans cesse valorisée, coordonnée en temps réel, qui aboutit à une mobilisation effective des compétences » [Lévy1994] . En informatique, elle émane d’études sur les comportements collectifs (insectes sociaux) qui fournissent des méthodes pour la conception d’algorithmes d’optimisation combinatoire [Bonabeau1994, Bonabeau et al.2000], ou encore de travaux de recherche dans le domaine des Systèmes Multi Agents (SMA) [Ferber1995]. Nous constatons que la philosophie sociale s’intéresse, pour sa part, à l’intelligence collective en tant que valeur émergente d’un système complexe par la collaboration entre humains et grâce aux moyens de communication actuels. Quant à la recherche en informatique, elle se consacre essentiellement à la modélisation des comportements sociaux. Par exemple, la kénétique [Ferber1994] consiste à formaliser les principes conduisant à l’auto-organisation d’un SMA par une modélisation des différentes formes d’interaction. Notre démarche est radicalement différente. Nous ne cherchons pas à reproduire artificiellement un comportement intelligent. Nous cherchons plutôt à définir un modèle pour catalyser le potentiel d’intelligence collective présent dans un système complexe et dont l’origine peut être  tantôt humaine tantôt artificielle. Ainsi, comme le montre la figure 1.1, l’espace anthropologique du savoir, introduit par PIERRE LEVY, peut se représenter comme un réseau dont les nœuds sont des agents dotés d’une intelligence humaine (agents humains) ou des agents dotés d’une intelligence artificielle (agents artificiels). Tous ces agents interagissent en offrant des services basés sur leurs compétences. Les ressources informatiques réalisent ici soit du calcul, soit une mise en relation pertinente de ces compétences.

Le paradigme centré-interaction

   L’étude des interactions entre humains et systèmes informatisés est un domaine qui connaît une popularité croissante sous l’impulsion des travaux menés ces dernières années par PETER WEGNER [Wegner1996, Wegner1997, Wegner & Goldin1999]. Le paradigme centré-interaction diffère de plusieurs façons du paradigme centré-algorithme basé sur le modèle de la machine de TURING [Goldin et al.2002, Wegner & Goldin2003]. La notion d’interaction intègre notamment l’idée de réaliser une tâche ou de fournir un service plutôt que de produire, par un procédé algorithmique, des résultats en sortie à partir de données en entrée. D’autres aspects comme l’observation d’un comportement général, ou encore l’importance de l’environnement sur les décisions des agents du système sont des propriétés qui distinguent un système en interaction d’un algorithme. Une récente classification identifie trois niveaux d’interaction dans un système composé d’humains et de dispositifs informatisés [Beaudouin-Lafon2006] :
1. Interaction directe entre un utilisateur et des objets informatiques. Par exemple, le déplacement de fichiers d’un répertoire à un autre au moyen d’un navigateur.
2. Interaction à travers des processus intelligents qui peuvent travailler en arrière-plan et dialoguer occasionnellement avec l’utilisateur pour indiquer, par exemple, la progression d’une tâche.

Aux origines de la théorie des systèmes

   Pendant que DESCARTES divisait les problèmes en une série d’éléments et conduisait par ordre sa pensée du plus simple au plus complexe [Descartes1996], PASCAL s’interrogeait sur la pertinence de comprendre les parties sans en comprendre le tout et inversement. A sa manière, PASCAL a posé les bases de la théorie des systèmes. La causalité linéaire et la causalité circulaire sont deux notions qui  s’opposent. La première est une caractéristique des processus déterministes, à savoir la relation de cause à effet. La seconde est une caractéristique des systèmes complexes qui décrit l’effet de rétroaction d’un système. Donc toutes choses étant causées et causantes, aidées et aidantes, médiates et immédiates et toutes s’entretenant par un lien naturel et insensible qui lie les plus éloignées et les plus différentes, je tiens impossible de connaître les parties sans connaître le tout, non plus que de connaître le tout sans connaître particulièrement les parties (Pensées, Oeuvres Complètes, p.527 [Pascal1963]) La théorie des systèmes, baptisée plus tard la systémique, a véritablement été introduite par un biologiste LUDWIG VON BERTALANFFY pour qui le déterminisme causal s’oppose aux processus stochastiques [von Bertalanffy1973]. Dans le déterminisme, l’état final dépend des conditions de départ. Dans un processus stochastique le principe d’équifinalité et d’organisation au hasard des circonstances favorables permet d’atteindre un état final à partir de différents états initiaux et quels que soient les voies et moyens. L’approche systémique a été par la suite étendue au domaine de la théorie de la communication par un anthropologue GREGORY BATESON qui compare le comportement d’un algorithme avec celui d’une stratégie [Bateson1977]. Dans un algorithme, le comportement est exhibé à partir de règles et de réglages fixés a priori. Dans une stratégie, les ajustements sont successivement établis selon l’expérience acquise a posteriori. Une stratégie a un comportement moins prévisible qu’un algorithme car la stratégie se fixe un but quel que soit le parcours, alors que l’algorithme est déterministe, il dépend des conditions initiales.

Espaces collaboratifs à l’échelle européenne

   Si les espaces collaboratifs héritent à la base des principes des ENT, il s’en démarquent à plusieurs titres. Le terme espace plutôt qu’environnement exprime mieux l’idée d’une souplesse de structure. Le terme collaboratif 2 pluôt que travail suggère davantage de liberté d’action. Ils en étendent fortement les capacités en matière d’organisation, de dimensionnement et se caractérisent par des propriétés telles que l’ Interface Homme-Machine (IHM) multimodale ou encore l’immanence que nous décrirons plus loin. Par la suite, l’idée d’espace collaboratif ubiquitaire prend tout son sens lorsqu’une volonté de déploiement d’infrastructure est envisagée. Toutefois, avant de choisir une infrastructure, il est souhaitable de bien identifier les contraintes imposées à l’architecture. Dans le cadre du projet européen European Learning Grid Infrastructure (ELeGI), nous avons tenté d’identifier ces contraintes et avons exploré les potentialités techniques de GRID. La méthodologie employée a consisté à dérouler des scénarii d’apprentissage collaboratif tout en évaluant diverses technologies de façon itérative. Les développements ont été menés parallèlement aux évaluations. Ceci a permis d’analyser les comportements des utilisateurs dans leur contexte d’apprentissage. Cette méthodologie s’est révélée être efficace dans la mesure où nous avons pu tirer, dès la première année du projet, des enseignements utiles à réinjecter dans les spécifications techniques. Nous avons observé, par exemple, un fort engouement pour un apprentissage collaboratif de nature socio constructiviste. Ce mode d’apprentissage que nous avons décrit dans la section 1.4 considère l’apprentissage comme un effet de bord de la collaboration [Breuker et al.2005] et s’est montré complémentaire aux méthodes formelles d’apprentissage. Alors, plutôt que de structurer des environnements dédiés à un apprentissage formel, nous avons opté pour développer un espace collaboratif le plus générique et le plus évolutif possible. Sur le plan technique, la collaboration fait intervenir des interactions en mode asynchrone et synchrone [Dugénie & Lemoisson2005]. Ceci a définitivement écarté l’idée d’utiliser une technologie WEB traditionnelle. Les projets comme ENCORA et ENTICE adressent surtout le partage d’informations réparties avec des accès en mode asynchrone et peuvent se contenter d’une technologie WEB. Le service de visualisation partagée en mode synchrone adopté par le projet ELeGI a demandé un effort supplémentaire pour trouver des solutions.

Comment remédier à ces inconvénients

   Toutes les solutions de visualisation partagées, citées plus haut, présentent de nombreux inconvénients d’ordres opérationnels. Pour comprendre les contraintes techniques mises en jeu, sur la figure 2.4 la partie haute du diagramme montre comment les solutions qui font appel à de la ressource du poste client sont dans l’incapacité de servir convenablement les autres clients. En effet, sur ce diagramme, avec une collaboration à quatre, chacun peut prendre la main à tour de rôle. En d’autres termes, l’un des agents occupe le rôle de serveur (celui qui diffuse son écran) et les trois autres occupent le rôle de client. L’intensité du trafic va devenir importante au niveau du serveur et ceci proportionnellement au nombre de participants (clients à servir). La capacité de la ligne aux terminaisons du réseau capillaire est dans la plupart des cas insuffisamment dimensionnée. Sur une liaison de longue distance, le goulot d’étranglement se situe le plus souvent à cet endroit du réseau. Un autre inconvénient à ne pas négliger est la sécurité. Ouvrir son poste de travail à toutes sortes d’accès extérieurs n’est souvent pas autorisé par les administrateurs de réseaux. Ceci se justifie par le fait qu’une intrusion mal intentionnée est facilitée par les failles de sécurité connues des systèmes d’exploitation des ordinateurs personnels. La partie basse du diagramme figure 2.4 montre une solution d’architecture qui rationalise l’utilisation des ressources système et réseau. De cette façon, le trafic est distribué entre les services et redirigé vers les agents. Les clients sont sans état car c’est le service qui gère l’état des conversations. Un agent Xi dans l’état actif interagit avec les autres agents par l’intermédiaire de son service associé Si. Par la suite, nous verrons comment les serveurs peuvent être virtualisés et remplacés par des services à état afin de rendre cette architecture parfaitement ubiquitaire (cf. chapitre 3).

Rigidité dans l’organisation des groupes

   En nous référant au chapitre 1, nous constatons que l’autonomie décisionnelle est une condition sine qua none à l’auto-organisation d’un groupe de personnes. Un groupe peut se voir comme un système à la fois ouvert et fermé [Watzlawick et al.1972]. Il est ouvert car chacun des membres qui le compose peut communiquer avec l’extérieur et apporter des éléments nouveaux sur son évolution. Par contre, un groupe est un système fermé du point de vue décisionnel. Toute décision qui influe sur le devenir du groupe doit être prise par le groupe lui-même et non pas par une entité extérieure. Par ailleurs, nous avons vu dans le chapitre 1 que le contexte joue un rôle majeur dans une activité collaborative de type socio-constructiviste. Cette activité se comporte comme un système complexe dont le comportement ne peut être déterminé par avance. A partir du moment où l’humain est intégré au processus, l’intelligence collective émergente des interactions dans ce système repose sur des critères liés à la compréhension,la confiance, le naturel, l’accessibilité ou encore l’interprétation. Autant de critères subjectifs qui  ne peuvent pas être déconnectés des aspects culturels et sociaux dans lesquels les valeurs et les rôles des intervenants sont capitaux pour assurer le fonctionnement du système. Ainsi, toute rigidité introduite dans l’organisation d’un groupe peut nuire à son développement. Dans le cas des systèmes les plus répandus, cette rigidité est habituellement introduite par une mauvaise interprétation de ses concepts constitutifs ou à une nécessité d’appliquer des règles fixées a priori qui n’auront pas été souhaitées par le groupe. La mauvaise intérprétation des concepts constitutifs d’un groupe (utilisateur, membre, droits et permissions) provient d’une confusion largement répandue avec l’héritage des modèles multi-utilisateurs classiques. Par exemple, le membre d’un groupe dans le modèle Unix peut être tantôt un utilisateur tantôt un superutilisateur. La notion de super-utilisateur se distingue d’abord de la notion d’utilisateur par le fait qu’elle n’est pas nominative. Ensuite et surtout, elle est confondue avec une notion particulière de privilèges (ex. le super-utilisateur root a des droits absolus sur tous les services d’un système Unix). Une autre source de confusion vient de la notion même de groupe. Dans le cas d’Unix, comme dans la plupart des systèmes actuels , le concept de groupe peut avoir une signification particulière vis-à-vis de certains utilisateurs : il peut s’agir de leur groupe principal. Or, ce même groupe peut être vu comme un simple groupe vis-à-vis d’autres utilisateurs. Cette caractéristique de groupe principal implique plusieurs situations particulières : un groupe principal est le groupe par défaut de l’utilisateur après qu’il se soit authentifié et un groupe principal ne peut être supprimé. Ces cas de figures illustrent toute la rigidité d’une vaste majorité des systèmes multi-utilisateurs actuels. Ainsi, nous proposons de bâtir notre modèle sur les conditions suivantes :
1. adopter le concept de rôle et une relation ternaire entre le groupe, l’utilisateur et le rôle de l’utilisateur en tant que membre d’un groupe donné ;
2. décliner le concept de groupe en deux autres concepts : la catégorie d’utilisateurs (ex. invité) à la place du groupe principal (en autorisant plusieurs catégories) et la communauté d’utilisateurs.

Harmonisation technologique pénalisante

   Pour qu’un espace collaboratif puisse émerger, il doit au préalable être technologiquement harmonisé. C’est à dire qu’un groupe qui décide de collaborer doit se mettre d’accord sur le choix des outils et des formats de fichiers utiles à la collaboration. De par l’obligation d’installer des logiciels spécifiques à tous ces outils, les solutions actuelles réduisent cette harmonisation au plus petit dénominateur commun des possibilités d’interopérabilité. Un exemple de situation est souvent rencontré avec des utilisateurs de plateformes différentes. Ceux-ci peuvent s’échanger des fichiers dans un format portable comme le pdf ou encore exécuter le même code écrit dans un langage générique tel que Java mais ils ne pourront toutefois pas exécuter des programmes spécifiquement compilés pour une plateforme sur une autre plateforme. Pour éviter de se retrouver dans une situation trop contraignante, les groupes se voient dans l’obligation d’imposer à tous leurs membres une configuration type de plateforme cliente que chaque membre devra adopter. Il est fréquent de voir qu’un service est accessible uniquement pour tel ou tel navigateur configuré de telle ou telle manière. Il persistera toujours des situation frustrantes où des utilisateurs devront faire preuve d’un effort accru d’adaptation pour se soumettre à une plateforme adoptée par d’autres membres du groupe. Bien que cette approche affecte peu les utilisateurs qui accèdent toujours au service par le même poste client et qui font partie d’un seul groupe, elle ne résoud pas le problème des utilisateurs nomades ou membres de nombreux groupes. En d’autres termes, cette approche est une entrave au principe d’ubiquité que nous cherchons à promouvoir. En outre, ces effets cumulés, par une multiplication de barrières d’acceptation, risquent de nuire à la motivation des utilisateurs. Un problème récurrent avec les modèles existants est qu’ils imposent des règles d’harmonisation technologiques contraignantes dès lors qu’une collaboration doit se mettre en place. Les modèles exis Il est important de noter ici (nous le verrons plus loin) que les solutions de gestion des organisations virtuelles dans Grid (en particulier VOMS), hérite des défauts du modèle Unix. tants utilisent la ressource informatique du poste client, notamment la ressource de stockage. Ceci a pour effet de mettre le poste client dans un état statique, complexe à administrer et, parfois, avec des comportements imprévisibles. Ainsi, gérer la ressource au niveau du client ôte toute possibilité d’ubiquité (i.e attachement de l’utilisateur à son poste). Si l’on se place dans un contexte collaboratif où les utilisateurs peuvent être membres de plusieurs groupes, chaque groupe effectue un choix d’applications commun à l’ensemble des membres du groupe mais ce choix peut varier selon les groupes. L’utilisateur se retrouve ainsi dans l’obligation de se soumettre à la maîtrise d’un environnement technologique qu’il n’a pas choisi, et ceci pour autant de groupes dont il est membre, au lieu de consacrer son temps à son domaine de compétence.

Du WEB à GRID

   Alors que le WEB a montré toute la puissance d’une infrastructure pour le partage d’informations distribuées, GRID ouvre un nouveau champ de possibilités avec une infrastructure mutualisant des ressources informatiques réparties géographiquement. De ce fait, GRID apporte de nouvelles réponses à certaines limites intrinsèques du WEB, telle que la coordination des ressources pour délivrer une qualité de service à la demande [Foster2002]. Bien qu’il existe des points de convergence entre ces deux architectures [Talia2002], ce qui distingue foncièrement GRID du WEB sont des différences d’ordre topologique  entre les nœuds de provision des ressources et les nœuds de consommation de ces ressources. Pour expliquer cette évolution, la figure 3.1 nous donne une représentation schématique des trois familles de topologies qui sont apparues depuis l’existence des réseaux informatiques. Les cercles indiquent les terminaisons côté utilisateur tandis que les carrés décrivent les terminaisons du côté des ressources informatiques. Le premier cas correspond à la période qui précéde l’ère internet ; les ressources sont fortement concentrées en un point et découplées des terminaisons utilisateurs. Le second cas correspond à la période qui suit l’apparition des architectures client-serveur et du WEB ; les ressources commencent à être réparties mais restent fortement couplées physiquement aux terminaisons des utilisateurs. C’est la principale raison pour laquelle il n’est pas possible de coordonner les ressources réparties sur une infrastructure WEB. Le troisième cas correspond à une utilisation généralisée de GRID avec des ressources réparties et virtualisées. Les terminaisons des utilisateurs ne sont plus couplées physiquement à des ressources informatiques mais elles sont en interaction avec des services à état, un concept clé de GRID dont nous détaillerons les principes dans ce chapitre.

Table des matières

Remerciements
Préface de PIERRE LÉVY
Introduction générale
Cap vers l’intelligence collective
Un contexte technologique favorable
Motivation, proposition et approche scientifique
Cadre et structure de cette thèse
Chapitre 1 Intelligence collective 
1.1 Fondements 
1.2 Interactions 
1.3 Systèmes complexes
1.4 Approche socio-constructiviste 
1.5 Conclusion : mise en relation de compétences réparties
Chapitre 2 Espaces collaboratifs ubiquitaires 
2.1 Panorama
2.2 Services d’un espace collaboratif ubiquitaire
2.3 Limites des solutions existantes 
2.4 Caractérisation
2.5 Recommandations pour le déploiement 
Chapitre 3 Infrastructure à ressources distribuées 
3.1 Evolution conceptuelle et technologique 
3.2 Principes
3.3 Synergie entre GRID et les SMA
3.4 Projection future 
Chapitre 4 Modèle et plateforme AGORA 
4.1 Cadre conceptuel 
4.2 Description fonctionnelle
4.3 Développement du prototype AGORA
4.4 Développement du service COLLABUREAU
4.5 Intégration 
Chapitre 5 Expérimentations 
5.1 Objectif et méthodologie 
5.2 Cadre expérimental général 
5.3 Scénarii d’expérimentation
5.4 Résultats majeurs  
Chapitre 6 Synthèse 
6.1 Bilan 
6.2 Discussion
Conclusion et perspectives
Annexe A : Fonctions AGORA
Annexe B : Procédures PISA
Table des figures
Liste des tableaux
Definitions
Abréviations
Bibliographie

Télécharger le rapport complet