montré clairement les rôles et les outils pour chaque étape de modélisation.

Cependant, le cycle de modélisation de KIMONO est en effet compliqué et les outils proposés restent limités. Les manuels permettant l'utilisation des outils et logiciels sont absents. Les travaux portant sur cette méthode ont bien analysé la collaboration entre des rôles de contributeurs dans la conception des modèles. Néanmoins, l'auteur n'a pas indiqué comment on effectue cette collaboration. Dans la méthode, on voit seulement comme une juxtaposition des différents intervenants. De plus, comme pour les deux dernières méthode (Commod et ARDI), la collaboration abordée sont souvent face-à-face. La collaboration à distance qui sont actuellement le scénario commune n'est pas préoccupée pertinemment.

### 3.2.6 Synthèse

Au cours de cette section, nous avons examiné quelques méthodes de modélisation et simulation des systèmes complexes. Nous avons commencé avec l'approche de Fishwick et Gilbert & Troitzsch [Fishwick 1995, Fishwick 1997, Gilbert 1993, Gilbert 1999] qui est considéré à l'origine de plusieurs méthodes actuelles. Ces méthodes nous ont donné une vue générale sur le processus de modélisation et de simulation de tels systèmes. Cependant, la traduction du modèle initial en un modèle calculable présentée dans ces méthodes apparaît comme naturel et elle est orientée tâche au lieu de modèle.

Ensuite, la méthode de modélisation et simulation orienté agent de [Drogoul 2003] qui a répondu aux inconvénients de ces deux approches est présenté ci-dessus. L'auteur a proposé un processus itératif et incrémental. Cette méthode a résolu la difficulté de l'implémentation du modèle conceptuel en ajoutant une étape intermédiaire qui constitue le lien entre ce que le modélisateur a conçu et ce qui va être implémenté. Un des résultats importants de cette approche est que l'auteur a bien montré les rôles des contributeurs, le modélisateur y est le cœur. De plus, cette méthode propose un cycle de modélisation intéressant qui tient compte de la nécessité de raffiner l'ensemble des modèles tout au long du processus de modélisation-simulation. Néanmoins, l'étape de création du modèle du domaine n'est pas détaillé. D'autre part, cette méthode n'introduit pas la collaboration entre les rôles : le travail à chaque étape est présenté comme des travaux individuels.

Cet inconvénient est surmonté par les trois méthodes suivantes : Commod [Bousquet 2005, Müller 2007], ARDI [Etienne 2011] et KIMONO [Amouroux 2011]. Ces méthodes proposent un cycle de modélisation qui encadre l'élicitation de la connaissance individuelle pour conduire à l'émergence de la connaissance collective. Elles impliquent les stakeholders du système étudié au cœur même du processus de modélisation-simulation. Cependant, seul KIMONO développe de manière détaillée les différents rôles à chaque étape, les outils conceptuels nécessaires et les guides de modélisation.

Ces trois méthodes précédemment citées ont mis en évidence l'importance de la collaboration durant le processus de modélisation-simulation des systèmes complexes. Néanmoins, la collaboration à distance qui pourtant s'impose aujourd'hui dans la monde de recherche n'est pas abordée. D'autre part, leurs cycles de modélisation restent encore compliqués (pour ARDI et KIMONO qui impliquent plusieurs termes techniques spécifiques ou lié au problème étudié), ou manquent de détail (pour Commod qui présente pas en détail les modèles conçus à chaque étape). De plus, elles ne proposent pas d'infrastructures logicielles pour réaliser chaque étape
de modélisation.

Si l'on voulait utiliser une de ces approches pour concevoir et rendre collaboratif un simulateur, une méthode de modélisation et simulation serait idéale si elle offrait :

- Un cycle de modélisation simple, claire et complet.

- Une spécification des rôles des contributeurs et leur collaboration à chaque étape

- Des outils conceptuels : Chaque étape est représentée par des modèles

- Des outils logiciels pour la conception : Chaque étape est soutenue par des outils pour la rédaction de modèles

<table><caption>TABLE 3.1 – Comparaison les méthodes de modélisation et simulation</caption><thead><tr><th></th><th>Fishwick et<br>Gilbert&Troitzsch</th><th>Drogoul<br>et al</th><th>Commod</th><th>ARDI</th><th>KIMONO</th></tr></thead><tbody><tr><td>Cycle de modélisation</td><td></td><td>x</td><td></td><td></td><td></td></tr><tr><td>Spécifier des rôles</td><td></td><td>x</td><td></td><td></td><td>x</td></tr><tr><td>Outil conceptuel</td><td>x</td><td>x</td><td>x</td><td>x</td><td>x</td></tr><tr><td>Outil logiciel</td><td></td><td></td><td>x</td><td>x</td><td>x</td></tr></tbody></table>

La synthèse de ces méthodes est présentée dans le tableau 3.1. Notre méthode va adapter les points forts de chaque méthode.

Ainsi, nous allons nous baser sur les résultats de [Drogoul 2003] et KIMONO [Amouroux 2011]. La collaboration entre des rôles est mise en évidence dans Commod [Müller 2007], ARDI et KIMONO. Mais dans KIMONO l'auteur ne mentionne pas comment obtenir ça, et les outils associés. Tandis que Commod et ARDI supportent seulement la collaboration face à face, qui est difficile à effectuer dans la réalité, aucun outil supports collaboratifs à distance n'est pas présenté. Par conséquent, nous devons proposer des solutions propres pour cette collaboration.

## 3.3 Méthodes pour la conception des collecticiels

Dans cette section, nous allons étudier quelques méthodes de conception des collecticiels pour chercher comment on élicite le modèle du domaine et les outils informatiques associés que l'on utilise souvent pour ce type de travail.

### 3.3.1 Modèle en trèfle

Ce modèle qui est initié par [Ellis 1994] et complété par le travail de [Salber 1995] propose un modèle conceptuel pour déterminer les fonctionnalités d'un collecticiel :

- **L'espace de communication** contient des fonctionnalités permettant l'échange entre des acteurs. Elle est une sorte de communication homme-homme médiatisée, et peut être, par exemple : Messagerie électronique, Chat, messagerie instantanée, Visiophonie ou visioconférence.

- **L'espace de production** décrit les fonctionnalités de production et des accès à des objets partagés. En générale, ils sont spécifiques au domaine d'application [Touzi 2007].
<figure><img src="image_24.png" /><figcaption>FIGURE 3.9 – Modèle en trèfle [Salber 1995]</figcaption></figure>

- L'espace de coordination correspond aux fonctionnalités pour définir les rôles, les tâches et les permissions. Ces fonctionnalités ont pour but de coordonner les acteurs entre eux afin de réaliser une oeuvre commune.

Les trois espaces fonctionnels d'un collecticiel étant définis, il convient néanmoins de noter que certaines fonctionnalités peuvent être à l'intersection de plusieurs de ces espaces. Ainsi, la distinction selon les trois espaces n'est pas stricte car il est tout à fait possible qu'une activité de coordination ait lieu suite à une activité de communication.

3.3.2 RCOM

RCOM (Role-driven Component-Oriented Methodology) est une méthode pour concevoir des systèmes collaboratifs pour le commerce [Park 2004]. L'objectif de RCOM est de supporter la stratégie du commerce collaboratif dans lequel les intervenants commerciaux collaborent interactivement. Le commerce collaboratif a été examiné par trois perspectives : (i) les activités interactives qui sont caractérisées par des communications et identifiées selon la définition des rôles ; (ii) la stratégie orientée communauté est plus important : le consensus est essentiel ; (iii) le partage des connaissances qui nécessite l'utilisation d'un système collaboratif pour supporter les échanges entre les intervenants.

Cette méthode contient trois niveaux d'architecture : conceptuel, logique et physique. Premièrement, au niveau conceptuel, on réalise des analyses concernant la collaboration. Les domaines des rôles et la collaboration sont identifiés en se basant sur la compétence des stakeholders. Chaque domaine de rôle possède plusieurs rôles qui sont les unités détaillés pour effectuer un domaine de rôle. L'interaction entre les rôles est définie comme des événements qui sont décrit par des scénarios en langage naturel. Ces scénarios spécifient l'activité collaboration entre les stakeholders. Chaque unité de ces scénarios est référée comme un *component view* au niveau conceptuel. Au niveau logique, ces *component views* sont transformés en trois
<figure><img src="image_25.png" /><figcaption>FIGURE 3.10 – RCOM [Park 2004]</figcaption></figure>

composants en basant sur leur caractères, comme le composant de donnée, logique et visuel. Enfin, au niveau physique, chaque composant représente ensuite par un élément indépendant, par exemple le composant visuel devient un dialogue ou une fenêtre.

Ce travail propose une analyse de la collaboration à partir de scénarios. Cela permet d'identifier des rôles, des composants et des workflows. Cependant, le fait d'identifier le rôle en se basant sur les compétences peut conduire aux préjugés, à la manipulation, aux témoignages contradictoires, ou à erreur de jugement. D'autre part, les scénarios sont descriptifs, ils manquent alors la capacité d'analyse exploratoire ou explicative.
3.3.3 Méthode CoCSys

CoCSys est une démarche de conception de systèmes collaboratifs mobiles pour utiliser dans
le contexte du Travail Collaboratif (TCAO) Capillaire. Selon la définition de [David B. 2003], le
TCAO Capillaire a pour but d'étendre les capacités fournies par les outils de travail coopératifs
par la construction de ramifications de plus en plus fines, depuis leur utilisation sur des postes
fixes, jusqu'aux clients "légers", mobiles et indépendants.

<figure><img src="image_26.png" /><figcaption>FIGURE 3.11 – CoCSys [DELOTTE 2006]</figcaption></figure>

CoCSys est un processus itératif de conception centré utilisateur qui s'appuie sur 4 grandes phases de transformation et sur 3 modèles, comme présenté dans la figure 3.11. Son principe est de créer des applications collaboratives ayant comme point de départ l'identification des besoins à l'aide de scénarios appropriés (scénario contextualisés).

La première phase (Phase 0 dans la figure 3.11) vise à identifier des scénarios par des discus-
sions avec des utilisateurs potentiels. Ensuite, à partir des scénarios conçus, CoCSys les organise
au sein d'un modèle comportemental CAB (Contextual Application Behaviour) (fig 3.11 Phase
1) par une transformation dans laquelle les scénarios sont étudiés pour extraire les informations
nécessaires. Ce modèle contient l'ensemble des concepts utilisés pour des applications collabora-
tives : acteurs, rôles, activités, workflow, artefacts, documents ou outils. Après ça, à la deuxième
phase de transformation (fig 3.11 Phase 2), le modèle CAB est converti pour plus de description.
C'est en fait une projection du modèle CAB en une architecture collaborative prédéfinie qui est
structurée en 3 niveaux : Application collaborative, Infrastructure du Groupware et Système
Distribué. Enfin, la dernière transformation vise à prendre en compte l'évolution des scénarios
et l'évolution du modèle CAB.

Comme la méthode RCOM, CoCSys se base sur les scénarios pour analyser les besoins de l'utilisateur. Mais, seulement dans CoCSys, les utilisateurs sont impliqués dans l'étape de collection des scénarios. De plus, CoCSys supportent également deux outils pour faciliter le collection des scénarios et la création du modèle comportemental.

## 3.4 Synthèse

Au cours de ce chapitre, nous avons fait une synthèse non exhaustive des méthodes de conception. Ces travaux nous offre une base solide pour la création d'une méthode supportant à la fois la simulation et la collaboration. En se basant sur ce principe, notre processus sera issu de trois domaines : le génie logiciel, la modélisation et simulation des systèmes complexes et des collecticiels.

Dans la première partie 3.1 page 50, quatre approches du génie logiciel : Modèle en cascade, l'approche itérative et incrémentale, modèle Spiral et Agile sont présentées et analysées. Aucune de ces approches ne répond à nos objectifs car elles sont générales et vastes, tandis que notre objectif est spécifique pour la simulation.

Cependant, ces méthodes ont adoptés des procédés intéressants. Comme le modèle en cascade, notre méthode sera doté d'une démarche réduisant les risques, en minimisant l'impact des incertitudes et d'une structure complète, claire qui facilite la participation des experts du domaine. Pour assurer la qualité du résultat, l'intégration des membres dans un processus de collaboration dans notre démarche semble approprié. Les utilisateurs et les concepteurs de la méthode travaillent dans des domaines très différents. Leur participation dans un processus de collaboration permet de réduire la distance entre eux.

Le modèle Spiral est davantage un cadre de travail guidant la construction d'une démarche spécifique de projet, plutôt qu'une démarche formalisant l'implication de l'utilisateur dans le processus de développement via des interviews.

Quatre valeurs d'Agile sont intéressantes pour notre méthode. Parce qu'elle repose sur un travail de groupe, une équipe soudée qui collabore régulièrement est importante. Cependant, cette méthode n'utilise pas beaucoup la documentation qui occupe, selon[Amouroux 2011], un rôle important pour un processus incrémental. Ainsi, dans notre méthode, elle est bien exploitée pour supporter les concepteurs.

Ensuite, dans la deuxième partie 3.2 page 53, nous avons analysé 5 méthodes de modélisation et simulation des systèmes complexes : l'approche de Fishwick[Fishwick 1995, Fishwick 1997] et Gilbert&Troitzsch[Gilbert 1993, Gilbert 1999], Drogoul et al [Drogoul 2003], Commod [Bousquet 2005, Barnaud 2008], ARDI [Etienne 2011], KIMONO [Amouroux 2011].

Chacune de ces méthodes propose un processus de modélisation intéressant, en particulier celle proposé par Drogoul. L'approche proposée par Drogoul s'appuie sur un cycle de modélisation détaillé et générique. Néanmoins, il est tacitement accepté que toutes les données nécessaires soient prêtes. Aucune méthode pour collecter les données n'est présentée. Ce problème peut être résolu par un processus d'élicitation des connaissances individuelles amenant à l'émergence d'une connaissance collective initiée dans ARDI et COMMOD ensuite développé dans KIMONO. Ces trois méthodes ont mis en évidence l'importance de la collaboration entre les intervenants lors de la conception des modèles. Néanmoins, la collaboration à
distance qui est la situation la plus courante du monde de recherche actuel n'a pas été abordée.

Ainsi une adaptation tirant partie de l'approche KIMONO et de celle proposé par Drogoul et al. offre une base solide pour concevoir et développer une démarche permettant la production de l'outil spécifique demandé. Nous allons donc nous reposer sur ces éléments plus particulièrement la définition de rôles de KIMONO, le cycle de modélisation itératif et incrémental de Drogoul.

Enfin, dans la troisième partie 3.3 page 62, des méthodes et outils supportant la conception des collecticiels sont abordés. Notre outil spécifique va suivre le modèle en trèfle pour identifier des fonctionnalités, et le modèle Clover pour l'architecture.

Concernant, l'élicitation de la connaissance collective des thématiciens, par l'analyse de la méthode RCOM [Park 2004] et CoCSys [DELOTTE 2006], l'approche à la base des scénarios est choisi pour aider ce travail. Elle est peut-être moins formels que celle basé sur les tâches. Mais, elle est plus souple. De plus, les scénarios peuvent être décrits en utilisant un langage naturel, qui peut renforcer la facilité d'utilisation et la compréhension.
<figure><img src="image_27.png" /></figure>
Deuxième partie

Approche pour introduire la
collaboration dans la simulation des
systèmes complexes
<figure><img src="image_28.png" /></figure>
# Vers une nouvelle vision de la collaboration dans la simulation

## Sommaire

<table><tr><td>4.1</td><td>Notre vision de la collaboration</td><td>71</td></tr><tr><td>4.1.1</td><td>Exemples de scénarios collaboratifs de simulation</td><td>71</td></tr><tr><td>4.1.2</td><td>Un simulateur : une boîte noire</td><td>73</td></tr><tr><td>4.1.3</td><td>Le simulateur collaboratif</td><td>75</td></tr><tr><td>4.2</td><td>Proposition d'un méta-modèle de simulateurs collaboratifs</td><td>76</td></tr><tr><td>4.2.1</td><td>Méta-modèle du simulateur collaboratif</td><td>76</td></tr><tr><td>4.2.2</td><td>Besoin d'une infrastructure supportant le méta-modèle</td><td>78</td></tr><tr><td>4.2.3</td><td>Synthèse</td><td>80</td></tr><tr><td>4.3</td><td>Pams : un portail pour collaborer autour d'un simulateur</td><td>80</td></tr><tr><td>4.3.1</td><td>Architecture</td><td>80</td></tr><tr><td>4.3.2</td><td>Technologies utilisées</td><td>82</td></tr><tr><td>4.3.3</td><td>Utilisation du simulateur collaboratif avec PAMS</td><td>83</td></tr><tr><td>4.4</td><td>Conclusion</td><td>85</td></tr></table>

Comme présentée en section 2.2 page 33, la collaboration autour d'un simulateur reste encore difficile. Un des objectifs de notre travail est de résoudre ce problème en proposant une approche permettant cette collaboration. Nous proposons un ensemble d'outils conceptuels et logiciels permettant la collaboration, à la fois, dans un cadre de général de collaboration et dans le cadre de la simulation des systèmes complexes.

Au cours de ce chapitre, nous allons répondre à la question : “Quels seraient les contours d'une plate-forme générique assurant la collaboration autour d'un simulateur ?” énoncé dans la section 2.4 page 47. Pour cela, nous présenterons dans un premier temps les concepts centraux de notre approche, ensuite nous introduirons le méta-modèle. Finalement nous présentons l'infrastructure logicielle qui a été mise en place.

## 4.1 Notre vision de la collaboration

### 4.1.1 Exemples de scénarios collaboratifs de simulation

Avant de présenter notre vision, nous identifions au moyen de quelques scénarios liés à nos objectifs. Ainsi, nous serons en mesure de définir les concepts, les fonctionnalités et les outils à
mettre en place.

## a) Scénario 1 : Expérimentation collaborative synchrone à distance

M.X et Y (chercheurs en écologie), respectivement situés à Paris et à Hanoi, souhaitent lancer des simulations afin d'obtenir des résultats qui seront illustrés dans l'article qu'ils écrivent ensemble. Les deux chercheurs se connectent à leur espace de travail commun et commencent une discussion privée. M. X charge le simulateur souhaité et invite M. Y. à partager son interface. M. X commence à saisir les paramètres de simulation. N'étant pas d'accords, M. Y. commence une session de vidéo conférence afin d'échanger avec M. X ses idées. Il a également déposé sur l'interface du simulateur un mémo indiquant la valeur des paramètres qui semblent corrects. Après un long débat, les chercheurs s'accordent sur les valeurs. M. X lance la simulation et choisit d'afficher seulement le graphique de l'évolution de la biodiversité, tandis que Mr.Y visualise uniquement la distribution spatiale des espèces. Chacun dépose, en temps réel, sur sa propre interface, des annotations explicatives. Ces dernières apparaissent, simultanément, dans l'interface des deux chercheurs. Ainsi, ils amorcent l'ébauche d'une discussion (enregistrée en tant que telle dans le système de messagerie instantanée). Faute de temps, M. X doit partir. Ils décident de reprendre cette discussion plus tard et d'enregistrer la session actuelle. Trois jours plus tard, en revenant sur le site, la conversation redémarre là où elle s'était arrêtée...

## b) Scénario 2 : Expérimentation collaborative asynchrone à distance

M.X et Y (chercheurs en écologie) sont respectivement situés à Paris et à Hanoi. Supposons que M.X a commencé une simulation, mais M.Y ne peut pas participer à la simulation pour des raisons de décalage horaire. M.X choisi des paramètres de simulation, exécute le simulateur et enregistre l'état final de la simulation dans la base de données. Par l'intermédiaire d'outils collaboratifs asynchrones dont le blog, M.X informe M.Y de ce qu'il a fait ainsi que les avancés de sa réflexion. Quelques jours plus tard, M.Y accède à son tour à l'espace collaboratif. Il visualise et analyse les paramètres d'expérimentation ainsi que les résultats de la simulation qui ont été choisis par M. X. N'étant pas d'accord avec les choix de M.X, M.Y change les paramètres qui lui posent problèmes. Il exécute ensuite le simulateur, enregistre les résultats dans la base de données et notifie ses modifications au moyen du blog. Quelques jours plus tard, M.X se reconnecte, il visualise les modifications de M.Y, les analyse et approuve les modifications apportées.

## c) Scénario 3 : Création d'une expérimentation privée puis publique

M.X et Y (chercheurs en écologie et géographie) respectivement situés à Paris et à Hanoi, sont membres d'un projet où plusieurs dizaines de scientifiques participent. Étant donnée la taille du projet, les participants sont organisés en groupes de travail et réalisent des tâches différentes. M.X et M.Y réfléchissent sur un modèle interdisciplinaire. M. X et M. Y souhaitent lancer le simulateur en privé afin de vérifier une hypothèse avant d'ouvrir l'expérimentation à l'ensemble des membres du projet. Les deux chercheurs se connectent à leur espace de travail commun et créent une expérimentation privée. Ils lancent le simulateur et conversent pour déterminer les paramètres qui valideront leur hypothèse. Lorsque les paramètres sont déterminés, M. X et
Y ouvrent l'expérimentation à l'ensemble des membres du groupe. M.Z qui est un membre du groupe se connecte à son tour à l'expérimentation. Étant surpris des résultats, M. Z. décide donc d'approfondir l'expérimentation...

d) **Scénario 4 : Expérimentation collaborative optionnelle avec des rôle différents**

M.A et B, chercheurs en écologie, sont respectivement situés à Paris et à Hanoi et M.C est représentant d'une organisation écologique. Ces trois personnes veulent résoudre un problème posé par M.D portant sur la pollution de l'eau dans les pays d'Afrique. M.E et F sont des modélisateurs appartenant à une université espagnole.

