Architecture du simulateur

général. La classe SimuLauncher permet de lancer une (ou plusieurs simulations) via l'application (successive) de sa méthode run(). Celle-ci consiste essentiellement en l'initialisation de l'Organisation ciblée et en la répétition de la méthode step() d'une Simulation.

Chaque Simulation peut être associée à plusieurs SimuViewer, chacun ayant alors la main à chaque pas (step()) pour collecter, calculer et/ou renvoyer des informations à l'utilisateur. Les SimuViewer peuvent être accrochés (handleView) et décrochés (unHandle) de la Simulation, en général au niveau de la méthode run(). Par ailleurs, chaque Actor de l'Organisation à également la main, suivant les règles d'ordonnancement choisies dans la méthode step(). Chacun verra alors sa méthode to_act() déclenchée. C'est également au sein de la méthode step() qu'est gérée la mise à jour de l'état des Relations suite aux actions générées au préalable.

Figure VII.4 - Diagramme de classes du simulateur.

L'objet Organisation recouvre de nombreuse informations importantes pour le fonctionnement de chacun des modules. Par soucis de cohérence sémantique la classe Organisation sera à terme éclatée en une classe Organisation, et une classe Paramètres.

En effet la classe Organisation est construite autour d'une structure de donnée puissante, dont l'objectif premier était de pouvoir étendre et modifier la structure d'un SAC et les modèles d'agent, sans avoir à tout réécrire ou recompiler à chaque modification. Partant du postulat que toute organisation pourrait être décrite par un ensemble d'entités et un ensemble de relations binaires entre ces entités, nous avons articulé tout notre développement autour d'une structure permettant d'ajouter à la volée autant de caractéristiques que désiré pour n'importe quel type d'élément (pour nous ActorKey41 et Relation) ainsi que pour n'importe quel type de relation binaire orientée (ActorKey-ActorKey, ActorKey-Relation, Relation-ActorKey, Relation-Relation). La structure s'est avérée si simple et si puissante à utiliser42, que cela a été fait au dépend d'une certaine cohérence sémantique de la classe Organisation, puisqu'elle sert à mémoriser les paramètres des simulations.

En terme de fonctionnalité, la classe Organisation permet toutes les opérations nécessaires à la construction et à la manipulation d'un SAC ainsi que l'accès à l'ensemble des indicateurs ex situ et in situ.

3 Module d'édition

Le module d'édition permet de construire, modifier, dupliquer, sauvegarder et annoter un modèle de système d'action concret (voir Figure VII.5 et Figure VII.6). L'outil présente une interface ergonomique qui permet dans un premier temps de fournir une description générale de 41 La classe ActorKey sert à identifier les acteurs alors que la classe Actor est une classe abstraite dont les classes

filles décrivent des modèles de rationalité. Chaque acteur est alors implanté comme un objet ActorKey lui même associé à un objet Actor pour les besoins des simulation.

l'organisation considérée, ainsi que de définir les acteurs et relations la constituant. L'utilisateur peut ensuite définir les contrôles, les enjeux et les solidarités (éventuellement imprécis), ainsi que les fonctions d'effet pour chaque paire acteur-relation. L'utilisateur peut justifier chacun de ses choix et générer un rapport de modélisation après avoir sauvegardé son travail sous la forme d'un fichier XML de l'Organisation sérialisée43.

Comme évoqué ci-dessus en section 1, ainsi que dans les Chapitres IV et VI, il est essentiel que l'utilisateur de SocLab puisse documenter le modèle d'une organisation qu'il est en train de produire. D'une part, pour ne pas être prisonnier des contraintes de la formalisation, il lui faut expliciter l'analyse sociologique sous-jacente à son modèle : pourquoi tel acteur, à quel comportement correspond la valeur -1 de l'état de telle relation, etc.. D'autre part, cette explicitation des éléments du modèle est indispensable pour être en mesure d'interpréter les résultats que fournit SocLab, qu'il s'agisse des états remarquables, des indicateurs ou des résultats de simulation.

L'utilisateur peut ainsi effectuer sa modélisation en justifiant chacun de ses choix dans les termes du discours habituel du sociologue. Il peut définir et associer une ou plusieurs sémantiques aux différents intervalles constituant le domaine de valeur de l'état de chaque relation. Ces choix établis, faciliteront la définition des fonctions d'effet et l'interprétation des résultats de simulations (voir Chapitre VI). Par ailleurs tout ce travail descriptif est une réelle plus value dans un travail collaboratif, puisqu'il en reste une trace sous forme de fichier et également sous la forme d'un rapport qu'il est possible de générer automatiquement.