M.C propose une hypothèse sur un forum international et demande de l'aide auprès de modélisateurs et d'experts du domaine. M.A, B, E et F intéressés par la problématique décident de contacter M.C. Ce dernier crée alors un nouveau projet, où M.C est le chef du projet, M.A et M.B sont des utilisateurs, M.E et M.F sont des concepteurs du modèle. M.E et M.F développent le modèle à partir des informations de M.C, M.D, M.A, et M.B. Lorsque des problèmes apparaissent, ils accèdent à leur espace de travail commun afin de collaborer. Après avoir terminé la phase de développement des modèles conceptuels et informatiques, les chercheurs déploient le simulateur sur le serveur pour que les autres puissent l'utiliser. M.C crée une expérimentation du nouveau modèle et invite les membres du projet. Il attribue un rôle à chaque membre : (i) les thématiciens utilisateurs (M.C et M.D) peuvent utiliser toutes les fonctionnalités d'une expérimentation (manipuler l'expérimentation, créer des groupes, ajouter, supprimer des membres...), (ii) les thématiciens concepteur (M.A et M.B) peuvent seulement modifier les paramètres du simulateur, contrôler l'exécution des simulations et analyser les résultats, (iii) M.E et M.F n'ont que le droit de visualiser la simulation.

Au cours de l'exécution de la simulation M.A veut observer seulement les changements du paramètre P tandis que M.B veut visualiser l'image représentative de la topologie d'un espace. Durant la simulation, M.A identifie un bogue. Il souhaite en référer à M.B. Pour cela, M.A autorise M.B à visualiser le paramètre P. M.A et M.B discutent et comprennent la raison du bogue et le corrige. Ensuite, ils continuent leur discussion un long moment et décident d'arrêter pour reprendre un autre jour. Pour cela, ils enregistrent l'état de la simulation dans la base de données. Trois jours plus tard, ils re-accèdent à la plate-forme et reprennent leur travail où ils s'étaient arrêtés.

Les quatre scénarios sont des cas que l'on rencontre souvent dans un projet de simulation. En nous basant sur ces scénarios, nous percevons le simulateur comme une boîte noire.

4.1.2 Un simulateur : une boîte noire

Un simulateur peut être exécuté plusieurs fois avec différents paramètres afin d'expérimenter diverses situations. Dans ce contexte, les thématiciens se focalisent sur les entrées et les sorties du simulateur et se désintéressent du fonctionnement interne du modèle implémenté. Pour cette raison, nous considérons un simulateur comme une boîte noire qui possèdent des entrées et des sorties manipulable par les chercheurs.

De plus, dans un contexte de travail collaboratif, un simulateur doit être manipulable par plusieurs utilisateurs, de concert (au sein d'une même expérimentation) ou en parallèle (dans
plusieurs expérimentations).

<figure><img src="image_29.png" /><figcaption>FIGURE 4.1 – Le simulateur une boîte noire</figcaption></figure>

Par conséquent, la collaboration qui nous intéresse apparaît principalement sous deux formules : (i) soit les échanges, les discussions pour bien comprendre les entrées et les sorties ; ou (ii) soit la manipulation simultanée des entrées et sorties. Ainsi, peu importe le simulateur (simulateur à base d'agent, d'équations différencielles ou d'automates cellulaires), il peut être considéré comme une boîte noire. Finalement les chercheurs ont besoin de manipuler des entrées/des sorties et de conserver une trace des échanges. Cette dernière permet de mettre en place une base de connaissance commune entre les participants.

Selon [Treuil 2008], les entrées sont des paramètres dont la valeur est définie en-dehors du modèle et qui représente ce que le simulateur peut perturber. Tandis que, les sorties sont des variables qui expriment ce que l'on cherche à mesurer en réponse à ces perturbations.

En effet, les entrées manipulées dans la simulation sont les produits d'un processus de la
collection et l'analyse des données. Ces derniers peuvent être obtenus à partir des ouvrages his-
toriques ou des données collectionnées, comme les données des enquêtes ménages-déplacements
de Dijon dans le projet MIRO [Arnaud 2005, Banos 2012]. Après le processus de collection et
d'analyse, les entrées sont représentées sous différentes formes telles que les valeurs numériques,
les chaines de caractères et les fichiers textuels. En se basant sur la forme des entrées, la façon
de les modifier est variée. Ainsi, le support collaboratif est aussi varié et doit être approprié avec
l'entrée et la manière d'échanger. Par exemple, pour une entrée numérique, on modifie simple-
ment par le clavier et le support collaboratif est simple. Mais, pour l'entrée qui est un plan, la
modification est effectué par la souris et les actions drag/drop. Par conséquent, le support de
collaboration est plus compliqué.

La manipulation des sorties dépend également de leur façon de représenter. Comme les entrées, les sorties d'une simulation peuvent être affichés sous formes différentes, comme la valeur numérique, les graphiques, les images ou les fichiers externes.

Par conséquent, nous devons avoir un environnement qui permet de collaborer autour d'un
simulateur en tenant compte de la variété de ses entrées et sorties. Cet environnement doit
être une espace de travail commun qui aide à manipuler différentes types des entrés/sorties et
conserver la connaissance.
4.1.3 Le simulateur collaboratif

Bien que des développements dans le domaine du travail collaboratif assisté par l'ordinateur comme présenté à la section 2.3 page 39, mais l'utilisation courante des postes informatiques pour la simulation est l'utilisation en local mono-poste [Ralambondrainy 2009]. Les acteurs se réunissent en un même lieu pour réaliser la simulation. Car la plupart des simulateurs actuels sont des applications stand-alone qui ne supportent pas l'échange entre des thématiciens.

Dans ce contexte, les technologies de la communication sont souvent utilisées pour supporter des échanges, tel que la visio-conférence. Dans la littérature, nous trouvons trois scénarios possibles pour cela : (i) soit qu'une seule personne gère la simulation et interagisse avec les autres par des outils de communication conventionnels comme la visio-conférence; (ii) soit que chaque acteur dispose d'une copie locale de la plate-forme et du modèle simulé, ce qui demande également des outils de support pour des discussions additionnelles [Ralambondrainy 2009] et (iii) soit qu'une personne utilise un outil collaboratif spécifique permettent de partager des applications via le réseau, comme VNC, NetMeting. Par conséquent, pour le premier cas, il y a seulement un participant qui manipule directement le simulateur. Tandis que dans le deuxième cas, chacun effectue des simulations différentes d'un même modèle. Dans le troisième cas, on doit installer et adapter les outils supports pour l'objet principal de collaboration, ces outils sont souvent dépendant du systèmes d'exploitation, et complexe à utiliser. Cela risque des ambiguïtés, prend du temps et facilement être hors du contexte.

Ainsi, pour résoudre ces problèmes, nous devons mettre en place une solution qui permette aux thématiciens distribués géographiquement d'avoir une même simulation qui entraine immédiatement les thématiciens à la simulation sans perdre le temps pour les tâches inutiles, comme installer des logiciels supports, partager les modèles. Le simulateur collaboratif est une solution convenable pour ce problème. Il s'agit d'une part du simulateur qui permet :

- d'entrer, modifier les paramètres,

- exécuter, arrêter la simulation,

- visualiser, analyser les résultats,

D'autre part c'est un outil collaboratif qui permet :

- la communication, coordination et collaboration entre des thématiciens,

- les manipulations simultanées et à distance,

- plusieurs interactions en même temps,

- de s'adapter au utilisateur

D'une manière générale, lorsque la complexité d'un modèle nous échappe, la simulation joue ainsi principalement le rôle d'une source d'information qui permet d'alimenter les discussions. Ce simulateur est alors un des outils qui nous permet de partager des connaissances, des théories, des hypothèses et des points de vue sur le monde.

Un tel type de simulateur supportera bien les scénarios abordés dans les sections dans 4.1.1 page 71. La communication et l'interaction entre des participants sont indispensables. Mais, la chose la plus importante est la synchronie entre les activités des participants : les participants qui ont un même rôle doivent avoir un même point de vue sur la simulation en même temps. Un simulateur collaboratif devra satisfaire ces conditions.

Nous avons identifié au moyen de quelques scénarios les besoins en terme de simulation collaborative. Ainsi, nous sommes en mesure d'avoir une spécification explicite d'un simulateur collaboratif. Dans les sections suivantes, nous allons identifions un méta-modèle d'un tel
simulateur collaboratif.

## 4.2 Proposition d'un méta-modèle de simulateurs collaboratifs

La simulation collaborative exige une communication efficace et optimisée, et la synchronisation entre les participants et leurs activités. Ainsi, à côté des fonctionnalités collaboratives génériques, nous devons également ajouter des fonctionnalités collaboratives spécifiques à la simulation. Les outils génériques contiennent des outils de communication, de coordination et d'annotation. Tandis qu, les autres contiennent des mécanismes de manipulation collaborative qui permettent des interactions sur le simulateur et ses composants (les paramètres, les moniteurs ou les graphiques). L'objectif de cette section est de proposer un méta-modèle pour le simulateur collaboratif.

### 4.2.1 Méta-modèle du simulateur collaboratif

Selon [Treuil 2008], l'utilisation du simulateur va imposer l'usage d'un méta-modèle. Ainsi, nous avons conçu un méta-modèle pour le simulateur collaboratif en se basant sur trois concepts principaux : le simulateur, l'utilisateur et le rôle (voir la figure 4.2).

<figure><img src="image_30.png" /><figcaption>FIGURE 4.2 – Les concepts de base</figcaption></figure>

- Simulateur : Implémentation informatique d'un modèle

- Utilisateur : Les utilisateurs qui correspondent aux thématiciens utilisateurs. Ces derniers sont définis par un ensemble de compétences.

- Rôle : Le rôle est une représentation abstraite d'une fonction utilisateur, le service ou l'identification dans un projet de simulation. Un utilisateur peut avoir plusieurs rôles, et un rôle peut être utilisé par un ou plusieurs utilisateurs. La notion de rôle est toujours liée à la notion de permission.

En se basant sur ces concepts, nous avons créé un méta-modèle (la figure 4.3) qui permet de décrire un simulateur collaboratif et les interactions entre des utilisateurs et leurs usages. Ce méta-modèle est décrit en utilisant un diagramme de classe UML. Ce langage a été choisi car : il est compréhensible par la communauté scientifique et simple à utiliser.

Ce méta-modèle peut-être divisé en cinq parties, comme illustré par la figure 4.3 :

- le noyau

- les entrés et les sorties

- l'outil et les contrôleurs

- le rôle

- l'utilisateur

Le noyau est composé par la classe *Simulator*. Tous les simulateurs collaboratifs doivent étendre cette classe. Cette classe est associée à : des fonctions de base, des entrées et des sorties cor-
<figure><img src="image_31.png" /><figcaption>FIGURE 4.3 – Méta-modèle du simulateur collaboratif</figcaption></figure>

respondant, respectivement, aux actions possibles (start, stop, step, clic de souris, ...), aux paramètres d'entrée et aux variables de sortie.

Dans ce méta-modèle, nous avons séparé les entrées et les sorties (E/S) du noyau dans la partie 2. Cette séparation nous permet de facilement gérer les opérations sur les E/S. Deux types d'E/S ont été identifiées : (i) *Variable* ; (ii) *Action*. Le premier représente toutes les variable du simulateur, y compris les paramètres d'entrées, les outputs et les variables internes que les utilisateurs peuvent manipuler.

Prenons l'exemple du modèle de fourmis [Wilensky 1997]. Dans ce modèle, *une colonie de fourmis fourrage pour se nourrir. Bien que chaque fourmi suit un ensemble de règles simples, la colonie peut être vue comme une entité qui effectue des actions de manière sophistiquée*. Les *Variables* sont alors la population de fourmis, le taux de diffusion ou le taux d'évaporation.

Une *Action* représente toute activité qui influence le simulateur. Par exemple, : Charger un modèle, installer un modèle, lancer, arrêter le simulateur ou analyser les résultats.

Les entrées et sorties du simulateur sont contrôlées par *VariableController* et *ActionController* qui contient également un ensemble de l'objet *AccessTool*, dans la partie 3. *AccessTool* est un composant de l'interface graphique (bouton, zone de texte, graphique, etc) qui permet soit d'agir, soit d'observer la simulation.

Pour chaque rôle, des permissions sont attribuées à chaque élément de l'interface si bien que pour un même rôle plusieurs éléments de l'interface peuvent être autorisés. Ainsi des interfaces différentes peuvent être affichées en fonction du profil utilisateur.
4.2.2 Besoin d'une infrastructure supportant le méta-modèle

Comme présenté dans les sections dernières, l'infrastructure logicielle occupe une place im-
portante de notre approche. En proposant le méta-modèle, nous devons développer des outils
flexibles et adaptés en vue de permettre d'ajouter des nouveaux outils qui sont appropriés avec
chaque simulateur différent.

Selon [Zier 2005], une des approches efficaces pour concevoir le travail collaboratif est d'utili-
ser une infrastructure générique, extensible. Grâce à la facilité de l'intégration de nouvelles fonc-
tionnalités, une infrastructure peut-être utilisée pour le développement de logiciels collaboratifs
de manière indépendante. Ainsi, le développement de nouvelles fonctionnalités collaboratives
devient facile.

À partie de l'expérience concernant les systèmes de simulation collaborative, nous allons
présenter dans la section suivante des caractères nécessaires pour une telle infrastructure.

a) Caractéristiques minimales d'une plate-forme collaborative de simulation

Le succès de la collaboration dépend non seulement du moyen de communication, mais
egalement de l'environnement utilisé [Otto 2003]. Dans notre travail, les outils collaboratifs
qui permettent de coordonner et de communiquer possèdent un rôle important. Ils aident à
atténuer les difficultés liées à l'éparpillement géographique.

En se basant sur les scénarios présentés dans la section 4.1.1 page 71, les outils et plateformes
devrons satisfaire les caractéristiques suivantes :

- compatibilité avec la plupart des plateformes de simulation pour faciliter l'installation du simulateur venant des plateformes de simulation connues (NetLogo [Stigberg 2012], Repast [North 2006], MadKit [Gutknecht 2001] ...);

- généricité pour permettre la simulation de différents systèmes complexes ;

- convivialité pour être utilisable par des scientifiques venant de domaines différents ;

- être un système distribué pour supporter la simulation à large échelle et permettre la gestion de plusieurs simulations et connections simultanées ;

- être synchrone pour permettre l'échange instantané entre des scientifiques (visio, message instantané, whiteboard ou desktop sharing);

- être asynchrone pour permettre la collaboration en différé (mail, forum ou wiki);

- être basée sur WEB pour être disponible partout et ne rien avoir à installer ;

- être composé des fonctionnalités essentielles à un simulateur pour lancer, arrêter, et ins-
taller des simulations avec plusieurs paramètres ;

- être composé de fonctionnalités avancées pour analyser les résultat de simulation, les
stocker dans une base de données et relancer simulations ;

- être composé de fonctionnalités collaboratives spécifiques dédiées au domaine de la simulation ( modifier des paramètres, partager des résultats, attribuer des rôles différents ... );

- être composé d'un système de gestion d'information publiée-privée pour permettre à un participant de déterminer la partie publique (partagée avec les autres) et la partie privée.

b) Besoin d'une représentation commune
Selon [Reitsma 1996], plusieurs échecs de la négociation proviennent de l'absence de partage entre les négociateurs. Une des méthodes les plus simples pour renforcer cette légitimation est la participation de tous les membres impliqués pour unifier une description commune du travail ou du système qui sera utilisée dans la négociation. En apportant une connaissance commune, ils peuvent empêcher ainsi des conflits dûs à des malentendus ou à de fausses déclarations [Nguyen-Duc 2005]. Cette description commune résout également la difficulté concernant l'asynchronisation entre des thématiciens dans l'usage du simulateur, discutée dans la section 2.2 page 33.

Selon Mathieu [Mathieu 1997], un dialogue ou une négociation entre plusieurs disciplines passe par la construction de références communes rendant possibles le contrôle réciproque des connaissances, même si elles sont de natures différentes. Cette idée est également démontrée par le travail de Quensire [Quensière 1997]. Selon-lui, une attention plus grande des équipes pour la définition de leurs objets serait utile, notamment pour la communauté interdisciplinaire. Cela permettrait de progresser vers une meilleure maîtrise d'une complexité encore trop souvent enfouie sous la gangue des *a priori* et du formalisme cybernéticien. Par conséquent, la difficulté concernant l'asynchronisme entre des thématiciens sera résolue par une définition conjointe des échelles de travail.

Il est évident que, si chacun travaillait seul, on ne définirait pas son objet d'étude de la même façon et n'aurait pas le même questionnement. En participant à une oeuvre commune il se place donc délibérément en marge du problème qui lui est habituel. [Quensière 1997]. Ainsi, pour bien simuler de façon collaborative, au début, le thématicien et le modélisateur doivent réagir ensemble à une description commune qui stocke des informations importantes. Pour cela, nous devons répondre aux deux questions suivantes :

1. Comment organisons-nous cette description commune ? quelles informations sont importantes ?

2. Le thématicien et le modélisateur devront collaborer comment pour réagir cette description ?

Examinons les scénarios dans partie 4.1.1 page 71 illustrant la collaboration pouvant apparaître autour d'un simulateur. Nous constatons que la deuxième question ci-dessus peut être résolue en appliquant un processus collaboratif à l'aide d'outils collaboratifs, comme un éditeur collaboratif, des outils de communication. En ce qui concerne la première question, la description commune contiendra l'information qui cause l'asynchronisme présenté dans la partie 2.2.1 page 34. Après le travail de littérature, nous décidons de chercher dans l'ensemble des travaux existants pour trouver une telle description qui

1. doit être largement utilisée dans la modélisation et la simulation des systèmes complexes. Par conséquent, c'est facile pour les chercheurs de s'adapter notre solution si nous prenons un travail qui est largement utilisé.

2. est un document supportant plusieurs disciplines : en raison de la caractéristique pluridisciplinaire (ou interdisciplinaire) de la simulation des systèmes complexes, la représentation commune est utilisée par les différents acteurs et dans les différentes disciplines. Par conséquent, il doit contenir des informations de toutes les disciplines utilisées dans le projet.

3. présente les informations de base pour bien connaître le modèle.
Plusieurs méthodes proposant une telle représentation ont été présentés dans la littérature, comme Business Process Model and Notation [Dijkman 2008], le modèle de cas d'utilisation [Anda 2001]. Cependant, seul le modèle textuel peut être facilement compris par à la fois par les thématiciens et les modélisateurs. C'est pourquoi, nous allons étendre cette solution pour l'adapter à la problématique de la collaboration dans la simulation. Dans ce contexte protocole ODD [Grimm 2010] semble être le candidat parfait.

### 4.2.3 Synthèse

Dans cette section, nous avons proposé un méta-modèle pour le simulateur collaboratif. Ce méta-modèle est la partie importante de notre approche. Il permet de définir une interface générique pour différents types de simulateur. De plus, ce méta-modèle est assez abstrait. La partie d'E/S est séparé du noyau du simulateur. Il nous permet de travailler avec différents types de données, d'ajouter de nouvelles activités, de nouveaux types d'E/S qui n'influencent pas les autres parties.

Ensuite, dans la deuxième section, nous identifions le besoin d'une infrastructure flexible pour supporter le méta-modèle. Nous essayons également de définir les caractères importants pour une telle infrastructure. Dans les sections suivantes, nous allons présenter une infrastructure qui permet de répondre à tous ces besoins.

## 4.3 Pams : un portail pour collaborer autour d'un simulateur

PAMS (Plate-forme d'Aide à la Modélisation-Simulation) [Nguyen 2008b, Nguyen 2008a] est un environnement collaboratif conçu et développé en collaboration avec l'unité de recherche GEODES (IRD, France) et le laboratoire MSI (IFI, VietNam). Ce projet qui a débuté en 2007 nous a permis de développer une première version de l'environnement PAMS qui a ensuite été refondue pour aboutir à la version actuelle de l'environnement.

Le but du projet est de créer un ensemble d'outils conceptuels et logiciels pour modéliser et simuler des systèmes complexes. Cet environnement associe des outils conventionnels de collaboration (tableau blanc, messagerie instantanée, forums, répertoirs partagés, etc...) avec des outils spécifiques permettant la manipulation de simulateurs, d'expérimentations et de résultats.

Notre travail initie une nouvelle démarche de collaboration dans un projet de recherche. Les modèles et les simulateurs ne sont plus uniquement diffusés au travers de communications scientifiques (articles, conférence...), ils deviennent des objets manipulables à distance, via le Web, et sont ainsi élevés au rang de support de la collaboration.

### 4.3.1 Architecture

L'environnement PAMS est basé sur une architecture à plusieurs niveaux. C'est une architecture à base de composants qui est vue, en génie logiciel, comme une approche de développement modulaire et flexible. L'architecture de PAMS tire partie de l'approche MVC (Model View Controller) [Reenskaug 2003] qui distingue l'interface graphique (View) des fonctions métiers (les contrôleurs) et des bases de données (Modèle). L'approche multi-niveaux [Eckerson 1995] organise les fonctions métiers sous forme de modules qui peuvent être appelés et utilisés indépendamment.
<figure><img src="image_32.png" /><figcaption>FIGURE 4.4 – Architecture de Pams</figcaption></figure>

Cinq modules composent le noyau de l'environnement PAMS (voir figure 4.4) :

- le module *drivers* permet l'interconnexion entre l'environnement PAMS et des plate-formes de simulation multi-agents tel que Repast [North 2006] ou Gama [Amouroux 2007]. Ce module exécute les simulateurs stockés sur le serveur, produit des données et les envoie vers les modules *Sorties*. Il y a un driver par plate-forme de simulation.

- le module *Sorties* rassemble et met en forme les résultats de simulation provenant des drivers afin de partager ces données avec les autres modules du système. Puis ces données sont formatées pour être affichées dans l'interface utilisateur et/ou stockées dans la base de données.

- le module *Affichage* formate les données partagées (issues des simulateurs) afin de générer et de gérer l'affichage des utilisateurs. Plusieurs affichages sont proposés : (i) les moniteurs pour observer des changements des paramètres, (ii) les plots pour visualiser les graphiques et / ou (iii) les grilles 2D (images). L'interface utilisateur accède au module *Affiche* pour générer automatiquement et dynamiquement une interface personnalisée du simulateur utilisé dans l'expérimentation.

- le module *Sauvegarde* enregistre dans une base de données l'ensemble des résultats de simulation. Ces données sont utilisées par la suite pour revoir le déroulement de la simulation sans réexécuter le simulateur.

- le module *Contrôleurs* permet le contrôle des simulateurs (exécuter et voir le résultat).

- un explorateur d'expérimentation qui permet la gestion, le partage des expérimentations et les échanges de résultats. Grâce à cette interface, les utilisateurs peuvent voir des expérimentations réalisées ou en créer de nouvelles. De plus, il est possible de : (i) rejoindre des expérimentations en cours d'exécution, de revoir des expérimentations terminées (si
elle est publique), et (ii) télécharger les résultats de ces expérimentations pour les analyser ensuite.

- *une GUI permettant l'exécution à distance des simulateurs, le partage et le contrôle de ces mêmes simulateurs. Ainsi, les utilisateurs peuvent modifier les paramètres, déterminer et afficher les résultats ensemble. De plus, l'interface fournit des fonctionnalités pour la création de groupes de travail, la visualisation des informations personnelles et la configuration des options personnelles.*

### 4.3.2 Technologies utilisées

<figure><img src="image_33.png" /><figcaption>FIGURE 4.5 – Technologies d’utiliser dans PAMS</figcaption></figure>

La plate-forme PAMS peut être considérée comme un conteneur dans lequel les simulateurs sont chargés, connectés avec une base de données, exécutés par des serveurs dédiés et gérés via une interface Web.

L'environnement PAMS est basé sur des technologies issues du domaine des systèmes distribués (voir le figure 4.5) :

- Un serveur d'applications Web renferme les pages JSP, Ajax [Dave Crane 2005] et les Servlet [Jason Hunter 1998] (Sakai-Tomcat) permettant la gestion de l'interface collaborative.

- Un serveur collaboratif (Red5) qui rend les services collaboratifs, comme la manipulation du simulateur, la visio conférence ...
- Un serveur d'applications Entreprise Java Bean (Jonas) pour exécuter des simulateurs, pour gérer des expérimentations, des entrées, des sorties et la collaboration.

- Une base de données (MySQL) pour stocker les modèles, les expérimentations (conditions initiales et résultats) et les échanges entre les utilisateurs de PAMS.

L'utilisation d'Entreprise Java Beans (EJB) [N Kassem 2000] est une technique qui permet à l'environnement PAMS d'être flexible, modulaire et améliorable. Chaque module du framework est composé de plusieurs EJB. Tous les EJB d'un même module sont utilisés au travers d'une interface métier unique (déterminée pour le module). Ainsi, pour ajouter de nouvelles fonctionnalités, des EJBs peuvent être développés et déployés dynamiquement sans réviser les anciens composants de PAMS. Mais, ces nouveaux EJB doivent implémenter les interfaces prédéfinies dans PAMS.

Les interactions entre les composants du framework seront assurées par des messages JMS et des appels distants de méthodes (RMI). L'environnement PAMS pourra ainsi être déployé sur une grille d'ordinateurs. Diverses configurations de déploiement peuvent être proposées et utilisées, par exemple : un serveur pour gérer l'interface web, l'affichage, les sorties, des modules d'enregistrement, et plusieurs serveurs pour exécuter les simulateurs.

Nous avons utilisé la technologie Flash d'Adobe avec le serveur Red5¹ pour supporter des fonctionnalités collaboratives (conventionnelles et spécifiques). Dans la section suivante, nous allons présenter ces nouvelles fonctionnalités.

### 4.3.3 Utilisation du simulateur collaboratif avec PAMS

En combinaison avec notre simulateur collaboratif, cette infrastructure fournit deux fonctionnalités principales :

- (i) les fonctionnalités pour gérer les listes d'expérimentations, de modèles, d'utilisateurs et d'outils, comme illustré par la figure 4.6.

- (ii) les fonctionnalités permettant la manipulation collaborative des simulateurs, comme présenté dans la figure 4.7 et 4.8.

Les fonctionnalités (i) sont proposées grâce à un espace de travail commun et public pour tous les participants. Dans cet espace, les informations concernant les modèles et simulateurs disponibles, les expérimentations en cours d'exécution et terminées, les utilisateurs et leurs rôles et les outils disponibles sont présentées.

Au contraire, les fonctionnalités (ii) sont groupées dans un espace privé où seulement les participants qui ont le droit peuvent accéder. Cet espace est en fait une simulation privée qu'il affiche quand on crée une expérimentation. Il fournit un ensemble d'éléments permettant :

1. des manipulations collaboratives sur le simulateur :

- un panneau de contrôle : un ensemble de boutons qui représentent des actions essentielles pour une simulation (setup, start, step et stop). Ces boutons sont utilisés seulement par des participants qui en ont le droit.

- des panneaux de paramètres : l'ensemble des paramètres sont représentés sous une forme adéquate. Ils sont modifiés par des personnes qui en ont le droit. Quand il y a une modification d'une paramètre, son label et le panneau qui la contient va changer

<footnote n="1">1. http://www.red5.org/</footnote>
<figure><img src="image_34.png" /><figcaption>FIGURE 4.6 – Espace de travail public</figcaption></figure>

la couleur selon la couleur de l'auteur de la modification. Et les autres participants qui
ont le droit de voir ce paramètre vont visualiser immédiatement le changement.

- un panneau pour créer des moniteurs : le moniteur est une notion répandue dans le domaine de la simulation. On utilise souvent des moniteurs pour observer le changement des variables, des graphes sorties d'une simulation. Ce panneau fournit un mécanisme pour observer la dynamique de simulation.

- un panneau de l'interface 2D

2. **d'attribuer des permissions** : nous nous sommes basés sur le modèle de rôle pour supporter la simulation collaborative. Ainsi, dans une simulation des systèmes complexes, il existe des rôles différents avec des droits différents. Quand on crée une simulation, les droits de chaque participant sont initialisés selon leur rôle que l'on a déclaré lors de la création du compte. Par défaut, les participants peuvent modifier des objets qui sont dans son domaine. Par exemple, un écologue peut modifier les paramètres liées à l'écologie. Au cours de la simulation, le droit des participants peut-être changé par l'auteur de la simulation.

3. des annotations :

- une liste des participants : elle est utilisée pour informer des personnes en ligne.

- la visio conférence : pour créer des vidéo conférences

- un panneau de message : il affiche les informations concernant des changement de la simulation.
<figure><img src="image_35.png" /><figcaption>FIGURE 4.7 – Espace travaillé privé</figcaption></figure>

– un télé-pointeur : Il s’agit du pointeur de souris que l’ensemble des participants peuvent voir.

Pour réaliser ce module, nous nous sommes basés sur le serveur open-source Red5². Ce serveur supporte des objets partagés et des mécanismes de synchronisation dynamique qui nous permettre de facilement traiter la coordination et la synchronisation des actions des participants. De plus, il nous permet de fournir une simulation collaborative vraiment synchronisée.

## 4.4 Conclusion

La collaboration autour de la simulation est complexe. Mais en observant le simulateur comme une boite noire dans laquelle les thématiciens s’intéressent seulement aux entrées et sorties, cette collaboration devient contrôlable. Elle passe principalement par les activités de changement des entrées, de l’acquisition et de l’analyse des sorties. Par conséquent, nous pouvons bien supporter la collaboration dans une simulation par l’étude de ces activités.

D’un côté, un simulateur collaboratif est un simulateur qui fournit toutes les fonctionnalités essentielles pour effectuer une simulation. Mais, de l’autre côté, c’est aussi un outil collaboratif qui supporte des fonctionnalités collaboratives spécifiques pour les activités de changement des entrées, de l’acquisition et de l’analyse des sorties. Ainsi, nous supportons la simulation collaborative par la production du simulateur collaboratif.

<footnote n="2">2. www.red5.org</footnote>
<figure><img src="image_36.png" /><figcaption>FIGURE 4.8 – Espace travaillé privé - Simulation avec le modèle MIRO</figcaption></figure>

Pour faciliter la conception du simulateur collaboratif, nous avons proposé dans ce chapitre le méta-modèle de ce type de simulateur. Ce méta-modèle se base principalement sur trois notions essentielles : (i) simulateur; (ii) rôle et (iii) utilisateur. Un utilisateur qui peut avoir plusieurs rôles pour manipuler le simulateur par les permissions qui sont assignées à ses rôles.

Nous avons fourni une infrastructure logicielle qui supporte ce méta-modèle et permet de facilement ajouter les nouvelles fonctionnalités collaboratives. C'est PAMS qui est une plateforme collaborative BSCW avec suffisamment de fonctionnalités collaboratives conventionnelles. La plateforme étend des technologies de Red5 et Flash Adobe, tel que la visioconférence, tableau blanc, messagerie instantanée. Nous les avons également combiné avec des solutions ouvertes pour construire et transformer la plateforme collaborative PAMS en un BSCW supportant la simulation collaborative.

Dans ce chapitre nous avons répondu à la première question proposée à la fin du chapitre 2 page 29. Maintenant, il nous reste encore la deuxième question : Comment concevoir un simulateur à partir d'une problématique et d'un modèle existant, qui favorise la collaboration ? Dans le chapitre suivant, nous allons détailler la réponse à cette question.
# DeCoSim : Méthode pour concevoir un simulateur collaboratif

## Sommaire

<table><tr><td>5.1</td><td>Introduction de la méthode</td><td>87</td></tr><tr><td>5.2</td><td>Les rôles des contributeurs</td><td>88</td></tr><tr><td>5.3</td><td>Processus pour concevoir le simulateur collaboratif</td><td>89</td></tr><tr><td>5.3.1</td><td>Modèle du domaine : Le protocole ODD collaborative - CoODD</td><td>91</td></tr><tr><td>5.3.2</td><td>Modèle de conception : Méta-modèle du simulateur collaboratif</td><td>96</td></tr><tr><td>5.3.3</td><td>Transformation</td><td>101</td></tr><tr><td>5.3.4</td><td>Validation</td><td>102</td></tr><tr><td>5.3.5</td><td>Utilisation</td><td>102</td></tr><tr><td>5.4</td><td>Environnement logiciel associé</td><td>103</td></tr><tr><td>5.5</td><td>Conclusion</td><td>106</td></tr></table>

Lors de ce chapitre, nous allons présenter notre réponse à la deuxième question proposé dans la partie 2.4 : **Comment concevoir un simulateur à partir d'une problématique et d'un modèle existants, qui favorise la collaboration ?**

Actuellement, les méthodes de modélisation et simulation permettent de produire seulement un simulateur *stand-alone*. Simplement car l'objectif initial de ces méthodes n'est pas la collaboration entre des thématiciens. Il faut avoir une méthode qui permet de transformer un simulateur *stand-alone* en simulateur collaboratif.

Pour cela, nous avons deux solutions : (i) Développer un nouveau simulateur en ajoutant des fonctionnalités collaboratives par le processus de modélisation et simulation à la section 1.3 page 17 ; ou (ii) Exploiter ce que existe déjà, c'est-à-dire, en se basant sur un simulateur *stand-alone* auquel seront ajouter de nouvelles fonctionnalités qui le transformeront en simulateur collaboratif. Par une recherche de littérature, nous trouvons que la deuxième solution est plus économique concernant le temps et les forces nécessaires. La méthode présentée dans ce chapitre va appliquer cette idée.

## 5.1 Introduction de la méthode

Les échanges réalisés autour d'un simulateur sont fortement conditionnés par les objectifs scientifiques. La définition *a priori* des moyens de collaboration à mettre en place ne pourrait se faire sans tenir compte : (i) des objectifs globaux de simulation ; (ii) de la question scientifique ; (iii) de l'expérience des participants ; (iv) de leurs habitudes. D'autre part, l'introduction de la
collaboration au sein d'un simulateur existant nécessite souvent un développement considérable
des nouvelles fonctionnalités souhaitées.

Afin de faciliter ce travail d'analyse et de développement, nous proposons l'approche De-
CoSim : une procédure originale facilitant la transformation d'un simulateur *stand-alone* en
simulateur collaboratif. Cette transformation ne pouvant se réaliser sans un concours conjoint
des thématiciens et des modélisateurs, DeCoSim repose sur un processus collaboratif supporté
par des outils informatiques dédiés et collaboratif.

<figure><img src="image_37.png" /><figcaption>FIGURE 5.1 – L’objectif et l’utilisateur de DeCoSim</figcaption></figure>

Ainsi, l'approche DeCoSim propose un processus incrémental de conception du modèle. De chaque étape résulte un prototype du modèle, qui peut-être manipulé et utilisé conjointement par les thématiciens et les modélisateurs. Ces échanges de tous les instants assureront la bonne conduite du processus de transformation du simulateur.

Comme le souligne [Gaudou Benoit 2009], un processus reproductible ne peut pas être dis-
socié des outils pour devenir une méthode. DeCoSim se repose donc sur ce principe pour ca-
ractériser une méthode. D'autre part, pour un travail collaboratif, le fait d'identifier différents
rôles est important. Par conséquent, nous adaptons à DeCoSim le point de vue sur le concept
de role de Kimono. En résumé, DeCoSim se compose des trois composants suivants :

- *une définition des rôles des contributeurs*

- un *processus reproductible* pour conduire le concepteur en fixant des sous-buts in-termédiaires à atteindre

- des outils conceptuels et logiciels, ainsi que des guidelines de modélisation pour aider dans l'application le processus et atteindre des buts intermédiaires. Ces différents points sont abordés dans la suite de ce chapitre.

5.2 Les rôles des contributeurs

La simulation des systèmes complexes est un travail interdisciplinaire qui repose sur de
multiples sources de données dans des domaines différents.

Notre méthode contient divers niveaux de descriptions du système de référence (un texte
informel initial à une infrastructure pour la simulation collaborative) qui est conçu par des
acteurs différents. Par conséquent, il existe différents rôles de contributeurs dans la méthode.
En adaptant les rôles présentés par [Drogoul 2003], nous identifions quatre rôles de contributeur :
thématicien utilisateur, thématicien concepteur, concepteur et développeur.
L'un des acteurs majeurs du processus de modélisation-simulation d'un système complexe est le thématicien (géographe, biologiste, ...) qui possède une connaissance approfondie du système investigué [Drogoul 2003]. Cependant, par le travail de conception et l'utilisation du simulateur, nous trouvons qu'il y a en fait deux types de thématiciens qui sont présents à différents moments avec des différents rôles :

- **thématicien concepteur** : il participe à la conception du modèle et du simulateur, il est en étroite collaboration avec un concepteur (mathématicien, informaticien, ...)

- **thématicien utilisateur** : il utilise le simulateur comme un produit fini, il collabore alors avec d'autres experts utilisateurs pour réaliser des simulations. Ce rôle est similaire avec le rôle **initiateur** dans KIMONO [Amouroux 2011].

Les thématiciens utilisateurs fournissent le détail du problème, la question scientifique qui n'est pas trouvé dans la littérature. Il va utilisé le produit final pour réaliser des simulations collaboratives. De plus, il y a seulement lui qui est capable de décider si le problème est résolu. Par conséquent, ce rôle est impliqué aux premières étapes et à la fin de la démarche.

Le thématicien concepteur participe à notre démarche pour aider dans la conception du modèle et simulateur collaboratif. Il supporte les thématiciens utilisateurs dans l'identification des scénarios collaboratifs et dans la validation du produit final, et les modélisateurs dans la conception des modèles : le modèle du domaine, le modèle conceptuel.

Le concepteur qui est similaire avec le modélisateur dans [Drogoul 2003], va commencer son travail à l'étape de conception du modèle du domaine. Il prend les scénarios collaboratifs, et le document ODD du modèle pour créer un document CoODD (voir la section 4 page 71). Ce travail va réaliser avec l'aide du deux rôle de thématicien (utilisateur et concepteur). Le premier va aider le concepteur dans la synthèse des scénarios collaboratifs (Puisque, les thématiciens proposent plusieurs scénarios, le concepteur va les analyser et synthétiser pour des scénarios plus généraux et pour éviter la répétition). Ces deux thématiciens participent également à l'élaboration des nouvelles parties de CoODD (comme le simulateur, le rôles, la collaboration).

Comme discuté dans [Drogoul 2003], dans un processus de modélisation et simulation le modélisateur est responsable de traduire le modèle du domaine en un modèle plus formel qui pourra être considéré pour implémentation par les informaticiens. C'est similaire pour notre démarche. Le concepteur clarifie des concepts utilisés, supprime les ambiguïtés potentielles, et intègre des connaissances des domaines différents dans le modèle conceptuel. Il aide ensuite le développeur pour transformer le modèle conceptuel en simulateur collaboratif.

Le rôle développeur est similaire avec celui l'informaticien dans [Drogoul 2003]. Il a deux missions principales : (i) proposer un modèle pour faire le lien entre le modèle conceptuel et la transformation ; (ii) Développer un adapteur pour transformer le simulateur.

## 5.3 Processus pour concevoir le simulateur collaboratif

En nous reposant sur l'approche KIMONO et Drogoul et al [Drogoul 2003] nous proposons une démarche qui vise, d'une part, à caractériser la collaboration autour d'un simulateur en fonction d'objectifs scientifique et d'autre part à rendre collaboratif ce même simulateur par l'utilisation d'une plate-forme dédiée.

Comme nous l'avons vu dans la section 2.2 page 33, deux facteurs sont essentiels pour l'échange entre deux interlocuteurs :
- *un matériel, un sujet et un objectif commun*, dans notre cas, le modèle et le simulateur à rendre collaboratif;

- *des outils collaboratifs* qui assurent la transmission des échanges entre les intervenants.

Le premier facteur est un espace (physique ou virtuel) où les participants peuvent accéder et travailler ensemble, face à face (par exemple une table, un bureau) ou à distance (par exemple un espace virtuel de travail). Dans le cadre de cette thèse nous proposons des solutions afin de faciliter ces échanges virtuels. Ce facteur identifie aussi une base de connaissance commune entre les participants. Car la connaissance est une notion abstraite et relative, on a souvent besoin spécifier le mécanisme pour la représenter et la stocker. Par exemple, le tableau noir et ce que on écrit sur ce tableau dans Commod [Bousquet 2005] ou ODD protocole associé à l'approche KIMONO [Amouroux 2011]. Ainsi, à chaque étape du processus, nous supportons un moyen pour représenter et stocker la connaissance de base, tel qu'un modèle, un document.

Les besoins en terme de modélisation sont à chaque étape différents. Ainsi la nature des échanges est variée. Par conséquent, pour chaque étape, nous devons proposer des outils spécifiques. Ces derniers sont associés à des outils collaboratifs génériques et former ainsi une infrastructure collaborative complète, un collecticiel.

En nous reposant sur les approches du génie logiciel section 3.1 page 50, de la modélisation-simulation section 3.2 page 53, nous identifions 5 phases différentes pour un processus de conception : (i) la création du modèle du domaine, (ii) la création du modèle conceptuel, (iii) la phase d'implémentation, (iv) la phase de test et (v) la phase d'utilisation. Cependant, compte tenu de nos objectifs spécialisés, ces phases ne sont pas suffisantes. Il ne s'agit pas de développer un nouveau modèle mais de le transformer : nous rendons un simulateur existant en simulateur collaboratif.

Ainsi la démarche DeCoSim permet de transformer un simulateur *stand-alone* avec 5 étapes suivantes (voir la figure 5.2) :

<figure><img src="image_38.png" /><figcaption>FIGURE 5.2 – DeCoSim</figcaption></figure>

- **Création du modèle domaine** : Il s'agit d'une description textuelle (reposant sur ODD [Grimm 2010] du simulateur, du modèle qu'il implémente et du processus collaboratif qui sera réalisé entre les thématiciens-utilisateurs. Ce modèle résulte d'une étroite collabo-
ration, entre thématiciens-concepteurs et concepteur. Ces échanges sont facilités par un
éditeur collaboratif de texte.

- **Création du modèle conceptuel** : il s'agit d'une représentation UML du simulateur collaboratif qui sera déployé. Cette phase sera facilitée par un éditeur UML collaboratif dédié.

- **Transformation** : lors de cette étape, le simulateur *stand-alone* sera effectivement transformé en un simulateur collaboratif. Cette étape n'est pas propice à l'interaction, et peut-être réalisée, en solitaire, par l'informaticien.

- **Validation** : Lors de cette étape, le nouveau simulateur collaboratif est validé par les thématiciens-concepteur et le concepteur. Ils s'assurent alors que le simulateur fonctionne bien et que toutes les prérogatives de collaboration sont prises en compte.

- **Utilisation du simulateur collaboratif** : Le simulateur est maintenant ouvert à la communauté et peut donc être utilisé par les thématiciens-utiliateurs. Le simulateur est alors accessible par tous les membres autorisés via une plate-forme web collaborative.

La démarche que nous proposons présente l'avantage de faire intervenir concepteurs et thématiciens-concepteurs à toutes les étapes du processus de spécification de la collaboration. Chaque étape de la démarche repose sur des méta-modèles et langages compréhensibles par des thématiciens et des concepteurs, et sur des outils logiciels collaboratifs qui assurent les échanges. Dans les sections suivantes, nous allons détailler ces étapes.

5.3.1 Modèle du domaine : Le protocole ODD collaborative - CoODD

L'objectif de notre modèle du domaine est non seulement de décrire le modèle mais également
l'objet de communication entre les concepteurs et les thématiciens concepteurs. Selon Grim
et al. [Grimm 2006], un problème de la communication autour du modèle basée individuel
(IBM) est que sa description est souvent difficile à lire, incomplète, ambiguë et donc moins
accessible. Tandis que la science est basée sur des observations reproductibles. Nous trouvons
que ce problème est présent également dans notre méthode. Par conséquent, pour le modèle du
domaine, nous devons faire un modèle simple mais facile à lire et à comprendre. Nous pouvons
obtenir une telle description si elle prend en compte les attentes du concepteur et celles du
thématicien concepteur. Ces derniers aborderont mieux l'information si la description est fourni
dans un environnement familier, une structure significative [Gopen 1990].

Dans ce contexte, le modèle du domaine sera plus lisible s'il décrit, simplement, par un
langage naturel, le modèle, le simulateur et la nature de la collaboration qui sera réalisée entre
les thématiciens-utilisateurs. L'approche ODD (Overview, Design concepts, Detail) abordée
dans la partie 4.2.2 page 79 semble être une bonne piste dans la mesure où elle permet d'établir
une description simple, complète, et didactique d'un modèle d'un système complexe. De plus,
cette approche fait aussi référence dans le domaine des systèmes complexes si bien qu'elle est
connue par une grande partie de la communauté.

Ce protocole répond à une partie concernant le modèle. Il nous reste encore la nature du
simulateur et la collaboration autour lui. Ainsi, pour le modèle du domaine CoODD, nous
avons donc étendu ce protocole par de nouvelles primitives permettant la description de la
collaboration autour d'un modèle et d'un simulateur. Cette extension, que nous avons appelée
CoODD (Collaborative ODD) introduit au sein d'ODD quatre nouveaux blocs : (i) le simulateur,
<table><caption>TABLE 5.1 – Le protocoles CoODD complète</caption><thead><tr><th></th><th>Purpose</th></tr></thead><tbody><tr><td>Overview</td><td>State variables and scales<br>Process overview and scheduling</td></tr><tr><td>Design Concepts</td><td>Design Concepts</td></tr><tr><td>Detail</td><td>Initialization<br>Input<br>Submodels</td></tr><tr><td>Simulator</td><td>General information<br>Input Parameters<br>Output</td></tr><tr><td>User's profile</td><td>User's profile</td></tr><tr><td>Application aspect</td><td>Application aspect</td></tr><tr><td>Collaboration</td><td>Responsibilities<br>Collaborator<br>Permission<br>Collaboration template</td></tr></tbody></table>

(ii) le profil d'utilisateurs, (iii) l'aspect des applications et (iv) la collaboration et les scénarios typiques. Ce sont des parties rouges dans le tableau 5.1.

### a) Simulator

Le simulateur peut être assimilé à un logiciel *stand-alone* pour lequel nous voulons déterminer une interface graphique collaborative pour les utilisateurs. Un simulateur est manipulé par des utilisateurs qui sont caractérisés par leurs propres connaissances et compétences. Il est également considéré par les utilisateurs comme un logiciel qu'ils paramètrent, exécutent et dont ils visualisent les résultats.

Comme présenté dans la section précédente, nous considérons un simulateur comme une boîte noire qualifiée par les entrées/sorties et un but (la question scientifiques). Par conséquent, s'il n'y a pas d'explication sur les entrées/sortie du simulateur, les utilisateurs (experts du domaine) ne seront pas capables de les comprendre, de les modifier et de collaborer autour d'elles.

Afin de décrire précisément le simulateur, nous avons décidé d'ajouter le bloc **Simulator**. Le bloc **Simulator** est composé de trois éléments :

- **General information** : vise à définir la description générale du simulateur;

- **Input Parameters** : vise à déterminer les entrées (paramètres) du simulateur (objectif, la portée, le type). Nous avons distingué deux types d'entrées : (i) les variables qui sont les paramètres du modèle (paramètres numériques, paramètres de choix); (ii) les actions qui définissent des événements résultant des actions de l'utilisateur (clic de souris ou bouton).

- **Output** permet aux utilisateurs d'observer et de comprendre la dynamique simulée par différents types de vues (graphique ou moniteurs). Comme la partie **Input Parameters**, une description (objectif, type) doit être définie pour chaque sortie afin de déterminer les
buts eux-mêmes.

A titre d'illustration, un extrait du modèle *Wedding-Ring* est présenté ci-dessous.

## Simulator

### 1. General information :

Modèle formulé et implémenté par S. F. Railsback Ce modèle est vaguement basé sur le modèle de l'âge du mariage : Billari, F. C., A. Prskawetz, B. Aparicio Diaz, and T. Fent. 2007.

### 2. L'entrée :

Les paramètres d'entrée possibles sont :

- Social-network-age-range : la range **la variation** de l'âge dans un réseau social

- Social-network-angle-range : La range **la variation** de l'âge dans un réseau social.

- Social pressure $Y = \exp(Z)(1+\exp(Z))$ tandis que $Z = a + bX$. $X$ est la fraction du mariage. Elle est calculée par la fraction de toute personne dans le réseau social qui est marié.

- La population initiale.

- Max-age : l'âge maximum d'un individu.

- Min-marriage-age : l'âge minimum pour lequel un individu peut se marier.

- Birth-rate : Le taux qui maintient une taille de la population stable.

### 3. Actions :

- Setup simulation : L'action pour initialiser les paramètres.

- Run simulation : L'action pour lancer la simulation jusqu'à sa fin.

- Step simulation : L'action pour exécuter la simulation étape par étape.

- Les actions pour manipuler les paramètres.

### 4. Sortie :

- La distribution Age-at-marriage : c'est un histogramme du nombre marié vs. l'âge.

## b) User's Profile

Le but de ce bloc est d'identifier les profils d'utilisateur qui utiliseront le simulateur. Les utilisateurs d'un modèle sont caractérisés par leur objectifs scientifiques, leurs recherches, leurs connaissances, leur expérience et ainsi de suite. Déterminer la collaboration autour d'un simulateur vise à profiter au mieux des spécificités de chaque utilisateur afin d'améliorer l'expérimentation de groupe.

Par conséquent, une liste exhaustive de profils d'utilisateur doit être déterminée. Chaque profil d'utilisateur définit un point de vue sur la simulation et un objectif spécifique que l'utilisateur tentera d'atteindre. Nous souhaitons également souligner les capacités des utilisateurs afin de déterminer leur rôle dans la simulation et ainsi adapter l'interface graphique à l'utilisateur.

Ci-dessous nous illustrons la partie **User's Profile** extrait du modèle *Wedding-Ring*

### User's Profile

Il y a quatre types du profile d'utilisateur répartie en deux groupes : (i) le démographe et le sociologue et (ii) le psychologue et l'économiste.
## 1. Profile 1 : Démographe

- Domaine : Démographie - Les sciences sociales.

- *Compétences et responsiblités* : La démographie est l'étude statistique des populations humaines. Elle peut être une science très générale qui peut être appliquée à la plupart des populations humaines, évoluant dans le temps ou dans l'espace. Elle englobe l'étude de la taille, de la structure, de la répartition de ces populations, et s'intéresse aux changements spatiaux et / ou temporels pour répondre à la naissance, la migration, le vieillissement et le décès.

## 2. Profile 2 : Sociologue

- Domaine : Sociologie - Les sciences sociales

- *Compétences et responsibilités* : La sociologie est l'étude de la société. C'est une science sociale qui utilise diverses méthodes empiriques d'investigation et d'analyse critique. L'objectif est de développer et d'affiner un ensemble de connaissances concernant l'activité sociale humaine, souvent avec le but d'appliquer des connaissances à la poursuite du bien-être social.

...

## c) Application aspect

Ce bloc décrit les objectifs scientifiques du modèle. Le modèle et le simulateur des systèmes complexes peuvent avoir un nombre d'applications différentes. Par conséquent, il existe des scénarios différents dans lesquels le modèle et son simulateur sont manipulés de manières différentes. Ainsi, pour un unique simulateur de système complexe, mais nous pouvons trouver que plusieurs processus d'échanges différents existent (processus participatifs ou collaboratifs). En d'autres termes, un processus d'échange et des scénarios de simulations collaboratives peuvent être définis et identifiés par l'objectif scientifique des utilisateurs.

Ainsi, pour avoir une vue globale sur les échanges et les scénarios possibles entre des thématiciens, il est nécessaire d'identifier clairement les applications du modèle et du simulateur. Ces applications peuvent être identifiées au moyen des questions scientifiques du thématicien et de la façon de manipuler les paramètres pour y répondre.

Par exemple pour le modèle *Wedding-Ring*, 4 aspects d'application sont identifiés par l'objet scientifique de chaque profil d'utilisateur. Il s'agit d'un exemple de l'objectif du Démographe.

### Application Aspect

Le modèle a 4 aspects d'application qui correspondent à différents objectifs scientifiques.

#### 1. Examiner la liaison entre la pression sociale et l'âge-du-marriage

- *Question* : Comment est-ce que la pression sociale influence l'âge-du-mariage ?

- *Hypothèse* : Le désir de mariage d'un individu est influencé principalement par son âge, le comportement et l'interaction sociale des individus dans son réseau

Les paramètres concernant ces questions et hypothèses sont :

- Le nombre initiale de la population

- Social-network-age-range

- Social-network-angle-range

- Max-age
- Min-marriage-age

- Birth-rate

...

d) Collaboration

Normalement, comme n'importe quel processus collaboratif, il est premièrement nécessaire d'identifier clairement les éléments de base qui forment le processus, comme l'environnement, les participants ou l'objectif. L'étape suivante vise à clarifier comment utiliser et combiner ces éléments dans le processus de façon harmonieuse. Les trois blocs précédents (*Simulator*, *User's Profile* et *Application Aspect*) ont présenté la partie de base qui est la condition nécessaire pour établir une simulation collaborative. Le bloc **Collaboration** décrit comment utiliser cette information dans les échanges entre des thématiciens.