Figure VII.5 - Modélisation d'une organisation. A gauche : définition des acteurs et des relations à droite et en bas : définition d'une échelle d'interprétation.

Figure VII.6 - Modélisation d'une organisation. De gauche à droite : ensemble des fonctions d'effet, définition des solidarités entre acteurs, et l'édition d'une fonction d'effet.

4 Module d'analyse statique

Après avoir modéliser une organisation, il est possible de calculer les indicateurs ex situ à l'aide du module d'analyse statique. Les indicateurs peuvent être visualisés sous forme de tableaux ou de réseaux. Les réseaux peuvent directement intégrés au rapport. Les tableaux peuvent être copier depuis SocLab vers n'importe quel document textuel ou feuille de calcul. Toutes les données (nœuds des réseaux et colonnes des tableaux) sont par ailleurs manipulables afin de faciliter la lecture des résultats44.

Figure VII.7 - Indicateurs ex situ dans le module statique. A gauche : représentation sous forme de graphes, et à droite : représentation sous forme de tableaux.

5 Module de simulation

Le module de simulation, dint l'architecture a été présentée en section 2.3, dispose d'une interface permettant de paramétrer les simulations par l'état initial des relations et la valeur des paramètres des modèles de rationalité sélectionnés (voir Figure VII.8). Il est possible d'utiliser le mode fuzzy, pour les enjeux et les solidarités des acteurs, afin de tester la robustesse du modèle face à l'imprécision des données (théoriquement récoltées auprès d'acteurs fournissant forcément des informations peu exactes). L'interface permet de lancer la réplication de simulations. Elle 44 Le nouvel outil de visualisation de réseaux ayant servi à produire les schémas du cas Bolet (Chapitre VI) n'est

pas encore intégrer à SocLab. On peut remarquer le manque de lisibilité de l'outil basé sur la bibliothèque Jung (à gauche sur la Figure VII.7) évoqué en Section 2.1.

donne par ailleurs accès aux différents outils du module de synthèse permettant d'en analyser les résultats. Enfin l'outil permet de générer un rapport de synthèse incluant les valeurs des paramètres et les résultats de synthèse (ratio et temps moyen de convergence, moyenne et écart type des satisfactions des acteurs et des états des relations).

Figure VII.8 - Interface de l'outil de simulation.

6 Module de synthèse

Le module de synthèse s'articule autour de deux outils permettant de mieux comprendre la dynamique des simulations et les états de convergence en résultant.