Les échanges dans une simulation des systèmes complexes se traduisent sous la forme de processus collaboratifs / participatifs. Ainsi, ce bloc répond également aux questions suivantes : Quelles sont les permissions des thématiciens ? Qui va collaborer avec qui ? Quels sont les outils collaboratifs disponibles ? Quelles sont les responsabilités de chaque utilisateur dans la simulation ?

Une brève description de la collaboration en termes généraux est proposée. Suite à cette analyse, des scénarios, les permissions, les responsabilités ou les outils collaboratifs sont attribués à chaque profil d'utilisateurs. En d'autres termes, ce bloc permet de distinguer l'interface entre les utilisateurs et les méthodes de collaboration.

A titre d'exemple la suite montre la partie **Collaboration** du modèle *Wedding-Ring*. Dans les exemples précédents, nous avons présenté différentes parties concernant le processus collaboratif autour du modèle *Wedding-Ring*, tel que le simulateur NetLogo, les quatre profils d'utilisateur et les applications possibles. Dans cet exemple, différentes information vont être combiner pour une simulation collaborative.

Collaboration

*Wedding-Ring* est un projet multidisciplinaire où quatre profils d'utilisateur sont identifiés. D'un côté, les démographes collaborent avec les sociologues pour mettre l'accent sur la modélisation et l'explication des faits stylisés importants qui est une présentation simplifiée d'une découverte empirique, tels que la forme typique de courbes d'âge-du-mariage. Leurs stratégies analytiques sont souvent basées sur des modèles mathématiques et statistiques de niveau macro. De l'autre côté, les psychologues collaborent avec les économistes pour étudier le processus de recherche de leurs partenaires.

Ces difficultés sont apparues dans la manipulation collective des simulateurs. Les participants doivent collaborer pour modifier les paramètres, lancer la simulation, analyser les résultats. Néanmoins, la version original du simulateur de *Wedding-Ring* ne supporte pas la collaboration, ainsi il ne peut pas effectuer ses activités de façon collaborative.

...

Afin de créer efficacement un modèle Co-ODD, nous avons besoin d'outils collaboratifs (voir 4.2.2 page 79) permettant la conception et la rédaction du modèle, à plusieurs. Par conséquent, nous avons développé un éditeur collaboratif, basé sur les technologies du web, qui permet de
rédiger de manière synchrone et collaborativement un document texte dont la structure repose
sur celle de Co-ODD. Cet éditeur est basé sur l'éditeur open-source EtherPad [Eth 2011]. Nous
le détaillons dans la section 5.4 page 103 l'outil et ses fonctionnalités.

Après la rédaction du modèle du domaine, nous pouvons établir le modèle de conception.

5.3.2 Modèle de conception : Méta-modèle du simulateur collaboratif

La suite logique du modèle CoODD implique la définition d'un modèle de conception. Pour
cela, nous profitons du caractère didactique et "universel" du langage UML afin de produire
les modèles de conception. En effet, le langage UML est un langage graphique qui trouve des
applications dans la majorité des disciplines si bien qu'il est connu et reconnu. Associer à
un méta-modèle et à des solutions informatiques adaptées ce langage offre un moyen efficace,
adapté et structuré pour décrire la collaboration. Ainsi, nous avons conçu un méta-modèle
UML permettant de définir la collaboration autour d'un simulateur. Pour le méta-modèle, nous

<figure><img src="image_39.png" /><figcaption>FIGURE 5.3 – Méta-modèle du simulateur collaboratif</figcaption></figure>

utiliserons le méta-modèle du simulateur collaboratif que nous avons présenté dans la section 4.2 page 76. Il permet de définir une interface générique permettant d'accueillir les différents types de simulateurs.

Le méta-modèle contient 5 parties principales : (i) le paquet Simulator ; (ii) les entrées ; (iii) les sorties ; (vi) les rôles et (v) les outils. Pour le première partie, le paquet Simulator est packagé par les thématiciens et les modélisateurs. Il est stocké sur le serveur. Par conséquent, nous ne touche pas cette partie.

Dans cette section, nous présentons en détail 4 parties importantes (présenté dans la section 4.1 page 71) : (i) les entrées ; (ii) les sorties ; (iii) les rôles et (vi) les outils.

a) Les entrées

Comme abordé dans la section 4.2 page 76, les entrées d'un simulateur collaboratif sont des
paramètres entrées et les actions possibles que les thématiciens peuvent effectuer. Les paramètres
<figure><img src="image_40.png" /><figcaption>FIGURE 5.4 – Les paramètres entrées du simulateur collaboratif</figcaption></figure>

entrées sont en effet un type de l'objet **Variable** dans le méta-modèle 4.2. Cette partie est
présenté en détail comme la partie grise dans la figure 5.4. L'objet **Parameter** représente des

<figure><img src="image_41.png" /><figcaption>FIGURE 5.5 – Les actions du simulateur collaboratif</figcaption></figure>

paramètres entrées du simulateur. Tous les paramètres sont contrôlés par une instance de la classe **ParameterSO** qui hérite de la classe **VariableController**. Cette classe met à jour les paramètres quand les autres les modifient. Un paramètre contient aussi un composant graphique, le classe **ParameterUI** qui est un type de **AccessTool**. Ce dernier peut être des curseurs ou des combobox présentés dans la partie **Simulateur**.

Concernant les entrées de type d'action, chaque action est associé à une classe **HydridButton** qui contient un bouton sur l'interface graphique, comme illustré dans la partie grise de la figure 5.5. Toutes les actions sont contrôlées par le contrôleur **SimulationRoom**. Cet objet va
mettre à jour les actions effectuées dans la simulation.

<figure><img src="image_42.png" /><figcaption>FIGURE 5.6 – Les sorties du simulateur collaboratif</figcaption></figure>

b) Les sorties

Les sorties d'un simulateur collaboratif sont des moniteurs par exemple qui permettent des observations sur une valeur numérique ou sur un graphique. Comme présenté dans la section 4.2 page 76, nous considérons ces moniteurs comme des objets **Variable** qui est illustré dans la partie grise de la figure 5.6.

Comme le paramètre, chaque moniteur est contrôlé par la classe MonitorSO qui hérite aussi de la classe **VariableController**. Ce dernier met à jour ses moniteurs quand il y a des changements par les autres participants. Les moniteurs sont affichés : soit par la classe **Numeric** qui représente une valeur numérique d'un attribut, soit par **Plot** qui représente un plot graphique ou graphique qui représente une interface 2D.

c) Les rôles

Les thématiciens interagissent avec le simulateur par le biais des **Role**. Chaque rôle est différencié par l'ensemble des objets **Permission**. Ce dernier contient les droits d'utilisation de l'interface graphiques, sur les paramètres, les actions et les visualisations, comme illustrée dans la figure 5.7.

d) Les outils

A côté des outils permettant d'interagir avec les entrés et les sorties, comme présenté dans les sections précédentes, nous devons proposer d'autres outils pour effectuer des fonctionnalités collaboratives spécifiques comme la visio conférence, l'annotation. Ces dernières sont implémentés également via les objets de type **AccessTool**, comme présenté dans la figure 5.8.

e) Un exemple avec le modèle Wedding-Ring[Billari 2007]

Les parties les plus importantes dans ce méta-modèle est les rôles, les variables et les actions.
Quand nous concevons un modèle du simulateur collaboratif. Le travail principal est d'identifier ces trois composants. Les autres sont presque identiques pour tous les modèles. Par

<figure><img src="image_43.png" /><figcaption>FIGURE 5.7 – Rôle et le simulateur collaboratif</figcaption></figure>

<figure><img src="image_44.png" /><figcaption>FIGURE 5.8 – Les AccessTools du simulateur collaboratif</figcaption></figure>

exemple pour le modèle “Wedding-Ring” [Billari 2007] présenté dans la section précédente, nous avons pris le simulateur NetLogo du modèle Wedding-Ring implémente par Railsback et al. [Railsback 2009] en le développant dans un cas plus général. Nous avons rendu ce modèle du simulateur collaboratif.

En nous basant sur le travail de [Billari 2007], nous avons identifié quatre rôles principaux dans des simulations collaboratives avec le modèle *Wedding-Ring* : le Démographe, sociologue, psychologue, et l'économiste. Ces rôles sont présentés comme dans la figure 5.9. Chaque rôle est
<figure><img src="image_45.png" /><figcaption>FIGURE 5.9 – Les rôles Démographe et Psychologue</figcaption></figure>

lié avec un ensemble de Permissions sur les variables et actions.

<figure><img src="image_46.png" /><figcaption>FIGURE 5.10 – Les paramètres du modèle *Wedding-Ring*</figcaption></figure>

Le simulateur *Wedding-Ring* a sept variables (six paramètres et un monitor) comme illustré dans la figure 5.10 et 5.11 qui est divisé par deux groupes : un est contrôlé par le démographe et le sociologue, et l'autre manipulé par le psychologue et l'économiste. Ce simulateur a trois actions *Setup*, *Go* et *Step* comme présenté dans la figure 5.12 que tous les rôles peut les manipuler.

Les composants *ParamètreSO*, *MonitorSO*, *Plot* corresponde à *Tool* dans le méta-modèle. Les deux premiers composants permettant de contrôler le changement des paramètres et monitors de façon collaborative. Le *Plot* permet d'afficher les graphes des moniteurs.
<figure><img src="image_47.png" /><figcaption>FIGURE 5.11 – Le moniteur du modèle *Wedding-Ring*</figcaption></figure>

<figure><img src="image_48.png" /><figcaption>FIGURE 5.12 – Les actions du modèle *Wedding-Ring*</figcaption></figure>

### 5.3.3 Transformation

Après avoir défini le modèle conceptuel, c'est le temps pour transformer le simulateur *stand-alone* en celui collaboratif. Lors de cette étape, pour des plateformes de simulation déjà connu (comme NetLogo) le développeur effectue simplement des configurations qui sont stockées en-suite dans la base de données et met les paquets nécessaires pour exécuter le simulateur sur le serveur de plate-forme PAMS. Ces configurations doivent respecter le modèle conceptuel.

Pour une nouvelle plateforme, avant de faire des configurations, le développeur doit développer un adapter qui permet la plate-forme PAMS d'interagir avec la plate-forme.

On peut aussi intégrer des simulateurs adhoc, mais pour cela, il faut en plus de l'étape de configuration, implémenter un adapteur qui revient à implémenter une interface 5.2.

Actuellement, la configuration doit faire à la main par le développeur. Mais, via un assistant, cette intégration peut se réaliser semi automatiquement, voire automatiquement. La configuration de la base de données est effectuée comme suit :
## 5.4 Environnement logiciel associé

Une méthode n'est pas une méthode sans la proposition d'outils et des guides aidant à la modélisation. C'est pourquoi, chaque étape du processus est facilitée par des outils (conceptuels et logiciels) correspondants : CoODD et l'éditeur collaboratif CoPad, le modèle du domaine et l'éditeur CoUML, la transformation et le modèle de l'adaptateur. De plus avec l'infrastructure proposée dans la section 4.3 page 80, chaque pas est associé des outils collaboratifs conventionnels.

<figure><img src="image_49.png" /><figcaption>FIGURE 5.13 – DeCoSim et l'infrastructure logicielle supporte</figcaption></figure>

Ainsi notre méthode est présentée avec les outils dédiés comme dans la figure 5.13. Après avoir fini la conception, le simulateur collaboratif est prêt à utiliser, car notre infrastructure est disponible via Internet.

### a) CoPad : l'éditeur collaboratif pour la rédaction de CoODD

L'objectif de CoPad est de faciliter les thématiciens et les modélisateurs dans la rédaction du modèle du domaine CoODD et la collaboration entre eux. Cet éditeur hérite en effet de l'Etherpad<fnref n="1" />, un éditeur en ligne qui permet la rédaction collaborative des documents.

EtherPad est un service web qui permet la collaboration pour la rédaction de documents en temps réel pour les groupes et des équipes. Il permet aux auteurs de modifier simultanément un document textuel. Ils peuvent visualiser et éditer en temps réel. Chaque auteur d'un texte est affiché dans sa propre couleur. Il y a aussi une boîte de discussion dans le sidebar pour permettre la méta communication. De plus, c'est un logiciel open-source, on peut télécharger Etherpad et modifier le source de l'éditeur pour développer de nouvelles fonctionnalités.

Dans Etherpad nous avons ajouté les fonctionnalités qui sont :

<footnote n="1">1. Etherpad - L'éditeur collaboratif en ligne : http://etherpad.com/</footnote>
<figure><img src="image_50.png" /><figcaption>FIGURE 5.14 – CoPad</figcaption></figure>

- le template CoODD : il aide des auteurs à créer facilement et rapidement les différents parties de CoODD.

- le guide pour CoODD : permettant la consultation facile et rapide des règles de CoODD.

- Nous allons supporté un mécanisme pour que les documents soient au bon format CoODD : plusieurs buttons dans ce sens ont été définis. Ils permettent la génération de la forme des blocs de CoODD. Lorsque quelqu'un veut déclarer, par exemple, un nouveau paramètre, il/elle doit seulement cliquer sur le bouton correspondant. Le modèle d'un nouveau paramètre sera alors inséré.

Comme présenté dans la figure 5.14, l'éditeur a cinq parties principales : (1) l'espace pour entrer le texte ; (2) La liste des participants ; (3) Le chat ; (4) Les fonctionnalités soutenant CoODD ; (5) Le menu. Avec ces nouvelles fonctionnalités, CoPad devient une bonne solution pour la rédaction collaborative des documents CoODD.

Mais pour avoir un outil vraiment complet il faudrait ajouter quelques fonctionnalités spécifiques pour traiter le texte. La partie collaborative est acceptable, mais les fonctionnalités typographiques sont limités. Nous ne pouvons pas créer des tableaux, les formes supports sont encore simple, les caractères spécifiques (comme mathématique) ne sont pas supportés.

## b) CoUML : l'éditeur UML collaboratif

L'objectif de CoUML est de faciliter les modélisateurs et les thématiciens concepteurs dans la rédaction du modèle conceptuel et les collaborations entre eux.
<figure><img src="image_51.png" /><figcaption>FIGURE 5.15 – CoUML</figcaption></figure>

Nous nous sommes reposé sur l'environnement Web BeoModeler 5.15 pour créer les diagramme UML. Il fonctionne en basant sur la technique Flash d'Adobe. BeoModeler utilise la plate-forme Flex (comme Flash, mais Flex est libre à utiliser – un open-source plate-forme). Il fonctionne bien, mais il ne supporte pas la collaboration entre des individus.

Par conséquent, notre équipe a ajouté des fonctionnalités suivantes pour un éditeur d'UML collaboratif :

- un tableau blanc : qui permet aux participants de partager leur idées visuellement

- la conception collaborative d'UML : qui permet aux participants de concevoir simulationtement des diagrammes d'UML.

Maintenant, CoUML permet de créer des diagrammes UML de façon collaborative. Mais, pour devenir un outil fort, il faut ajouter :

- un mécanisme d'annotation : pour l'instance, il n'y a aucune relation entre des participants. On ne sait pas combien de clients sont connectés et quel client est en train de modifier le schéma.

- un mécanisme pour différencier le rôle et le droit des participants : maintenant, tous les participants peuvent accéder et modifier tous les diagrammes stocké sur le serveur.

c) Déployeur pour la transformation

Lors de la troisième étape, pour pouvoir transformer un modèle d'une plate-forme quelconque en un simulateur collaboratif, le développeur doit avoir un Driver correspondant avec cette plate-
```java
class MonAdapter extends PamsAdapter {
    public void setup() { ... };
    public void start() { ... };
    public void stop() { ... };
    public void step() { ... };
    public void free() { ... };
    public void setParameterWithName(String name, Object value) { ... };
    public Object getParameterWithName(String name) { ... };
    public ISimulationAdapter create(String modelName, int exp) { ... };
}
```

<caption>TABLE 5.2 – Modèle de l'adaptateur</caption>

forme. En effet, ce Driver est une classe qui est hérité l'interface **PamsAdapter** prédéfini, comme présenté dans le tableau 5.2. Le travail de cette étape se résume à de l'implémentation, et peut être réalisé individuellement par le développeur.

Pour les plate-formes qui ont déjà un Driver, comme NetLogo, la transformation est simple et peut-être effectuée automatiquement par une fonctionnalité d'import et de mise à jour la base de donnée.

## 5.5 Conclusion

Au cour de ce chapitre, nous avons présenté la deuxième réponse pour soutenir la collaboration dans la simulation des systèmes complexes : une méthode pour transformer un simulateur *stand-alone* en une version collaboratif. L'origine de la méthode est le besoin des fonctionnalités collaboratives spécifiées pour la simulation. Tandis que la plupart des simulateurs des systèmes complexes actuels est comme une application *stand-alone* qui ne supporte pas les services nécessaires pour le nouveau contexte d'utilisation, par exemple la manipulation simulée, plusieurs interactions en même temps, adapté à l'utilisateur en se basant sur leur rôle et permission. Pour résoudre ce problème, il faut avoir une méthode pour concevoir le simulateur collaboratif. Grâce à l'expérience dans le projet PAMS, nous avons décidé de transformer le simulateur *stand-alone* en ajoutant des services collaboratifs, au lieu de le développer.

En se basant sur les travaux d'état de l'art, dans le chapitre 3 page 49, nous avons présenté la méthode pour transformer le simulateur *stand-alone* en une version collaborative. En prenant les avantages du génie logiciel, notre méthode est une démarche itérative, incrémentale et collaborative. Grâce aux méthodes de modélisation et simulation, notre méthode contient trois composants : (i) Les définitions des rôles des contributeurs qui sont développés de l'idée de Drogoul et al [Drogoul 2003], (ii) Un cycle de modélisation avec les guides qui est adapté celui de [Drogoul 2003] et [Amouroux 2011], et (iii) Des outils de support (conceptuel et logiciel). La conception de TCAO nous permet d'identifier la façon d'analyser le besoin en nous basant sur les scénarios et les outils nécessaires pour une conception collaborative.
Actuellement, en suivant la méthode, on peut concevoir le simulateur collaboratif et l'intégrer
dans notre plateforme Web. Grâce à cette infrastructure, non seulement la conception mais en-
core la simulation collaborative devient plus facile à réaliser. Cependant, notre méthode actuelle
supporte seulement des plate-formes de simulation qui ont déjà ses adaptateurs (pour l'instant
c'est NetLogo, bientôt Gama [Taillandier 2012b]). Pour des nouvelles plate-formes, il faut ajou-
ter des adaptateurs correspondants.

En effet, notre méthode DeCoSim et Pams peuvent être amélioré pour la conception et
l'utilisation du simulateur collaboratif plus convivial. Premièrement, le déploiement et la confi-
guration de la base de données lors de l'étape **Transformation** peut-être effectué de façon semi
automatiquement. Nous pourrions développer une fonctionnalité qui permettrait d'importer les
modèles, les analyses et les transférer ensuite (les paramètres, les actions, les moniteurs) dans
la base de données. Pour la spécification des rôles et des permissions, il faut avoir l'aide des
modélisateurs et des thématiciens.

Deuxièmement, le protocole de validation est encore simple. Il faut ajouter un protocole de
validation qui permet de garder toutes les idées des thématiciens et modélisateurs, comme une
check-list sur les fonctionnalités importantes. Cette check-list doit être examinée par tous les
contributeurs.

Enfin, concernant notre infrastructure, ce sera plus intéressant si elle a un système de log qui
trace tous les travaux, les interactions passées dans la simulation collaborative. Cette fonction-
nalité va nous permet de revoir la simulation et faire des analyses profondeurs pour bien adapter
les besoins des thématiciens, voire réaliser des étydes, par des sociologues, avec les simulations
réalisées.
<figure><img src="image_52.png" /></figure>
# Expérimentation & Évaluation

## Sommaire

<table><tr><td>6.1</td><td>Protocole d'évaluation</td><td>110</td></tr><tr><td>6.1.1</td><td>Méthodes d'évaluation du génie logiciel</td><td>110</td></tr><tr><td>6.1.2</td><td>Méthodes d'évaluation dans le domaine de la simulation collaborative</td><td>111</td></tr><tr><td>6.1.3</td><td>Proposition d'une méthode d'évaluation adaptée</td><td>112</td></tr><tr><td>6.2</td><td>Cas d'application : le projet MIRO</td><td>114</td></tr><tr><td>6.2.1</td><td>Le projet, son contexte, ses enjeux</td><td>116</td></tr><tr><td>6.2.2</td><td>Le modèle</td><td>116</td></tr><tr><td>6.2.3</td><td>Le simulateur</td><td>117</td></tr><tr><td>6.2.4</td><td>Synthèse : Identification de la collaboration autour du simulateur MIRO</td><td>118</td></tr><tr><td>6.3</td><td>Transformation du simulateur MIRO par DeCoSim</td><td>121</td></tr><tr><td>6.3.1</td><td>Identification des différents rôles</td><td>121</td></tr><tr><td>6.3.2</td><td>Établissement du modèle du domaine</td><td>122</td></tr><tr><td>6.3.3</td><td>Établissement du modèle conceptuel</td><td>134</td></tr><tr><td>6.3.4</td><td>Transformation</td><td>137</td></tr><tr><td>6.3.5</td><td>Validation</td><td>138</td></tr><tr><td>6.4</td><td>Expérimentation par les experts</td><td>138</td></tr><tr><td>6.4.1</td><td>Évaluation des fonctionnalités collaboratives</td><td>139</td></tr><tr><td>6.4.2</td><td>Évaluation des performances de la plateforme PAMS</td><td>144</td></tr><tr><td>6.4.3</td><td>Évaluation de l'efficacité par la synchronisation</td><td>146</td></tr><tr><td>6.4.4</td><td>Synthèse</td><td>147</td></tr><tr><td>6.5</td><td>Conclusion</td><td>149</td></tr></table>

Lors de deux chapitres précédents, nous avons présenté notre proposition, au niveau théorique :

- un ensemble de mécanismes pour collaborer autour d'une expérimentation (voir le chapitre 4)

- une méthode pour transformer un simulateur *stand-alone* en une version collaborative (voir le chapitre 5)

De plus, nous avons développé une infrastructure logicielle pour introduire et expérimenter des simulations collaboratives. Il est maintenant nécessaire d'évaluer ces propositions.

Cependant, il est difficile de s'assurer de la pertinence et de la complétude des outils mis en œuvre car nous ne disposons pas d'éléments tangibles qui prouvent l'efficacité de notre approche. La seule méthode que nous connaissons vise à confronter la méthode à des problèmes concrets de simulation des systèmes complexes. À l'usage, nous aurons ainsi une idée des atouts et des faiblesses de notre méthode.
Dans le temps limité d'une thèse, il est difficile de réaliser des expérimentations sur un grand nombre de cas différents, ainsi nous avons choisi un cas concret de simulation collaborative : le projet ANR MIRO. MIRO est un projet de recherche du domaine de la géomatique qui tente de reproduire les dynamiques urbaines de la ville de Dijon, et de Grenoble en France.

Au cours de ce chapitre, premièrement, nous allons présenter le contexte de notre application (le projet MIRO) et identifier les besoins entre les utilisateurs des simulations MIRO. Ensuite, nous allons montrer comment rendre collaboratif le simulateur MIRO en appliquant notre démarche de transformation. Troisièmement, le nouveau simulateur sera utilisé de manière collaborative dans des expérimentations avec des utilisateurs réels. Nous clôturons ce chapitre avec un certain nombre d'analyses de l'efficacité et de l'utilisabilité de notre travail.

## 6.1 Protocole d'évaluation

L'évaluation est une ou plusieurs collections d'opérations pour démontrer qu'un produit, une approche ou un travail est fiable et répond à ce que l'utilisateur exige. Cependant, par une étude bibliographique, nous trouvons qu'il y a peu d'efforts concernant l'évaluation de l'efficacité des outils et méthodes de simulation collaborative par exemple le travail de Taylor et al [Taylor 2003], de Korichi et al [Korichi 2008], GroupSim [Hirata 2008], CollabBillboard [Dugan 2002]. Par conséquence, dans cette section, nous allons proposer une approche pour évaluer notre proposition en nous basant sur les méthodes d'évaluation du génie logiciel.

### 6.1.1 Méthodes d'évaluation du génie logiciel

La littérature disponible concernant l'évaluation empirique des approches de développement logiciel s'avère assez limitée [Kitchenham 2006]. Mais en général, nous pouvons identifier trois catégories de méthodes d'évaluation [Coulin 2007, Kitchenham 1996] : (i) des méthodes quantitative ; (ii) des méthodes qualitatives ; et (iii) des méthodes hybrides.

L'évaluation quantitative se base sur l'hypothèse que nous pouvons identifier certaines propriétés mesurables (ou propriétés) d'un produit logiciel ou d'un processus que nous nous attendons à changer à la suite de l'utilisation des méthodes/outils que nous voulons évaluer. L'évaluation quantitative peut être catégorisée de trois façons différentes :

- **Étude de cas** : L'étude de cas est une méthode qui examine le phénomène réel dans son contexte naturel. Cette méthode est facile à effectuer pour l'organisation du développement logiciel, car elle n'exige pas la réplication.

- **Expérimentation formelle** : C'est la méthode dans laquelle un nombre de groupes d'utilisateurs utilise des approches ou outils différentes pour effectuer une même tâche, sous les mêmes conditions et circonstances, pour la comparaison. Cette méthode est bonne pour examiner des approches alternatives.

- **Sondage** : Les sondages sont utilisés lorsque la(les) méthode(s)/outil(s) variés ont été utilisés dans une organisation (ou groupe d'organismes). Dans cette situation, les utilisateurs de la méthode (s) / outil (s) peuvent être invités à fournir des informations sur n'importe quelle propriété intéressante (par exemple, le processus de développement ou la productivité).

Les méthodes qualitatives (autrement dit l'approches Feature Analysis) sont basées sur
l'identification des besoins que les utilisateurs ont pour une activité particulière, et l'identi-
fication des moyens proposés par la méthode/outil. Ensuite, ces caractéristiques sont évalués
par une comparaison avec d'autres méthodes alternatives ou avec les résultats de la littérature
[Kitchenham 1996] identifie trois approches d'évaluation qualitative :

- **L'expérimentation qualitative** : Une évaluation des moyens est effectuée par un groupe d'utilisateurs potentiels. Il s'agit d'élaborer les critères d'évaluation et la méthode de l'analyse des résultats en utilisant l'approche qualitative mais l'organisation de l'activité d'évaluation comme une expérimentation.

- **L'étude qualitative de cas** : Une évaluation des caractéristiques effectuées après une méthode/outil a été utilisée dans la pratique dans un projet réel.

- **Le sondage qualitatif** : Une évaluation basée sur les caractéristiques fait par des gens qui ont une expérience de l'utilisation ou ont étudié les méthodes/outils d'intérêt. Il s'agit de concevoir un critère d'évaluation et la méthode de l'analyse des résultats en utilisant l'approche qualitative, mais l'organisation de l'évaluation est comme un sondage.

Enfin, les méthodes d'évaluation hybrides qui mélangent des éléments quantitatifs et qua-
litatifs dans une seule méthode. Nous pouvons citer comme de méthodes l'analyse des effets
qualitatifs et le Benchmarking [Kitchenham 1996], ou la méthode utilisé pour évaluer l'environ-
nement informatique ubiquité [Burnett 2001].

### 6.1.2 Méthodes d'évaluation dans le domaine de la simulation collaborative

Les travaux d'évaluation réalisés sur la simulation collaborative ne manquent pas en nombre.
Cependant, les principaux travaux de validation existants qui bénéficient d'une crédibilité scien-
tifique ou ceux d'un organisme agréé sont : le travail de Taylor [Taylor 2001, Taylor 2003],
Korichi [Korichi 2008], GroupSim [Hirata 2008], CollabBillboard [Dugan 2002]

Le travail de Simon JE Taylor [Taylor 2001, Taylor 2003] est un des rares travaux
s'intéressant à la validation des simulations collaboratives. Il a mis l'accent sur l'importance du
collecticiel dans le processus de modélisation simulation. Ce dernier fournit des fonctionnalités
collaboratives qui permettent de réaliser des communications, la coordination et la collabora-
tion entre des participants distribués géographiquement. Par exemple, il propose d'utiliser l'outil
NetMeeting de Microsoft pour réaliser les tâches collaboratives, comme la visio-conférence, la
messagerie instantanée ou le partage d'application.

Enfin, pour évaluer sa théorie, il a effectué une évaluation qui est une combinaison entre la
méthode d'expérimentation et le sondage. Premièrement, il invite les personnes qui s'intéressent
au problème de la simulation collaborative, à participer à une démonstration avec des collec-
ticiels. Après la démonstration, les participants répondent à un questionnaire pour comparer
et évaluer la solution selon leur expérience. Ensuite, après deux ou trois mois, il va chez ces
participants pour observer leur adaptation à la solution proposée. Lorsque la première étape
est achevée, le résultat obtenu est un diagramme qui représente la classification de chaque ser-
vice de la solution proposée. Tandis que, pour la deuxième étape, le résultat est un résumé de
l'observation et des discussions avec les personnes qui utilisent encore la solution proposée.

Similaire au travail de Taylor, Korichi [Korichi 2008] a mis en évidence la collaboration dans
le processus de modélisation et simulation. Comme nous avons déjà abordé dans la section 2.2
page 33, Korichi a proposé une solution qui est une combinaison entre la technologie du Web
<table><caption>TABLE 6.1 – Synthèse des méthodes utilisées</caption><thead><tr><th></th><th></th><th>Taylor</th><th>Korcichi</th><th>GroupSim</th><th>CollabBillboard</th></tr></thead><tbody><tr><td>1</td><td>Étude de cas</td><td></td><td></td><td>x</td><td></td></tr><tr><td>2</td><td>Expérimentation</td><td>x</td><td>x</td><td></td><td>x</td></tr><tr><td>3</td><td>Sondage</td><td>x</td><td>x</td><td></td><td>x</td></tr><tr><td>4</td><td>Approche qualitative</td><td></td><td></td><td></td><td></td></tr><tr><td>7</td><td>Hybride</td><td></td><td></td><td></td><td></td></tr></tbody></table>

et le TCAO pour former le collecticiel de simulation à la base de Web (Web Based Simulation Groupware - WBSG).

Pour valider sa théorie, Korichi a réalisé une méthode expérimentale combinée avec un sondage conduit par deux étudiants, deux ingénieurs et un spécialiste des statistiques. Les étudiants ont réalisé les expérimentations sous la direction de leurs superviseurs. L'expérimentation a eu lieu sur plus de six mois. L'évaluation est effectuée par des sondages, des questionnaires après chaque expérimentation. De façon similaire à l'approche de Taylor, le résultat obtenu est d'une classification sur les services et la solution proposée.

GroupSim [Hirata 2008] est un environnement collaboratif pour le développement de simulateurs à événements discrets pour le World Wide Web. Pour évaluer le travail, Hirata et al ont appliqué la méthode l'étude de cas avec trois applications réelles.

CollabBillboard [Dugan 2002] est un collecticiel de simulation synchrone. Pour évaluer son produit, les acteurs ont pris la méthode d'expérimentation et le sondage.

Le table 6.1 synthétise les méthodes d'évaluation présentées dans cette partie. Les trois méthodes quantitatives sont appliqués souvent pour évaluer le travail concernant la simulation collaborative. Dans la section suivante, nous allons présenter notre méthode en nous basant sur ces travaux.

### 6.1.3 Proposition d'une méthode d'évaluation adaptée

#### a) L'objectif d'évaluation

Notre travail a pour but de proposer des méthodes et outils pour faciliter la collaboration entre des thématiciens dans la simulation. Ainsi la mesure la plus importante que nous voulons évaluer est l'utilisabilité de notre solution. Selon l'organisation internationale de normalisation (ISO), l'utilisabilité est le degré selon lequel un produit peut être utilisé, dans un domaine, par des utilisateurs identifiés, pour atteindre des buts définis avec efficacité, efficience et satisfaction : ("extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use."). Ainsi, nous avons développé une approche pour évaluer notre proposition selon trois aspects :

- **Efficacité** : Est-ce que le produit permet à ses utilisateurs d'atteindre le résultat prévu ?

- **Efficience** : Est-ce que l'utilisateur peut atteindre le résultat avec un moindre effort ou requiert un temps réduit ?

- **Satisfaction** : Est-ce que le produit est agréable à utiliser ?
Pour évaluer notre travail, nous appliquons trois méthodes quantitatives : l'étude de cas, l'expérimentation et le sondage. Premièrement, nous effectuons une étude de cas où notre méthode (DeCoSim) est appliquée pour transformer le simulateur MIRO en celui collaboratif (nous allons présenter le détail du modèle MIRO dans la partie suivant). Ensuite, le nouveau simulateur est expérimenté par les utilisateurs réels du projet. Après les expérimentations chaque participant va faire un sondage quantitatif pour évaluer le simulateur. Avant l'expérimentation, nous allons faire également un sondage court s'intéressant à l'expérience personnelle des participants dans la simulation collaborative. Le fait d'organiser deux sondages permet d'avoir une vue comparative entre notre résultat avec des méthodes que les participants ont déjà utilisées.

### b) La méthode et les mesures d'évaluation

En nous basant sur trois aspects proposés par ISO pour les tests d'utilisabilité, nous raffinons ces indicateurs pour notre méthode d'évaluation :

- **Efficacité** : Est-ce que la méthode DeCoSim permet de transformer le simulateur *stand-alone* en une version collaborative ? Est-ce que le nouveau simulateur et les mécanismes proposés permettent d'effectuer des simulations collaboratives ?

- **Efficience** : Est-ce que l'utilisateur peut concevoir et manipuler le simulateur collaboratif et les simulations collaboratives avec un moindre effort ou en peu de temps ?

- **Satisfaction** : Est-ce que la méthode DeCoSim, les mécanismes pour la simulation collaborative et l'infrastructure logicielle sont agréables à utiliser ?

Pour le premier aspect, l'**efficacité** c'est la capacité de notre solution à atteindre l'objectif de transformation de simulateur MIRO et l'ergonomie pour la simulation collaborative. Nous la mesurons également par la réussite de la tâche et la performance de la plateforme lors de la simulation des scénarios pré-définis.

Tandis que, l'**efficience** est la capacité de réaliser une tâche donnée avec le moindre d'effort. Nous réalisons les simulations collaboratives en utilisant le nouveau simulateur, et mesurons l'efficience à l'aide des indicateurs suivants : le taux et la nature des erreurs d'utilisation, le temps nécessaire pour exécuter une tâche.

Enfin, pour la **satisfaction**, nous allons la mesurer par des questionnaires (de type Oui/Non) qui s'intéressent aux fonctionnalités importantes pour une simulation collaborative. Les questions ont pour objectif de déterminer si les participants peuvent utiliser les fonctionnalités de la plateforme.

Dans ces trois aspects d'évaluation, l'**efficience** peut être examinée par l'observation des expérimentations et l'étude de cas. Elle est évaluée via le taux, la nature des erreurs et le temps nécessaire pour exécuter une tâche, tandis que les autres sont évalués par le résultat du sondage et de l'étude de cas. Les questionnaires du sondage que nous proposons s'intéressent à ces deux aspects.

Ainsi, nous nous basons principalement sur le travail SUMI [Kirakowski 1993], SUS [Brooke 1996] et de Coulin [Coulin 2007] pour concevoir les questionnaires du sondage. Chaque réponse à une question est une note entre 1 et 5. Cependant, ces derniers ont proposé des questions très génériques qui ne sont pas suffisantes dans notre cas. Nous voulons évaluer des fonctionnalités concrètes et spécifiques. Par conséquent, au lieu de concevoir des questions de type générique, nous rédigeons des questions détaillées. Les fonctionnalités/tâches importantes
qui influencent le plus la simulation collaborative sont identifiées. Chaque fonctionnalité/tâche est évaluée par une question avec deux catégories de réponse. La première catégorie pour savoir si le participant peut effectuer cette fonctionnalité (la réponse est Oui ou Non). Cette catégorie nous permet de connaître la **satisfaction** de l'utilisateur. La deuxième catégorie est pour évaluer la qualité/utilité ou la réussite de chacune selon une échelle de valeurs : 1-très faible, 2-faible, 3-moyen, 4-élevée, 5-très élevée.

Deux groupes de fonctionnalités/tâches sont identifiés : (i) les fonctionnalités collaboratives conventionnelles et (ii) les fonctionnalités collaboratives spécifiques à la simulation. Pour le premier groupe, il y trois fonctionnalités importantes, et 18 fonctionnalités pour le second groupe. Dans ces fonctionnalités/tâches, nous identifions 8 fonctionnalités/tâches qui sont critiques pour le succès d'une simulation collaborative, comme présenté par le tableau 6.2 (Les fonctionnalités/tâche en gras sont critiques).

Le résultat du sondage est traité ensuite selon la façon suivante :

- Pour la première question où la réponse est Oui/Non, nous calculons le pourcentage de réponses "OUI" sur le nombre de participants. Nous considérons la valeur de 0 à 20% est insatisfait, 20% - 40% est peu satisfait, 40% - 60% est acceptable, 60% - 80% satisfait, et 80% - 100% est très satisfait. En nous basant sur cette évaluation, nous pouvons déterminer si notre travail satisfait les utilisateurs.

- Concernant la deuxième réponse, nous calculons la valeur moyenne en divisant le somme des réponses sur le nombre d'utilisateur qui peut effectuer la fonctionnalité/tâche. Cette valeur varie de 0 à 5. Nous considérons une moyen entre 0-1 est correspondant très faible, 1-2 est faible, 2-3 est moyen, 3-4 est élevé et 4-5 très élevé.

De plus, pour bien connaître les expériences des participants et pour avoir une vue comparative avant et après les expérimentation. Nous faisons également un sondage avant l'expérimentation concernant l'expérience personnelle de chaque participant.

Pour une évaluation fidèle, il faut organiser les expérimentations dans le temps (au moins 6 mois comme la méthode de Kroichi) avec la participation des personnes dans des domaines différents. Cependant, à cause de contrainte de temps et les conditions de réalisation des expérimentations (les participants de l'expérimentation sont distribués géographique et très occupés), nous ne pouvons pas réaliser des expérimentations avec la quantité prédéfinie. Néanmoins, sur l'ensemble des résultats obtenus, ils nous permettent une évaluation acceptable pour le développement et l'amélioration dans le futur.

## 6.2 Cas d'application : le projet MIRO

Ce projet vise à reproduire les dynamiques intra-urbaines en ayant une approche originale basée sur les activités. Depuis plusieurs années, l'homme a essayé d'étudier la mobilité pour bien comprendre le monde qui l'entoure. Cependant, la mobilité lie souvent des systèmes complexes, ainsi son étude est une tâche difficile. Habituellement, il faut combiner la connaissance de domaines différents pour comprendre un problème. Un exemple marquant est celui du projet MIRO concernant la mobilité urbaine qui invoque la connaissance de géographes, d'économistes, de statisticiens et d'informaticiens. Au cours de cette section, nous allons présenter ce projet pour avoir une vue globale avant détailler l'application de notre méthode.
<table><caption>TABLE 6.2 – Les fonctionnalités/tâche pour les questions</caption><thead><tr><th></th><th>Fonctionnalité</th><th>Oui/Non</th><th>1</th><th>2</th><th>3</th><th>4</th><th>5</th></tr></thead><tbody><tr><td>1</td><td>Messagerie instantanée</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>2</td><td>Visio conférence</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>3</td><td>Tableau blanc</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>4</td><td>Lister les modèles disponible et les descriptions</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>5</td><td>Inviter de nouveaux participants à distance</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>6</td><td>Créer une expérimentation avec un modèle choisi</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>7</td><td>Configurer l'expérimentation et ses fonctionnalités collaboratives</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>8</td><td>Voir et bien connaître les scénarios disponibles pour chaque modèle</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>9</td><td>Connaître les rôles décrits dans un scénario (sa mission, ses droits)</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>10</td><td>Choisir les rôles pour chaque participant</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>11</td><td>Lister des expérimentations encours et terminées</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>12</td><td>Rejoindre une expérimentation</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>13</td><td>Bien connaître les participants (leur rôle, leur expérience ...)</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>14</td><td>Modifier des paramètres selon vos droits</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>15</td><td>Voir et analyser les résultats selon vos droits</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>16</td><td>Percevoir les modifications des paramètres par les autres participants</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>17</td><td>Percevoir les changements d'état de simulation par les autres participants</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>18</td><td>Avoir des sorties privées que les autres ne peuvent pas voir</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>19</td><td>Partager des paramètres, observations, moniteurs privées avec d'autres</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>20</td><td>Percevoir l'état des participants (en ligne ou pas)</td><td></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>
## 6.2.1 Le projet, son contexte, ses enjeux

MIRO est un projet financé, à l'origine, par le ministère des transports via le PREDIT, ensuite par l'Agence Nationale de la Recherche, qui étudie la mobilité urbaine. Au contraire avec des approches comme Transims [Nagel 2001] (ce projet résout la problématique par la reproduction de l'urbain dynamique). Il s'inscrit dans un cadre théorique plus vaste, regroupant des travaux variés autour des systèmes complexes et de la simulation à base d'agent.

Ce projet de recherche pluridisciplinaire associe géographes, économistes, statisticiens et informaticiens de plusieurs institutions et universités : CNRS (géographie cité), IRD (UM-MISCO), Université de Strasbourg (UMR LIVE), Franche-Comté à Besançon (UMR CRESE et UMR FEMTO-ST), de Bourgogne (THEMA), de Grenoble (PACTE), d'Orléans (CEDETE). En fait, ce projet est divisé en deux périodes. Le premier temps, de 2002 à 2006, est financé par le GO 1 du PREDIT 2, puis de 2009 à 2013 (MIRO2) par l'ANR Ville Durables. Ce projet fait partie des projets labellisés par le pôle Véhicules du Futur et par l'institut des Systèmes Complexes de Paris-Ile de France (www.iscpif.fr).

Le projet MIRO repose sur une approche centrée individus s'intéressant à la mobilité urbaine. Un modèle multi-agent a été développé. Il permet d'évaluer, par simulation, l'influence de l'espace urbain, sur le fonctionnement collectif de comportements individuels la construction et la réalisation de programmes quotidiens d'activités.

L'objectif de la deuxième période est d'accroître l'accessibilité à la ville pour maîtriser la mobilité urbaine en exploitant les résultats de la première étape. Cela implique une réflexion de fond sur l'accessibilité à l'espace urbain, au niveau structurel ainsi qu'au niveau fonctionnel.

Dans le cadre de cette thèse, nous nous reposerons sur ces recherches, le modèle MIRO2 et le simulateur développé. Ainsi, nous appliquerons notre approche DeCosim pour transformer le simulateur Miro2 en un simulateur participatif utilisable dans le cadre d'un jeu sérieux.

## 6.2.2 Le modèle

A la suite d'un travail bibliographique portant notamment sur la plate-forme TRANSIMS [Nagel 2001], la méthode de conception du modèle MIRO est choisi comme présenté dans la figure 6.1 et 6.2. Quatre grandes étapes sont alors distinguées.

La première concerne la création d'une ville virtuelle, à partir de données SIG existantes portant sur Dijon. L'idée est ici de décrire le plus finement possible les localisations résidentielles, l'offre de transport et l'offre d'activité, y compris en termes d'horaires d'ouverture et de capacité d'accueil. La deuxième étape porte sur la création et l'affectation spatiale d'une population d'agents « synthétiques » virtuels, à partir de données disponibles d'enquête comme l'enquête ménages-déplacements (EMD) de Dijon et de Grenoble.

Ces deux premières étapes constituent le socle fondamental nécessaire à la réalisation de la troisième étape : la génération par chaque agent de son emploi du temps, à partir d'une liste individualisée d'activités à accomplir et la prise en compte des contraintes spécifiques des lieux d'activité concernés. Ces trois premières étapes constituent ce que l'on pourrait appeler l'initialisation du système multi-agent. L'objectif de la dernière étape est alors de laisser chaque agent tenter de respecter son emploi du temps ainsi composé en explorant et parcourant l'espace urbain par utilisation des modes de transport à leur disposition.
<figure><img src="image_53.png" /><figcaption>FIGURE 6.1 – Le ceour du projet MIRO [LANG 2006]</figcaption></figure>

### 6.2.3 Le simulateur

Lors de la première période, le modèle MIRO a été implémenté dans un simulateur multi-agent qui est développé à partir de la bibliothèque RAFALE-SP [Marilleau 2006]. Ce simulateur s'interface avec la plate-forme MadKit qui l'exécute. L'entrée de ce simulateur est venu de deux sources différentes : une base de données My-SQL Open-GIS et des fichiers textuels. Le premier contient toutes les données cartographiques de la ville de Dijon (tronçon de route et bâti) qui sont essentielles à la création d'un environnement virtuel où se déplacent les agents. Le dernier stocke les informations importantes pour la création des agents représentatifs d'une population synthétique représentative des habitants de Dijon. L'exécution de ce simulateur permet la production de plusieurs données, par exemple la position des mobiles à chaque instant, l'activité de chaque mobile, le taux d'occupation d'un tronçon, pour chaque agent le planning qu'il génère et celui qu'il exécute réellement. Toutes ces informations sont stockées de deux manières :

- certaines sont utilisées pour être visualisées via une interface englobante.

- les autres (la plupart) sont stockées dans des fichiers de trace permettant ainsi une analyse, à posteriori, par la plate-forme d'intégration visuelle (comme dans la figure 6.3).

La deuxième version du simulateur Miro2 est quant-à elle plus simple mais plus attractive. Ce simulateur a été développé au sein de la plate-forme libre NetLogo, comme illustré par les figures A.7 et A.8 dans l'annexe, afin d'explorer les possibilités de création du jeu sérieux à destination des décideurs politiques et des acteurs publics. Le détail de ce simulateur est présenté dans l'annexe 7.2 page 168. Dans le cadre de cette thèse, nous nous reposerons sur cette version du simulateur.

L'objectif de ce simulateur est plus restreint : tester quatre organisation des services :
<figure><img src="image_54.png" /><figcaption>FIGURE 6.2 – L’approche retenue dans MIRO [LANG 2006]</figcaption></figure>

- polarisées (gros centres commerciaux périphériques et de centre ville)

- semi polarisées (modèle supérette)

- homogènes (relais colis, un service tous les 250 m)

- à domicile (livraison à domicile)

En effet, la simulation avec ce simulateur est un travail pluridisciplinaire. Dans la section suivante nous allons voir deux scénarios d'utilisation collaborative de ce simulateur.

### 6.2.4 Synthèse : Identification de la collaboration autour du simulateur MIRO

Comme déjà présenté dans les sections ci-dessus, MIRO est un projet pluridisciplinaire qui associe des thématiciens provenant de domaines différents : ils sont géographes, économistes, statisticiens et informaticiens. Ces thématiciens sont géographiquement dans des endroits différents, si bien que la collaboration autour du simulateur MIRO est une collaboration à distance. Considérons deux scénarios : Le premier est simple et le second est plus complexe.

#### a) Premier scénario : un jeu de deux rôles pour organiser la ville

Cette situation est passée entre deux communautés différentes : l'aménageur et l'usager. Le premier est responsable d'organiser la ville, de calibrer les routes pour les voitures et de contrôler la vitesse des mobiles. Le second (l'usager) se déplace, utilise les transports en commun etc. Chaque usager a une satisfaction personnelle à atteindre, par exemple aller au bureau, à l'université ou aller au supermarché.

Dans ce scénario, chaque acteur possède un sous ensemble des paramètres dont il a la responsabilité. Généralement, les rôles de deux acteurs ne sont pas équivalents. L'aménageur est considéré comme une personne qui a le plus de pouvoir. Il ordonne des politiques qui influencent
<figure><img src="image_55.png" /><figcaption>FIGURE 6.3 – Algorithme pour la génération des emplois du temps [LANG 2006]</figcaption></figure>

le déplacement des usagers.

Ce scénario est effectuée comme un jeu sérieux entre les deux rôles. Chaque rôle s'intéresse à des paramètres différents, chacun possède un droit qui correspond à son rôle. En se basant sur ce droit, le simulateur est simultanément manipulé. Le rôle de l'aménageur est considéré comme le contrôleur qui définit des politiques que l'usager utilise. La simulation sera bien passée seulement si leurs activités sont effectués harmonieusement et selon l'ordre : l'aménageur donne les contraintes, puis l'usager essaye avec différents modes de transports utilisés, et enfin analyser les résultats.

### b) Deuxième scénario : un jeu de quatre rôles pour organiser la ville

Ce jeu sérieux est conçu pour accueillir 3 joueurs, ainsi qu'un maître du jeu. Chacun de ces participants a un rôle défini différent des autres. Les trois joueurs sont acteurs de la simulation et assurent un rôle : soit l'acteur économique, soit l'acteur citoyen ou soit l'acteur public.

De manière similaire au premier scénario, chaque acteur dispose d'une partie des fonctionnalités offertes par le simulateur. La simulation est alors manipulée par l'ensemble des acteurs. Les trois acteurs économiques, citoyens et publics sont similaires à l'aménageur dans le scénario précédent. Mais, ils sont assignés à des tâches plus concrètes et précises. Chacun s'occupe d'un type de service. Il les localise et les spécifie pour construire la carte.

La simulation dans ce scénario suit un protocole identifié qui a été déterminé par les géographes :

1. Le maître du jeu crée l'expérimentation et invite les autres à participer.

2. Quand tous les rôles sont connectés, l'acteur public commence la simulation par la création du réseau, la spécification de la ZAPA (Zone d'Action Prioritaire pour l'Aire) et la définition des vitesses.

3. Puis, le maître du jeu réalise le calcul des plus courts chemins.

4. Ensuite, l'acteur économique localise/déplace/supprime les services publics, commerciaux et des lieux de travail. Tandis que, l'acteur citoyen localise/déplace/supprime les domiciles
(maisons individuelles et résidences) et modifie la capacité d'hébergement des résidences.

5. Ensuite, le maître du jeu crée les agents et lance la simulation.

À son tour, chacun effectue une mission concrète. Le travail d'un acteur dépend du résultat de l'étape précédente. La collaboration entre ces rôles doit être harmonieuse pour que la simulation soit bien effectuée et pour éliminer les conflits.

<figure><img src="image_56.png" /><figcaption>FIGURE 6.4 – La simulation collaborative avec le simulateur MIRO *stand-alone*</figcaption></figure>

Ces deux scénarios offrent deux cas d'étude qui nous permettront d'évaluer l'approche, les moyens conceptuels et les outils que nous avons défendus tout au long de cette thèse. En effet, les scénarios nécessitent une collaboration importante entre les participants. Par ailleurs, le simulateur MIRO repose sur une architecture *stand-alone*. Dans le contexte du projet, les scénarios mis en place nécessitant des interactions distantes, nous transformerons alors le simulateur Miro actuel afin d'introduire la collaboration. Pour cela nous nous reposerons sur l'approche DeCoSim.

<figure><img src="image_57.png" /><figcaption>FIGURE 6.5 – La simulation collaborative avec le simulateur MIRO collaboratif</figcaption></figure>
## 6.3 Transformation du simulateur MIRO par DeCoSim

Dans la section précédente, nous avons présenté le projet MIRO, et analysé la collaboration autour de ce simulateur. La faiblesse de ce dernier dans le support la collaboration est également identifiée. Au cours de cette section, nous allons appliquer notre démarche pour transformer ce simulateur standalone en une version collaborative, comme illustré dans la figure 6.6. La section va s'organiser selon les étapes de notre démarche. Tout d'abord, les différents rôles des contributeurs vont être identifiés, ensuite nous allons spécifier le modèle du domaine CoODD pour MIRO. Puis, le modèle conceptuel sera établi. Enfin, nous effectuerons la transformation du simulateur et sa validation.

<figure><img src="image_58.png" /><figcaption>FIGURE 6.6 – Processus de transformation du simulateur MIRO</figcaption></figure>

### 6.3.1 Identification des différents rôles

En nous basant sur les deux cas d'utilisation proposés dans la section 6.2.4 page 118, nous identifions le rôle des contributeurs nécessaire à la transformation du simulateur MIRO. Dans les deux cas, j'assurerai le rôle de concepteur et de développeur informaticiens. Tandis que les thématiciens concepteurs sont les membres du projet MIRO :

- Un géographe - Chef de projet : il est responsable scientifique pour le projet MIRO2. Il m'aide à identifie les scénarios collaboratifs et à évaluer l'utilisabilité de notre travail avec MIRO.

- Un modélisateur : il est responsable scientifique du projet et donc initiateur de celui-ci. Il organise la direction scientifique et les aspects administratifs. Pour le projet MIRO 2, il travaille sur la vérification des agents impliqués dans le cadre du simulateur et sur la distribution de la plate-forme de simulation pour la montée en charge.
- Deux géo-informaticiens : Ils m'aident à bien comprendre le modèle et simulateur, à établir les scénarios collaboratifs, à valider le nouveau simulateur collaboratif et à évaluer l'utilisabilité de notre travail avec MIRO.

- Deux géographes : Ils apportent les connaissances en géographie.

- Un ingénieur : Il est le développeur principale du simulateur NetLogo. C'est aussi lui qui m'aide à valider le nouveau simulateur collaboratif. Il m'aide également à réagir des scénarios collaboratif et bien comprendre le simulateur *stand-alone* NetLogo.

Ces thématiciens concepteurs m'ont aidé pour comprendre le modèle, le simulateur, et ont été force de proposition pour l'établissement des scénarios. À cause de la distribution géographique, nous avons souvent travaillé par des outils collaboratifs synchrones permettant la visio-conférence, ainsi que les outils asynchrones comme le courriel.

Concernant les thématiciens utilisateurs, ils sont dans un premier scénario simple aménageurs, usager de la ville (cf 6.2.4 page 118), dans le second scénario ils sont : l'acteur économique, l'acteur citoyen, l'acteur public.

## 6.3.2 Établissement du modèle du domaine

Lorsque de cette étape, nous avons collaboré avec les thématiciens concepteurs pour élaborer le CoODD de MIRO. Dans cette partie, nous présentons seulement les parties concernant la collaboration de CoODD (Simulateur, Profile d'utilisateur, l'aspect d'application et Collaboration, comme présenté dans la figure 6.3). Pour les autres parties de ODD (Overview, Design Concepts, Detail), le lecteur peut les consulter dans l'annexe 7.2 page 168.

<table><caption>TABLE 6.3 – Les parties concernant la collaboration de CoODD</caption><thead><tr><th></th><th></th></tr></thead><tbody><tr><td>...</td><td>...</td></tr><tr><td rowspan="3">Simulator</td><td>General information</td></tr><tr><td>Input Parameters</td></tr><tr><td>Output</td></tr><tr><td>User's profile</td><td>User's profile</td></tr><tr><td>Application aspect</td><td>Application aspect</td></tr><tr><td rowspan="4">Collaboration</td><td>Responsibilities</td></tr><tr><td>Collaborator</td></tr><tr><td>Permission</td></tr><tr><td>Collaboration template</td></tr></tbody></table>

### a) Simulateur

Comme présenté dans la section 5.3.1 page 92, dans cette partie, nous présentons trois blocs concernant : (i) l'information générale du simulateur ; (ii) les paramètres d'entrées et (iii) les sorties.

#### Simulator

##### 1. General information

Cette nouvelle version du modèle est prévue pour fonctionner avec la plate-forme NetLogo
dans sa version 5.0.1. L'utilisation avec des versions antérieure peut provoquer des dysfonctionnements. Ce modèle vient sous la forme d'un ensemble de fichiers, décomposés comme tel :

- Statik_v2.nlogo : C'est le fichier principal, qu'il convient d'ouvrir avec NetLogo.

- Un ensemble de fichiers d'extension .nls, lesquels regroupent les fonctions, classées thématiquement, utilisés par le fichier principal.

- Un dossier nommé *nw* : Il s'agit là d'une extension NetLogo qui permet d'effectuer rapidement tous les calculs portant sur le réseau. Il convient d'installer cette extension avant le lancement du modèle. Pour ce faire, il suffit de coller le dossier nw dans son ensemble dans le sous-dossier *extensions* du dossier où est installée la version 5.0.1 de NetLogo.

Généralement, le simulateur MIRO peut être divisé en deux parties, voir les figures 1 et 2. La première est constitué par l'ensemble des entrées (des paramètres et des actions possibles) et les sorties génériques que tous les utilisateurs peuvent manipuler. La seconde présente les sorties pour les rôles différents.

Ce simulateur est manipulé par des différents thématiciens. Ils doivent suivre le cheminement proposé pour bien installer les éléments de base, comme les services. Le cheminement est organisé par une ensemble de boutons qui sont numérotés sur la gauche de la fenêtre de visualisation (la figure 1). Chaque bouton contient également un ensemble de sous-boutons, de paramètres qui sont situés à la droite de la fenêtre.

Dans la figure 2, les sorties sont organisées selon chaque profil d'utilisateur. Chacun d'eux possède un ensemble de moyens pour analyser l'exécution de la simulation.

## 2. Input parameters

Les entrées du simulateur MIRO sont groupées selon les étapes du scénario que nous avons établi. Chaque étape possède un ensemble de paramètres et des actions associées. Il y a 7 étapes dont :

1. Initialisation du réseau (Créer réseau)

2. Création de la ZAPA

3. Définition des vitesses limites

4. Calcul des plus courts chemins

5. Activation des services

6. Création des agents mobiles

7. Lancer la simulation

Chaque étape contient un ensemble paramètres et des boutons qui représente l'entrée de l'étape. Par exemple, dans les figures 3, 4, ce sont des entrées pour l'étape *Initialisation du réseau*

Le réseau est la trame de base de la simulation qui représente les routes de la ville. La forme qu'on lui attribut au départ va conditionner tout le déroulement de l'expérimentation. L'utilisateur (ici l'aménageur) se voit proposer 3 formes de réseaux :

- Réseau régulier dit de Manhattan (par défaut) : Réseau qui représente un quadrillage régulier de l'espace, où de fait, tous les tronçon font la même longueur. Ce réseau peut
être soit orthogonal, chaque intersection étant reliée aux 4 plus proches (2 ou 3 pour les nœuds périphériques), soit octogonal, les intersections étant alors reliés aux 8 plus proches (3 ou 5 en périphérie).

- Réseau fractal (dit Serpienski) : Ce réseau est un réseau de type fractal, créé à partir d'une structure de base que l'on élargit de manière récurrente.

- Réseau libre d'échelle : C'est un réseau aléatoire que l'utilisateur peut modifier.
<figure><img src="image_59.png" /></figure>
<figure><img src="image_60.png" /><figcaption>Figure 2 : Le simulateur MIRO - Les sorties réservées aux rôles</figcaption></figure>
1) CRÉATION DU RÉSEAU
Choisir le type de réseau, et le configurer avec les options situées à droite de la fenêtre de visualisation. Quand paramétré, cliquer sur Créer le réseau.

Créer le réseau

<figure><img src="image_61.png" /><figcaption>Figure 4 : Les paramètres entrées pour le réseau</figcaption></figure>

Pour les autres étape, voir le détail dans l'annexe 7.2 page 168.

## b) Profil d'utilisateur

Le premier scénario comporte deux rôles simples : (i) Aménageur et (ii) Usager. Pour le second scénario, l'auteur de MIRO se concentre sur la version dans laquelle chaque objet (service commercial, service public, résidence, lieu de travail, réseau ou zapa) peut correspondre à un rôle. Il s'agit d'un jeu collaboratif : pas de compétition entre les joueurs mais des objectifs à la fois collectifs et individuels. Ils ont proposé deux versions différentes :

- une version à 3 joueurs : (Acteur économique (Service Public, Service Commercial, Travail); Acteur citoyen (Résidentiel) et Acteur public (Route, ZAPA, Transport Public)).

- une version à 7 joueurs : (Acteur Service Public, Service Commercial, Travail, Résidentiel, Route, ZAPA, Transport Public).

### User's profile

#### 1. Acteur Aménageur

- Domaine : L'aménagement du territoire et l'urbanisme

- Compétence et responsabilité : L'aménageur est à la fois acteur du développement local, organisateur de l'espace et créateur du cadre de vie de demain. Sa fonction est d'organiser l'espace en vue de créer de nouveaux quartiers, de prévoir leurs insertions en les reliant à leur environnement naturel et urbain, et de mettre en place les équipements nécessaires à la satisfaction des besoins des populations.

- Collaborateurs :

- D'autres aménageurs : Un aménageur collabore avec d'autres aménageurs afin de bien définir des politiques de la ville.

- Usager : L'aménageur collabore avec usager pour satisfaire bien le veux de l'usager, comme travailler, déplacer, utiliser des transports communes.

#### 2. Acteur Usager

- Domaine :

- Compétence et responsabilité : Ce sont des utilisateurs de la ville. Ils se déplacent, utilisent les transports en commun. Ils sont l'objet de mobiliser des stratégies.

- Collaborateurs :
- D'autres usagers : Un usager collabore avec d'autre usager pour bien effectuer une stratégie qui est ordonné par l'aménageur.

- Aménageur : L'usager collabore avec l'aménageur pour lui aider dans la recherche des politiques le plus convenable pour la ville.

## 3. Acteur Economique

- Domaine : L'aménagement du territoire et l'urbanisme

- Compétence et responsabilité : C'est un aménageur. Mais il concentre à organiser seulement des services publics, commerciaux et lieux de travail.

- Collaborateurs : Il collabore avec d'autre acteur économique ainsi d'autre acteur pour bien organiser la ville selon une stratégie prédéfinit.

## 4. Acteur Citoyen

- Domaine : L'aménagement du territoire et l'urbanisme

- Compétence et responsabilité : C'est un aménageur. Mais il concentre à organiser seulement des domiciles (maisons individuelles et résidences) et réglage de la capacité d'hébergement des résidences.

- Collaborateurs : Il collabore avec d'autre acteur citoyen ainsi d'autre acteur pour bien organiser la ville selon une stratégie prédéfinit.

## 5. Acteur Public

- Domaine : L'aménagement du territoire et l'urbanisme

- Compétence et responsabilité : C'est un aménageur. Mais il concentre à organiser seulement des routes, ZAPA, et transports public.

- Collaborateurs : un acteur public collabore avec d'autres acteurs publics pour bien organiser la ville selon une stratégie prédéfinie.

## 6. Acteur Service Public

- Domaine : L'aménagement du territoire et l'urbanisme

- Compétence et responsabilité : C'est un aménageur qui concentre à organiser le service public uniquement.

- Collaborateurs : Il collabore avec d'autres acteurs services publics pour bien organiser la ville selon une stratégie prédéfinie.

## 7. Acteur Service Commercial

- Domaine : L'aménagement du territoire et l'urbanisme

- Compétence et responsabilité : C'est un aménageur qui se concentre à organiser sur le service commercial.

- Collaborateurs : Il collabore avec d'autres acteurs service commercial citoyen pour bien organiser la ville selon une stratégie prédéfinit.

## 8. Acteur Travail

- Domaine : L'aménagement du territoire et l'urbanisme

- Compétence et responsabilité : C'est un aménageur qui se concentre à organiser seulement le lieu de travail.

- Collaborateurs : Il collabore avec d'autres acteurs travail.

## 9. Acteur Résidentiel

- Domaine : L'aménagement du territoire et l'urbanisme

- Compétence et responsabilité : C'est un aménageur. Mais il concentre à organiser seulement la résidence.
- *Collaborateur* :Il collabore avec d'autre acteur résidentiel.

10. Acteur Route

- Domaine : L'aménagement du territoire et l'urbanisme

- *Compétence et responsabilité* : C'est un aménageur. Mais il concentre à organiser seulement les routes.

- *Collaborateur* : Il collabore avec d'autre acteur route.

11. Acteur ZAPA

- Domaine : L'aménagement du territoire et l'urbanisme

- *Compétence et responsabilité* : C'est un aménageur. Mais il concentre à organiser seulement le ZAPA.

- *Collaborateur* :Il collabore avec d'autre acteur zapa.

12. Acteur Transport Public

- Domaine : L'aménagement du territoire et l'urbanisme

- *Compétence et responsabilité* : C'est un aménageur. Mais il concentre à organiser seulement le transport public.

- *Collaborateur* : Il collabore avec d'autre acteur transport public.

Pour d'avantage d'information le lecteur peut se référer à l'annexe 7.2 page 168.

c) Aspect d'application

Application aspect

L'objectif de ce modèle est d'accroître l'accessibilité à la ville pour maîtriser la mobi-
lité urbaine. Par un prototype multi-agents, le but du modèle collaboratif est d'assister les
aménageurs dans la définition de nouvelles politiques temporelles et/ou spaciales de trans-
port. Ce prototype est capable de tester des scénarios d'aménagement en jouant sur les niveaux
d'accès à la ville (rythmes et horaires des services, contraintes modales sur les réseaux), à partir
de la spécification de comportements individuels et de leur mise en interaction localisée.

Dans un premier scénario, l'aménageur utilise le modèle en proposant des politiques différentes à l'usager.L'aménageur essaye de trouver la meilleure solution de déplacement : quelle est la mode de transport le plus optimal pour la ville pour l'usager ?

Dans un second scénario, les thématiciens principaux sont des aménageurs. Mais, lors de cette situation, ils sont spécifiés en correspondant avec les services. Chaque rôle s'occupe la politique des services correspondantes. En changeant ces politiques, ils combinent différentes conditions pour chercher la meilleure solution pour la ville et les usagers qui sont les mobiles.

d) Collaboration

Dans les sections précédentes, nous avons présenté la collaboration autour du modèle et du
simulateur MIRO. Par conséquent, dans cette section, nous présentons seulement la partie
scénarios caractérisant les permissions et l'interface graphique d'utilisation pour chaque rôle.
Premièrement, nous abordons le premier scénario présenté dans la section 6.2.4 page 118.
## Collaboration

...

### 1. Le scénario 1 : Un jeu collaboratif entre deux acteurs

Messieurs X, Y représentent respectivement deux communautés : les aménageurs et les usagers à Paris et à Besançon. Ils cherchent à trouver des politiques appropriées pour le déplacement urbain. Dans ce scénario, il s'agit de trouver la politique qui peut satisfaire le plus grand nombre possible d'usagers tout en déployant une zone ZAPA (Zone d'Action Prioritaire pour l'Air). Cette dernière est une zone protégée de la ville, réservée aux véhicules écologiques, comme les véhicules collectifs (bus) ou les véhicules électriques. Elle interdit tout véhicule polluant.

<table><caption>Tableau 1 : Les paramètres accessible et les permissions des l'utilisateurs</caption><thead><tr><td>No</td><td>Paramètre</td><td>Permission de X</td><td>Permission de Y</td></tr></thead><tbody><tr><td>1</td><td>Network-Structure</td><td>Modifier</td><td>Voir</td></tr><tr><td>2</td><td>number-nodes</td><td>Modifier</td><td>None</td></tr><tr><td>3</td><td>Speed-Value</td><td>Modifier</td><td>Voir</td></tr><tr><td>4</td><td>ZAPA-size</td><td>Modifier</td><td>Voir</td></tr><tr><td>5</td><td>NB-Public-Services</td><td>Modifier</td><td>Voir</td></tr><tr><td>6</td><td>NB-shops</td><td>Modifier</td><td>Voir</td></tr><tr><td>7</td><td>NB-Workplaces</td><td>Modifier</td><td>Voir</td></tr><tr><td>8</td><td>NB-Houses</td><td>Modifier</td><td>Voir</td></tr><tr><td>9</td><td>nb-ecological-mobile</td><td>Modifier</td><td>Voir</td></tr><tr><td>10</td><td>nb-mobile-Agents</td><td>Modifier</td><td>None</td></tr><tr><td>11</td><td>Mode-de-transparent</td><td>Voir</td><td>Modifier</td></tr><tr><td>12</td><td>Vitesse-de-bus</td><td>Modifier</td><td>Voir</td></tr><tr><td>13</td><td>Vitesse-de-voiture</td><td>Modifier</td><td>Voir</td></tr></tbody></table>

<table><caption>Tableau 2 : Les actions et les permissions de l'utilisateur</caption><thead><tr><td>No</td><td>Action</td><td>Permission de X</td><td>Permission de Y</td></tr></thead><tbody><tr><td>1</td><td>Setup Regular Network</td><td>Effectuer</td><td>None</td></tr><tr><td>2</td><td>Setup simple network</td><td>Effectuer</td><td>None</td></tr><tr><td>3</td><td>Modifier la vitesse</td><td>Effectuer</td><td>Voir</td></tr><tr><td>4</td><td>Calculer la plus court chemin</td><td>Effectuer</td><td>Voir</td></tr><tr><td>5</td><td>Setup les service</td><td>Effectuer</td><td>Voir</td></tr><tr><td>6</td><td>Créer des mobiles</td><td>Effectuer</td><td>Voir</td></tr><tr><td>7</td><td>Exécuter les mobile</td><td>Effectuer</td><td>Effectuer</td></tr></tbody></table>

Y a une satisfaction personnelle à attendre, et le but de X est de satisfaire cette satisfaction. X ordonne différentes politiques en changeant les services de la ville. Ensuite, Y utilise les ces services pour trouver la politique qui est la plus satisfaisant. Le scénario va se réaliser en essayant avec des contraintes suivant :

1. Tester avec différent structure de network : X va essayer avec des topologies différentes de routes tandis que les autres paramètres sont constants, sauf le mode de transport utilisé qui est manipulé par Y.

2. Tester le cas où il n'y a que des voitures : X peut alors changer la vitesse des voitures.

3. Tester le cas où il n'y a que le bus : X va essayer avec le cas où il y a seulement les
bus qui roule. Il peut changer la vitesse des bus. Y peut modifier seulement le mode de transparent utilisé.

4. Tester avec les différentes quantités de services : X change le nombre de services, Y peut changer seulement le mode de transport.

5. Tester avec les différentes quantités de mobiles (écologique et normale). Y peut modifier seulement le mode de transport utilisé. Tandis que X modifie les autres, comme la vitesse, la route.

6. Tester avec les différents conditions de zone ZAPA : interdire les voitures, limiter la vitesse de bus, limiter le nombre de bus

7. Tester avec les cas où on combine les contraintes ci-dessus.

Dans ce scénario, X s'intéresse aux paramètres et aux activités dans le tableau 1, 2. Il a tout les droits (modification ou exécution). Tandis que, Y modifie seulement le mode de transport utilisé. Ce scénario est simple dans le sens où la collaboration entre le rôle **Aménageur** et **Usager** n'est pas formalisée.

Puisque l'**usager** n'a pas beaucoup de permission, ainsi, il n'y a pas des conflits dans leur action. Par conséquent, ce scénario ne demande pas des outils collaboratif spécifique, sauf les outils de communication.

## 2. Le scénario 2 : Un jeu collaboratif entre 4 acteurs

Messieurs A, B, C, D sont respectivement représenté pour l'acteur économique, l'acteur citoyen, l'acteur public et le maître du jeu dans le projet MIRO. Ils sont distribué géographiquement. Ils tendent à trouvé des politiques appropriées pour le déplacement urbain. Ce scénario est présenté dans la figure 5.

<figure><img src="image_62.png" /><figcaption>Figure 5 : Le scénario avec quatre joueurs</figcaption></figure>
<figure><img src="image_63.png" /><figcaption>Figure 6 : GUI prédéfinies pour l'acteur économique</figcaption></figure>

Dans ce scénario, l'objectif de A est :

- d'augmenter l'accessibilité structurelle de ses services, ainsi que l'accessibilité fonctionnelle des agents mobiles.

Les objectifs de B sont :

- d'augmenter l'accessibilité structurelle des domiciles et l'accessibilité fonctionnelle des agents mobiles.

- de diminuer l'exposition aux polluants des agents mobile.

Les objectifs de C sont de :

- Réduire le mécontentement des agents mobiles (fluidifier le trafic).

- Réduire les expositions aux polluants des agents mobiles.

- Réduire les émissions de polluants.

Les objectifs de D sont :

- de contrôler le jeu

- de calculer les plus courts chemins

- d'exécuter la simulation

Dans ce scénario, D s'occupe de l'installation du réseau des vitesses. A est responsable pour les services économiques, B installe les domiciles, D gère le déroulement du jeu, par exemple le lancement du simulateur. Comme présenté dans la figure 5, chaque étape est coloriée selon le couleur de l'acteur. Pour avoir un jeu équitable, chaque utilisateur a une interface graphique d'utilisateur (GUI) adapté à ses objectifs et leur permission. Pour un paramètre ou une activité, il y a seulement l'acteur qui travaille dans le domaine qui peut les manipuler.
Les GUIs de chaque acteur sont prédéfinies par les thématiciens comme le montre la figure 6 pour l'acteur économique.

En se basant sur les GUIs prédéfinies, nous pouvons identifier les permission de chacun, par exemple le tableau 3 définit les permission de A - l'acteur économique.

<table><thead><tr><th>L'entrée</th><th>Permission</th></tr></thead><tbody><tr><td>nb-services-publics</td><td>Tous</td></tr><tr><td>nb-commerces</td><td>Tous</td></tr><tr><td>nb-lieux-travail</td><td>Tous</td></tr><tr><td>type-service</td><td>Tous</td></tr><tr><td>type-accessibilite-structurelle</td><td>Tous</td></tr><tr><td>type-accessibilite-fonctionnelle</td><td>Tous</td></tr><tr><td>Localisation aléatoire</td><td>Tous</td></tr><tr><td>Localisation interactive</td><td>Tous</td></tr><tr><td>Activer les services</td><td>Tous</td></tr><tr><td>Les actions Cartographier<br>suivi les sorties<br>dans le tableau de sortie</td><td>Tous</td></tr></tbody></table>

<table><caption>Tableau 3 : Les permissions de A - l'acteur économique</caption><thead><tr><th>La sortie</th><th></th></tr></thead><tbody><tr><td>L'information de Service Public</td><td>Tous</td></tr><tr><td>Accessibilité structurelles aux Services Publics</td><td>Tous</td></tr><tr><td>L'information de Service Commercial</td><td></td></tr><tr><td>Accessibilité structurelles aux Services Commerciaux</td><td>Tous</td></tr><tr><td>L'information de Lieux de Travail</td><td></td></tr><tr><td>Accessibilité fonctionnelle des agents mobiles</td><td>Tous</td></tr><tr><td>La carte</td><td>Tous</td></tr></tbody></table>

A noter ici, tout est proposé dans un ordre prédécesseur-successeur, mais toutes des étapes ne sont pas nécessaires. Par exemple, après une simulation, il est possible de juste modifier la ZAPA, de re-calculer les plus court chemin PCC, et de relancer la simulation, sans modifier les services et vitesses.

Ce scénario peut aussi être exécuté sans maître du jeu, en prédéfinissant donc les réglages des agents-mobiles (leur nombre doit être automatiquement ajusté à la capacité des domiciles), et en attribuant une suite d'action à chaque bouton des acteurs.

L'acteur Public déclencherait donc le calcul des PCC en cliquant sur « Activer les vitesses », et l'acteur économique ou Citoyen (selon l'ordre que l'on fixera) lancera la création des agents mobiles et la simulation ensuite.

Pour ce scénario, nous pouvons imaginer que le clic sur les boutons ici représentés gèle l'écran du joueur, et active celui du suivant. Concernant la dernière étape d'une phase de jeu (après l'exécution d'une simulation, c'est Graphiques et cartographies dans la figure 5), c'est peut-être plus difficile à gérer (nécessité d'avoir des affichages de la carte indépendants pour chaque joueur), et peut-être faut-il alors y remettre un ordre d'affichage. Par exemple, l'acteur économique modifie la carte selon les variables qu'il souhaite, puis clique sur un bouton « Terminer », et c'est au tour du suivant.

La collaboration dans ce scénario est plus complexe que celui précédent. Bien qu'il n'y ait pas la compétition entre des rôles, mais les objectifs sont à la fois collectifs et individuels. La tâche qui demande plus le traitement du conflit collaboratif est la localisation manuellement des services. Ce processus demande un traitement du synchronisme des thématiciens pour qu'un thématicien ne puisse pas modifier l'objet de l'autre. Par conséquent, à côté des outils collaboratif de communication, ce scénario demande une fonctionnalité collaborative spécifique permettant la manipulation collaborative de la carte.

En général, pour les interactions avec le modèle dans les deux scénarios, les rôles utilisent la
souris pour interagir. Ils peuvent cliquer sur la carte pour ajouter, enlever un service ou modifier la vitesse de chaque tronçon. De plus, ils peuvent également déplacer un service en utilisant la fonctionnalité drag/drop. A noter que les utilisateurs peuvent manipuler seulement les objets de la ville dont ils ont la charge. Par exemple les lieux de travail sont seulement manipulés par l'acteur économique - Travail, les commercial est manipulé par l'acteur économique - service commercial ...

### 6.3.3 Établissement du modèle conceptuel

Lors de cette section, nous allons présenter la solution que nous avons appliqué pour la création d'un modèle conceptuel représentatif le simulateur collaboratif MIRO. Ce modèle conceptuel suit le méta-modèle du simulateur collaboratif présenté dans la section 4.2.1 page 76.

#### a) Les entrées

Comme la spécification dans la partie 5.3.2 page 96, les entrées sont des paramètres et des actions possibles. A partir l'information de la partie **Simulator** du modèle CoODD de MIRO, les paramètres d'entrées sont les variables que l'on peut changer dans **Input Parameters**, par exemple **type-reseau**, **structure-reseau-regulier**. Les actions sont toutes des boutons et des événements permettant d'interagir avec la carte 2D, par exemple **Créer le réseau**, **Activer la ZAPA**. La figure 6.7 est un extrait du modèle des entrées avec le paramètre **Type-service**.

<figure><img src="image_64.png" /><figcaption>FIGURE 6.7 – Extrait des entrées du simulateur collaboratif MIRO</figcaption></figure>

Les paramètres contiennent l'information comme un identifiant, un nom, et un valeur. Chaque paramètre a trois opérations importante : (i) *inform* pour informer le changement le valeur de paramètre à l'autre collaborateur, (ii) *buildDisplay* pour créer une interface graphique utilisateur pour la paramètre, et (iii) *updateDisplay* pour mette à jour l'interface de la paramètre quand il y a un changement effectué par les collaborateurs, comme présenté par le classe **Type-reseau**.
<figure><img src="image_65.png" /><figcaption>FIGURE 6.8 – Extrait des actions du simulateur collaboratif MIRO</figcaption></figure>

La figure 6.8 est un extrait du modèle des entrées avec l'action **Créer le réseau**. Une action contient trois informations essentielles : un identifiant, un nom, et une commande. Cette dernière contient la code de cette action dans le modèle original. Par exemple pour l'action **Créer le réseau**, son code est *setup*.

A noté ici que toutes ces entrées (les paramètres et les actions) et ses composants seront créés automatiquement. Car nous tirons l'information à partir du modèle CoODD pour générer le modèle conceptuel et remplir la base de données. Quand une expérimentation est effectuée, notre plateforme va tout prendre en charge et générer les classes correspondantes.

b) Les sorties

Les sorties sont des moniteurs qui permettent des observations sous la forme d'une valeur numérique ou un graphique. Ces informations sont présentées dans la partie **Output - Simulator** du modèle CoODD. Par conséquent, en analysant, le modèle CoODD du MIRO, nous avons identifié tous les sorties du modèle. La figure 6.9 est un extrait du modèle avec deux variables : *Accessibilite* - un moniteur graphique et *Voitures* - un moniteur numérique.

Chaque **Variables** est définie par un identifiant, un nom, et un objet graphique pour afficher le contenu de la variable. Ce dernier est un plot(*PlotAccessibilite*) qui contient un composant graphique (*ChartComponent*) pour la variable *Accessibilite* et un moniteur numérique (*MonitorVoitures*) qui contient un composant textuel (*Label*) pour la variable *Voitures*.

c) Les rôles

Dans le modèle COODD - la partie **User's Profile** 6.3.2 page 127, nous avons identifié 12 profiles d'utilisateur différents. Tandis que, pour notre méta-modèle, chaque profile d'utilisateur identifié correspond avec un rôle concret. Par conséquent, nous avons des rôles suivants qui est une instance de la classe **Role** dans le méta-modèle :

- **Aménageur** et **Usager** pour le scénario 1.

- **Role économique**, **Role citoyen**, **Role Public** et **Maître de jeu**.

Ces rôles sont spécifiés par un id unique, un nom et une collection des permissions concer-
<figure><img src="image_66.png" /><figcaption>FIGURE 6.9 – Extrait des sorties du simulateur collaboratif MIRO</figcaption></figure>

nant les **AccessTool**. Par exemple, pour le rôle **Public** comme illustré par la figure 6.10, il peut manipuler la variable **Type-reseau** et l'action **CreerReseau**. Ainsi, il a la permission **Manipulate** pour leurs outils d'accès (**CreerButton** et **TypeReseauUI**). Pour les variables **Accessibilite** et **Voitures**, il peut visualiser seulement. Par conséquent, il possède la permission **Visualise** pour leurs outils d'accès (**VoitureNumericalMonitor** et **PlotAccessibilite**).

<figure><img src="image_67.png" /><figcaption>FIGURE 6.10 – Un exemple du rôle Public</figcaption></figure>

d) Les outils
En parallèle des outils collaboratifs spécifiques pour supporter le simulateur MIRO, nous avons implémenté les outils collaboratifs conventionnels comme la visio conférence, la messagerie instantanée, les pointeurs. Ce sont des composants de type **AccessTool**.