Le premier outil (Figure VII.4 à gauche) permet de visualiser les résultats des simulations concernant les acteurs et les relations (typiquement la satisfaction des acteurs et l'état des relations) et indique si les simulations ont effectivement convergé dans le nombre de pas spécifié. L'affichage montre les graphiques de l'évolution des variables observées que ce soit pour l'ensemble des acteurs ou relations au cours d'une simulation ou bien pour l'ensemble des simulations concernant un seul acteur ou relation (ce qui permet de bien observer la dispersion des résultats des différentes simulations). Les graphiques peuvent ensuite être comparés deux à deux. Dans une perspective de vérification/validation, l'outil permet ainsi de rapidement constater l'incohérence de certains comportements ou résultats de convergence. Il permet également de rapidement situer les zones d'attractions des convergence.

Le deuxième outil (Figure VII.4 à droite) permet de comparer l'état moyen résultant des simulations aux états remarquables de l'organisation (ou aux états définis par l'utilisateur), ainsi que les principaux indicateurs in situ qu'impliquent l'un et l'autre (pouvoir et satisfaction, individuel et cumulé). Si l'interprétation des valeurs de l'état des relations a été correctement documenté, on obtient directement l'interprétation de l'état obtenu45. Pour l'analyse du cas Bolet nous nous sommes servi d'un outil équivalent, si ce n'est qu'il propose de représenter les différents états sous forme de réseaux et qu'il donne accès à l'ensemble des indicateurs in situ proposés dans cette thèse.

Les résultats de ces outils peuvent être exportés dans un rapport de simulation afin de 45 A ce sujet, la Figure VII.4 à droite illustre un cas caractéristique de modélisation sans attention pour

pouvoir être analysés sereinement et collectivement autour d'une version papier.

Figure VII.9 - Module de synthèse. A gauche : comparateur de traces de simulations (graphiques), à droite comparateur d'état à convergence avec différents états remarquables (tableaux).

7 Outils de visualisation

S'il est facilement envisageable de représenter les acteurs et relations d’une organisation comme un graphe, il semble plus difficile de concevoir une représentation de l’ensemble des données du modèle et des indicateurs sur une même vue. Il est par contre plus intéressant de considérer l’organisation comme un objet complexe présentant plusieurs points de vue que les utilisateurs-modélisateurs peuvent visiter suivant leurs objectifs. Ce sont ces considérations qui ont guidé la réalisation de la plupart des interfaces de visualisation de SocLab. Les données peuvent ainsi être visualisées sous une ou plusieurs formes de représentations : graphiques 2D ou 3D/4D, tableaux ou réseaux ; chacune de ces forme de représentation permettant plusieurs point de vue sur l'organisation et les résultats de simulation.

Figure VII.10 - Outils de visualisation. A gauche, SocLab 3D Results permet l'étude de l'évolution d'une variable au cours d'une ou plusieurs simulation par la manipulation dans l'espace et le temps des résultats. A droite l'outil OrgNetEditor permet d'accéder à l'ensemble des indicateurs in situ et ex situ qui

sont alors présentés sous la forme d'un graphe (simple ou bipartie) préalablement ordonné.

Le second leitmotiv dans la réalisation de ces outils est d'offrir la possibilité de manipuler, d'organiser et de comparer les données afin de pleinement s'en saisir. Ces outils de visualisation se présentent ainsi avant tout comme des outils d'interaction.

8 Conclusion

La réalisation de cette thèse a donné lieu au développement de nombreux outils facilitant la modélisation, la simulation et l'analyse d'organisations sociales au sein de SocLab. Un effort important a été investi pour faciliter l'interprétation, l'observation et la manipulation du modèle et des résultats de l'analyse structurelle et des simulations sous plusieurs angles et à travers différents prismes. En l'état, ces outils couvrent l'essentiel de nos besoins dans une perspective de formalisation de la SAO et d'expérimentation in silico de systèmes d'action concret.

Si l'on met de côté les détails concernant la généricité de certains outils, SocLab souffre essentiellement de deux défauts. Le premier défaut est l'interopérabilité avec d'autres outils et langages, qui est pour l'instant assurée par l'export de fichiers depuis SocLab. Il concerne plutôt les prochains développeurs de SocLab, et est lié au choix d'un développement tout-en-Java. Le second défaut est l'impossibilité de construire des modèles de rationalité depuis SocLab sans passer par Java. Cela concerne essentiellement les utilisateurs non-informaticiens qui souhaiteraient créer ces modèles. Afin de répondre à ces deux défauts un prototype fonctionnel d'éditeur de script a été développé (Figure VII.2). Basé sur le langage Lua qui permet l'interface Java-C/C++, l'éditeur permet de manipuler les différentes bibliothèques de SocLab. Il reste toutefois à penser à une utilisation bien intégrée et surtout contrainte de Lua, qui en l'état est assez déroutant pour un non expert.

Figure VII.11 - Prototype de l'éditeur de script Lua pour Soclab.

Il reste également un défi intéressant : faire de SocLab un véritable outil de modélisation participatif. Nous avons affirmé jusqu'ici que la modélisation permettait de partager des connaissances et de les co-construire collectivement. C'est un peu l'idée du tableau noir que tout le monde peut voir et ou chacun peut écrire. Or, jusqu'à présent et dans l'état de nos connaissances, nous n'avons jamais vu un outil de modélisation dédié au sciences sociales qui

fournirait une craie à chaque participant pour interagir dans la même pièce sur le tableau noir. Une recherche approfondie, menée par des ergonomes et des spécialistes en interfaces homme-machine, devrait pouvoir renseigner sur les modes de construction collectives, les situations d'utilisation et les technologies adéquates.

Il existe pourtant des technologies efficaces pour interagir à plusieurs sur la même interface. Les tables multi-touch par exemple s'avèrent être des outils efficaces et peu chers à réaliser pour qu'un petit groupe puisse interagir simultanément sur les même objets. Nous avons réalisé un prototype46 à partir de la plateforme multi-modale OpenTouch pour éprouver le concept. Moyennant un bout de plexiglas, une boite en carton et une vieille webcam, il est possible de s'essayer à plusieurs sur différentes applications interactives. Un deuxième prototype basé sur les travaux de Jonny Lee [Lee & Hudson, 2008] et le principe de réflexion interne totale frustrée [Han, 2005] est en cours de réalisation.