À noté qu'ici ces objets sont créés automatiquement au début de l'exécution du simulateur en tenant compte des informations de paramétrage stockées dans la base de données. Par conséquent, les outils collaboratifs conventionnels sont génériques et peuvent s'appliquer à d'autres modèles. Ainsi, l'important effort de développement mené prend tout son sens car maintenant, pour un modèle Netlogo, seul une configuration de la base de données est nécessaire pour le rendre collaboratif le simulateur.

### 6.3.4 Transformation

Lors de cette étape, je travaille comme un développeur qui transforme le simulateur MIRO *stand-alone* en celui collaboratif en le déployant dans la plateforme PAMS. Comme présenté dans la section précédente, à côté des fonctionnalités collaboratives, j'ai intégré également dans cette plate-forme l'étape de **Transformation**. Une base de données est pré-définie et contient toutes les configurations nécessaires pour la simulation. Ces dernières sont supportées avec un mécanisme de chargement dynamiquement qui permet de configurer les scénarios collaboratifs.

Par conséquent, le travail pour cette étape se décompose en deux tâches principales. Premièrement, il s'agira d'上传er le modèle et les bibliothèques nécessaires à son exécution sur le serveur PAMS. Dans le cas de MIRO, nous avons uploadé le modèle Netlogo et l'extension *nw* (Network Extension) pour le fonctionnement du simulateur. La deuxième étape vise à ajouter les caractéristiques du modèle dans la base de données. Pour le modèle MIRO nous avons ajouté des éléments dans les tables :

- **Model** : le nom, la description, la chemin, l'identifiant de la plateforme.

- **Parameter** : le nom, la type, la valeur défaut et le domaine, pour chaque paramètre du simulateur présenté dans la partie 6.3.2 page 122, comme présenté dans la figure 6.11 page 138.

- **Output** : le nom, la description, le type de valeur, le type de sortie (Moniteur numérique ou graphique ou l'interface 2D).

- **simulation_step** : les 7 étapes du simulateur MIRO sont stockée dans cette table. Une huitième a été ajoutée pour la visualisation des sorties entre chaque tour.

- **simulation_step_detail** : Les différentes actions qui sont représentées par des boutons présentés dans la partie 6.3.2 page 122 sont ajoutés.

- **Scenario** : Les deux scénarios présentés dans la section 6.3.2 page 129 sont stockés ici.

- **scenario_role** : La suite logique du scénario est la configuration des rôles pour les scénarios, cette information est stockée dans ce tableau.

- les tableaux **permissionDIGITALDIGITALDIGITALDIGITAL** : Enfin, la dernière configuration nécessaire pour le lancement du simulateur collaboratif MIRO se traduit par la définition des permissions par rapport aux objets **Action** (stockés dans **simulation.step detail**), les sorties dans la table **Output**, et les paramètres d'entrée dans la table "parameter".

Après ces travaux le simulateur MIRO devient un simulateur collaboratif accessible sur internet via the plate-forme PAMS.
<figure><img src="image_68.png" /><figcaption>FIGURE 6.11 – Tableau **Parameter** avec l'information de MIRO</figcaption></figure>

Par exemple avec le moniteur **MoniteurVoitures**, simplement nous devons déclarer son nom (**Voitures**), son type de la valeur (**Integer**) et son type de sortie (**2** pour moniteur numérique).

### 6.3.5 Validation

Après avoir transformé le simulateur MIRO, nous l'avons mis sur le serveur d'IRD à l'adresse http://vmpams.mpl.ird.fr:5080/pams/. Un géographe, un géo-informaticien et l'ingénieur (voir la partie 6.3.1 page 121) m'ont aidé à tester et valider ce nouveau simulateur. Plusieurs sessions de tests ont été organisées. Grâce de cela, quelques erreurs sont identifiées.

Par exemple dans le test au 1/8/2012, les thématiciens du MIRO ont rencontré un problème avec les plots **Accessibilités** des services. Tous ces plots affichent un même graphique, bien que la simulation fonctionne bien. Après quelques discussions, nous avons trouvé que le concepteur a fait une erreur dans la configuration du nom des plots : tous les plots ont utilisé un même nom. Cette erreur est résolue ensuite par le concepteur. Depuis peu, après quelques tests le nouveau simulateur est validé et prêt à utilisé notamment dans le cadre d'expérimentation avec des experts..

## 6.4 Expérimentation par les experts

Au cours de la dernière section, nous avons cherché à évaluer la démarche proposée et ses outils de modélisation, en la confrontant à un problème concret dans le domaine de la mobilité géographique. Maintenant, il nous faut évaluer la réalisation des simulations collaboratives au moyen de tests.
À partir du protocole d'évaluation définit dans 6.1.3 page 112, nous cherchons à évaluer l'efficacité, l'efficience et la satisfaction du simulateur collaboratif et les mécanismes proposés. Trois expérimentations ont été organisées en appliquant deux méthodes d'évaluation quantitatives : l'expérimentation et le sondage. Dans la suite de cette section, nous allons détailler consécutivement ces trois expérimentations.

### 6.4.1 Évaluation des fonctionnalités collaboratives

#### a) Protocole d'expérimentation

Nous avons réalisé des expérimentations avec 5 participants (4 en France - 3 à Paris, 1 à Dijon et 1 au Hanoi - Vietnam)

Il s'agit d'une première expérimentation, le protocole que nous avons réalisé est donc simple : fixer le nombre de participants, expérimenter en changeant les paramètres. Nous effectuons quelques sessions d'expérimentations entre des acteurs différents, en utilisant le scénario présenté dans la section précédente (voir le scénario 2 dans la section 6.3.2 page 129) et le simulateur collaboratif MIRO.

Les sessions de simulation sont effectuées en une demi journée. Entre deux sessions consécutives, les participants organisent une discussion d'environ 5 minutes concernant le résultat de l'expérimentation. Après chaque discussion, ils changent les paramètres du modèle et relancent une nouvelle simulation pour tester les nouvelles hypothèses.

Les résultats sont obtenus de deux façons : (i) après chaque expérimentation les participants répondent à un questionnaire comme présenté dans la section 6.1 page 110 ; (ii) Des observations du déroulement sont faites par le maître du jeu qui a la possibilité de voir l'ensemble de la simulation. Cela me permet d'apprécier le déroulement de la simulation collaborative.

L'expérimentation est distribuée sur le réseau Internet. Tous les participants accèdent à un même serveur. Le serveur se situe à Montreplier, France. Sa capacité est Intel(R) Xeon(R) CPU E5345 dual core 2.33GHz, 3 G RAM, et le systèmes d'exploitation CentOS.

#### b) L'expérience du participant

Les participants se situent dans deux pays différents (France et Vietnam). Dans cette expérimentation, les participants ont pris les rôles suivants :

- M.J qui se situe à Hanoi, Vietnam a occupé la place du **Maître du jeu**. Pour cette simulation, j'ai assuré ce rôle.

- M. C, un modélisateur qui se situe à Dijon, France. Dans la première session, il a pris le rôle **Public**.

- M. D qui est un géographe et aussi un modélisateur, il travaille à Paris Ile-de-France. Il a pris le rôle **Public** dans la deuxième session.

- M. A, un géographe qui travaille à Dijon, France. Il a pris le rôle **Economique**. Il n'est pas membre du projet MIRO.

- Mlle B, une géographe qui est à Dijon, France. Il a pris le rôle **Citoyen**. Elle n'est pas membre du projet MIRO.
<table><caption>TABLE 6.4 – L'expérience personnelle des participants</caption><thead><tr><th></th><th>Mlle B</th><th>M. D</th><th>M. C</th><th>M. A</th></tr></thead><tbody><tr><th>Expérience</th><td>3 ans</td><td>10 ans</td><td>10 ans</td><td>1 an</td></tr><tr><th>Compétence</th><td>Modélisateur, Géographie, Aménagement</td><td>Modélisateur, Géographie, Développeur</td><td>Modélisateur, Développeur</td><td>Géographie-Environnement</td></tr><tr><th>Nombre de projet</th><td>2</td><td>plus de 10</td><td>10</td><td>1</td></tr><tr><th>Distribution des partenaires</th><td>Différents instituts d'un pays</td><td>Différents instituts d'un pays, différents pays</td><td>Dans différents pays</td><td>Non distribué</td></tr><tr><th>Taille moyenne des projets</th><td>2 à 5 personnes</td><td>15 personnes</td><td>4 personnes</td><td>4 personnes</td></tr></tbody></table>

– M. E, un géographe qui travaille à Dijon, France. Il a observe les jeux seulement.

Dans l'ensemble les participants, D et E connaissent bien le modèle MIRO. C et moi-même ont une connaissance partielle du modèle. A et B ne connaissent pas le modèle.

L'expérience personnelle de chacun dans la modélisation simulation est résumé dans le tableau 6.4. Par ce tableau, nous constatons que D et C sont les experts dans la modélisation et simulation. Tandis que le reste sont des thématiciens géographes. La simulation collaborative est un travail familier avec ces participants (sauf pour A). Dans les projets de simulation auxquels ils participent, ils travaillent souvent avec plusieurs personnes. Ces dernières sont distribués souvent dans des pays différents ou dans différents instituts d'un même pays. La simulation à plusieurs est indispensable. Le tableau 6.5 résume les techniques que les participants ont utilisées pour effectuer la simulation à plusieurs. Trois catégories sont identifiées : (1) Se déplacer et se regrouper en un lieu pour travailler ensemble ; (2) Utiliser des outils supports sans se déplacer et (3) Réaliser les simulations tout seul.

<table><caption>TABLE 6.5 – Les techniques utilisées pour simulation à plusieurs</caption><thead><tr><th></th><th>Mlle B</th><th>M. D</th><th>M. C</th><th>M. A</th></tr></thead><tbody><tr><th>(1)</th><td>X</td><td>X</td><td>X</td><td>X</td></tr><tr><th>(2)</th><td>X</td><td></td><td>X</td><td></td></tr><tr><th>(3)</th><td></td><td>X</td><td>X</td><td></td></tr></tbody></table>

La façon de collaborer dans le domaine de la simulation se traduit par un déplacement en un même lieu. D et C effectue également la simulation tout seule et discutent ensuite. Dans l'ensemble des participants, il y a C et B qui ont utilisé les outils supports pour effectuer la simulation collaborative. Néanmoins, B utilise seulement les outils collaboratives conventionnelles, comme la messagerie instantanée comme Skype ou Google Talk. Seulement C utilise des outils collaboratifs spécifique pour la simulation. Il a utilisé des outils collaboratifs convention-
nels comme la messagerie instantané Skype, EVO, la vidéoconférence Polycom, l'outil VNC. Pour la collaboration spécifique à la simulation, il a utilisé VNC et Skype pour effectuer les simulations interactives.

En résumé, la simulation collaborative est habituelle avec les participants. Néanmoins, les méthodes utilisées ne sont pas efficaces. Les outils (conventionnels et spécifiques) ne sont pas correctement appliquées (seulement C les utilise tout en étant conscient des limites techniques).

### c) Analyse des résultats

Par observation au cours de l'expérimentation, nous constatons que :

- Il y a un petit problème dès la première session, deux joueurs B et A ont essayé d'analyser le résultat tandis que la simulation n'est pas terminée, et quelques erreurs sont alors affichées.

- Le système de visio-conférence de la plate-forme n'est pas stable. Sa qualité est très réduite quand le nombre des participants augmente. Ce problème est expliqué une partie par la capacité du serveur IRD, mais aussi par le problème du développement. Il faut revoir cette fonctionnalité.

- Les participants ne peuvent pas changer leur rôle lorsque la simulation est créé.

- Mais, en général, notre plate-forme répond bien aux actions concernant des fonctionnalités collaboratives et de simulation des participants.

Cette observation nous permet d'évaluer une partie de l'**efficience** du simulateur collaboratif. Par observation des taux des erreurs et de la nature des erreurs, nous trouvons que les utilisateurs rencontrent souvent des erreurs au début de l'expérimentation. Ceci tient du fait de l'inexpérience des utilisateurs vis à vis de la plate-forme et du simulateur. Néanmoins, à partir des sessions suivantes, après quelques explications, ils ont réalisé la simulation sans erreur. Un mécanisme comme le *story-board* est envisagé pour résoudre ce problème, il permettrait à l'utilisateur de bien suivre le scénario et la simulation.

Concernant les questions de **satisfaction**, le résultat est présenté par le tableau 6.6 et le graphique 6.12. Ces derniers résument la **satisfaction** des participants sur les fonctionnalités collaboratives spécifiques. Il s'agit d'un pourcentage de réponse OUI sur le nombre de participants.

Comme présenté dans la partie 6.1.3 page 113, nous considérons le pourcentage de 0 à 20% est *insatisfait*, 20% - 40% est *peu satisfait*, 40% - 60% est *acceptable*, 60% - 80% *satisfait*, et 80% - 100% est *très satisfait*. Ainsi, en analysant le graphique 6.12, nous avons :

- Une fonctionnalité est *insatisfait*

- Trois fonctionnalités sont *acceptable*

- Quatre fonctionnalités sont *satisfaites*

- Neuf fonctionnalités sont *très satisfaites*

Ainsi, la plupart des fonctionnalités proposées satisfont les besoins des participants. Il y a seulement une fonctionnalité (*Lister des expérimentations en cours et terminées*) qui n'est pas bon. Mais, cette fonctionnalité n'est pas importante, et elle peut-être réalisée d'autre façons. Particulièrement, les fonctionnalités critiques (ce sont des colonnes violettes dans le graphique 6.12) obtiennent une évaluation positive.

Le tableau 6.7 et le graphique 6.13 résument la satisfaction des utilisateurs sur les fonc-
<table><caption>TABLE 6.6 – Résultat d'enquête sur les fonctionnalités collaboratives spécifiques</caption><thead><tr><th>No</th><th>Fonctionnalité</th><th>Nombre d'utilisateurs</th><th>B</th><th>D</th><th>C</th><th>A</th><th>%</th></tr></thead><tbody><tr><td>1</td><td>Lister les modèles disponibles et les descriptions</td><td>4</td><td>O</td><td>N</td><td>O</td><td>O</td><td>75%</td></tr><tr><td>2</td><td>Inviter de nouveaux participants à distance</td><td>1</td><td>-</td><td>-</td><td>O</td><td>-</td><td>100%</td></tr><tr><td>3</td><td>Créer une expérimentation avec le modèle choisi</td><td>1</td><td>-</td><td>-</td><td>O</td><td>-</td><td>100%</td></tr><tr><td>4</td><td>Configurer l'expérimentation et ses fonctionnalités collaboratives</td><td>1</td><td>-</td><td>-</td><td>O</td><td>-</td><td>100%</td></tr><tr><td>5</td><td>Voir et bien connaître les scénarios disponibles pour chaque modèle</td><td>4</td><td>N</td><td>N</td><td>O</td><td>O</td><td>50%</td></tr><tr><td>6</td><td>Connaître les rôles décrits dans un scénario (sa mission, ses droits)</td><td>4</td><td>O</td><td>O</td><td>O</td><td>O</td><td>100%</td></tr><tr><td>7</td><td>Choisir les rôles pour chaque participant</td><td>4</td><td>O</td><td>O</td><td>O</td><td>O</td><td>100%</td></tr><tr><td>8</td><td>Lister des expérimentations encours et terminées</td><td>4</td><td>N</td><td>N</td><td>N</td><td>N</td><td>0%</td></tr><tr><td>9</td><td>Rejoindre une expérimentation</td><td>4</td><td>O</td><td>O</td><td>O</td><td>N</td><td>75%</td></tr><tr><td>10</td><td>Bien connaître les participants (leur rôle, leur expérience)</td><td>4</td><td>O</td><td>N</td><td>O</td><td>O</td><td>75%</td></tr><tr><td>11</td><td>Modifier des paramètres selon vos droits</td><td>4</td><td>N</td><td>N</td><td>O</td><td>O</td><td>50%</td></tr><tr><td>12</td><td>Voir et analyser les résultats selon vos droits</td><td>4</td><td>O</td><td>O</td><td>O</td><td>O</td><td>100%</td></tr><tr><td>13</td><td>Percevoir la modification des paramètres par les autres participants</td><td>4</td><td>O</td><td>O</td><td>O</td><td>O</td><td>100%</td></tr><tr><td>14</td><td>Percevoir le changement d'état de simulation par les autres participants</td><td>4</td><td>N</td><td>O</td><td>O</td><td>N</td><td>50%</td></tr><tr><td>15</td><td>Avoir des sorties privées que les autres ne peuvent pas voir</td><td>4</td><td>O</td><td>O</td><td>O</td><td>O</td><td>100%</td></tr><tr><td>16</td><td>Partager des paramètres et observations privées avec d'autres</td><td>4</td><td>O</td><td>O</td><td>O</td><td>O</td><td>100%</td></tr><tr><td>17</td><td>Percevoir l'état des participants (en ligne ou non)</td><td>4</td><td>O</td><td>O</td><td>O</td><td>N</td><td>75%</td></tr></tbody></table>
<figure><img src="image_69.png" /><figcaption>FIGURE 6.12 – Étude détaillée de satisfaction des fonctionnalités collaboratives spécifiques</figcaption></figure>

<table><caption>TABLE 6.7 – Étude détaillée de satisfaction des fonctionnalités collaboratives conventionnelles</caption><thead><tr><th>Fonctionnalité</th><th>Nombre d'utilisateur</th><th>B</th><th>D</th><th>C</th><th>A</th><th>%</th></tr></thead><tbody><tr><td>Messagerie instantanée</td><td>4</td><td>O</td><td>O</td><td>O</td><td>O</td><td>100%</td></tr><tr><td>Visio conférence</td><td>4</td><td>O</td><td>O</td><td>O</td><td>O</td><td>100%</td></tr><tr><td>Tableau blanc</td><td>4</td><td>N</td><td>N</td><td>N</td><td>N</td><td>0%</td></tr></tbody></table>

tionnalités collaboratives conventionnelles. Il y a seulement la fonctionnalité *Whiteboard* qui n'obtient pas la satisfaction d'utilisateurs. Car, dans ce premier temps, nous ne nous sommes pas concentré sur cette fonctionnalité. Les restes sont satisfait le besoin d'utilisateur, elles sont évalué *très satisfait*.

L'efficacité est évaluée par l'évaluation de chaque participant sur la qualité/utilité ou la réussite des fonctionnalités/tâches avec la range de 1 à 5. Concernant les fonctionnalités collaboratives conventionnelles, le tableau 6.8 et le graphique 6.14 résument le résultat d'évaluation des utilisateurs. En analysant ces résultats, la visio-conférence est très bien évaluée. Cet outil apparaît être très utile durant une simulation. La messagerie instantanée est aussi bien évaluée tandis que le tableau blanc n'obtient pas le succès escompté.

Pour les fonctionnalités collaboratives spécifiques, le tableau 6.9 et le graphique 6.15 résument l'évaluation des participants. Le premier est le détail de l'évaluation de chacun, tandis que le second synthétise l'évaluation moyenne de chaque fonctionnalité sur le nombre d'utilisa-
<figure><img src="image_70.png" /><figcaption>FIGURE 6.13 – Étude détaillée de satisfaction des fonctionnalités collaboratives conventionnelles</figcaption></figure>

<table><caption>TABLE 6.8 – Évaluation des fonctionnalités collaboratives conventionnelles</caption><thead><tr><th>Fonctionnalité</th><th>Nombre d'utilisateur</th><th>B</th><th>D</th><th>C</th><th>A</th><th>Moyen</th></tr></thead><tbody><tr><td>Messagerie instantané</td><td>4</td><td>3</td><td>2</td><td>4</td><td>5</td><td>3.5</td></tr><tr><td>Visio</td><td>4</td><td>5</td><td>5</td><td>5</td><td>5</td><td>5</td></tr><tr><td>Whiteboard</td><td>4</td><td>1</td><td>1</td><td>1</td><td>3</td><td>1.5</td></tr></tbody></table>

tions. Cela nous permet également d'avoir un point de vue sur l'efficacité des fonctionnalités collaboratives proposées par Pams qui sont spécifiques à la simulation.

Comme présenté dans la partie 6.1.3 page 113, nous considérons une moyenne entre [0;1] comme étant très faible, entre [1;2] est faible, entre [2;3] est moyen, entre [3;4] est élevé et entre [4;5] très élevé. Ainsi, en analysant le graphique 6.15, nous trouvons que la plupart des fonctionnalités/tâches sont appréciées (7/17 soit 41.2 %), voire adaptées pour 53 % (9/17) des cas, en terme de l'efficacité. Il y seulement une fonctionnalités/tâche qui est très faible (1/17 soit 5.9 %). Particulièrement, toutes les fonctionnalités critiques (les colonnes violet dans le graphique 6.15) sont bien évaluées (4/7 fonctionnalités sont élevé et 3/7 fonctionnalités sont très élevé).

En résumé, malgré quelques difficultés de manipulation pour des novices, la plate-forme s'avère bénéfique en terme de collaboration dans la simulation. A titre indicatif certains participants ont dit après utilisation :

* "La première expérience nous a donné envie d'en faire une seconde plus longue! Excellent travail."

* "La dimension collaborative était vraiment très intéressante par rapport au simple Netlogo que j'ai utilisé auparavant..."

## 6.4.2 Évaluation des performances de la plate-forme PAMS

### a) Protocole d'expérimentation
<table><caption>TABLE 6.9 – Évaluation détaillée des fonctionnalités collaboratives spécifiques</caption><thead><tr><th></th><th>Fonctionnalité</th><th>Nombre d'utilisateurs</th><th>B</th><th>D</th><th>C</th><th>A</th><th>Moyen</th></tr></thead><tbody><tr><td>1</td><td>Lister les modèles disponibles et les descriptions</td><td>4</td><td>3</td><td>2</td><td>2</td><td>5</td><td>3</td></tr><tr><td>2</td><td>Inviter de nouveaux participants à distance</td><td>1</td><td></td><td></td><td>5</td><td></td><td>5</td></tr><tr><td>3</td><td>Créer une expérimentation avec le modèle choisi</td><td>1</td><td></td><td></td><td>5</td><td></td><td>5</td></tr><tr><td>4</td><td>Configurer l'expérimentation et ses fonctionnalités collaboratives</td><td>1</td><td></td><td></td><td>5</td><td></td><td>5</td></tr><tr><td>5</td><td>Voir et bien connaître les scénarios disponibles pour chaque modèle</td><td>4</td><td>2</td><td>2</td><td>4</td><td>5</td><td>3.25</td></tr><tr><td>6</td><td>Connaître les rôles décrits dans un scénario (sa mission, ses droits)</td><td>4</td><td>5</td><td>3</td><td>5</td><td>5</td><td>4.5</td></tr><tr><td>7</td><td>Choisir les rôles pour chaque participant</td><td>4</td><td>5</td><td>3</td><td>5</td><td>5</td><td>4.5</td></tr><tr><td>8</td><td>Lister des expérimentations encours et terminées</td><td>4</td><td>1</td><td>1</td><td>3</td><td>1</td><td>1.5</td></tr><tr><td>9</td><td>Rejoindre une expérimentation</td><td>4</td><td>5</td><td>4</td><td>5</td><td>2</td><td>4</td></tr><tr><td>10</td><td>Bien connaître les participants (leur rôle, expérience ...)</td><td>4</td><td>4</td><td>2</td><td>2</td><td>5</td><td>3.25</td></tr><tr><td>11</td><td>Modifier des paramètres selon vos droits</td><td>4</td><td>2</td><td>2</td><td>5</td><td>5</td><td>3.5</td></tr><tr><td>12</td><td>Voir et analyser les résultats selon vos droits</td><td>4</td><td>5</td><td>4</td><td>5</td><td>5</td><td>4.75</td></tr><tr><td>13</td><td>Percevoir la modification des paramètres par les autres participants</td><td>4</td><td>5</td><td>4</td><td>3</td><td>5</td><td>4.25</td></tr><tr><td>14</td><td>Percevoir le changement d'état de simulation par les autres participants</td><td>4</td><td>1</td><td>4</td><td>4</td><td>3</td><td>3</td></tr><tr><td>15</td><td>Avoir des sorties privées que les autres ne peuvent pas voir</td><td>4</td><td>2</td><td>4</td><td>5</td><td>3</td><td>3.5</td></tr><tr><td>16</td><td>Partager des paramètres et observations privées avec d'autres</td><td>4</td><td>3</td><td>4</td><td>4</td><td>5</td><td>4</td></tr><tr><td>17</td><td>Percevoir l'état des participants (en ligne ou non)</td><td>4</td><td>3</td><td>4</td><td>3</td><td>2</td><td>3</td></tr></tbody></table>
<figure><img src="image_71.png" /><figcaption>FIGURE 6.14 – Évaluation des outils collaboratifs conventionnels</figcaption></figure>

L'objectif de cet expérimentation est d'évaluer les performances de la plateforme. Le temps d'exécution du modèle MIRO *stand-alone* sur Netlogo est considéré comme la valeur optimale. Nous le comparons avec celui effectué par notre travail.

Dans cette expérimentation, nous fixons les paramètres et augmentons le nombre de participants après chaque simulation. Cela nous permet d'avoir une comparaison juste. Nous effectuons sept expérimentations avec le modèle MIRO. Premièrement, nous réalisons une expérimentation témoin avec le modèle d'origine NetLogo. Les expérimentations suivantes sont réalisées avec le simulateur collaboratif en augmentant le nombre de participants de 2 à 7.

L'expérimentation réalisée sur un réseau local sans fils de 54Mb/s. La simulation est exécutée sur un même serveur qui possède un Intel Core 2 Due 3.06Ghz, 8Go Ram, et Mac OSX 10.6.8. Ce serveur dispose des caractéristiques matérielles identiques à l'ordinateur utilisé pour réaliser l'expérimentation témoin.

## b) Analyse des résultats

A partir des résultats obtenus (le graphique 6.16), nous pouvons dire qu'avec les mêmes paramètres d'entrée, le temps d'exécution du simulateur collaboratif est quasi identique à celui du simulateur témoin. Par conséquent, en se basant sur le temps d'exécution de simulations collaboratives, notre solution fournit des performances acceptables.

## 6.4.3 Évaluation de l'efficacité par la synchronisation

### a) Protocole d'expérimentation

L'objectif de cette expérimentation est d'évaluer l'apport d'une telle plateforme sur les échanges entre les participants. Dans ce contexte, la synchronisation des échanges est importante : la collaboration est plus efficace si les participants ont un même point de vue en même temps [Hara 2003]. Ainsi, dans cette expérimentation, nous allons examiner la synchronisation entre des participants. Nous avons exécuté 4 simulations avec le simulateur collaboratif MIRO en augmentant le nombre de participants et avons noté le temps (en miliseconde) pour finir une exécution chez chaque participant.

L'expérimentation s'est déroulé sur un réseau local sans fils de 54Mb/s. La simulation exécutée sur un unique serveur (identique à celui utiliser pour les simulations stand-alone).
<figure><img src="image_72.png" /><figcaption>FIGURE 6.15 – Évaluation des outils collaboratifs spécifiques</figcaption></figure>

Ce serveur est doté d'un Intel Core 2 duo, 8Go de Ram et fonctionne avec Mac OSX 10.6.8 comme système d'exploitation. Les quatre machines "clientes" possèdent les caractéristiques techniques suivantes :

- Un MacBook Pro, Lion 10.7.4, Intel Core 2 Duo 2.66 Ghz, 4 GB Ram

- Un Window XP, Intel Core 2 Duo 2.66 Ghz, 2GB RAM

- Un Window 7, Intel Core i7, 4GB Ram

- Un Linux Ubuntu Intel Core Duo 2Ghz, 1 GB RAM

b) Analyse des résultats

Le résultat de cette expérimentation est résumé par le graphique 6.17. Facilement, nous pouvons voir que la différence du temps obtenu chez chaque participant est minime malgré la distribution géographique. Par conséquent, notre solution répond bien à la synchronisation entre des participants. En combinaison avec le résultat de la première expérimentation, nous pouvons dire que notre travail a une **efficacité** élevée.

6.4.4 Synthèse

Au cours de cette section, nous avons effectué notre dernière évaluation sur le nouveau simulateur collaboratif MIRO. Cette évaluation donne une estimation sur le bon fonctionnement
<figure><img src="image_73.png" /><figcaption>FIGURE 6.16 – Le temps d’exécution</figcaption></figure>

<figure><img src="image_74.png" /><figcaption>FIGURE 6.17 – La synchronisation entre des participants</figcaption></figure>

de la plateforme, mais aussi sur la capacité de notre démarche DeCoSim dans la création des simulateurs collaboratifs.

Trois expérimentations ont été réalisées avec 5 participants (un géographe à Paris-France, 3 géographe et modélisateur à Dijon-France, et un modélisateur à Hanoi-Vietnam). Les résultats obtenus nous permettent de dire que notre travail répond au problème posé au départ de la thèse.

De plus, à côté de cette expérimentation, nous avons réalisé une autre expérimentation avec 35 participants. Trois simulations se sont déroulés en parallèle sur un même serveur. Elles se sont organisées en quatre groupes : un groupes de maître du jeu, un groupe d'aménageurs, un groupe de services commerciaux, un groupe d'habitants.

L'expérimentation s'est bien déroulée, les participants ont obtenue une initiation aux jeux sérieux autour du modèle MIRO. Mais, nous avons plusieurs choses dont l'interface utilisateur afin de faciliter le suivi des sessions de jeux sérieux.
## 6.5 Conclusion

Lors de ce chapitre nous avons appliqué notre approche et nos outils pour introduire dans un simulateur existant (MIRO) la collaboration. En appliquant la démarche DeCoSim, nous avons transformé le simulateur *stand-alone* MIRO en une version collaborative. Ensuite, le nouveau simulateur collaboratif est utilisé pour évaluer les possibilités de Pams à supporter la simulation collaborative. L'objectif de ce chapitre réside dans la validation et l'évaluation de ce que nous proposons par rapport au besoin des thématiciens dans la simulation collaborative des systèmes complexes.

Grâce à l'étude de cas de MIRO, nous pouvons dire que la démarche DeCoSim est suffisamment générique pour être utilisée pour introduire la collaboration dans des simulateurs de systèmes complexes. DeCoSim prend en charge une partie du processus de conception d'un simulateur, en se reposant notamment sur les techniques du génie logiciel et en se reposant sur des outils dédiés de modélisation. Après la conception, nous avons effectué la phrase *Transformation* qui est plus simple et ne prend pas beaucoup de temps par rapport à l'implémentation d'un modèle. Nous avons pu constater une progression entre les différentes étapes de modélisation et de transformation. Ceci conforte nos choix quant à l'organisation des outils conceptuels et logiciels utilisés dans DeCoSim.

L'expérimentation que nous avons pu réaliser nous a montré que notre infrastructure logicielle satisfait bien le besoin des utilisateurs en termes de collaboration. Nous avons effectué des simulations à distance, entre la France et le Vietnam avec des résultats encourageant. Tous les participants ont suivi bien l'évolution de la simulation, personne est hors du contexte. Le temps d'exécution de la simulation par notre solution est similaire avec ce qui est effectué par le simulateur *stand-alone*. De plus, bien que la simulation soit distribuée géographiquement, la synchronisation entre les participants est correctement assurée. Le décalage de rafraîchissement entre les interfaces s'avère réduit.

Par le travail de ce chapitre, notre travail répond bien à trois aspects d'évaluation :

- **Efficience** : L'introduction de la collaboration dans un simulateur nécessite un effort minime comparé au développement d'un nouveau simulateur collaboratif. Les taux d'erreur est bas, et leur raison est simple que les participants peuvent facilement résoudre. Le temps nécessaire pour exécuter est acceptable.

- **Efficacité** : Les appréciations des thématiciens sont positives. Toutes les fonctionnalités importantes suscitent l'intérêt en terme de qualité et d'utilité bien en termes de la qualité/utilité. Nous avons produit succès avec un simulateur collaboratif a partir d'un ce lui *stand-alone* sans le développement.

- **Satisfaction** : Par les réponses des thématiciens, nous pouvons dire que le simulateur collaboratif reste agréable à utiliser malgré quelques difficultés d'utilisation à la première utilisation.
<figure><img src="image_75.png" /></figure>
# Conclusion & perspective

## 7.1 Conclusion

Cette thèse se situe à l'intersection des domaines des systèmes complexes et de la collaboration. En effet, forcé de constater que la collaboration entre chercheurs et experts du domaine est inévitable pour modéliser, simuler et comprendre un phénomène complexe, j'ai mené une étude approfondie pour identifier les approches, les techniques et les outils de collaboration adaptés au domaine.

Malgré la pléthore d'outils collaboratifs proposés dans un cadre industriel à l'origine et réutilisés dans le monde de la recherche ensuite, nous constatons que peu d'entre eux sont adaptés au domaine qui nous intéresse. Ceci tient du fait de la spécificité du processus de modélisation simulation où la collaboration intervient à tout moment autour d'objets complexes qui sont les modèles et les simulateurs.

Compte tenue de la diversité des simulateurs proposés dans la littérature, la collaboration autour de la simulation constitue en soit une problématique de recherche suffisante. En effet, il n'existe pas une unique manière de collaborer autour d'un simulateur. La collaboration s'effectue au cas par cas selon les objectifs scientifiques des intervenants. C'est pourquoi, les moyens informatiques pour permettre ces échanges doivent être aussi flexibles que dédiés, mais surtout, ils doivent être choisis et configurés intelligemment.

Pour rendre un simulateur collaboratif, il est donc important de tenir compte à la fois des objectifs scientifiques, des objectifs de simulation et de l'expérience des utilisateurs, de leurs rôles et de leurs compétences. En fonction de ces paramètres, les outils de collaboration peuvent être déterminés. Dans ce contexte thématiquement très vaste, il est judicieux de s'interroger sur : (i) les contours d'une plate-forme générique assurant la collaboration autour d'un simulateur ; (ii) la procédure à suivre pour rendre un simulateur existant collaboratif. Ce sont les deux principales questions auxquelles je donne une réponse dans cette thèse.

**Première question : Quels seraient les contours d'une plate-forme générique assurant la collaboration autour d'un simulateur ?**

La simulation est l'espace de tous les échanges entre modélisateurs, thématiciens, opérationnels. Dans ce contexte, le simulateur devient le moteur de l'échange, c'est à dire l'objet manipulé par un groupe de personnes afin de produire de nouvelles connaissances sujettes à discussion. Le simulateur peut alors être vu, pour la plupart des utilisateurs, comme une boîte noire sur laquelle on peut influer au travers de paramètres d'entrées, pour obtenir des résultats en sortie : de nouvelles connaissances échangées et discutées à travers la collaboration.

La distribution géographique des participants contraint fortement l'interaction. Sans moyens adaptés, la collaboration à distance se limite à des échanges textuels, vocaux et de données sur les entrées et les sorties produites lors d'une simulation. Il s'agit d'une approche fréquemment