# ÉLABORATION D'UN PROCESSUS ET CONCEPTION DES OUTILS POUR INTRODUIRE LA COLLABORATION DANS SIMULATION

Khanh Nguyen Trong

► To cite this version:

Khanh Nguyen Trong. ÉLABORATION D'UN PROCESSUS ET CONCEPTION DES OUTILS POUR INTRODUIRE LA COLLABORATION DANS SIMULATION. Informatique [cs]. LIP6 - Laboratoire d'Informatique de Paris 6, 2013. Français. NNT: . tel-04429842

HAL Id: tel-04429842

https://theses.hal.science/tel-04429842

Submitted on 31 Jan 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

Public Domain
# THÈSE DE DOCTORAT
DE L'UNIVERSITÉ PIERRE ET MARIE CURIE

Spécialité : INFORMATIQUE

École doctorale : « L'ÉDITE de Paris »

présentée par

NGUYEN Trong Khanh

pour obtenir le grade de :

DOCTEUR DE L'UNIVERSITÉ PIERRE ET MARIE CURIE

Sujet de la thèse :

Élaboration d'un processus et conception des outils
pour introduire la collaboration dans simulation

soutenue le 30 septembre 2013

devant le jury composé de :

<table><tr><td>M<sup>me</sup></td><td>Amal El Fallah Seghrouchni</td><td>Directeur de thèse</td></tr><tr><td>M.</td><td>Nicolas Marilleau</td><td>Encadrant de thèse</td></tr><tr><td>M.</td><td>HO Tuong Vinh</td><td>Encadrant de thèse</td></tr><tr><td>M.</td><td>NGUYEN Thanh Thuy</td><td>Rapporteur</td></tr><tr><td>M.</td><td>Jean-Pierre Muller</td><td>Rapporteur</td></tr><tr><td>M.</td><td>Christophe Cambier</td><td>Examinateur</td></tr><tr><td>M.</td><td>Jean-Christophe Lapayre</td><td>Examinateur</td></tr></table>
<figure><img src="image_1.png" /></figure>
# Élaboration d'un processus et conception des outils pour introduire la collaboration dans simulation

**Résumé** : Cette thèse propose une démarche et d'outils conceptuels visant à définir les stratégies de collaboration dans un projet de simulation des systèmes complexes. Nous montrons en premier lieu l'indispensable de la collaboration pour l'étude des systèmes complexes, surtout pour la simulation de ce système. Cette collaboration passe principalement entre des thématiciens et autour d'un simulateur. Cependant, elle demeure complexe compte tenu de l'éloignement grandissant des thématiciens d'un même problème de recherche et ainsi leur éloignement de la géographie. De plus, les démarches de la modélisation et simulation actuelles nous permet produire seulement les simulateurs "stand-alones". Ces derniers sont pauvres en terme de la collaboration. Il supporte seulement des interactions locales, dans une même interface. Ceci tient du fait que la collaboration est inhérente au système complexe modélisé. Par conséquent, les thématiciens doivent utiliser plusieurs outils collaboratifs différents pour supporter leur travail. Néanmoins la plupart des outils actuels ne peuvent pas répondre complètement à leur besoin de simulation collaborative.

Nous proposons donc, dans un deuxième temps, une nouvelle vision qui facilite la collaboration dans la simulation des systèmes complexes et une démarche pour concevoir un outil collaboratif spécifique. Notre vision se base principalement sur le simulateur qui est considéré comme une boîte noire dans laquelle les thématiciens s'intéressent seulement à ses entrées et ses sorties. La collaboration limite maintenant à deux cas : (i) soit les échanges, les discussions pour bien comprendre des entrées et sorties ou (ii) soit la manipulation simultané des entrées et sorties. De plus, en équipant les fonctionnalités collaboratives au simulateur "stand-alone", nous pouvons obtenir un outil collaboratif spécifique, le simulateur collaboratif, qui est à la fois un simulateur qui permet d'effectuer des fonctionnalités de simulation, et un outil collaboratif qui permet de réaliser des fonctionnalités collaboratives. La nouvelle démarche, DeCoSim, permet la conception, à partir des simulateurs "stand-alone" existants, du simulateur collaboratif qui facilite la simulation collaborative des systèmes complexes.

Les solutions proposées a été appliquées et évaluées dans le contexte de la mobilité géographique avec le modèle MIRO. En appliquant notre démarche DeCoSim, nous avons transformé le simulateur "stand-alone" MIRO en celui collaboratif. Puis, nous l'avons combiné avec les mécanismes proposés pour faciliter des thématiciens à la simulation collaborative. Cette étude de cas a été conduite avec l'aide des utilisateurs réels de MIRO. Cela nous permet avoir une évaluation sur l'utilisabilité de notre travail.

**Mots clés** : Simulation collaborative, simulation participative, simulation des systèmes complexe, simulateur collaboratif, étude interdisciplinaire, pluridisciplinaire, jeux de rôle.
Elaboration of a process and design of tools
to introduce the collaboration in simulation

**Abstract** : This thesis proposes an approach and conceptual tools to identify strategies for collaboration in the simulation of complex systems. Firstly, we show the indispensable of collaboration for the study of complex systems, especially for the simulation of this system. This collaboration takes place primarily among thematicians and around a simulator. However, it remains complex due to the remoteness of thematicians in a same research problem and also their seperation geograpic . In addition, the actual approaches modeling and simulation allows us to produce only simulators “*stand-alones*” . They are poor in terms of collaboration. It supports only local interactions, in a single interface. This is due to the fact that collaboration is inherent to complex systems modeled. Therefore, thematicians must use several different tools to support their collaborative work. However most of these tools can not completely respond to their need for collaborative simulation.

We then propose a new vision that facilitates collaboration in simulation of complex
systems and an approach to design a specific collaborative tool. Our vision is mainly
based on the simulator that is considered as a black box in which the thematicians focus
only in its inputs and outputs. The collaboration limites to two cases : (i) exchanges,
discussions to understand the inputs and outputs or (ii) the simultaneous manipulation
of inputs and outputs. Moreover, by equipping collaborative functionalities for simulator
"stand-alone", we can obtain a specific collaborative tool, collaborative simulator, which
is at once a simulator that allows the simulation and a collaborative tool that supports
collaborative functionalities. The new approach, DeCoSim, allows to design, from an exis-
ting simulators "stand-alones", a collaborative simulator which facilitates collaborative
simulation of complex systems.

The proposed solutions have been implemented and evaluated in the context of geogra-
phical mobility with MIRO model. By applying our approach DeCoSim,, we transformed
the simulator "standalone" MIRO in the one collaborative. Then, we combined with pro-
posed mechanisms to facilitate the collaborative simulation among thematicians of MIRO
. This case study was conducted with the help of real users of MIRO. This allows us to
have an evaluation about the usability of our work.

**Keywords** : Collaborative simulation, participative simulation, simulation of com-
plexe systems, collaborative simulator, interdisciplinaire research, pluridisciplinaire re-
search, role playing game.
À ma femme Phan Thi Thuy Hanh et
à nos filles Nguyen Khanh Ha, Nguyen Khanh Linh
Remerciements

Ce manuscrit est l'aboutissement de travaux qui n'auraient pas vu le jour et n'auraient pas abouti sans la participation, l'aide et le soutien d'un grand nombre de personnes.

En premier lieu, je remercie Mme. Amal El Fallah Seghrouchni, M. Nicolas Marilleau et M. HO Tuong Vinh de m'avoir encadré pendant ces quatre dernières années. Leur implication et leur passion pour la recherche ont rendu ces années particulièrement stimulantes. Leur confiance, leurs conseils, leur soutien et les nombreuses discussions que nous avons pu avoir m'ont été d'une grande aide tout au long de ma thèse.

Je teins à remercier les membres de mon jury d'avoir accepté de juger mon travail et les « quelques » pages de mon manuscrit. Merci à M. Jean-Pierre Muller et M. NGUYEN Thanh Thuy de m'avoir fait l'honneur de rapporter ma thèse. Merci à M. Christophe Cambier et M. Jean-Christophe Lapayre d'avoir accepté d'assister à ma soutenance et d'examiner mes travaux.

Je remercie également les anciens ou actuels membres de l'équipe MSI d'IFI que j'ai pu côtoyer. L'ambiance et la bonne humeur, les repas d'équipe et autres « évènements mondains » ont rendu mes années de thèse particulièrement plaisantes. Merci donc à Alexis Drogoul, Serge Stinckwich, Jean Daniel Zucker, Vo Duc An, Nguyen Vu Quang Anh, Chu Thanh Quang, Nguyen Ngoc Doanh, Nguyen Thi Ngoc Anh, Doan Trung Tung, Nguyen Van Nam, Tran Nguyen Minh Thu, Edouard Amouroux, Benoit Gaudou, Bui Thi Mai Anh, Tran Thi Cam Giang, Bui The Quang, Nguyen Manh Hung.

Je teins à remercier en particulier à Tran Nguyen Minh Thu, Doan Thu Thuy, Nguyen Thi Minh Tuyen, Ngo Van Luyen, Huynh Thu Dung, Dang Hai Ha et les docteurs, les infirmières de l'hôpital Tenon de la France et de l'hôpital Viet Duc du Vietnam pour les supports au moment où ma santé était très mauvais.

Je remercie du fond du cœur ma femme, Hanh, pour son soutien et son amour dont elle fait preuve chaque jour. Une thèse est avant tout une aventure psychologique qu'elle a su comprendre et partager. Merci à mes deux filles, Khanh Ha et Khanh Linh, pour leur énergie et leur amour qui m'ont fait oublier les petits tracas quotidiens d'une thèse.

Je remercie enfin chaleureusement ma famille, en particulier mes parents et ma sœur, pour le soutien et la compréhension dont ils ont fait preuve lors de ces années marquant la fin de mes longues études.
# Table des matières

<table><tr><td>Table des figures</td><td>x</td></tr><tr><td>Liste des tableaux</td><td>xi</td></tr><tr><td>Introduction générale</td><td>xii</td></tr><tr><td>Une nouvelle méthode de conception du simulateur collaboratif</td><td>xii</td></tr><tr><td>Plan de la thèse</td><td>xiii</td></tr></table>

## Partie I Autour de la collaboration pour la simulation dans la littérature 1

<table><tr><td>Chapitre 1 Simulation, collaboration et systèmes complexes</td><td>3</td></tr><tr><td>1.1 Système complexe et leur étude</td><td>3</td></tr><tr><td>1.1.1 Concepts et définitions</td><td>4</td></tr><tr><td>1.1.2 Les enjeux</td><td>6</td></tr><tr><td>1.1.3 Démarche scientifique pour l'étude des systèmes complexes</td><td>7</td></tr><tr><td>1.1.4 Synthèse</td><td>11</td></tr><tr><td>1.2 La collaboration dans la recherche, une nécessité</td><td>11</td></tr><tr><td>1.2.1 Concepts et définitions</td><td>11</td></tr><tr><td>1.2.2 Les enjeux</td><td>13</td></tr><tr><td>1.2.3 Étude collaborative des systèmes complexes</td><td>15</td></tr><tr><td>1.3 Simulation des systèmes complexes</td><td>17</td></tr><tr><td>1.3.1 Concepts et définitions</td><td>17</td></tr><tr><td>1.3.2 Catégorie des simulateurs</td><td>19</td></tr><tr><td>1.3.3 Collaborer dans un projet de simulation</td><td>21</td></tr><tr><td>1.4 Conclusion</td><td>27</td></tr></table>

<table><tr><td>Chapitre 2 Collaboration autour d'un simulateur</td><td>29</td></tr><tr><td>2.1 Exemple du projet d'épidémiologie GAMAVI</td><td>29</td></tr><tr><td>2.1.1 Le simulateur GAMAVI</td><td>30</td></tr><tr><td>2.1.2 Intervenants et collaboration autour du simulateur GAMAVI</td><td>32</td></tr><tr><td>2.1.3 Synthèse</td><td>33</td></tr><tr><td>2.2 Usage de la simulation dans un contexte de groupe</td><td>33</td></tr><tr><td>2.2.1 Asynchronisme des échanges entre intervenants</td><td>34</td></tr><tr><td>2.2.2 Le manque d'outils appropriés</td><td>36</td></tr><tr><td>2.2.3 Synthèse</td><td>38</td></tr><tr><td>2.3 Méthodes et outils pour collaborer lors d'une simulation</td><td>39</td></tr><tr><td>2.3.1 Modèles de collaboration</td><td>39</td></tr></table>
<table><tbody><tr><td>2.3.2</td><td>Moyens informatiques de collaboration</td><td>41</td></tr><tr><td>2.3.3</td><td>Synthèse</td><td>46</td></tr><tr><td>2.4</td><td>Conclusion</td><td>47</td></tr><tr><td><b>Chapitre 3</b></td><td><b>Méthode pour la conception d'un outil de simulation et de la collaboration</b></td><td><b>49</b></td></tr><tr><td>3.1</td><td>Méthode d'ingénierie logicielle</td><td>50</td></tr><tr><td>3.1.1</td><td>Modèle en cascade [Foster 2009]</td><td>50</td></tr><tr><td>3.1.2</td><td>Approche itérative et incrémentale</td><td>50</td></tr><tr><td>3.1.3</td><td>Modèle Spiral</td><td>51</td></tr><tr><td>3.1.4</td><td>Approche Agile</td><td>52</td></tr><tr><td>3.1.5</td><td>Synthèse</td><td>53</td></tr><tr><td>3.2</td><td>Méthode de modélisation-simulation des systèmes complexes</td><td>53</td></tr><tr><td>3.2.1</td><td>Fishwick et Gilbert & Troitzsch</td><td>53</td></tr><tr><td>3.2.2</td><td>Drogoul et al [Drogoul 2003, Drogoul 2004]</td><td>54</td></tr><tr><td>3.2.3</td><td>ComMod - Modélisation d'accompagnement</td><td>56</td></tr><tr><td>3.2.4</td><td>ARDI</td><td>57</td></tr><tr><td>3.2.5</td><td>KIMONO</td><td>59</td></tr><tr><td>3.2.6</td><td>Synthèse</td><td>61</td></tr><tr><td>3.3</td><td>Méthodes pour la conception des collecticiels</td><td>62</td></tr><tr><td>3.3.1</td><td>Modèle en trèfle</td><td>62</td></tr><tr><td>3.3.2</td><td>RCOM</td><td>63</td></tr><tr><td>3.3.3</td><td>Méthode CoCSys</td><td>65</td></tr><tr><td>3.4</td><td>Synthèse</td><td>66</td></tr><tr><td><b>Partie II</b></td><td><b>Approche pour introduire la collaboration dans la simulation des systèmes complexes</b></td><td><b>69</b></td></tr><tr><td><b>Chapitre 4</b></td><td><b>Vers une nouvelle vision de la collaboration dans la simulation</b></td><td><b>71</b></td></tr><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></tbody></table>

<table><tbody><tr><td><b>Chapitre 5</b></td><td><b>DeCoSim : Méthode pour concevoir un simulateur collaboratif</b></td><td><b>87</b></td></tr></tbody></table>
<table>
  <tbody>
    <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>
    <tr>
      <td><b>Chapitre 6</b></td>
      <td><b>Expérimentation &amp; Évaluation</b></td>
      <td><b>109</b></td>
    </tr>
    <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>
    <tr>
      <td><b>Chapitre 7</b></td>
      <td><b>Conclusion &amp; perspective</b></td>
      <td><b>151</b></td>
    </tr>
    <tr>
      <td>7.1</td>
      <td>Conclusion</td>
      <td>151</td>
    </tr>
    <tr>
      <td>7.2</td>
      <td>Perspective</td>
      <td>153</td>
    </tr>
    <tr>
      <td><b>Bibliographie</b></td>
      <td></td>
      <td><b>155</b></td>
    </tr>
    <tr>
      <td><b>Annexe A : CoODD du modèle MIRO</b></td>
      <td></td>
      <td><b>169</b></td>
    </tr>
  </tbody>
</table>
Table des figures

<table><tr><td>1</td><td>L'organisation du manuscrit de thèse</td><td>xiv</td></tr><tr><td>1.1</td><td>Projection de l'étude des systèmes complexes à la démarche scientifique [Cornu 1998]</td><td>8</td></tr><tr><td>1.2</td><td>Augmentation des articles publiés en collaboration avec plus d'un auteur international, entre 1996 et 2008 [Brito 2011]</td><td>13</td></tr><tr><td>1.3</td><td>Citation par article versus le nombre de pays collaboré [Brito 2011]</td><td>15</td></tr><tr><td>1.4</td><td>Processus de simulation [Fishwick 1997]</td><td>18</td></tr><tr><td>1.5</td><td>Processus simple de modélisation et simulation [Drogoul 2003, Marilleau 2006]</td><td>22</td></tr><tr><td>1.6</td><td>Simulation et analyse les résultats</td><td>26</td></tr><tr><td>1.7</td><td>Fréquence d'échange dans un projet de simulation [Taylor 2003]</td><td>27</td></tr><tr><td>2.1</td><td>Simulateur Gamavi [Amouroux 2011]</td><td>31</td></tr><tr><td>2.2</td><td>Collaw [Hanisch 2001]</td><td>45</td></tr><tr><td>2.3</td><td>NetMeeting et SIMUL8 [Taylor 2001]</td><td>46</td></tr><tr><td>2.4</td><td>Entrée directe des paramètres [Nguyen 2008a]</td><td>47</td></tr><tr><td>2.5</td><td>Représentation du résultat par le converteur Proof2SVG [Henriksen 2002]</td><td>48</td></tr><tr><td>3.1</td><td>Modèle itératif</td><td>50</td></tr><tr><td>3.2</td><td>Modèle Spiral [Larman 2003]</td><td>51</td></tr><tr><td>3.3</td><td>Méthode Agile</td><td>52</td></tr><tr><td>3.4</td><td>Méthode de Gilbert et Troitzsch, conçu par [Drogoul 2003]</td><td>54</td></tr><tr><td>3.5</td><td>Méthode de Drogoul et al [Drogoul 2003]</td><td>55</td></tr><tr><td>3.6</td><td>Cycle de la modélisation d'accompagnement [Bousquet 2005]</td><td>56</td></tr><tr><td>3.7</td><td>Modèle généré par ARDI dans la gestion de l'eau à Rivière Corcodie [Etienne 2011]</td><td>58</td></tr><tr><td>3.8</td><td>KIMONO [Amouroux 2011]</td><td>60</td></tr><tr><td>3.9</td><td>Modèle en trèfle [Salber 1995]</td><td>63</td></tr><tr><td>3.10</td><td>RCOM [Park 2004]</td><td>64</td></tr><tr><td>3.11</td><td>CoCSys [DELOTTE 2006]</td><td>65</td></tr><tr><td>4.1</td><td>Le simulateur une boite noire</td><td>74</td></tr><tr><td>4.2</td><td>Les concepts de base</td><td>76</td></tr><tr><td>4.3</td><td>Méta-modèle du simulateur collaboratif</td><td>77</td></tr><tr><td>4.4</td><td>Architecture de Pams</td><td>81</td></tr><tr><td>4.5</td><td>Technologies d'utiliser dans PAMS</td><td>82</td></tr><tr><td>4.6</td><td>Espace de travail public</td><td>84</td></tr></table>
<table>
  <tbody>
    <tr>
      <td>4.7</td>
      <td>Espace travaillé privé</td>
      <td>85</td>
    </tr>
    <tr>
      <td>4.8</td>
      <td>Espace travaillé privé - Simulation avec le modèle MIRO</td>
      <td>86</td>
    </tr>
    <tr>
      <td>5.1</td>
      <td>L'objectif et l'utilisateur de DeCoSim</td>
      <td>88</td>
    </tr>
    <tr>
      <td>5.2</td>
      <td>DeCoSim</td>
      <td>90</td>
    </tr>
    <tr>
      <td>5.3</td>
      <td>Méta-modèle du simulateur collaboratif</td>
      <td>96</td>
    </tr>
    <tr>
      <td>5.4</td>
      <td>Les paramètres entrées du simulateur collaboratif</td>
      <td>97</td>
    </tr>
    <tr>
      <td>5.5</td>
      <td>Les actions du simulateur collaboratif</td>
      <td>97</td>
    </tr>
    <tr>
      <td>5.6</td>
      <td>Les sorties du simulateur collaboratif</td>
      <td>98</td>
    </tr>
    <tr>
      <td>5.7</td>
      <td>Rôle et le simulateur collaboratif</td>
      <td>99</td>
    </tr>
    <tr>
      <td>5.8</td>
      <td>Les AccessTools du simulateur collaboratif</td>
      <td>99</td>
    </tr>
    <tr>
      <td>5.9</td>
      <td>Les rôles Démographe et Psychologue</td>
      <td>100</td>
    </tr>
    <tr>
      <td>5.10</td>
      <td>Les paramètres du modèle Wedding-Ring</td>
      <td>100</td>
    </tr>
    <tr>
      <td>5.11</td>
      <td>Le moniteur du modèle Wedding-Ring</td>
      <td>101</td>
    </tr>
    <tr>
      <td>5.12</td>
      <td>Les actions du modèle Wedding-Ring</td>
      <td>101</td>
    </tr>
    <tr>
      <td>5.13</td>
      <td>DeCoSim et l'infrastructure logicielle supporte</td>
      <td>103</td>
    </tr>
    <tr>
      <td>5.14</td>
      <td>CoPad</td>
      <td>104</td>
    </tr>
    <tr>
      <td>5.15</td>
      <td>CoUML</td>
      <td>105</td>
    </tr>
    <tr>
      <td>6.1</td>
      <td>Le ceour du projet MIRO [LANG 2006]</td>
      <td>117</td>
    </tr>
    <tr>
      <td>6.2</td>
      <td>L'approche retenue dans MIRO [LANG 2006]</td>
      <td>118</td>
    </tr>
    <tr>
      <td>6.3</td>
      <td>Algorithme pour la génération des emplois du temps [LANG 2006]</td>
      <td>119</td>
    </tr>
    <tr>
      <td>6.4</td>
      <td>La simulation collaborative avec le simulateur MIRO stand-alone</td>
      <td>120</td>
    </tr>
    <tr>
      <td>6.5</td>
      <td>La simulation collaborative avec le simulateur MIRO collaboratif</td>
      <td>120</td>
    </tr>
    <tr>
      <td>6.6</td>
      <td>Processus de transformation du simulateur MIRO</td>
      <td>121</td>
    </tr>
    <tr>
      <td>6.7</td>
      <td>Extrait des entrées du simulateur collaboratif MIRO</td>
      <td>134</td>
    </tr>
    <tr>
      <td>6.8</td>
      <td>Extrait des actions du simulateur collaboratif MIRO</td>
      <td>135</td>
    </tr>
    <tr>
      <td>6.9</td>
      <td>Extrait des sorties du simulateur collaboratif MIRO</td>
      <td>136</td>
    </tr>
    <tr>
      <td>6.10</td>
      <td>Un exemple du rôle Public</td>
      <td>136</td>
    </tr>
    <tr>
      <td>6.11</td>
      <td>Tableau Parameter avec l'information de MIRO</td>
      <td>138</td>
    </tr>
    <tr>
      <td>6.12</td>
      <td>Étude détaillée de satisfaction des fonctionnalités collaboratives spécifiques</td>
      <td>143</td>
    </tr>
    <tr>
      <td>6.13</td>
      <td>Étude détaillée de satisfaction des fonctionnalités collaboratives conventionnelles</td>
      <td>144</td>
    </tr>
    <tr>
      <td>6.14</td>
      <td>Évaluation des outils collaboratifs conventionnels</td>
      <td>146</td>
    </tr>
    <tr>
      <td>6.15</td>
      <td>Évaluation des outils collaboratifs spécifiques</td>
      <td>147</td>
    </tr>
    <tr>
      <td>6.16</td>
      <td>Le temps d'exécution</td>
      <td>148</td>
    </tr>
    <tr>
      <td>6.17</td>
      <td>La synchronisation entre des participants</td>
      <td>148</td>
    </tr>
    <tr>
      <td>A.1</td>
      <td>Architecture générale de MIRO</td>
      <td>171</td>
    </tr>
    <tr>
      <td>A.2</td>
      <td>Le cœur du projet MIRO</td>
      <td>172</td>
    </tr>
    <tr>
      <td>A.3</td>
      <td>Approche retenue dans MIRO</td>
      <td>174</td>
    </tr>
    <tr>
      <td>A.4</td>
      <td>Profils d'activités simulés par classe (en % par classe)</td>
      <td>177</td>
    </tr>
    <tr>
      <td>A.5</td>
      <td>Profils socio-démographiques des six groupes définis</td>
      <td>178</td>
    </tr>
    <tr>
      <td>A.6</td>
      <td>L'algorithme pour la génération des emplois du temps</td>
      <td>180</td>
    </tr>
    <tr>
      <td>A.7</td>
      <td>Le simulateur MIRO - Les entrées et les sorties génériques</td>
      <td>181</td>
    </tr>
    <tr>
      <td>A.8</td>
      <td>Le simulateur MIRO - Les sorties réservées aux rôles</td>
      <td>182</td>
    </tr>
  </tbody>
</table>
<table><tr><td>A.9 Les paramètres entrées pour définir la ZAPA</td><td>183</td></tr><tr><td>A.10 L'action pour activer la ZAPA</td><td>183</td></tr><tr><td>A.11 Les paramètres entrées pour définir la vitesse</td><td>184</td></tr><tr><td>A.12 Les paramètres entrées définir la vitesse de transport public</td><td>184</td></tr><tr><td>A.13 L'action pour activer la vitesse</td><td>185</td></tr><tr><td>A.14 L'action pour calcule les plus cours chemins</td><td>185</td></tr><tr><td>A.15 Les paramètres entrées pour définir les services</td><td>186</td></tr><tr><td>A.16 L'action pour activer les services</td><td>186</td></tr><tr><td>A.17 Les paramètres entrées pour définir les agents</td><td>187</td></tr><tr><td>A.18 L'action pour créer les services et lancer la simulation</td><td>187</td></tr><tr><td>A.19 Les options pour visualiser les résultats</td><td>188</td></tr><tr><td>A.20 Le graphique accessibilité</td><td>189</td></tr><tr><td>A.21 L'absorption de polluants</td><td>189</td></tr><tr><td>A.22 Part Modale du réseau</td><td>192</td></tr><tr><td>A.23 La carte</td><td>193</td></tr></table>

## Liste des tableaux

<table><tr><td>1.1 Table des modes de travail en groupe</td><td>12</td></tr><tr><td>1.2 Taxonomie des participants en fonction des rôles identifiés dans [Ormerod 2001, Robinson 2003]</td><td>24</td></tr><tr><td>2.1 Typologie de la collaboration entre plusieurs disciplines [van Dusseldorp 1998]</td><td>37</td></tr><tr><td>2.2 Comparaison entre des moyens</td><td>44</td></tr><tr><td>3.1 Comparaison les méthodes de modélisation et simulation</td><td>62</td></tr><tr><td>5.1 Le protocoles CoODD complète</td><td>92</td></tr><tr><td>5.2 Modèle de l'adaptateur</td><td>106</td></tr><tr><td>6.1 Synthèse des méthodes utilisées</td><td>112</td></tr><tr><td>6.2 Les fonctionnalités/tâche pour les questions</td><td>115</td></tr><tr><td>6.3 Les parties concernant la collaboration de CoODD</td><td>122</td></tr><tr><td>6.4 L'expérience personnelle des participants</td><td>140</td></tr><tr><td>6.5 Les techniques utilisées pour simulation à plusieurs</td><td>140</td></tr><tr><td>6.6 Résultat d'enquête sur les fonctionnalités collaboratives spécifiques</td><td>142</td></tr><tr><td>6.7 Étude détaillée de satisfaction des fonctionnalités collaboratives conventionnelles</td><td>143</td></tr><tr><td>6.8 Évaluation des fonctionnalités collaboratives conventionnelles</td><td>144</td></tr><tr><td>6.9 Évaluation détaillée des fonctionnalités collaboratives spécifiques</td><td>145</td></tr><tr><td>A.1 Le rôle Aménageur et Usager</td><td>188</td></tr></table>
<table><tr><td>A.2 Le rôle économique et son sous-rôles</td><td>190</td></tr><tr><td>A.3 Le rôle citoyen, public et leur sous-rôles</td><td>191</td></tr><tr><td>A.4 Le rôle global</td><td>193</td></tr></table>
# Introduction générale

Le monde où nous vivons est un espace où la complexité est reine. L'étude de cette complexité est nécessaire pour comprendre notre passé, notre présent et prévenir l'avenir. Lors de l'étude d'un système complexe, même simple, de nombreuses compétences et connaissances sont requises pour sa modélisation et sa simulation. Ces connaissances du système proviennent de multiples champs disciplinaires. Il est alors difficile, pour une seule et unique personne, de les assimiler dans leur globalité et d'avoir le recul suffisant pour les utiliser intelligemment. Pourtant ces associations sont primordiales pour mener à bien un projet de modélisation-simulation.

La collaboration entre thématiciens et modélisateurs est donc une nécessité dans un projet de modélisation-simulation des systèmes complexes. Toutefois, elle demeure difficile compte tenu de l'éloignement grandissant des chercheurs. Ces derniers travaillent souvent dans des instituts, des villes voire des pays différents. Leurs communications, coordinations et collaborations deviennent de plus en plus difficiles sans l'usage de technologies nouvelles telle que les collecticiels. De plus, des experts sont habituellement membres de plusieurs projets si bien que les disponibilités de chacun d'eux sont limitées.

Le développement des nouvelles technologies de l'informatique depuis ces 20 dernières années permet d'envisager la création de démarches et de solutions informatiques qui facilitent l'échange. Bien que, ces solutions ne pourront jamais égaler les collaborations physiques, de visu, elles offrent, néanmoins, un moyen intéressant pour surmonter les difficultés géographiques, temporelles ainsi que de résoudre des problèmes liés à la pluridisciplinarité.

Dans le monde scientifique et plus particulièrement dans le domaine des sciences de la complexité, l'usage des technologies collaboratives devient une nécessité. A la fois moteur et fruit de la réflexion scientifique, le modèle et le simulateur sont des objets complexes échangés et manipulés à la fois par les modélisateurs et par les experts du domaine. Nombre de plates-formes permettent la manipulation des modèles et des simulateurs mais peu d'entre elles intègrent le caractère collaboratif du processus de modélisation-simulation. Ceci tient du fait que la collaboration est inhérente au système complexe modélisé. Elle doit donc être défini au cas par cas selon les objectifs scientifiques. Dans ce contexte, la proposition de démarches et d'outils conceptuels visant à définir les stratégies de collaboration dans un projet de modélisation-simulation semble primordiale. Là se situe l'enjeu de cette thèse.

Cependant, les simulateurs actuels sont souvent des solutions dites “stand-alone” qui supportent seulement des interactions locales, dans une même interface. La collaboration à distance est alors difficile. Récemment, quelques travaux s'intéressent à cette problématique en offrant des solutions participatives/collaboratives. Cependant, il n'y a, selon nous, aucune approche qui permet la transformation d'un simulateur “stand-alone” en une version collaborative. Notre travail tente justement de répondre à cette question.

## Une nouvelle méthode de conception du simulateur collaboratif

À partir de notre expérience dans le domaine de la simulation collaborative, et de ce que nous pouvons voir dans la littérature, nous notons un manque de moyens pour échanger dans le cadre d'une simulation. Les chercheurs doivent utiliser des outils externes pour permettre les échanges. Ces outils sont variés selon les projets, les règles de chaque laboratoire, de chaque pays et les habitudes du chercheur.
L'utilisation de simulateurs collaboratifs semble être un choix intéressant dans le domaine des systèmes complexes. D'un côté, il joue parfaitement son rôle de simulateur. De l'autre, il est un formidable outil d'échanges entre thématiciens, modélisateurs et acteurs de terrain.

Une méthode permettant la conception du simulateur collaboratif à partir d'un simulateur "stand-alone" va faciliter la collaboration des thématiciens dans la simulation des systèmes complexes. Ce travail s'inscrit dans une volonté de créer des outils conceptuels et logiciels qui aident à enrober des outils de la collaboration autour d'un simulateur.

## Plan de la thèse

Afin d'avoir une vue d'ensemble de nos travaux, nous avons découpé ce mémoire en six chapitres :

### Chapitre 1 :

Dans ce chapitre nous donnerons une vue générale sur la collaboration dans l'étude des systèmes complexes. Nous nous interrogeons d'abord les tenants et les aboutissants des sciences de la complexité et nous présenterons ensuite la collaboration et son importance pour l'étude des systèmes complexes notamment pour la simulation.

### Chapitre 2 :

Suite de la logique du dernier chapitre, dans ce chapitre, nous étudions la collaboration autour d'un simulateur qui est le dispositif principal pour la simulation. Ce travail préliminaire nous amène à étudier un cas concret, le projet GAMAVI. À partir de l'expérience acquise dans ce projet, nous étudions l'usage des simulateurs dans un contexte de groupe. À la fin de ce chapitre, nous allons clarifier notre objectif de la recherche en proposant deux questions scientifiques principales.

### Chapitre 3 :

Compte tenu de l'absence de la méthode pour concevoir un outil spécifique permettant à la fois la simulation et la collaboration, nous faisons une étude des grandes approches dans trois aspect de conceptions : (i) le génie logiciel, (ii) la modélisation et simulation des systèmes complexes et (iii) le travail collaboratif assiste par l'ordinateur (TCAO). Les inconvénients et les avantages de chaque méthode, par rapport avec notre objectif de conception d'un simulateur collaboratif, sont présentés et analysés. De cette analyse nous déduisons quelques caractéristiques importantes que doit intégrer notre démarche.

### Chapitre 4 :

Lors des trois chapitres ci-dessus, nous essayons de donner d'un point de vue générale dans la littérature concernant la simulation collaborative des systèmes complexes. Durant ce chapitre, nous donnerons la réponse pour la première question proposée dans le chapitre 2. Une nouvelle vision pour la simulation collaborative va être présentée. C'est le fondement qui nous permet de développer notre travail en profondeur. Premièrement, notre point de vue avec le simulateur sera présenté. La signification du simulateur collaboratif pour notre étude, ainsi que son méta-modèle serons détaillé. Nous présentons ensuite une infrastructure logicielle collaborative qui supporte complètement le méta-modèle du simulateur collaboratif proposé.
## Chapitre 5 :

Dans ce chapitre la deuxième question proposé dans le chapitre 2 va être répondu. Il vise à décrire en détails, l'approche DeCoSim, notre processus de transformation d'un simulateur *stand-alone* en simulateur collaboratif. Ce chapitre sera illustré au travers du projet wedding-ring.

## Chapitre 6 :

Pendant les deux derniers chapitres, nous avons abordé d'un point de vue théorique notre travail. Au cours de ce dernier chapitre, nous présentons une étude de cas de notre travail réalisé dans le cadre du projet MIRO. Mais, avant de présenté en détail et d'analyser les résultat de l'étude de cas, nous présentons la démarche d'évaluation que nous avons utilisé.

<figure><img src="image_2.png" /><figcaption>FIGURE 1 – L'organisation du manuscrit de thèse</figcaption></figure>
Première partie

Autour de la collaboration pour la
simulation dans la littérature
<figure><img src="image_3.png" /></figure>
# Simulation, collaboration et systèmes complexes

## Sommaire

<table><tr><td>1.1</td><td>Système complexe et leur étude</td><td>3</td></tr><tr><td>1.1.1</td><td>Concepts et définitions</td><td>4</td></tr><tr><td>1.1.2</td><td>Les enjeux</td><td>6</td></tr><tr><td>1.1.3</td><td>Démarche scientifique pour l'étude des systèmes complexes</td><td>7</td></tr><tr><td>1.1.4</td><td>Synthèse</td><td>11</td></tr><tr><td>1.2</td><td>La collaboration dans la recherche, une nécessité</td><td>11</td></tr><tr><td>1.2.1</td><td>Concepts et définitions</td><td>11</td></tr><tr><td>1.2.2</td><td>Les enjeux</td><td>13</td></tr><tr><td>1.2.3</td><td>Étude collaborative des systèmes complexes</td><td>15</td></tr><tr><td>1.3</td><td>Simulation des systèmes complexes</td><td>17</td></tr><tr><td>1.3.1</td><td>Concepts et définitions</td><td>17</td></tr><tr><td>1.3.2</td><td>Catégorie des simulateurs</td><td>19</td></tr><tr><td>1.3.3</td><td>Collaborer dans un projet de simulation</td><td>21</td></tr><tr><td>1.4</td><td>Conclusion</td><td>27</td></tr></table>

## 1.1 Système complexe et leur étude

Les sciences de la complexité se proposent d'étudier des dynamiques, souvent appartenant au monde réel, afin de comprendre les causes de leur émergence et/ou anticiper leur devenir. Bien que récent, ce domaine de recherche est déjà adopté par de nombreuses communautés, par exemple en géographie, en sciences du sol ou en halieutique. Tous ces champs scientifiques ont une vision propre de la complexité qui tient compte de leur objectif scientifique, et adoptent ainsi des approches spécifiques au thème.

Ces domaines différents sont souvent impliqués dans un même processus pour la compréhension de la complexité. Ces études sont généralement multidisciplinaires ou inter-disciplinaires où la collaboration est indispensable.

Pour mieux comprendre le concept du domaine de la complexité, au cours de cette section, nous allons donner une définition générale des systèmes complexes, leurs enjeux ainsi qu'un processus générique pour les étudier. Ensuite, nous allons analyser la collaboration dans la globalité de la recherche et dans l'étude des systèmes complexes. Dans la troisième partie, la simulation des systèmes complexes sera abordée. Enfin, la section se termine par une conclusion posant le problème de la validation.
1.1.1 Concepts et définitions

Les sciences de la complexité est un domaine transdisciplinaire où interviennent géographes, biologiques, écologistes, mathématiciens ou informaticiens. La composition des réseaux natio-
naux tel que le RNSC (Réseau National des Systèmes Complexe) pour la France, ou interna-
tionaux comme le SCS (Society of complex system) affichent cette pluridisciplinarité aussi bien
dans les événements qu’ils organisent, que dans les projets menés.

Les systèmes complexes apparaissent dans tous les domaines, comme les milieux granulaires
[Breton 2000], l'hydrologique des sol cultivés, la physique [Servat 2000], les systèmes microbiens
[Lardon 2002, Cambier 2007], les écosystèmes marins [Mullon 2004, Garavelli 2012], la biolo-
gie, l'économie [Said 2002, Kejriwal 1985] ou les sciences sociales [Sanders 1997, Banos 2012]
(domaine qui nous intéresse particulièrement dans le cadre de cette thèse).

La ville fait l'objet d'une attention particulière en géographie. Elle est considérée comme un système social et spatial complexe [Badariotti 2005]. C'est un espace où la complexité représentée : (i) par ceux qui la vivent – résidents, services (entreprise, administrations, etc) ; et (ii) par ceux qui la pensent (aménageurs, politiques ou chercheurs). Elle n'est donc pas seulement une concentration d'habitations, d'habitants et d'outils économiques. Elle se caractérise par un ensemble d'interactions entre ses différents composants qui sont rendues possibles notamment par une structuration de ses réseaux techniques [Lhomme 2010].

Ainsi, une multitude de définitions est proposée dans la littérature et précise le concept de “système complexe”. A titre d’exemple nous pouvons citer celle de Herber Simon, en anglais où un système complexe est :

**Définition 1.** “*A system that can be analyzed into many components having relatively many relations among them, so that the behavior of each component depends on the behavior of others*”. [Simon 1962]

C'est-à-dire *un système qui peut être analysé en plusieurs composantes en relation, si bien que le comportement de chaque composant est dépendant du comportement des autres.*

Selon Lhomme [Lhomme 2010], la ville est comme un carrefour où tous les composants se nouent, les réseaux permettant à la ville de remplir diverses fonctions comme bancaires, commerciales, administratives, hospitalières ou éducatives. Le comportement de ces composants sont dépendant les uns des autres.

D'autres définitions introduisent une orientation thématique de la complexité comme celle
de Volker Grimm qui définit un système complexe comme : "*a dynamic networks of many inter-
acting agents; examples include ecosystems, financial markets, and cities ...*, ce qui introduit
la relation entre les systèmes complexes et la modélisation et simulation à base d'agent.

Ainsi l'ensemble de la communauté s'accorde à définir un système complexe comme un
système constitué d'entités (microscopique) en interactions, ayant une dynamique individuelle,
engendrant un comportement collectif, macroscopique, global au système [Magee 2004].

Drogoul et al. dans [Drogoul 2004] met l'accent sur le caractère composite, hétérogène,
mobile, distribué et multi-échelle des systèmes complexes ce qui se traduit par un comportement :

- Émergent - La variabilité des constituants du système, la spontanéité des interactions conduisent à un comportement macroscopique (à l'échelle du système complexe étudié) imprédictible de la connaissance de l'ensemble des comportement locaux.
- Multi-échelle - les comportements de bas niveau peuvent influencer le comportement global du système par effet d'amplification

- Évolutif : la nature des composants, leur structure et l'organisation même du système modélisé évoluent au cours du temps

Selon [Boccara 2004], comme une multiplicité des champs disciplinaires, l'étude des systèmes complexes attire des chercheurs de plusieurs horizons différents. Par conséquent, nous devons combiner souvent des compétences différentes pour une telle étude. Par exemple, des compétences en géographie doivent être mobiliser pour l'étude d'une ville et de sa structure. Des compétences en économie sont nécessaires pour bien comprendre les relations économiques. Des compétences en modélisation et en informatique sont exigées pour concevoir et développer des modèles efficaces.

Ainsi, la difficulté de l'étude de ces systèmes dérive non seulement de leur structure et leur comportement, mais aussi de la quantité de connaissances nécessaire pour les comprendre. La recherche sur les systèmes complexes s'appuie ainsi sur un véritable travail interdisciplinaire. L'échange entre des participants occupe une place importante pour cette sorte de travail.

Exemple 1 : Embouteillage

L'embouteillage est un exemple populaire pour les systèmes complexes. C'est un encombrement de circulation dans lequel plusieurs moyens de transport ne peuvent pas déplacer ou se déplacent très lentement. Ce système est composé par des moyens de transport, la route, la condition de l'environnement ...

On étudie ce système pour bien contrôler la circulation et diminuer le temps de trajet. Comme un système complexe, son comportement dépend du comportement de ses composants et des interactions entre eux qui sont très variables. Par exemple, le comportement d'un moyen de transport va changer quand les autres moyens autour de lui changent, une pluie forte diminue la capacité d'une route d'environ 10% : donc plus il pleut, plus un embouteillage se forme rapidement, l'introduction d'un nouveau véhicule va causer l'augmentation du temps de trajet ...

L'étude des systèmes routiers en général, et des embouteillages tel l'exemple ci-dessus exigent de jours en jours l'effort de différents domaines. Par exemple, des ingénieurs civils les étudient pour être capable de prévoir la circulation pour créer des réseaux routiers, des intersections efficaces et sécurisés, des ingénieurs environnementaux pour étudier la pollution atmosphérique qui en résultent. Les urbanistes les étudient pour décider comment utiliser le plus efficacement et mettre en œuvre les systèmes de circulation. Les mathématiciens aident à prévoir des nouveaux modèles de trafic et d'étudier l'efficacité de modèle actuel. Des informaticiens évaluent des solutions différents en produisant des modèles qui peuvent s'exécuter sur l'ordinateur pour que les autres puissent tester...

Exemple 2 : La famille

La famille peut être vu comme un système complexe. Elle est composée par plusieurs individus avec des caractéristiques, des comportements différents. Chacun a une relation avec d'autres, par exemple, un homme peut être le père de ses enfants, mais lui-même est aussi enfant de son père. Il a toujours une interaction entre les relations et les qualités de l'individu.
1.1.2 Les enjeux

L'étude, le questionnement que nous avons à propos des systèmes complexes, nous per-
mettent de mieux comprendre la dynamique du monde qui nous entoure ainsi que son devenir.
Cette étude nous aide à comprendre les phénomènes et mécanismes fondamentaux de la vie et
de l'environnement mais aussi les dynamiques sociales et économiques qui en découlent. Les
enjeux sont d'améliorer notre capacité à faire face aux défis de demain dans un monde où les
changements s'accélèrent. Comme nous verrons par exemple pour le cas de la dépollution, de
l'économie et de l'aménagement de la ville dans les sections suivantes.

a) Les sciences de la complexité au service de l'aménagement de la ville

L'aménagement urbain est un travail pas simple qui demande de bien comprendre la mobilité quotidienne à l'échelle d'une ville. Cette planification ne peut pas être déconnectée des politiques de transport. Cependant, en réalité, on ne peut pas essayer des différents politiques pour trouver la meilleure solution dans la vie réelle.

L'étude de la mobilité quotidienne par la modélisation et simulation nous donne la chance d'expérimenter une solution sans affecter notre vie. Par la création d'un modèle simplifié de la réalité, les aménageurs peuvent facilement définir de nouvelles politiques urbaines temporelles et/ou de transport.

b) Les sciences de la complexité au service de la dépollution

Prenons l'exemple de la dépollution de l'eau avec les biofilms. Ces derniers sont des systèmes microbiens se développant sur des supports et baignant dans un environnement aqueux dont ils tirent leurs nutriments [Treuil 2008].

L'étude des biofilms permet de résoudre plusieurs problèmes dans les domaines sanitaires, de l'environnement et de l'industrie. Elle nous permet, notamment, de bien contrôler des réacteurs biologiques utilisés pour la dépollution des eaux usées, comme le propose [Lardon 2002]. Cette étude s'interroge sur la prolifération et le cycle de vie des biofilms dans un objectif d'optimisation des stations d'épuration.

c) Les sciences de la complexité au service de l'économie

Dans le domaine de l'économie, l'étude des systèmes complexes rend la capacité de comprendre
le comportement des consommateurs, d'anticiper les réactions et d'établir des stratégies mar-
keting. Les travaux du domaine comme [Basu 1998, Janssen 2000, Said 2002] sont le fruit de
collaborations multi-disciplinaires en sociologie, psychologie, socio-psychologie, économie. Le
résultat de ces études sont aujourd'hui introduit dans la société de consommation sous diverses
formes dont le modèle CUBES [Said 2001] (Customer Behaviors Simulation) est un exemple.
Ce dernier permet de simuler une population de plusieurs milliers de consommateurs et de tes-
ter les réactions d'un marché face à différentes stratégies de marques, mettant plus ou moins
l'accent sur l'innovation, la fidélisation, la promotion, l'image de marque. Il aide les directeurs
marketing et les directeurs stratégiques à mieux concevoir leurs stratégies de marque
Dans la littérature, les expérimentations pour étudier des systèmes complexes sont souvent présentées comme des simulations massives, des jeux sérieux, des outils d'aide à la décision qui permettent, par exemple, l'anticipation des conséquences sociales, économiques, écologiques ou d'un choix d'aménagement. Comment évaluer à long terme l'impact d'une décision politique dans le vaste ensemble de scénarios dessiné par les futurs possibles d'un système aussi complexe qu'une ville ? Comment, d'ailleurs, construire cet ensemble de scénarios en prenant en compte des données aussi diverses que la démographie, l'évolution du climat, la dynamique écologique ? Telles sont quelques-unes des questions auxquelles sont confrontés les chercheurs intervenant sur ces problématiques et bon nombre d'entre elles constituent des défis scientifiques qu'il est urgent de relever.

Actuellement, les méthodes et outils classiques, notamment en mathématique et en informatique, ne peuvent pas individuellement répondre aux problématiques abordés dans les sciences de la complexité. Ils doivent être associés, combinés en tenant compte de l'expérience et des résultats acquis dans les autres disciplines [Bousquet 2001, Drogoul 2003, Guyot 2004, Barnaud 2008, Bousquet 2005, Crookall 2010, Xu 2011, Byrne 2010, Wang 2012, Ridgewell 2011, Müller 2007, Müller 2011]. Dans la littérature, plusieurs méthodes sont proposées. Elles s'intéressent à un contexte d'étude identifié.

1.1.3 Démarche scientifique pour l'étude des systèmes complexes

La démarche scientifique est un outil d'investigation pour décrire et comprendre un
phénomène[Cornu 1998]. Dans les sciences de la complexité, elle guide, selon [Marilleau 2006],
modélisateurs et thématiciens, dans la démarche d'observation et de compréhension d'un
phénomène complexe en vu de le modéliser pour extraire par simulation (infomatique ou
mathématique) des compétences, des connaissances et des préconisations.

Selon Jean-Michel Cornu l'acquisition de connaissances scientifiques nécessitent quatre étapes (cf figure 1.1) [Cornu 1998] : (1) l'observation ; (2) la création d'une nouvelle vision ; (3) la mise en équations ; et (4) la production des prévisions observables. La première étape vise à observer les phénomènes et à acquérir les données nécessaires à son étude. La deuxième introduit une nouvelle vision du phénomène, plus synthétique traduisant une question scientifique. Puis, cette nouvelle vision est traduite par de nouveaux postulats de modélisation. Enfin, en nous basant sur les résultats des dernières étapes, les chercheurs proposent des lois qui permettent de fournir des prévisions dans divers cas de figure.

Le processus proposé dans [Cornu 1998] correspond à une succession idéalisée d'activités que nous pouvons retrouver dans nombre de démarche de la littérature comme [Bernard 1947, Giordan 1976, Cariou 2002, Dépelteau 2003].

Néanmoins, l'augmentation des études interdisciplinaires jumelées à une spécialisation dis-
ciplinaire font qu'il est de moins en moins possible pour un chercheur de réaliser seul une étude
"satisfaisante" d'un phénomène complexe. C'est pourquoi, les auteurs d'un modèle sont ma-
joritairement des chercheurs qui viennent d'horizons différents. La collaboration est alors un
facteur important pour ce type d'étude. Modélisateurs, experts du domaine échangent, par-
tagent des expériences et des équipements pour associer leurs connaissances et en faire émerger
de nouvelles.

L'étude des systèmes complexes présente la même ossature que celle proposé par Cornu.
<figure><img src="image_4.png" /><figcaption>FIGURE 1.1 – Projection de l'étude des systèmes complexes à la démarche scientifique
[Cornu 1998]</figcaption></figure>

Mais, nous pouvons aussi remarquer une importante variabilité dans les démarches scientifiques. Par exemple, lors de l'étape 4 dans la démarche de Cornu, le résultat obtenu doit être capable de prédire des phénomènes non encore observés. Pendant que, à l'étape IV, l'étude des systèmes complexes souvent tirent des conclusions ou des validations sur seulement le problème étudié. De plus, c'est difficile de donner des prévisions pour des systèmes complexes.

Dans la littérature, nous voyons quatre étapes pour cette étude : (I) l'observation - analyse des données, (II) la modélisation, (III) l'expérimentation et (IV) la validation - conclusion, comme illustré dans la figure 1.1.

a) L'observation - analyse des données

"En science, tout commence et tout finit par des observations" [Cornu 1998]. Cette tâche vise à acquérir les informations nécessaires à la modélisation. Elle se base principalement sur des méthodes empiriques qui ne doivent pas influencer ou dénaturer les phénomènes observés. Cette idée est similaire avec celle énoncée dans la démarche de Cornu.

Les sciences comme celles de la complexité, rencontrent aujourd'hui nombre de difficultés pour l'observation et l'analyse des données, conséquence d'une pluridisciplinarité exacerbée, de phénomènes étudiés de plus en plus complexes qui sont noyés dans une masse de données à analyser. Dans ce contexte, une analyse préliminaire importante doit être menée.

Ces analyses demandent la participation de plusieurs acteurs. Chacun observe une partie, un aspect, selon ses compétences et échange son observation, son expérience pour constituer une connaissance commune.
Il s'agit donc d'une analyse préalable qui vise à mettre en forme les données acquises afin de les rendre intelligibles lors du processus de modélisation [Han 2011]. La construction de cette structure constitue ce qui est communément appelé le *modèle du domaine* [Drogoul 2003]. Ce modèle est régulièrement révisé tout au long du processus de modélisation, au fur et à mesure de l'évolution de la question scientifique [Treuil 2008].

b) La modélisation

L'objectif de cette étape est d'appliquer des méthodes et outils de modélisation pour caractériser
à la fois la structure d'un système complexe et sa dynamique. Il s'agit d'un modèle représentatif
donnant une vision simplifiée du système réel, selon le questionnement scientifique. Son anima-
tion (par calcul et/ou simulation) reproduit la dynamique du système réel.

Les choix des méthodes de modélisation dépendent d'une part des usages et coutumes de la
discipline et d'autre part d'une réflexion sur les propriétés attendues du modèle [Treuil 2008].
La littérature concernant ces méthodes croît extrêmement rapidement, si bien qu'il est difficile
d'avoir une compréhension complète sur ces techniques. Cependant, nous pouvons identifier
deux principales approches qui demandent, pour chacune d'elles, des compétences spécifiques
[Newman 2011].

La première approche implique la création et l'étude des modèles mathématiques simplifiés qui essaient de faire abstraction des éléments qualitatifs les plus importants dans un cadre soluble par lequel nous pouvons obtenir un aperçu scientifique, bien que la méthode ne peut pas imiter exactement le comportement des systèmes réels. Cette approche demande la compétence concernant la théorie des systèmes dynamiques, théorie de l'information, les automates cellulaire, les réseaux, la théorie de la complexité de calcul et des méthodes numériques.

La deuxième approche consiste à créer des modèles plus compréhensifs et plus réalistes, souvent sous forme de simulation informatique, qui représente les parties en interaction du système complexe. Ils sont ensuite utilisés pour regarder et pour mesurer les comportements émergents qui apparaissent. Les compétences nécessaires pour cette approche sont la simulation Monte-Carlo, la simulation à base d'agent [Müller 2002].

Bien que la méthode par simulation soit jeune par rapport aux autres, elle promet une
meilleure compréhension des systèmes complexes. En effet, les systèmes complexes sont souvent
auto-organisé et ont des propriétés émergentes qui ne peuvent pas être décrites simplement par
des équations mathématique déterministe, continues, déterministe ou non [Heylighen 2008]. Les
récentes avancées dans le domaine montre que ce problème peut être résolu par des modèles
simplifiés qui permettent de reproduire artificiellement l'évolution d'un système. C'est l'idée
principale de la méthode de modélisation et simulation.

Lors de cette étape, la quantité des échanges entre les participants est donc importante
car les concepts manipulés nécessitent des compétences variées. Ils proviennent non seulement
des modélisateurs qu'ils soient mathématiciens, statisticiens ou informaticiens, mais aussi des
personnes qui travaillent dans le domaine scientifique concerné qui sont les thématiciens. Par
exemple, des ingénieurs civils, des ingénieurs environnementaux ou des urbanistes. Il faut une
communication régulière pour former une modèle précis qui représente bien le système complexe
de référence.
c) L'expérimentation - validation

Tandis que l'observation permet d'acquérir une première connaissance des systèmes com-
plexes étudiés, au sens le plus large, et en d'en déduire éventuellement des hypothèses,
l'expérimentation aide alors à les vérifier, préciser ou amender pour raisonner des expériences
scientifiques. Selon Chevreul, l'expérimentation est [Michel-Eugène 1856] :

un phénomène frappe vos sens; vous l'observez avec l'intention d'en découvrir
la cause, et pour cela, vous en supposez une (méthode) dont vous cherchez la
vérification en instituant une expérience [...]. Ce raisonnement constitue la méthode
que j'appelle expérimentale, parce qu'en définitive l'expérience est le contrôle, le
critérium de l'exactitude du raisonnement dans la recherche des causes ou de la
vérité.

Cette activité tente d'établir le lien de causalité d'un phénomène complexe afin de lui apporter une meilleure compréhension. Cette tâche est réalisée à l'aide d'un dispositif expérimental (le simulateur) qui permet de produire à partir d'une simple observation d'un phénomène naturel (traduite dans les paramètres du modèle), de nouvelles observations apportant de nouvelles connaissances. Ainsi, on réalise une multitude de tests, de scénarios, par des expérimentations répétées, parfois en utilisant des moyens de calcul haute performance [Marilleau 2006] afin d'obtenir des résultats qualitatifs et/ou quantitatifs les dynamiques du systèmes étudié.

Une des réponses possibles se trouve dans les recherches menées depuis quelques années
par la communauté informatique au sein du vaste ensemble des « sciences de la complexité ». Les modèles et simulateurs qui y sont développés s'attaquent à des problématiques écologiques, économiques et sociales d'actualité et proposent de nouveaux instruments de décision basés sur la simulation et la fouille de données. Constituant de véritables expérimentations virtuelles à vocation prédictive ou déductive, elles permettent de mieux appréhender le devenir d'un système et de concevoir des scénarios « what if » permettant d'évaluer des politiques avant leur mise en application, au moyen de simulations massives, de jeux sérieux ou de techniques d'exploration « intelligentes ». Dans ces approches, l'acte de modélisation est complémentaire de l'expertise ou du travail de terrain mais va également au delà de ces approches, en proposant une démarche de recherche à la fois conceptuelle (via la construction de modèles pluridisciplinaires) et expérimentale (via la mise en œuvre de simulations).

En se basant sur les résultats lors des expérimentations, cette étape vise également à valider
les modèles conçus pour des dernières étapes. Si les résultats obtenus ne s'accordent pas avec
des données de l'observation du système réel ou avec des hypothèses obtenues dans l'étape de
modélisation, les travaux des précédentes avants va être remis en question. Il y a six types de
validation [Knepell 1993] :

- la validation conceptuelle examine l'adéquation du modèle conceptuel ou théorique avec le système réel. Pour cela il existe des approches dites "d'animation de modèle" comme le propose Fabrice Bouquet et al. dans [Dadeau 2011].

- la validation interne assure la conformité du codage, comme présenté par Drogoul et al. dans [Drogoul 2003].

- la validation externe compare les données produites par simulation avec les données réelles, comme présenté par Drogoul et al. dans [Drogoul 2003].

- la validation modèle-croisée assure le processus de transformation entre deux modèles successifs. Pour cet type de validation, il existe par exemple comme *holdout me-*
thod [Blum 1999], k-fold cross-validation [Bengio 2004] ou leave-one-out cross validation
[Kearns 1999]

- la validation des données étudie la fidélité des données (réelle et générée).

- la validation de sécurité vise à minimiser l'altération du modèle.

### d) Analyse des résultats - Conclusion

Lors de la précédente étape, on analyse également les résultats en vu de valider les modèles conçus. L'objectif de cette étape est, par l'analyse des résultats, de tirer des conclusions sur les dynamiques observées. Ensuite, on va essayer avec des autres observations et des nouvelles hypothèses. Ainsi la démarche est reproduite dans une nouvelle itération. Le modèle est utilisé maintenant pour avoir une meilleure compréhension du système complexe, ou trouver la solution pour le problème réel.

#### 1.1.4 Synthèse

En conclusion le domaine des systèmes complexes est vaste et fait appel à de nombreux champs disciplinaires. Leur étude nécessite l'intervention d'un groupe de chercheurs en collaboration, l'activité de modélisation solitaire devenant anecdotique. La création d'un modèle et d'un simulateur suivent, dans son ensemble, une démarche linéaire mais de nombreuses rétroactions apparaissent, au fur et à mesure de l'avancement du projet. Ces rétroactions sont le fruit des échanges entre les participants et sont gages d'une émergence de connaissance. La collaboration étant un facteur important non seulement dans l'étude des systèmes complexes, mais aussi dans la recherche, nous développons cet aspect dans la section suivante.

## 1.2 La collaboration dans la recherche, une nécessité

La collaboration est un aspect critique pour la recherche. Aucun scientifique individuel peut posséder toutes les connaissances, les compétences ou le temps requis pour apporter des contributions théoriques ou appliquées dans plus d'un domaine très étroit de la recherche [Hara 2003]. Par conséquent, la recherche s'accompagne de la collaboration. Cependant, cette dernière est dominée souvent par des problèmes complexes, le changement rapide de la technologie, la croissance dynamique des connaissances et des zones très spécialisées d'expertise. Au cours de cette section, premièrement nous allons donner une définition de collaboration. Ensuite, les raisons principales pour la collaboration dans la recherche sont identifiées. Enfin, la collaboration dans l'étude des systèmes complexes est analysée.

### 1.2.1 Concepts et définitions

La collaboration est un mode de travail qui de plus en plus s'applique largement dans le monde entier. C'est un processus visant à partager la création [Denise 1999]. Des individus s'organisent en groupe et échangent afin de résoudre un problème commun. Néanmoins chaque membre dispose d'une expérience, de compétences, d'une vision différente à propos du système complexe.
Selon le dictionnaire le Petit Larousse en ligne<fnref n="1" />, la collaboration est une action de *travailler de concert avec quelqu'un d'autre, l'aider dans ses fonctions*; *participer avec un ou plusieurs autres à une œuvre commune*. C'est une définition élémentaire pour la collaboration. Par cette définition, nous pouvons identifier deux éléments principaux que tous les travaux collaboratifs doivent assurer : travail collectif et but commun. Cependant, cette définition est simple dans le contexte de collaboration actuelle.

Schrage [Schrage 1995] a étendu la définition de collaboration en détaillant la façon de l'effectuer : *the process of shared creation : two or more individuals with complementary skills interacting to create a shared understanding that none had previously possessed or could have come to on their own*. Cette idée apparaît aussi dans la définition de Iivonen et al [Iivonen 2000] : "human behavior that facilitates the sharing of meaning and completion of activities with respect to a mutually shared superordinate goal and which takes place in a particular social, or work, setting".

Ces nouvelles définitions ajoutent un élément important : le partage de la connaissance. Ainsi, la collaboration nécessite non seulement des objectifs communs mais aussi un partage des connaissances et des compétences.

En résumé, la collaboration est souvent vu comme un processus dans lequel les participants possèdent des connaissances, des compétences différentes et complémentaires pour résoudre un problème commun. Mais, dans cette vision on oublie un élément important de la collaboration qui est le support de l'échange, le média de la communication. Ce dernier peut-être une simple feuille de papier, un logiciel voire un collecticiel. C'est sur quoi cette thèse va s'intéresser particulièrement.

Avec l'augmentation de la collaboration distante, le développement d'outils devient indispensable. On collabore en utilisant des techniques de communication, de coordination en vue de partager l'expérience.

Dans un contexte de groupe<fnref n="2" />, la spatialité et la temporalité sont un facteur important dans la prise de décisions et dans le choix d'une méthode de travail. A partir de ces deux critères, 4 niveaux de collaboration peuvent être identifiés [ElliS 1991] comme cela est présenté par la figure 1.1.

<table><caption>TABLE 1.1 – Table des modes de travail en groupe</caption><thead><tr><th></th><th>Synchrone</th><th>Asynchrone</th></tr></thead><tbody><tr><th>Présentiel</th><td>Collaboration<br>face-à-face</td><td>Collaboration<br>asynchrone</td></tr><tr><th>Distantiel</th><td>Collaboration distante<br>synchrone</td><td>Collaboration distante<br>asynchrone</td></tr></tbody></table>

Dans quatre modes de collaboration, la collaboration face-à-face est la plus efficace car tous les membres collaborent en même temps et sur le même espace. Ensuite, c'est la collaboration distante synchrone, avec laquelle les membres collaborent simultanément, mais chacun d'eux se situe en des lieux différents, par exemple : un éditeur de document en temps réel. Puis, c'est la collaboration asynchrone où les membres échangent sur une même espace, mais pas

<footnote n="1">1. http://www.larousse.com/</footnote>

<footnote n="2">2. aussi bien dans le contexte de la recherche que dans un contexte plus général</footnote>
simultanément, par exemple : le tableau d'information physique. Enfin, la collaboration distante asynchrone qui est correspondante avec le cas où les membres collaborent ni simultanément et ni en même temps par exemple : le système de courriel électronique ou le forum.

Cependant, dans la littérature, on trouve que la collaboration face-à-face et asynchrone résultent souvent des décisions moins risquées par rapport aux autres [Valacich 2002]. Car à un moment, il y a seulement une personne qui peut parler. De plus, la collaboration asynchrone nous oblige à être plus synthétique dans le discours. Tandis que pour les deux types de collaboration distante qui utilisent des médias supportant le parallélisme, les participants facilement entrent l'information simultanément. Cela conduit plus de participations, et ainsi plus d'exposition des pensées et des opinions des autres. Par conséquent, des décisions plus risquées sont produites. Dans ce contexte, encore une fois, le rôle du support de la collaboration montre son importance. Il permet de structurer la discussion, le modèle de la collaboration.

### 1.2.2 Les enjeux

La communauté scientifique est de plus en plus interconnectée. Selon la Royal Society<fnref n="3" />, en 2008, plus d'un tiers des articles publiés dans des journaux internationaux (environ 1.5 millions) sont le résultat de la collaboration internationale, en augmentation de 25% par rapport des années 1990, et de 10% avec des années 1996 [Brito 2011].

<figure><img src="image_5.png" /><figcaption>FIGURE 1.2 – Augmentation des articles publiés en collaboration avec plus d'un auteur international, entre 1996 et 2008 [Brito 2011]</figcaption></figure>

Il y a plusieurs motivations pour la collaboration dans la recherche. En premier lieu, la collaboration favorise l'excellence [Katz 1997, Brito 2011]. Les partenariats améliorent la qualité du travail des chercheurs, accroient leur efficacité par une mutualisation des efforts, de la logistique et des coûts. C'est ainsi que l'effort international entre des cliniciens, des épidémiologistes, des microbiologistes a eu raison de l'épidémie de SRAS (syndrome respiratoire aigu sévère) entre 2002-2003 [McAleer 2010].

La plupart des chercheurs échangent avec d'autres pour (i) partager des compétences, (ii) mutualiser des connaissances complémentaires, (iii) ou tout simplement pour s'ouvrir à d'autres

<footnote n="3">3. La Royal Society est une bourse de recherche des plus éminents scientifiques du monde entier et est la plus ancienne académie des sciences en existence continue</footnote>
disciplines et s'assurer de la validité de leur travail [Katz 1997, Melin 2000, Beaver 2001]. Au-
jourd'hui, aucun chercheur ne peut effectuer toutes les tâches scientifiques individuellement.
Comme Stilgoe et al [Stilgoe 2009] a dit concernant le domaine géographique : *if you are the
best, geography doesn't exist*. La collaboration entre des chercheurs permet de bien conduire
les travaux complexes et faire émerger des idées innovantes. Prenons l'exemple d'un fait réel,
l'étude de la multiplicité des particules chargées réalisée grâce au détecteur ATLAS à nécessité
le concours de 3 222 chercheurs provenant de 32 pays différents [Aad 2010].

Du point de vue économique, la collaboration réduit les coûts de la recherche par le partage
de moyens humains et d'équipements honéreux [Katz 1997, Melin 2000, Thorsteinsdóttir 2000,
Beaver 2001]. Nous rencontrons cette tendance dans les pays en développement. Par exemple
pour le domaine de calcul haute performance, l'exigence d'équipements puissants et souvent
très chers est la raison de plusieurs collaborations dans le domaine. Comme le projet ANR-JST
FP3C (Framework and Programming for Post Petascale Computing) qui est une collaboration
exceptionnelle entre la France et le Japon. Cette collaboration permet de fournir des supercal-
culateurs qui sont capables d'effectuer en un jour une tâche qu'un ordinateur de bureau mettrait
150 ans à accomplir [Brunet 2011].

De plus, la diminution du prix de transport et le développement de la technologie de commu-
nication, tel que l'Internet, la vidéo conférence ou l'email facilitent également la collaboration
entre des chercheurs.

Dans le cadre de projets importants, la collaboration permet de partager le volume de travail nécessaire à son accomplissement et de diviser des tâches compliquées en d'autres plus simples et intelligibles [Brito 2011]. Par exemple, la recherche concernant la diversité, la distribution et l'abondance de la vie marine est un travail difficile et complexe. Par conséquent, pour produire le rapport *First Census of Marine Life 2010* concernant ce thème, il faut une collaboration de 2700 chercheurs de 670 laboratoires venant de 80 pays pendant 10 ans [Census 2010].

L'augmentation du prestige ou de la visibilité est aussi une motivation de la collabora-
tion [Katz 1997, Beaver 2001]. Pour présenter les résultats de recherche, les chercheurs publient
sous forme d'articles scientifiques pour diffuser leurs résultats auprès de leur communauté. Dans
ce contexte, la citation est gage de qualité. Pour chaque auteur international sur un article, il y
a une augmentation correspondante sur l'impact des articles comme illustré dans la figure 1.3.

En effet, la collaboration est indispensable non seulement pour la recherche, c'est aussi vraie
pour d'autres domaines. Par exemple la télé-médecine qui est un processus dans lequel on utilise
des technologies de la collaboration pour supporter les participants distants dans le diagnostic
et la consultation, comme l'examen clinique et le transfert d'images médicales [Aupet 2009b].
Cette application permet d'amener les services médicaux aux clients plutôt que les clients aux
services où on rencontre plusieurs difficultés concernant la distance, le temps, la géographie,
l'économie et l'application. Cela permet la capacité de l'accessibilité aux soins de la spécialisés
[Aupet 2011]. De plus, la télé-médecine aide également de jeunes docteurs dans leurs études.
Ces docteurs peuvent participer à des examens réels en utilisant des systèmes de télé-médecine
pour observer les experts.

Ainsi la collaboration montre de plus en plus son importance, notamment dans le monde
de la recherche. Les sciences de la complexité sont loin d'être étranger à ce besoin d'échanger.
Nous développons cet aspect dans la partie suivante.
<figure><img src="image_6.png" /><figcaption>FIGURE 1.3 – Citation par article versus le nombre de pays collaboré [Brito 2011]</figcaption></figure>

### 1.2.3 Étude collaborative des systèmes complexes

Comme nous l'avons précédemment vu, le domaine des systèmes complexes est souvent ca-
ractérisé par une multi-disciplinarité qui résulte de la fragmentation et de la spécialisation des
savoirs dans l'étude et la compréhension des systèmes complexes [Drogoul 2004].

Par exemple, l'étude de l'âge du mariage de [Billari 2007] qui est un systèmes complexe. Cet étude est pour comprendre les normes sociales de l'âge du mariage. Ces normes peuvent être décrites par un graphe montrant le pourcentage des gens mariés à chaque age. Le modèle conçu explore plus particulièrement le rôle des réseaux sociaux dans l'influence de l'âge du mariage. Si l'on suppose que les gens sont plus susceptibles de se marier quand d'autres membres de leur réseau social sont mariés, est-ce que ça explique la répartition typique de l'âge-au-mariage ? Pour bien comprendre l'âge du mariage de ce modèle, on doit étudier deux perspectives différentes avec la collaboration entre le démographe, le sociologue, le psychologue et l'économiste. D'un côté, les démographes et les sociologues ont mis l'accent sur l'explication des faits stylisés importants tels que la forme typique de courbes âge-au-mariage ; leurs stratégies analytiques sont souvent basées sur les modèles mathématiques et statistiques pour le macro-niveau. De l'autre côté, les psychologues et les économistes se sont concentrés sur l'étude du processus de recherche de partenaires ; les hypothèses individualisées ont généralement été au cœur de cette approche.

L'étude des systèmes complexes nécessite la combinaison de plusieurs approches et la connaissance des experts du domaine et des modélisateurs. La quantité et la qualité de la collaboration est variée à chaque étape de l'étude des systèmes complexes [Taylor 2003] que nous avons tiré de la démarche de Cornu, dans la section précédente.

- L'observation - analyse des données : Les données observées résultent majoritairement de travaux empiriques réalisé par des experts tandis que le modèle propose des concepts et outils permettant de décrire la dynamique d'un système. Malgré les nombreux efforts présentés dans la littérature, tentant de rapprocher experts et modélisateurs [Grimm 2006,
Drogoul 2003, Amouroux 2010], l'expérience montre la difficulté de collaborer dans un projet de modélisation-simulation des systèmes complexes. Il est notamment délicat de représenter des phénomènes complexes par un formalisme compréhensible à la fois par des modélisateurs et par des experts. Après cette étape, les données doivent être mise en forme pour l'étape de modélisation. La collaboration entre l'expert et le modélisateur permet une compréhension mutuelle.

- La modélisation : A l'étape de modélisation, un modèle du système étudié va être formé par le modélisateur. Néanmoins, la participation de l'expert est indispensable. Ils aident le modélisateur dans la compréhension des terminologie du domaine, les données spécifiques ... pour concevoir un modèle fidèle. A cette étape, si les approches analytiques ou sto-chastiques sont appliqué et il faut la participation des mathématiciens. Pour l'approche par simulation, les informaticiens sont nécessaires.

- L'expérimentation : Pour bien identifier la liaison cause-conséquence dans l'expérimentation d'un modèle pluri-disciplinaire, nous devons combiner toutes les connaissances concernées. Ainsi, la collaboration entre des thématiciens à cette étape est importante. De plus, la collaboration avec des informaticiens permet de mettre en application le modèle et de bien manipuler l'application. D'autre part, la validation ne peut pas être faite sans le modélisateur et le thématicien [Gaudou 2011]. Le second connait bien le système étudié tandis que le premier connait seulement la technique de la modélisation. Le thématicien exécute simplement des simulations avec le simulateur, observe le résultats en comparant avec ses connaissances et ses données. Cette collabora-tion aide eux de compléter des connaissances et expériences pour déterminer si le modèle conçu doit re-développer.

- L'analyse du résultat - Conclusion : Les résultats, les sorties de l'expérimentation d'un modèle pluri-disciplinaire ne sont pas simples à comprendre et à analyser. Tous les thématiciens concernes doivent collaborer pour bien les exploiter et pour produire une bonne conclusion.

Citons ici un exemple concernant l'étude des systèmes complexes, dans le cas du projet MIRO [Arnaud 2005, Marilleau 2006] dans le domaine de la mobilité géographie. Pour répondre à l'exigence du nouveau mode d'analyse et de représentation des dynamiques quotidiennes, l'objectif de ce projet est de :

- développer une stratégie d'acquisition d'information individuelle finement datée et loca-lisée concernant les comportements de mobilité des populations urbaines

- définir un protocole d'observation et d'analyse des modalités d'émergence et d'évolution, dans le temps court de la journée, des configurations territoriales générées par une multi-tude de trajectoires individuelles

- assister les aménageurs dans la définition de nouvelles politiques urbaines temporelles.

C'est un projet de recherche interdisciplinaire avec la collaboration entre géographes, économistes, statisticiens et informaticiens de plusieurs institutions et Universités, tel que Laboratoire d'informatique de l'Université de Franche-Comte, Laboratoire Image et Ville (LIV), Théoriser et Modéliser pour Aménager de Besançon, TERRITOIRES d'institutes de Géographie Alpine.

Comme d'autre domaine dans le monde de recherche, l'étude des systèmes complexes présente des difficultés dans la collaboration. L'une des difficultés majeures est la conséquence
d'une répartition géographique distribuée des experts du domaine et des chercheurs. En ef-
fet, experts et modélisateurs travaillent souvent dans des instituts, des villes ou des pays
différents. De plus, les scientifiques sont habituellement membres de plusieurs projets si bien
que le temps de chacun d'eux est compté. Par conséquent, les fenêtres favorables à l'échange
s'avèrent extrêmement contraintes dans l'espace et dans le temps. Une des solutions possibles
à ce problème repose sur l'utilisation des groupware.

Une autre difficulté est causé par la combinaison de plusieurs disciplines (interdisciplinaires ou multidisciplinaires) dans une même étude. Tout d'abord se pose la question du vocabulaire. Les domaines différents possèdent des vocabulaires spécifiques. En fonction fu contexte d'utili-sation de la discipline et de l'utilisateur, un vocabulaire peut avoir des significations différentes.

Les objets d'étude étant souvent différents entre les disciplines de recherche, la collaboration s'en avère affectée. Les participants possèdent des points de vue différents, des méthodologies et des outils de travail différents pour un même objet d'étude ce qui implique des incohérences et des malentendus. Ce problème ne peut se résoudre sans une complicité entre experts et modélisateurs à propos de l'objet de l'étude.

Nombreux sont les travaux qui proposent des approches, des outils conceptuels, et des infra-
structures logicielles facilitant la production de modèles et de simulateurs [Treuil 2008]. Cepen-
dant, aussi dédiés soient ils, ces méthodologies, ces méta-modèles, ces DSL (Domain Specific Lan-
guage) ne remplaceront jamais l'échange de connaissances et d'expériences qui résultent d'une
collaboration entre un modélisateur et un thématicien durant les processus de modélisation et
de simulation.

1.3 Simulation des systèmes complexes

1.3.1 Concepts et définitions

La notion de simulation est présent depuis longtemps dans la science, selon Shannon
[Shannon 1976], la simulation est :

"the process of designing a model of a real system and conducting experiments with this model for the purpose either of understanding the behaviour of the system or of evaluating various strategies (within the limits imposed by a criterion or a set of criteria) for the operation of the system."

Ainsi, Shannon considère la simulation comme un processus dans lequel on reflète le système réel par un modèle dynamique. Au lieu d'étudier directement le système réel, on réalise des expérimentations avec ce modèle. Le modèle décrit une certaine forme de compréhension du système référence.

Dans la processus de Shannon, le processus de simulation est constitué, d'une part, par la
construction du modèle et, d'autre part, par l'utilisation analytique. Cette définition mélange
à la fois la modélisation et la simulation dans l'étude des systèmes complexes. Pourtant
ces deux étapes semblent bien distinctes dans un même processus. D'ailleurs Fishwick, dans
[Fishwick 1997], propose une définition qui va en ce sens

"Computer simulation is the discipline of designing a model of an actual or theore-
tical physical system, executing the model on a digital computer, and analyzing the
execution output."
<figure><img src="image_7.png" /><figcaption>FIGURE 1.4 – Processus de simulation [Fishwick 1997]</figcaption></figure>

Cette définition a clairement proposé trois étapes principales pour le processus de simulation :

1. l'élaboration du modèle.

2. l'exécution du modèle sur ordinateur

3. l'analyse de l'exécution du modèle et des résultats obtenus

Comme Shannon, la définition de Fishwick mélange également la modélisation et la simulation. Mais, Ce sont deux phases séparées et consécutives d'un même processus. La modélisation est l'étape pour concevoir le modèle, tandis que la simulation est celui qui permet d'animer le modèle, d'expérimenter et collectionner les résultats. Selon Treuil [Treuil 2008] :

> "la simulation est l'activité au cours de laquelle, selon un protocole et avec un objectif précis, on utilise un simulateur pour faire évoluer les entrées d'un modèle dynamique, l'exécuter, et en recueillir les sorties".

Ainsi le simulateur peut être perçu comme un objet complexe, une boîte noire, dont on ne connaît pas le fonctionnement interne, mais disposant d'entrées et de sorties. Ces entrées et sorties sont connues des utilisateurs et sont les éléments manipulés.

Par cette définition, nous pouvons identifier trois parties principales qui composent une simulation : un simulateur, des paramètres entrées et des résultats. Le simulateur reçoit les paramètres d'entrées qui introduits par l'utilisateur, exécute l'expérimentation, produit les résultats. Tout le simulateur dispose d'une interface pour que son utilisateur puisse interagir avec lui.

Nous nous intéressons particulièrement dans la cadre de cette thèse à la simulation basée sur les scénarios participatifs ou collaboratifs et les jeux (les jeux sérieux, de rôle et d'expérimentation).

Selon Carroll, les scénarios sont définis de la manière suivante :

> Scenarios have been defined variously as sketches of use and as a narrative description of an activity, taking the form of a story, a vignette, or an episode bound in time and taking place within a given context. [Carroll 2000]

> The defining property of a scenario is that it projects a concrete description of activity that the user engages in when performing a specific task, a description suf-
ficiently detailed so that design implications can be inferred and reasoned about.
[Carroll 2002]

Par conséquent, il y a deux façons de voir les scénarios : soit un scénario est unique et raconte une histoire à la manière des scénarios des films, soit un scénario décrit une activité décrite à un moment précis. Les scénarios collaboratifs ou participatifs de simulation sont des scénarios dans lesquels on décrit comment la simulation est organisée et manipulée. Notamment, dans ces scénarios, on concentre particulièrement sur l'échange entre les participants dans la simulation.

Nous nous intéressons également à la notion de jeux sérieux. Ces derniers se réfèrent à des jeux qui sont exécutés sur l'ordinateur ou des consoles de jeux pour la formation, la simulation, l'éducation ou la publicité. Dans la littérature, il existe plusieurs définitions pour les jeux sérieux. Et les débats sur ces définitions continuent encore jusqu'à maintenant. Dans le cadre de cette thèse, nous nous concentrons seulement aux jeux sérieux sous la forme de simulation qui a le regard et la sensation d'un jeu, mais en fait c'est une simulation du monde réel des événements ou des processus [Susi 2007]. Dans ce contexte, Crookall [Crookall 2010] considère les jeux sérieux comme des jeux/simulations informatiques utilisés pour la formation ou l'apprentissage.

Un autre type de jeu qui est appliqué souvent dans la simulation des systèmes complexes est les jeux de rôle ou les jeux d'acteur. Ces derniers sont appliqués souvent avec les scénarios où ils spécifient seulement les rôles et leur missions, au lieu de présenter des participants réels. C'est une méthode d'apprentissage active, basée sur l'exploration des expériences des participants. Le but est de discuter et de tirer des enseignements des expériences de chacun.

La simulation et le jeu de rôle possèdent des caractères complémentaires qui peuvent ren-
forcer l'étude des systèmes complexes quand nous les utilisons conjointement [Barreteau 2003].
Pour les études des systèmes complexes qui mettent en évidence le processus de la négociation
entre des participants, les méthodes expérimentales classiques orientées modèle ne sont pas assez
suffisant pour faire face avec cette complexité et incertitude. Elles ne peuvent pas tenir compte
de la diversité des points de vue des participants. En utilisant conjointement le jeu de rôle et
la simulation cette difficulté peut se voir résolue. Il y a deux catégories conjointes d'utilisa-
tion : le support mutuel dans l'utilisation et le support mutuel dans la conception et l'analyse.
Dans la première catégorie, les deux outils sont utilisés simultanément avec différents modèles
conceptuels de base. Dans la deuxième catégorie, les deux outils sont utilisés les uns après les
autres et ont le même modèle conceptuel de base. Les travaux de [Mermet 1993], [Toth 1988]
[Bousquet 1999] [Aubert 2002], [Nguyen-Duc 2005] sont quelques exemples de cette conjonction.

1.3.2 Catégorie des simulateurs

Lors de la modélisation, on conçoit un modèle traduisant une dynamique. Il s'agit d'une spécification constituée d'instructions qui permettent de générer le comportement du système [Michel 2004]. Ensuite, le développement d'un outil capable d'exécuter ces instructions est nécessaire. C'est le rôle du simulateur.

Selon [Treuil 2008], le simulateur est un :

"Programme (ou plate-forme) informatique capable d'interpréter des modèles dyna-miques, et utilisé(e) pour produire les perturbations désirées sur ces modèles"

Comme le modèle dynamique sont souvent formé sous des formes (modèle domaine, concep-
tuel ou computationnel) qui sont difficile d'explorer, le simulateur nous aide de concrétiser ce
modèle par un dispositif plus manipulable selon deux contraintes :

- Des contraintes structurelles : qui vont imposer une certaine forme de description et de formalisation du modèle

- Des contraintes d'accès : qui spécifient ce qu'implique le fait pour le modèle de pouvoir être perturbé et qui vont également prescrire une certaine forme de description.

La séparation du modèle et du simulateur permet d'envisager plusieurs implémentations d'un simulateur pour un même modèle [Zeigler 2000]. Pour qu'un simulateur respecte le modèle dynamique, on utilise un méta-modèle qui est "le modèle du langage de modélisation dans lequel sont exprimés les modèles dynamiques qu'un simulateur est censé pouvoir interpréter" [Treuil 2008]. Ce méta-modèle doit être conçu de façon indépendante de l'implémentation du simulateur.

Pour notre recherche, nous nous intéressons à la façon d'organiser des utilisateurs autour d'un simulateur. Par conséquence, trois types du simulateur sont identifiés : simulateur stand-alone, participatif et collaboratif

## a) Simulateur stand-alone

Un simulateur *stand-alone* ou bien isolé est un outil qui :

- ne permet qu'une manipulation locale. Les utilisateurs ne peuvent pas, à distance, modifier les paramètres, exécuter la simulation ou analyser les résultats;

- possède une interface unique pour tous participants.

- ne supporte qu'une seule interaction à un même moment. Si quelqu'un veut modifier un paramètre pendant que le simulateur est manipulé par quelqu'un d'autre, il doit attendre que l'action se finisse pour réaliser la modification.

La plupart des simulateurs actuels sont *stand-alone*, par exemple Miro [Arnaud 2005], Open Rescue [Chu 2008, Chu 2009], Ant [Wilensky 1997] ou le simulateur du modèle Game of life [North 2006].

## b) Simulateur collaboratif

Ce simulateur est pour supporter des simulations collaboratives qui sont les plus fréquentes dans le monde de la recherche. Contrairement à celui *stand-alone*, ces simulateurs :

- supportent des manipulations distantes

- acceptent plusieurs interactions en même temps

- s'adaptent aux utilisateurs

Pour ces simulateurs, nous pouvons citer par exemple le travail de Lapayre [Aupet 2009a, Pieralli 2009], le simulateur collaboratif de chirurgie S3, CVrS3 [CÔTE 2010], GroupSim [Hirata 2008] ou ASC portal [Bondarescu 2005]. Le simulateur collaboratif va être présenté en détail dans la partie 4.2 page 76.

## c) Simulateur participatif

Le simulateur participatif est le simulateur qui permet la participation des experts et non-experts dans un jeu de rôle [Bousquet 2001] [Drogoul 2003], [Nguyen-Duc 2005]. Il y peut y avoir deux catégories d'acteur dans ce type de simulateur : les acteurs humains et artificiels. Les
premiers sont des participants humains qui jouent les rôles simulés et interagissent directement avec les acteurs artificiels [Guyot 2004]. Ce type du simulateur est utilisé souvent pour explorer, modéliser et reproduire les comportements humains collectifs dans la conception des systèmes multi-agents [Chu 2011]. Pour ce simulateur nous avons, par exemple, le simulateur MADFAM [Nguyen-Duc 2005], le simulateur de Chu et al [Chu 2008, Chu 2009] ou le travail de Bousquet Commod - Companion Modeling [Bousquet 2001, Bousquet 2005], de Müller [Müller 2011].

Nous considérons le simulateur participatif comme un hybride des deux simulateurs précédents dans le sens qu'il existe des simulateurs qui supportent seulement les manipulations locales, une seule interaction en même temps et aussi des simulateurs qui supportent les manipulations distances, et plusieurs interactions en même temps.

d) Les différences entre simulateurs collaboratifs et simulateurs participatifs

Pour le simulateur participatif, on met l'accent sur la présence des participants dans l'utilisation du simulateur partagé. Mais, chacun travaille sur une partie (des paramètres, des sorties etc) différente. Il n'y a pas d'intersections d'entre ces parties. Au contraire, dans le simulateur collaboratif, chaque participant s'occupe une partie du simulateur partagé qu'il y a l'embrochement entre ces parties. Par conséquent, au cours de la simulation, une partie du simulateur participatif (par exemple une paramètre ou un résultat) est manipulé seulement par un participant. Tandis que, pour le simulateur collaboratif, elle peut être manipulé par plusieurs participants. Ainsi, l'ensemble des utilisateurs du simulateur collaboratif ont connaissance de l'ensemble de la simulation, au contraire avec celui participatif où chaque utilisateur possède une vision partielle sur la simulation. D'autre part avec le simulateur participatif, l'utilisateur est également l'acteur de la simulation. Tandis que avec le simulateur collaboratif, ils sont seulement les utilisateurs.

Concernant l'objectif des participants, pour le simulateur participatif, ils peuvent posséder des objectifs différents ou communes. Mais pour le simulateur collaboratif, tous les participants possèdent au moins un objectif commun.

D'autre part, les interactions autour d'un simulateur participatif sont plus simples que celui collaboratif. Elles sont souvent seulement des discussions. Tandis que, pour le simulateur collaboratif, ce sont des interactions pour travailler ensemble, non seulement la communication mais aussi la coordination. Dans la littérature, on considère souvent la participation comme le sous-ensemble de la collaboration.

La différence entre le simulateur participatif et collaboratif résulte la méthode d'utilisation des participants. Ainsi, selon la méthode d'utilisation, un simulateur peut être participatif ou collaboratif. Par exemple, pour le simulateur MIRO [Arnaud 2005, Banos 2012] [Marilleau 2006], il est considéré comme un simulateur participatif dans le scénario où il y a la participation de deux aménageurs, chacun avec des objectifs différents. Néanmoins, ce simulateur va être considéré collaboratif, s'ils ajoutent l'objectif commun de trouver un meilleur politique pour la ville étudiée.

1.3.3 Collaborer dans un projet de simulation

Un projet de simulation est un travail d'équipe plutôt que une tâche réalisée par un seul scientifique isolé [Korichi 2008]. Comme nous l'avons vue dans la section 1.2.3 page 15, la collaboration est hautement requise dans la simulation de systèmes complexes. En outre, l'équipe
d'un projet de simulation est composé de plusieurs champs disciplinaires (multidisciplinaire ou interdisciplinaire). Il est souvent composé de modélisateurs (mathématiciens ou informaticiens) associés à des experts provenant de divers domaines de recherche. Cette diversité est la raison de nombreux problèmes de simulation. Dans ce contexte, une plate-forme collaborative peut rendre de nombreux services et jouer un rôle important pour le succès d'un tel projet : "*Des outils collaboratifs sont essentiels pour la transformation des simulations aux modalités vraies de recherche*" [Berman 2003].

## a) Le processus de modélisation et simulation

Un projet de modélisation et simulation passe souvent par un certain nombre d'étapes itératives entre modélisateurs et des experts du domaine [Robinson 2003]. Dans la littérature, nous remarquons quelques travaux qui ont essayé de les définir, par exemple : le processus de Fishwick [Fishwick 1995, Fishwick 1995], Gilbert et Troitzsch [Gilbert 1993, Gilbert 1999], Drogoul [Drogoul 2003], Marilleau [Marilleau 2006] et [Amouroux 2011].

En analysant les travaux existants, le processus de modélisation et simulation peut-être résumé par cinq étapes suivantes (voir la figure 1.5) : *Modèle du domaine, Conception, Modèle computationel, Simulation et Analyse*.

Premièrement, le système ou le problème étudié est décrit globalement à l'étape *Modèle du domaine*. Le résultat de cette étape est un modèle du domaine qui est sous forme de langage naturel ou des règles [Marilleau 2006] ou dans formalisme des experts [Amouroux 2011], par exemple le protocole ODD [Grimm 2006, Grimm 2010].

A partir du modèle de domaine, les modélisateurs créent un modèle conceptuel pour former une description du modèle qui va être développé. Il s'agit d'un intermédiaire entre le modèle du domaine et le modèle computationel. La compilation des données et leur analyse s'inscrit également dans cette étape [Amouroux 2011]. De plus, les données détaillées nécessaires au développement du modèle computationel sont identifiées par le modèle conceptuel. A la fin de cette étape, un modèle sera présenté avec les spécifications des entrées et sorties.

Lors de l'étape de création du modèle *Computationel*, le modèle conceptuel est traduit en un modèle exécutable autrement dit un simulateur. Ce dernier est ensuite testé pour déterminer s'il reproduit bien le système étudié.

<figure><img src="image_8.png" /><figcaption>**FIGURE 1.5 – Processus simple de modélisation et simulation** [Drogoul 2003, Marilleau 2006]</figcaption></figure>

Après avoir implémenté, les simulations sont effectuées avec le simulateur afin d'obtenir une meilleure compréhension du système complexe étudié et produire de nouveaux résultats intéressants. En général, la simulation se fait par la réalisation d'une succession de scénarios "*What-if*" [Robinson 2003]. Ils changent d'entrées du modèle, exécutent le modèle, analysent les résultats, comprennent des résultats, font des modifications aux entrées et ainsi de suite. Les
sorties de cette étape sont les solutions et/ou la compréhension du problème.

La validation doit être effectuée à tous les stades du projet de simulation afin de s'assurer
que les différents modèles utilisés ne s'écartent pas du système complexe étudié.

b) Les rôles différents dans un projet de modélisation-simulation

L'expérimentation par la simulation est une tâche scientifique orientée "but". Ce travail doit être accomplie de manière collaborative parce que les modélisateurs ont l'expertise du modèle tandis que les experts ont l'expertise du système complexe étudié.

Dans la simulation participative, les utilisateurs sont les acteurs de la simulation. Ils font partie de l'expérimentation en participant aux jeux de rôles avec d'autre participants, ainsi que des agents artificiels. Tandis que, dans la simulation collaborative, il font partie de la simulation. Dans les deux modes, chaque participant a une expertise personnelle du système réel qui est simulé. Il/elle est assigné également un droit concret qui correspond avec sa permission. Ensembles, ils modifient l'évolution de simulation en fonction de leurs opinions et leurs droits pour atteindre leurs objectifs personnels.

Ainsi, soit dans un contexte d'expérimentation ou soit dans une simulation participative,
les différents rôles des utilisateurs peuvent être identifiés. Dans ce contexte, un rôle détermine
plusieurs tâches réalisées pour atteindre un objectif [Taylor 2001].

Avant d'identifier les rôles d'un projet de modélisation-simulation, analysons ceux en présence dans la recherche appliquée. Oremod et al. dans [Ormerod 2001] a identifié les rôles que nous illustrerons avec l'exemple du projet MIRO [Arnaud 2005, Marilleau 2006] présenté dans la section 1.2.3 page 15 :

- *Doers* : Les intervenants, comme les modélisateurs et les géographes.

- *Done for*: Les clients, comme les aménageurs, les personnes qui sont responsables d'organiser la ville.

- *Done with* : Les membres du projet, comme les experts de langage NetLogo.

- Done to : personnes interviewés, comme les citadins de Dijon qui sont interviewée pour la donnée.

- *Done without* : les membres de l'organisation et la société qui ne sont pas impliqués dans le projet, mais en sont affectés, par exemple, le citadin d'une ville qui bénéficie du résultat du projet.

Ces mêmes rôles sont transcrits, pour le contexte de la modélisation-simulation des systèmes complexes, par le tableau 1.2 issue de [Robinson 2003]. En effet, une personne peut prendre un ou plusieurs rôles. Un rôle peut être attribué à une ou plusieurs personne(s). Un *modélisateur* prend souvent les rôles de *chef de projet*, et *d'utilisateur du modèle* car il participe à la l'ensemble du processus de modélisation-simulation. Les thématiciens sont quant à eux des *experts*, des fournisseurs de données expérimentales et de concepts et des *utilisateurs*.

Le *thématicien*, *utilisateur du modèle* apparaît deux fois dans le tableau, sous le rôle *Doer* et *Done for*. Au début du projet, ils sont clients, le modèle est conçu pour leur utilisation. Ainsi, il s'occupe le rôle *Done for*. Lors que la conception est fini, ils expérimentent avec le modèle comme un *Doer*.

Selon Robinson [Robinson 2003], les trois premières catégories du tableau 1.2 regroupent le
noyau principal de l'équipe d'un projet de modélisation-simulation. Ils ont un impact direct sur
<table><caption>TABLE 1.2 – Taxonomie des participants en fonction des rôles identifiés dans [Ormerod 2001, Robinson 2003]</caption><thead><tr><th>Recherche Opérationnelle</th><th>Projet de simulation</th><th>Signification</th></tr></thead><tbody><tr><td rowspan="3">Doer</td><td>Chef de projet</td><td>Responsable de la gestion du projet</td></tr><tr><td>Modélisateur</td><td>Développe le modèle (conceptuel et informatique)</td></tr><tr><td>Thématicien, Utilisateur du modèle</td><td>Expérimenter pour obtenir la connaissance et pour chercher la solution du problème étudié</td></tr><tr><td rowspan="2">Done for</td><td>Client</td><td>Le problème propriétaire et recevoir des résultats; fonds direct ou indirect pour des travaux</td></tr><tr><td>Thématicien, Utilisateur du modèle</td><td>Recevoir le modèle</td></tr><tr><td rowspan="2">Done with</td><td>Fournisseurs de donné</td><td>Experts qui sont capable de fournir des données et de l'information pour le projet</td></tr><tr><td>Supporteur de modélisation</td><td>Un expert tiers (fournisseur de logiciels, de consultant ou de d'experts) fournit des logiciels et/ou des compétences de modélisation</td></tr><tr><td>Done to</td><td>Les personnes interrogées pour l'information</td><td>Un large groupe de personnes par lequel l'information est obtenu</td></tr><tr><td>Done without</td><td>Administrateur, clients</td><td>Les bénéficiaires du projet, qui n'y anticipent pas. Dans certains cas, ils ne sont pas au courant du projet</td></tr></tbody></table>

le projet. Tandis que les autres ont moins d'impact.

Le *Done to* caractérise un ensemble de personnes enquêtées afin d'obtenir les informations suffisantes pour modéliser un système. Néanmoins, ces personnes ne participent pas directement au projet de modélisation-simulation.

Les *Done without* ont bénéficié du résultat du projet, mais ils ne savent souvent pas l'existence du projet. Ce sont par exemple les citadins de la ville où est appliqué la politique optimale de transport tiré du résultat du projet MIRO. Ils ne connaissent pas ce projet, mais ils en profitent.
En résumé, il existe un ensemble de rôles différents dans un processus de modélisation-simulation. Chacun a une expertise personnelle et un droit spécifique qui correspond avec son objectif. Souvent, aucune personne ne peut suffisamment maîtriser ce processus tout seul. Pour cela, il faut combiner la connaissance de tous ces rôles. Par conséquent, la communication, la coordination et la collaboration entre eux est indispensable. Dans la section suivante nous allons analyser plus en détail cet aspect.

c) La collaboration dans le processus de simulation

Dans un projet de simulation, les modélisateurs sont des experts du modèle, ils construisent des modèles, mais peut ne connaissent pas les métiers. Le récepteur du modèle a une connaissance détaillée de certains processus, mais ne pas avoir une vue globale sur l'organisation. Le chef du projet manque de connaissances détaillées sur les processus, mais dispose d'une vision globale sur l'organisation

Pour partager leurs connaissances, ils doivent collaborer ensemble. L'exigence de collaboration apparaît parfois dans toutes les étapes d'un projet de modélisation et de simulation.

Au début d'un projet de modélisation-simulation, lors de la première étape, des réunions de lancement du projet sont souvent menées. Elles font, le plus souvent, intervenir le chef du projet, les concepteurs, et les experts du domaine pour déterminer les contours du problème à étudier, ou bien le modèle du domaine. Dans ce contexte, une *Collaboration face-à-face* ou une *Collaboration distante synchrone* s'avère la plus efficace.

La *Conception* est l'étape la plus importante dans un projet de modélisation-simulation. Cette étape conditionne les résultats qui seront obtenus lors de l'expérimentation. Selon [Robinson 2006] un des facteurs importants pour la modélisation d'un système complexe se situe dans l'échange entre le thématicien et le modélisateur. Seul le thématicien connaît en profondeur le système étudié. Les modélisateurs sont, la plupart du temps, interdisciplinaires si bien qu'ils ont ni l'expérience ni les connaissances d'un thématicien dans une thématique de recherche précise (à l'exception du domaine de la modélisation).

Il est donc nécessaire de maintenir une communication, une interaction constante entre le thématicien et le modélisateur. Le concepteur donc doit communiquer régulièrement avec l'utilisateur, l'expert et les connaisseurs. Lors de cette étape, les quatre méthodes collaboratives s'appliquent à savoir : (i) la collaboration face-à-face ; (ii) la collaboration asynchrone ; (iii) la collaboration distante synchrone ; et (iv) la collaboration distance asynchrone.

L'étape de modélisation computanionelle autrement dit de création du simulateur nécessite des échanges moins soutenus entre les participants. Des approches de collaboration asynchrone sont suffisantes. Car à cette étape, les développeurs ont une connaissance sur le modèle, ils peuvent effectuer leurs travaux de façon autonome.

Après la phase d'implémentation, le simulateur est testé et calibré. Pour cela, le concours des thématiciens est primordial.

Enfin, lors de l'étape d'analyse des résultats, le simulateur est paramétré avec des données expérimentales pour essayer de découvrir une solution pour le problème étudié. A cette étape, le simulateur est exécuté plusieurs fois en changeant les paramètres d'entrée, et une analyse des résultats est faite en sortie, comme illustré dans la figure 1.6. Souvent, les thématiciens vont apporter des données de terrain, et analyser des résultats, tandis que le modélisateur
<figure><img src="image_9.png" /><figcaption>FIGURE 1.6 – Simulation et analyse des résultats</figcaption></figure>

va s'assurer du bon fonctionnement du simulateur par une analyse du résultat et va calibrer le modèle. Ils travaillent collaborativement afin de déterminer les paramètres d'entrée et d'identifier d'éventuels bogues.

À cette étape, à cause de la différence entre l'expérience et l'objectif, chaque participant peut posséder des besoins différents. Par exemple, pour l'étude de la pollution de l'air, Xu *et al.* [Xu 2011] a présenté un scénario collaboratif qui est effectué par trois thématiciens : un géographe, un scientifique de l'environnement et un informaticien. Lors de la simulation, le scientifique préfère une interface 2D, le géographe choisi une carte 2D qui permet de l'interaction, tandis que l'informaticien qui a moins d'expérience concernant la pollution de l'air, préfère l'interface 3D. Par conséquent, pour un bonne collaboration, le simulateur doit être capable de s'adapter à ces besoins différents. Les simulateurs actuels, le plus souvent *stand-alone*, ne permettent pas la gestion de telles interfaces individualisées.

Pour résumer la discussion ci-dessus, nous utilisons le diagramme de Taylor dans [Taylor 2003] qui présente le niveau de la communication, de la coordination et de la collaboration entre les participants à un projet de simulation (voir la figure 1.7). La quantité d'échange aux deux étapes du modèle du domaine et modèle conceptuel est plus élevé que l'autre. À l'étape du modèle computationel, les échanges sont réduits. Enfin, ils sont peu nombreux à l'étape de la simulation et analyse les résultats.
<figure><img src="image_10.png" /><figcaption>FIGURE 1.7 – Fréquence d’échange dans un projet de simulation [Taylor 2003]</figcaption></figure>

## 1.4 Conclusion

Les sciences de la complexité s'avèrent être d'importance pour la compréhension et l'anticipation de phénomènes réels tel que le changement climatique, l'évolution des populations, des écosystèmes...

Afin d'apporter des réponses à ces problématiques, de nombreux travaux ont été menés ces dernières années. Ils se sont concrétisés par la création de modèles et de simulateurs. Au delà de ces recherches appliquées à un des phénomènes d'actualité, une réflexion en amont s'intéresse aux principes et techniques de modélisation-simulation des systèmes complexes. Elles apportent toutes leurs lots de concepts, de méthodes et d'outils en vue de faciliter le processus de modélisation-simulation. Malgré la pléthore de propositions qui vont dans ce sens, nous constatons que peu d'entre elles introduisent la collaboration au sein du processus de modélisation-simulation des systèmes complexes.

Comme nous l'avons vu au cours de ce chapitre, la collaboration est le phénomène indispensable à la bonne réalisation d'une activité de recherche. Toutefois, elle est souvent difficile à mettre en place car les répartitions géographiques des chercheurs et leur calendrier ne facilitent pas l'échange : les acteurs de la recherche travaillent souvent dans des instituts, des villes ou des pays différents et ont des disponibilités très limitées. Dans ce contexte, l'organisation de rencontres face-à-face qui sont pourtant un des moyens les plus efficaces pour travailler ne peuvent pas être organisés régulièrement.

L'étude des systèmes complexes est une activité scientifique où la collaboration et la pluridisciplinarité est de premier ordre : elle demande la participation de chercheurs, d'experts provenant d'horizons scientifiques et géographiques divers et variés. Compte tenu de la diversité disciplinaire omniprésente dans les sciences de la complexité, la simulation et la compréhension d'un phénomène complexe ne peut se réaliser sans une confrontation des connaissances et des
points de vue. Des échanges réguliers sont donc nécessaire pour atténuer tout malentendu causé
par un vocabulaire et une compréhension propre à chaque discipline.

L'objectif de cette thèse est justement de combler ce manque en introduisant la collaboration
au cœur du processus de modélisation-simulation des systèmes complexes. Compte tenu de l'am-
pleur de ce travail et des nombreuses questions scientifiques en suspend, nous nous intéressons,
plus particulièrement, au processus de collaboration durant la phase de simulation.

Comme nous avons présenté, la simulation est l'activité dans laquelle on utilise un simulateur pour faire évoluer les entrées, l'exécuter et analyser le résultat. Ainsi, la collaboration qui nous intéresse passe principalement autour de ce dispositif informatique. Dans le chapitre suivant, nous allons détailler cette collaboration.
# Collaboration autour d'un simulateur

## Sommaire

<table><tr><td>2.1</td><td>Exemple du projet d'épidémiologie GAMAVI</td><td>29</td></tr><tr><td>2.1.1</td><td>Le simulateur GAMAVI</td><td>30</td></tr><tr><td>2.1.2</td><td>Intervenants et collaboration autour du simulateur GAMAVI</td><td>32</td></tr><tr><td>2.1.3</td><td>Synthèse</td><td>33</td></tr><tr><td>2.2</td><td>Usage de la simulation dans un contexte de groupe</td><td>33</td></tr><tr><td>2.2.1</td><td>Asynchronisme des échanges entre intervenants</td><td>34</td></tr><tr><td>2.2.2</td><td>Le manque d'outils appropriés</td><td>36</td></tr><tr><td>2.2.3</td><td>Synthèse</td><td>38</td></tr><tr><td>2.3</td><td>Méthodes et outils pour collaborer lors d'une simulation</td><td>39</td></tr><tr><td>2.3.1</td><td>Modèles de collaboration</td><td>39</td></tr><tr><td>2.3.2</td><td>Moyens informatiques de collaboration</td><td>41</td></tr><tr><td>2.3.3</td><td>Synthèse</td><td>46</td></tr><tr><td>2.4</td><td>Conclusion</td><td>47</td></tr></table>

Actuellement, dans la simulation des systèmes complexes, le simulateur est considéré non seulement comme un outil d'exploitation des phénomènes dynamiques, mais aussi comme un moyen d'échange entre les participants. Cet échange permet d'une part de définir les paramètres, les scénarios et d'autre part, d'analyser les résultats de la simulation. La collaboration à cette phase se passe principalement autour d'un simulateur.

Cependant, nous constatons que peu de travaux abordent cet aspect. Pleins de questions sont posées dans la littérature, comme comment utiliser ces simulateurs, qui l'utilise et surtout comment collabore-t-on autour d'un simulateur ?

L'objectif de ce chapitre est de répondre à ces questions en analysant la collaboration autour d'un simulateur. Dans un premier temps, nous prenons un cas concret avec le projet GAMAVI [Amouroux 2011]. La collaboration, les problèmes et notre proposition dans cet exemple seront abordées pour que le lecteur ait facilement un point de vue concernant l'objectif de ce chapitre. Ensuite, nous allons résumer les problèmes de collaboration dans uns sens plus large. Enfin, notre proposition va être introduite.

## 2.1 Exemple du projet d'épidémiologie GAMAVI

Dans le domaine des systèmes complexes, de nombreux simulateurs sont apparus. Le projet et simulateur GAMAVI est un exemple parmi tant d'autres. Néanmoins, il présente l'intérêt de
faire intervenir sur un sujet d'actualité des chercheurs du CIRAD - La recherche agronomique pour le développement - France, de l'Institut Vétérinaire de Hanoi-Vietnam, des membres du Comité Populaire de Hanoi-Vietnam, et L'équipe Modélisation et Simulation Informatique des systèmes complexes MSI, IFI, UMMISCO.

L'objectif de ce projet est d'étudier les mécanismes de la propagation locale et de la persistance du virus H5N1, dans le contexte des secteurs traditionnels et semi-industrialisés du Vietnam du Nord. Précisément, ce travail s'intéresse aux relations entre environnements (comme réservoirs de virus) et le système de production de volailles traditionnel/semi-commerciale.

Ce projet vise à répondre aux deux questions suivantes :

1. Mécanismes de propagation : comment le virus se propagent localement (par les oiseaux à oiseaux, les humains et l'environnement tel que les fermes, marchés, etc.)

2. Mécanismes de persistance : comment le virus peut re-émerger dans une région précédemment infectée, parfois plusieurs mois après la fin de la vague pandémique.

Au cours de cette section, nous allons étudier la collaboration autour d'un simulateur sous le couvert d'un exemple. Ainsi dans ce chapitre, nous allons présenter le simulateur GAMAVI. Ensuite, nous allons détailler comment la collaboration s'est mise en place autour de ce simulateur. Enfin, une proposition pour renforcer cette collaboration est abordée.

## 2.1.1 Le simulateur GAMAVI

Les processus à l'échelle locale de propagation, persistance, et re-émergence sont un sujet difficile, impacté par de nombreux acteurs (domestiques ou non, l'environnement, l'activité humaine, etc ...). Cependant, les données pour les étudier sont insuffisantes en terme d'exhaustivité et de fiabilité. Dans ce contexte, modélisateurs et thématiciens se rassemble en vue de proposer de nouveaux moyens de production de données. Ils se concentrent notamment sur la modélisation informatique, moyen permettant de produire des données intéressantes qui ne peuvent parfois être obtenues.

Pour bien étudier ces questions par la simulation informatique, les épidémiologistes ont planifié quelques exigences pour un tel outil idéal :

1. L'environnement doit être largement représenté simultanément avec sa propre dynamique. Cette représentation doit aussi permettre l'utilisation de descriptions diverses et hétérogènes (géographiques, sociales, écologiques, etc.)

2. Les épidémiologistes ont besoin de la capacité de travailler à la fois au niveau de la population et directement sur les modèles d'individus.

3. Les interactions aux niveaux de la population ou individuel, mais aussi avec l'environnement, doivent être modélisés explicitement, car un changement dans ces interactions peuvent avoir un impact sur la dynamique de l'épidémie.

4. Ces données sont généralement exprimées en utilisant des formalismes hétérogènes que l'expert doit être capable de réutiliser dans la modélisation du système.

5. La plate-forme de simulation devrait être capable de recréer un environnement dans lequel des "expériences virtuelles" pourraient être exécutées (exploration de paramètres, etc).

Une solution générique et pragmatique est réalisée pour répondre à ce problème. Générique dans le sens où on a défini et implémenté un méta-modèle qui permet de répondre à ces différents
besoins en réglant les relations entre agents et environnement(s) dans le cadre d'une plateforme de simulation ; pragmatique dans le sens où on a instancié, à partir de ce méta-modèle, des architectures prototypiques d'environnement qui couvrent la majorité des besoins existants en modélisation.

La conception du modèle GAMAVI suit le processus de modélisation KINOMO [Amouroux 2011] introduit par Edouard Amouroux. Le système de référence a été défini de manière informelle après avoir établi la question de recherche. Cette description a été détaillée dans un modèle du domaine constitué d'une ontologie, une clarification textuelle et par des sous-modèles exprimées dans le formalisme des experts du domaine. Après cela, le cycle de modélisation effectue une séquence de conception, de formalisation et d'implémentation en suivant un processus itératif (à raffinement successifs). Enfin, le modèle est programmé dans un simulateur, et délivré aux thématiciens comme un outil prêt-à-l'emploi. Le simulateur Gamavi a été développé en GAML, un langage orienté thématicien, et exécuté sur la plateforme de simulation GAMA [Amouroux 2007, Taillandier 2012a, Taillandier 2012b]. La figure 2.1 présente une visualisation de l'exécution du simulateur avec quatre panneaux principaux : paramètre, moniteur, inspecteur, graphe et visualisation.

<figure><img src="image_11.png" /><figcaption>FIGURE 2.1 – Simulateur Gamavi [Amouroux 2011]</figcaption></figure>

Le panneau de paramètres permet aux thématiciens de modifier un paramètre avant de lancer une simulation. Le panneau de contrôle contient la valeur de variables globales à chaque pas de temps. Le panneau graphique montre l'évolution des variables globales, par exemple le nombre de troupeaux particulièrement sensibles, l'infection individuelle. Le panneau de visualisation affiche la dynamique spatiale des différentes entités : rouge représente le virus dans l'environnement, vert clair des champs de riz, verts sombre pour les élevages de canards, des étangs en bleu, brun sombre pour l'intérieur du village, brunes claires pour la fermes brunes.
2.1.2 Intervenants et collaboration autour du simulateur GAMAVI

GAMAVI est un sous-projet du projet Gripavi du CIRAD qui vise à étudier la dynamique écologique de la maladie de la grippe aviaire, évaluer le risque de propagation et améliorer les connaissances concernant l'épidémie.

Il est créé par Dr Desvaux qui est la coordinatrice du projet Gripavi au Vietnam. C'est un expert en épidémiologie. Dans le projet GAMAVI, elle prend des rôles différents par rapport à ceux proposés par Robinson [Robinson 2003] et Ormerod [Ormerod 2001] dans la section 1.3.3 page 23. Par exemple, elle est considéré comme le **chef du projet** mais également **expert du domaine, utilisatrice du modèle, fournisseur de données et cliente**. Parce qu'elle est l'initiateur du modèle, c'est elle qui a le plus de connaissance sur le problème, et enfin le simulateur conçu est utilisé par elle.

Dans ce projet, d'autres **thématiciens** ont participé dont un épidémiologiste du laboratoire TIMC-IMAG<fnref n="1" /> qui travaille sur la persistance du virus dans l'environnement, deux doctorants en épidémiologie qui étudie le système commercial et plusieurs vétérinaires (virologistes) provenant de l'Institut Vétérinaire de Hanoi Vietnam.

Le **modélisateur** principal est un doctorant en informatique du laboratoire Modélisation et Simulation Informatique de systèmes complexes MSI, IFI, UMMISCO. Le travail de ce **modélisateur** est supporté par un expert informatique de ce même laboratoire. Ce dernier prend également le rôle de **modélisateur**, parce qu'il est un des auteurs du langage GAMA.

L'étude épidémiologique concernant la grippe aviaire implique des interactions entre les populations de virus, d'hôtes et d'espèces sensibles ou réservoirs (oiseaux sauvages et domestiques, voire mammifères) et leur dynamique à différentes échelles : regroupements et migrations d'oiseaux sauvages, systèmes d'élevage, circuits de commercialisation. Par conséquent, les thématiciens possibles du simulateur GAMAVI sont des **épidémiologistes**, des **virologistes**, des **écologistes**, des **économistes**.

L'épidémiologiste est le thématicien principal du projet GAMAVI. Cependant, il doit collaborer avec d'autre thématiciens pour bien étudier le problème. Il collabore avec une écologiste qui est nécessaire pour des connaissances concernant l'écologie de l'influenza aviaire (émergence, dissémination, endémisme). Pour bien comprendre l'interaction entre communautés d'oiseaux sauvages et populations de virus, l'interaction virus - environnement et l'interaction entre populations d'animaux domestiques et populations de virus, l'épidémiologiste doit également collaborer avec des virologistes. Les connaissances de l'économiste sont aussi nécessaires. Parce qu'un des objectifs de GAMAVI est de rassembler les données des activités de recherche et d'expérimentation dans le but d'améliorer le coût-efficacité de la surveillance et du contrôle. Par conséquent, les implications économiques, l'impact socio-économique de l'IA, les coûts-efficacités ou coûts-bénéfices des mesures de contrôle sont étudiés par ce projet.

En se basant sur le travail de ces thématiciens, l'informaticien a extrait les paramètres du simulateur en trois groupes principaux. Le premier groupe contient des paramètres qui sont concernés par la configuration générique de l'environnement, comme la durée du jour et du soir, ou la distance maximale de ferme à rizière. Le deuxième groupe est les paramètres qui définissent la population du troupeau : le nombre de canards libres, le nombre d'étang peuplés par les canards, le nombre d'arrières-cours. Le dernier groupe compose des paramètres concer-

<footnote n="1">1. http://www-timc.imag.fr</footnote>
nant l'infection : la durée de l'infection, le nombre d'infections initial, la durée de l'infection dans l'eau, dans le riz et la probabilité de l'infection. Ces sont des paramètres orientés thématiciens : seulement ces thématiciens peuvent bien les comprendre et les configurer. Ainsi, ils doivent participer à la simulation pour bien manipuler ces paramètres.

Mais, en réalité, ces thématiciens n'ont pas été impliqués dans la simulation. Ils ont définis les scénarios ensemble. Ensuite, le modélisateur informaticien a réalisé tout seul bien qu'il n'ait pas de compétences dans le domaine. Une meilleure participation des thématiciens au projet aurait été un avantage.

En résumé, la collaboration entre les intervenants ci-dessus est claire et semble indispensable. Cependant, seulement une personne a réellement manipulé le simulateur : le modélisateur. Les thématiciens établissent les scénarios, et les transmettent ensuite au modélisateur qui occupe également le rôle d'informaticien. Cette personne réalise les scénarios tout seul. Par conséquent, la collaboration autour du simulateur pourrait être véritablement optimisée. Cette optimisation passe par la mise en place de moyens adaptés.

### 2.1.3 Synthèse

Bien que le collaboration autour d'un simulateur soit nécessaire, l'expérience montre qu'elle est très difficile à mettre en place. En fait, dans la plupart du temps, cette collaboration revient à mettre place des scénarios qui seront joués par simulation grâce à la manipulation, en autonomie, de l'informaticien. Ce dernier redonne ensuite les résultats de la simulation aux thématiciens qui tentent de les exploiter. Ces problèmes d'échange peuvent-être résolus par des collaborations synchrones à distance avec les moyens adaptés.

D'autre part, l'exemple de Gamavi montre que les solutions proposées par Ormerod [Ormerod 2001] et Robinson [Robinson 2003] ne s'adapte pas très bien au contexte de la modélisation et simulation. Les rôles sont très génériques et ils amènent à des ambiguïtés. Nous devons donc proposer une nomenclature qui est propre à chaque simulateur et jeux sérieux collaboratifs à mettre en place. La collaboration autour d'un simulateur passe principalement avec cette nomenclature.

## 2.2 Usage de la simulation dans un contexte de groupe

Selon Fishwick [Fishwick 1995, Fishwick 1997], les chercheurs s'intéressent plus à la modélisation qu'à la simulation et à l'analyse des résultats. Ces derniers sont considérés comme un travail moins scientifique, plus facilement traitable par des techniques spécialisées (l'exécution du programme et l'analyse les résultats peuvent être automatisés dans des cas particuliers).

Cependant, compte tenu de la complexité croissante des systèmes étudiés, la simulation et l'analyse les résultats sont devenus des tâches de plus en plus difficiles. Les systèmes et le travail des chercheurs sont de plus en plus distribués. Les institutions s'appuie sur des moyens humains géographiquement dispersés si bien que les outils de collaboration deviennent de plus en plus une nécessité.

Par l'intermédiaire du projet GAMAVI dans la section 2.1 page 29, nous constatons que la collaboration autour du simulateur actuel n'est pas optimale. Dans la plupart des cas, l'informaticien gère individuellement presque l'intégralité de la simulation. Plusieurs raisons sont
identifiées, mais en général elles sont réparties en deux catégories principales : (i) l'asynchronisme entre des intervenants ; et (ii) le manque de fonctionnalités collaboratives appropriées. Elles fournissent d'une part des échanges inefficaces, et d'autre part essouffle la collaboration entre le thématicien, le modélisateur et l'informaticien. C'est pourquoi, il y a souvent seulement l'informaticien qui réalise l'intégralité du travail de modélisation et simulation. Au cours de cette partie, nous allons présenter ces difficultés.

## 2.2.1 Asynchronisme des échanges entre intervenants

Dans la recherche mono-disciplinaire seuls importent le résultat et la méthode utilisée, c'est-à-dire l'énoncé de la méthode qui permettra à n'importe quel autre chercheur confronté à la même question d'aboutir à la même solution [Quensière 1997]. La personnalité de l'auteur, ses qualités humaines ou scientifiques, ses ambitions personnelles ainsi que les tracas que lui font subir ses collègues ne présentent aucun intérêt pour ses lecteurs et sont donc ignorés. Dans le cas d'une recherche pluridisciplinaire, les propositions s'inversent : le fruit de la recherche est moins important que la recherche elle-même. Non pas que le résultat des recherches soit devenu insignifiants, mais parce qu'il n'est plus jugé contrôlable par le premier venu. Seules des équipes de composition comparable, ayant suivi le même parcours, ayant franchi les mêmes étapes, ayant partagé les mêmes ambitions, peuvent prétendre appliquer la même méthode pour atteindre la même solution.

Une simulation de systèmes complexes faisant intervenir plusieurs disciplines (inter et pluridisciplinaire) exige la participation de thématiciens différents dans un même processus. Elle suppose un dialogue et un échange de connaissances, d'analyses, de méthodes entre deux ou plusieurs disciplines. Elle implique qu'il y ait des interactions et un enrichissement mutuel entre plusieurs experts (dans ce cas l'interdisciplinarité). Cependant, chaque discipline propose souvent des objets qui sont des boites noires pour les autres. Les uns comme les autres sont attachés à leur culture scientifique, comme la notion de virus pour les économistes, le terme coût-efficacité et coût-bénéfice pour les écologistes dans le projet GAMAVI. C'est la racine des difficultés dans la collaboration entre eux. Cette caractéristique cause le phénomène asynchrone dans le processus collaboratif.

Citons ici l'exemple du projet MIRO [Arnaud 2005, Marilleau 2006] de modélisation et simulation intra-urbaine des rythmes quotidiens (voir l'exemple de la section 1.2.3 page 15). La spécificité de MIRO réside dans l'importance accordée, au-delà des caractéristiques d'ordre socio-démographique, aux activités quotidiennes individuelles. C'est une branche de la démographie qui étudie avec une attention particulière les causes et les implications sociétales des dynamiques de population. Elle tend à emprunter ses concepts et ses méthodes à la sociologie, et notamment à la sociologie des rapports sociaux, des générations. Par conséquent, ce projet demande la participation à la fois des géographes et des sociologue. Ce projet s'intéresse également à la distribution des services et au calendrier tel que les restaurants, les résidences ou les bureaux. Cela exige la participation des économistes. De plus, il a besoin de l'aide des statisticiens et des informaticiens dans le traitement des données et la construction des produits informatiques.

Souvent, les différentes disciplines ont des façons différentes pour expliquer un mot, une notion, ou même une hypothèse. Cela peut causer la divergence de la compréhension. Selon Glisse [Glisse 2007], cette différence peut apparaître dans trois cas de figures :
- ce qui est propre au domaine : Il existe plusieurs mots, notions et hypothèses propres à un domaine qui sont inconnues pour des personnes d'autre domaines. Cela introduit une incohérence dans la communication entre les thématiciens.

- ce qui est spécifique mais existe dans tous les domaines concernés. Cela entraîne la confusion entre des thématiciens.

- ce qui est commun, mais au sein d'un contexte qui décrit les processus spécifiques à un domaine. C'est aussi une source d'incompréhension.

Ces faux amis conduisent à l'asynchronisme dans la compréhension entre les thématiciens. Par exemple, dans l'usage du simulateur MIRO, on a souvent utilisé le terme *mobilité* avec une interprétation différente de celle communément utilisée : la mobilité en géographie qui implique un changement de lieu, ou bien, des déplacement réels d'une position à une autre sur un territoire réel défini. Tandis que, Marilleau [Marilleau 2006] a abordé la mobilité qui recense et quantifie l'ensemble des évolutions qui s'opèrent sur un environnement dans le temps [Marilleau 2006].

Un autre problème est l'asynchronisme dans les méthodes utilisées. Plusieurs méthodes pour étudier les systèmes complexes sont proposées dans la littératures, par exemple les équations différentielles partielles, les automates cellulaires, les réseaux d'automates ou l'approche à base d'agents. Un thématicien maîtrise souvent seulement quelques méthodes adaptées à sa discipline. Cependant, pour analyser la sortie d'une simulation d'un système complexe, les thématiciens doivent quelques fois invoquer des méthodes d'autres disciplines. Ainsi, ce sera difficile, si on ne les comprend pas, par exemple pour l'explication du comportement productif d'une communauté, un sociologue doit utiliser des outils d'économistes (par exemple l'analyse coût-bénéfice), pour étudier le déclin de la fertilité, un agronome doit appliquer des moyens statistiques ou de données chimiques ou pour expliquer des choix économiques des personnes, un économiste doit avoir recours à la psychologie ...

Une des raisons d'asynchronisme des méthodes utilisées est l'étude d'objets différents dans l'utilisation du simulateur. A côté des objectifs communs, dans une simulation d'un système complexe, les thématiciens ont également des problèmes, questions et objectifs scientifiques propres qui appartient seulement à leur discipline. Par conséquent, les disciplines sont en opposition du fait que prises individuellement elles ne poursuivent pas les mêmes objectifs [Glisse 2007]. Chaque objectif est déroulé avec des connaissances, des ontologies et des processus spécifiques. C'est aussi à cause des méthodologie et d'outils de travail différents.

De plus, en se basant sur leur objectif, les thématiciens ont des rôles différents dans une simulation collaborative. A cause de leur distribution géographique, ces simulations sont souvent réalisées à distance. La répartition des rôles est donc une tâche très importante. Qui va s'occuper de quoi, comment les missions sont assurées d'être réalisées par les rôles correspondant, et qui peut aider à expliquer et à élucider un problème dans une discipline spécifique ... Comment on peut coordonner pour que le rôle réalise bien sa mission. Si cette répartition n'est pas bien soignée (c'est une tâche difficile), elle va causer aussi l'asynchronisation entre les thématiciens.

La conséquence de toutes ces différences est que l'on doit intégrer des sources non linéaires et incompatibles en un unique processus. En effet, expliciter un objet complexe pour répondre à une question précise le concernant ne peut se résumer à juxtaposer des discours disciplinaires. Il s'agit d'articuler ces discours, de dépasser leurs oppositions, pour aboutir à un schéma interprétatif cohérent.

Mais comment articuler des connaissances de nature très différentes (sociales, économiques,
biologiques), formalisées de façons également très différentes (données chiffrées, modèles mathématiques, représentations spatialisées, règles ou descriptions) ? Comment hiérarchiser l'influence des mécanismes qui ont été mis en évidence ? Comment s'assurer que les solutions proposées ne soient pas de simples artefacts générés par l'équipe, mais correspondent effectivement à une représentation de la réalité qui l'explicite et donne prise sur elle ? Même sur la base d'une bonne définition de l'objet d'étude, l'expérience montre que cet exercice peut revêtir une extrême complexité, non pas du fait d'une éventuelle mauvaise volonté des chercheurs, mais du fait du manque d'outils disponibles [Quensière 1997].

Si les thématiciens utilisent le simulateur séparément, ce problème n'apparait jamais, cependant le système complexe ne sera pas bien étudié. Il faut combiner plusieurs disciplines pour que l'on puisse comprendre et anticiper le système.

Selon Ryan [Ryan 2007], pour résoudre ce problème, il faut répondre à deux exigences. Tout d'abord, les hypothèses d'un modèle doivent être considérées, y compris les hypothèses implicites qui découlent de son origine disciplinaire. Deuxièmement, tous les éléments concernés doivent être examinés ensemble, et toutes les incohérences doivent être explicitement abordées. Identifier des raisons pour lesquelles les incohérences entre les théories disciplinaires apparaissent et fournir des solutions potentielles peuvent être une contribution majeure d'une telle approche.

## 2.2.2 Le manque d'outils appropriés

L'interdisciplinarité (ou pluridisciplinarité) est un mode de travail qui imprègne plusieurs sphères d'activités et qui laisse dans son sillage une nomenclature abondante : collaboration, échange, dialogue, décloisonnement, croisement, métissage, hybridation, intégration, fusion... Ces mots nous sont familiers et font références à un espace commun entre les disciplines un lieu d'échange qui favoriserait l'enrichissement mutuel (dans le cas de l'interdisciplinarité), la créativité et l'innovation.

En se basant sur une recherche dans la littérature, Dusseldorp [van Dusseldorp 1998] a proposé une classification des degrés de communication et d'organisation d'un travail de groupe. Selon cette classification (voir table 2.1), nous avons trouvé qu'il y a plusieurs cas de simulation collaborative dans lesquels :

- les paradigmes sont différents, comme l'économie et l'épidémiologie dans GAMAVI, la sociologie ou l'informatique dans MIRO.

- de nombreuses disciplines sont impliquées, par exemple quatre disciplines pour GAMAVI et MIRO.

- les membres de l'équipe travaillent au sein de différentes organisations, par exemple quatre organisations ont participé dans la simulation de GAMAVI : le CIRAD (Centre de coopération Internationale en Recherche Agronomique pour le Développement), l'Institut Vétérinaire de Hanoi, Vietnam, le Comité Populaire de Hanoi, Vietnam, le laboratoire Modélisation et Simulation Informatique des systèmes complexes MSI, (IFI, UMMISCO).

- Les membres de l'équipe sont issus de différentes cultures.

Par conséquent, nous sommes dans un cas où la communication et l'échange entre des participants sont complexes.

Cette situation n'est pas spécifique à la simulation des systèmes complexes. Mais ce domaine de recherche y est particulièrement sensible. Dans ce contexte, des outils et plateformes collabo-
<table><caption>TABLE 2.1 – Typologie de la collaboration entre plusieurs disciplines [van Dusseldorp 1998]</caption><thead><tr><th></th><th>Étroite</th><th>Largement</th></tr></thead><tbody><tr><th>Types de disciplines</th><td>Paradigmes similaires<br>Méthodes similaires</td><td>Paradigmes différents<br>Méthodes différentes</td></tr><tr><th></th><td><strong>Résultats faciles à intégrer</strong></td><td><strong>Résultats difficiles à intégrer</strong></td></tr><tr><th>Nombre de disciplines</th><td>Peu de disciplines impliquées</td><td>Nombreuses disciplines impliquées</td></tr><tr><th></th><td><strong>Communication simplifiée</strong></td><td><strong>Communication complexe</strong></td></tr><tr><th>Lieu de travail des membres de l'équipe</th><td>Membres de l'équipe travaillant au sein d'une même organisation</td><td>Membres de l'équipe travaillant au sein de différentes organisations</td></tr><tr><th></th><td><strong>Communication et organisation simplifiée</strong></td><td><strong>Communication et organisation complexes</strong></td></tr><tr><th>Culture des membres de l'équipe</th><td>Membres de l'équipe partageant la même culture</td><td>Membres de l'équipe issus de différentes cultures</td></tr><tr><th></th><td><strong>Communication simplifiée</strong></td><td><strong>Communication complexe</strong></td></tr></tbody></table>

ratives occupent un rôle important dans le succès de telle simulation : "des outils collaboratifs sont critiques pour la transformation de la simulation en la modalité d'une véritable recherche" [Marilleau 2008].

Le développement des nouvelles technologies de l'information et de la communication dans les 30 dernières années apporte des solutions potentielles pour ces problèmes. Elles peuvent-être utilisées pour organiser des collaborations à distance. Bien que cette solution ne puisse pas être aussi efficace que le face-à-face, elle permet de surmonter des difficultés géographiques, et temporelles. Cependant, les solutions actuelles présentent encore des inconvénients :

- Elles se concentrent pour répondre à des problèmes génériques comme la communication, la discussion.

- Elles ne permettent pas de collaborer autour d'objets complexes, comme les modèles, les simulateurs, les résultats qui sont les objets principaux d'une simulation.

- Elles ne suivent pas un processus unifié donc quand on bascule d'un projet à un autre, on doit changer d'outils ou de plateformes. On doit apprendre à les utiliser, ce qui fait perdre du temps.

- Et la plupart des outils et plateformes collaboratives que nous avons essayé ne sont pas adaptés aux besoins des experts dans la simulation et modélisation des systèmes complexes.

Bien que certains efforts ont été faits, comme par exemple TANGOSim [Beca 1997], ou l'environnement de simulation basé sur le Web développé par Ayani et Dharma [Ayani 2001], la collaboration informatique pour la simulation n'a été que légèrement explorée. En effet les
outils collaboratifs se sont principalement concentrés sur les espaces de travail communs, la vidéoconférence etc. Nous pouvons citer par exemple NetMeeting [Taylor 2003], VNC [Lu 2005] et Agora [Allan 2007]. Ces outils ont gagné beaucoup d'attention et d'utilisation. Mais ces environnements ne satisfont pas complètement à l'épine dorsale d'une application de simulation collaborative.

Un autre problème lors de la simulation collaborative à distance, c'est l'augmentation considérable de la charge du réseau tout au long de la simulation. Puisque beaucoup d'informations doivent être mises à jour souvent, et cela peut affecter ou même empêcher la visualisation de la simulation. De nombreux environnements, tels que VNC [Lu 2005], qui utilisent des captures d'écran (envoyés via le réseau), afin de permettre aux participants d'avoir un même point de vue en un même instant. Cela alourdit le réseau et empêche souvent les images des mises à jour d'arriver avec une fréquence nécessaire pour maintenir une image mobile continue. Le fait d'utilisation d'outils inappropriés causent des grands défis. Les problèmes principaux résident dans la synchronisation des actions des participants, l'optimisation des données et le maintien de la cohérence des données.

En outre, la politique de chaque institut, organisation et pays où les thématiciens travaillent : on peut utiliser un outil collaboratif dans un pays, mais il est interdit dans un autre pays. Par exemple l'outil Skype qui est utilisé largement pour la vidéo conférence dans le monde entier, est souvent déconseillé, voire bloqué dans les universités française. Cela peut causer des problèmes des médias support appropriés à tous thématiciens.

Le manque d'outils/plateformes adapté au problème de l'asynchronisme entre les thématiciens est en train de limiter le succès de la simulation collaborative des systèmes complexes. La nécessité d'avoir une approche pour aider les thématicens à surmonter ces difficultés est apparent. Par des travaux réalisés dans le projet PAMS [Nguyen 2008b, Nguyen 2009], il nous est apparu qu'il ne faut pas développer cette approche à partir de zéro, car de nombreuses solution permettant de répondre à une parte de ces difficultés existent déjà. Dans la section suivante, nous allons analyser ces solutions.

### 2.2.3 Synthèse

Au cours de cette section, nous nous sommes interrogés sur les raisons de l'absence du thématicien qui utilise simulateur GAMAVI et plus généralement les simulateurs. Deux difficultés principales sont analysées.

La première difficulté fait suite à l'asynchronie entre des thématiciens : l'asynchronisme des connaissances, des expériences, des méthodes, des objectifs ... Ce problème cause des incohérences dans la communication, des malentendus dans une discussion et une collaboration inefficace. L'origine de ce problème est la participation de plusieurs thématiciens venant de disciplines différentes. Chaque discipline propose souvent des objets qui sont des boites noires pour les autres. Par conséquent, tout combiner dans un unique processus, l'asynchronisme est compréhensible.

La deuxième difficulté résulte dans le choix de médias inappropriés de communication. La collaboration est bien effectuée avec l'aide d'outils/plateformes collaboratives. Mais, les solutions actuelles ne répondent qu'en partie aux besoins des thématiciens. La plupart permettent de résoudre des problèmes de communication seulement ou de coordination dans un cadre
générique, il manque des fonctionnalités pour manipuler le simulateur de façon collaborative.

La collaboration entre des intervenants (le thématicien, le modélisateur et l'informaticien) est un activité essentielle pour une simulation fidèle et efficace. Mais, à cause de ces difficultés, elle est mal exploitée. Dans la section suivante, nous allons faire un état de l'art concernant la collaboration autour des simulateurs actuels.

## 2.3 Méthodes et outils pour collaborer lors d'une simulation

Au cours de cette section, nous nous intéressons à des solutions ou approches existantes qui permettent de résoudre une partie de nos difficultés. Nous commençons avec des approches de l'utilisation du simulateur dans un contexte de groupe. Ensuite plusieurs outils et techniques souvent utilisés dans le domaine seront abordés.

### 2.3.1 Modèles de collaboration

Jusqu'à maintenant, plusieurs travaux ont soutenu l'utilisation du simulateur dans un contexte d'utilisation en groupe [Taylor 2003], [Roselló 2007], [Berglund 1998], [Bravo 2006], [Korichi 2008], [Henriksen 2002], [Robert 1998], [Hirata 2008], [Nguyen 2008b] ... Il est difficile de donner une catégorisation explicite de ces approches. Cependant en se basant sur la façon d'utiliser le simulateur et l'architecture utilisée, nous avons séparé 4 approches et modèles suivants : (i) modèle de tâche et modèle à base de rôles, (ii) simulation individuelle et partagée, (iii) simulation locale et distante, et (iv) simulation centrale et distribuée.

#### a) Modèle de tâche et modèle à base de rôles

De nombreux modèles ont été développés pour le Travail Collaboratif Assisté par Ordinateur (TCAO). Certains d'entre eux sont encore des champs de recherche actifs à l'heure actuelle. Le modèle de tâches est un des modèles de base pour représenter le TCAO. Penichet [Penichet 2007] a proposé un modèle de tâches pour TCAO. Ce modèle a décrit les tâches qui devraient être réalisées pour atteindre les objectifs d'application en leur donnant une bonne caractérisation. Ce modèle est une nouvelle "composition" de modèles de tâches existants afin d'avoir un modèle de tâche meilleure, plus complet et plus efficace.

Une autre solution qui attire récemment l'attention de nombreux chercheurs est le modèle à base de rôles qui est construit au-dessus du modèle de tâche. Kahina et al. [Hamadache 2009, Hamadache 2010] ont présenté un modèle basé sur les rôles qui est une combinaison de rôles, de tâches, d'actions et des ressources. Un rôle est une représentation des responsabilités et des droits, où les responsabilités sont les actions qu'un joueur doit effectuer et les droits sont les actions qu'il peut effectuer. Une tâche est un ensemble d'actions à réaliser tandis que les actions sont considérées comme les composantes des tâches. Un rôle peut être effectué par un ou plusieurs utilisateurs en même temps. Une tâche peut exiger un ou plusieurs rôles pour l'effectuer.

#### b) Simulation individuelle et simulation partagée

Par rapport aux autres types de simulation, la simulation individuelle est apparue plus tôt. Il
s'agit d'un utilisateur exécutant un simulateur standalone sur son ordinateur. Il l'utilise comme une application indépendante. La plupart des plates-formes comme Repast [North 2006], Netlogo [Wilensky 1999], Gama [Amouroux 2007] sont basées sur cette approche. Cette technique est simple à utiliser et à développer. Mais avec l'augmentation des simulations des systèmes complexes, la simulation individuelle montre ses limites pour la collaboration entre chercheurs. Un groupe ne peut pas avoir un même point de vue, si chaque membre réalise des simulations indépendantes et donc différentes.

La simulation partagée est proposée pour résoudre cet inconvénient. Cette approche permet à plusieurs utilisateurs d'expérimenter avec un seul simulateur. Actuellement, pour effectuer cette simulation, on simule ensemble en utilisant un logiciel support spécifique. Ce type de logiciel a une fonction spécifique qui permet de partager l'utilisation d'une application via le réseau, comme par exemple dans le travail de Taylor et al. [Taylor 2003]. Ils ont utilisé l'outil NetMeeting pour supporter la simulation partagée. Cet outil permet à un utilisateur de contrôler complètement l'application partagée sur l'ordinateur de son/sa partenaire. En parallèle de NetMeeting, d'autres outils existent comme VNC ou Remote Desktop Sharing.

La simulation partagée permet de surmonter l'inconvénient de la simulation individuelle, mais l'utilisateur a besoin d'installer des logiciels externes qui quelques fois dépendent du système d'exploitation. De plus, pour réaliser une simulation partagée, les participants doivent travailler avec la même application et à même moment : cette approche supporte seulement la collaboration synchrone. Ainsi, il faut intégrer d'autres outils pour la collaboration asynchrone.

## c) Simulation locale et Simulation à distance

Le développement des Nouvelles Technologies de l'information et de la Communication a fait apparaître de nombreuses techniques permettant la simulation collaborative dans laquelle le simulateur est disponible via le réseau. Le simulateur peut être téléchargé et exécuté sur la machine locale ou il peut être exécuté sur une machine distante.

Le simulateur est souvent stocké sur un serveur. Dans l'approche de simulation locale, l'utilisateur télécharge le simulateur sur son ordinateur et l'exécute sur l'ordinateur local comme une application indépendante. Le simulateur peut être une Applet ou un autre exécutable. Dans ce mode, chaque utilisateur expérimente sur une instance différente du simulateur.

WebSimMior [Nguyen 2009] est un exemple de simulation locale. Les utilisateurs le téléchargent et l'exécutent via leur navigateur en utilisant les ressources matérielles de leur propre ordinateur. Cependant, actuellement WebSimMior support seulement des simulateurs de NetLogo. Les utilisateurs ne peuvent interagir avec le navigateur et ils ne peuvent pas communiquer et effectuer des simulations ensembles et de manière synchrone.

Cette approche est similaire à la simulation individuelle. Un groupe n'a pas un même point de vue sur l'expérimentation, parce que chaque simulateur est géré de façon indépendante.

Au lieu de lancer l'expérimentation sur la machine locale, la simulation à distance s'exécute sur un serveur. Les résultats sont ensuite transmis via le réseau sur l'ordinateur de utilisateur. Citons quelques exemples de cette approche : ERIRC[Berglund 1998], DOMOSIM-TPC[Bravo 2006] ou PAMS [Nguyen 2008b] que nous détaillerons plus tard.

## d) Simulation centralisée et Simulation distribuée
Actuellement, pour exploiter des machines puissantes disponibles sur l'internet et ainsi sup-
porter la répartition des thématiciens, on déploie souvent la simulation sur une architecture
distribuée. En se basant sur ces architectures, deux approches de simulation sont identifiées :
simulation centralisée et distribué. Pour l'approche centralisée, les activités de modélisation et
de simulation sont réalisées sur un ordinateur distant, généralement un serveur distant. Les
utilisateurs peuvent accéder et recevoir le résultat via le réseau. ASP (Application Service Pro-
vider) est un exemple bien connu de cette approche. Un ASP installe, configure, et maintient
le logiciel de classe entreprise sur son propre serveur et permet à ses utilisateurs d'accéder au
logiciel à distance, qui est normalement via une connexion Internet sécurisée en utilisant un na-
vigateur Internet. D'autre exemple comme openQwaq [Suslov 2012], SecondLife [Papamichail ],
OpenSim [Ridgewell 2011].

Pour l'approche distribuée, l'expérimentation ne s'exécutent pas sur un ordinateur central : l'exécution peut être faite de façon indépendante sur un ensemble d'ordinateurs, ou sur un groupe/grille de serveurs. Ulriksson et al dans [Moradi 2004] présente la plate-forme NetSim qui montre comment la simulation peut être distribuée avec la technologie peer-to-peer. Les modèles se basent sur l'architecture HLA. En combinaison avec la plate-forme JXTA qui offre plusieurs services P2P. NetSim permet à une expérimentation d'être exécuté sur les machines de tous les participants.

2.3.2 Moyens informatiques de collaboration

Cette section aborde quelques techniques et outils supportant la collaboration autour d'un
simulateur dont certains sont employés dans non seulement une mais plusieurs méthodes men-
tionnées précédemment.

a) WSBG : Web Based Simulation Groupware

Le développement de technologies du Web à partir de la fin du siècle dernier a proposé une
nouvelle direction pour la simulation collaborative [Korichi 2008]. Le domaine des Web-Based
Simulation Groupware (WBSG) incorporent des simulateurs dans un environnement collaboratif
à base de Web. Plusieurs avantages sont identifiés pour WBSG [Byrne 2010, Wang 2012] : ils sont
faciles à utiliser, à collaborer, à déployé un modèle. Ce développement nous rend des solutions
plus économiques, la réutilisation du modèle, le support multi-plateforme, l'accès contrôle, la
disponibilité de partout, la facilité de versioning, la personnalisation et la maintenance.

À côté ces avantages ci-dessus, WBSG a les inconvénients, comme la perte de vitesse, la limitation de l'interface graphique utilisateur, la vulnérabilité.

WBSG sont appliqués principalement à des applications militaires, scientifiques, de l'éducation, de la formation et du secteur manufacturier [Bravo 2006, Byrne 2010, Wang 2012].

Nous nous intéressons à l'application de WBSGs à des travaux de recherche, spécialement l'étude des systèmes complexes. Dans ce domaine, on peut citer le Web Sim-Mior qui a été le premier essai pour fournir des outils web collaboratifs dédiés à la modélisation et simulation des systèmes complexes. Le portail Web-Sim-Mior est basé sur la plateforme générique agent NetLogo et permet aux utilisateurs d'exécuter des simulations sur leur propre ordinateur via le navigateur de web sans rien installer. Cette plateforme ne propose pas d'outils collaboratifs tels que la conférence vidéo, outil de chat, forum, blog. En effet, elle offre uniquement un portail
web interactif plutôt qu’un groupware. Elle permet d’exécuter uniquement des simulateurs de NetLogo. Les utilisateurs ne peuvent interagir avec le navigateur, et ils ne peuvent communiquer et effectuer des simulations en groupe.

## b) WBSC : Web Based Simulation Center

Le framework Web Based Simulation Center (WBSC) [Henriksen 2002] fournit un concept et une solution prototype pour supporter les spécialistes de différents domaines qui sont impliqués dans un projet de simulation, phase par phase, soutenue par des ressources de Web [Henriksen 2002]. Il prend en charge toutes les étapes d'un projet de simulation collaboratif. Un avantage de cette plateforme est de fournir des fonctionnalités suffisantes pour la collaboration dans la simulation comme une messagerie instantanée, un système de gestion de fichiers, un environnement pour l’écriture collaborative de documents (Collaw), et des caractéristiques spéciales pour multimodèlement réaliser des expérimentations (par exemple, modifier des paramètres, exécuter une simulation ou afficher des résultats sous forme d’images.).

Mais WBSC ne supporte que le simulateur développé par GPSS/H [Robert 1998] qui est un langage de programmation de simulation à temps discret. Il ne peut pas intégrer de nouveaux simulateurs qui ont été écrits dans d'autres systèmes de simulation tels que le modèle Mior. Par ailleurs WBSC ne supporte pas les outils collaboratifs synchrones comme la visioconférence, tableau blanc ou le partage d'écran ...

## c) BSCW : Basic Support Collaborative Work

Dans [Korichi 2008], Korichi Ahmed présente une plateforme basée sur le WEB avec des supports spécifiques au travail collaboratif (Basic Support Collaborative Work - BSCW) utilisable dans des domaines de recherche différents. C'est une plateforme qui est dotée des fonctionnalités collaboratives de base pour réaliser différents types de collaboration. Korichi Ahmed a associé un système BSCW avec des logiciels externes qui permettent de réaliser des fonctions synchrones de collaboration comme MS NetMeeting, VNC. Cette combinaison propose un espace de travail partagé avec des fonctions collaboratives asynchrones (forums, par exemple, la gestion des versions, le service d'événements) et des outils synchrones. Celui-ci introduit des services comme la visio-conférence, la messagerie instantanée, le partage de bureau, le partage d'utilisation de logiciel, et ainsi de suite.

L'approche proposée par Ahmed Korichi est très simple, utile et générique. Mais, parmi ses inconvénients, on peut noter qu'aucune règle de confidentialité ne peut être définie. Tout participant d'une session peut contrôler la simulation. En outre, il n'existe aucune fonctionnalité générique (par exemple une base de données) permettant de stocker des résultats de la simulation : les résultats sont partagés par le groupe lors de la simulation et ne peuvent pas être réutilisées par la suite. Cependant, le fait de combiner avec un BSCW s'avère être un avantage pour supporter la simulation collaborative. De plus, actuellement il existe plusieurs BSCW qui nous permettent d'être modifiée pour s'adapter à notre besoin spécifique : la simulation collaborative des systèmes complexes.

La modélisation et simulation des phénomènes complexes implique une synergie de multiples domaines disciplinaires traditionnels et implique la collaboration d'une équipe multidisciplinaire [Zhang 2009, Wang 2012]. Zhang et al [Zhang 2009, Wang 2012] ont basé sur l'ensemble de l'ap-
proche et les technologie pour soutenir cette simulation collaborative, comme l'approche orienté modèle (MDA) qui est de l'Object Management Group (OMG). C'est un bon choix pour séparer le modèle du système et des technologies de la plateforme. En intégrant l'approche de HLA et l'approche Service de Web, Zhang et al [Zhang 2009, Wang 2012] ont développé un modèle qui est indépendant de l'infrastructure et peut être distribué sur Internet. De plus, pour séparer les modèles et l'utilisateur, l'auteur a appliqué la technologie Web Service qui fournit l'interopérabilité multi-plateforme et indépendant de la langue. Les modèles sont stockés sur un serveur distant, par Web Service avec des documents WSDL (Web Service Description Language) qui spécifient chaque fonction du modèle, le client à distance peut facilement de simuler sans entrer dans les détails du modèle. Mais, en effet, ce travail concentre principalement sur l'intégration et à la collaboration entre différents sous-modèles. La manipulation simultanée et l'utilisation collaborative du simulateur ne sont pas bien pris en compte.

### d) Technique 3D

Une autre technique qui séduit également plusieurs recherches dans le domaine de la simulation et de l'apprentissage repose sur la constitution d'un monde virtuel 3D. Selon Bell [Bell 2008], un espace virtuel est "a synchronous, persistent network of people, represented as avatars, facilitated by networked computers". Un environnement 3D fournit une collaboration riche (ou participation) par laquelle il supporte des échanges synchrones et avec des illustrions 3D. Ces dernières permettent aux participants de faciliter le travail du groupe. Chaque participant est souvent représenté par un objet ( avatar ) dans l'espace 3D qui réalise les travaux dedans et collabore avec d'autres objets [Schmeil 2012]. Pour cette technique nous avons par exemple les plateformes SecondLife [Papamichail ], OpenSim [Ridgewell 2011], OpenQwaq [Suslov 2012].

Le fait de combiner la technique 3D et le WBSG permet d'exploiter à la fois les avantages de chaque approche pour renforcer la simulation collaborative. Chen et al. [Chen 2012] a présenté un tel travail avec la plateforme Sino-VirtualMoon. Cette dernière est une plateforme de WEB 3D pour la recherche collaborative. D'un côté, la plateforme support une visualisation riche 3D, de l'autre côté, elle supporte également l'analyse collaborative géospatiale de la Lune. De plus, pour renforcer la collaboration et éliminer les conflits, l'auteur a introduit un outil de vidéo-conférence et un mécanisme de détection des conflits. Ce mécanisme permet d'identifier les manipulations simultanées, et la visio-conférence permet de communiquer pour éliminer les conflits.

### e) Comparaison entre les moyens

Cette section est pour faire une comparaison entre les moyens présentées ci-dessus : WBSG avec le portail WEB-Sim-Mior, WSBC et BSCW. Cette comparaison est présentée par le tableau 2.2. Nous nous intéressons seulement au support de la simulation et des fonctionnalités collaboratives.

Pour la simulation, nous distinguions dix caractéristiques :

- Mode batch et Mode graphique pour le mode d'exécution des simulations.

- Modèle de simulation avec six caractéristiques : *Simulation individuelle*, *Simulation partagée*, *Simulation locale*, *Simulation à distance*, *Simulation centralisée* et *Simulation distribuée*.

- Capacité de manipulation collaborative des paramètres et des résultats de chaque moyens.
<table><caption>TABLE 2.2 – Comparaison entre des moyens</caption><thead><tr><th></th><th></th><th>WEB-Sim-Mior</th><th>BSCW</th><th>WBSC</th></tr></thead><tbody><tr><td rowspan="8">Simulation</td><td>Mode batch</td><td></td><td>X</td><td></td></tr><tr><td>Mode graphique</td><td>X</td><td>X</td><td>X</td></tr><tr><td>Simulation individuelle</td><td>X</td><td>X</td><td>X</td></tr><tr><td>Simulation partagée</td><td></td><td>X</td><td></td></tr><tr><td>Simulation distribuée</td><td></td><td></td><td></td></tr><tr><td>Simulation centralisée</td><td>X</td><td>X</td><td>X</td></tr><tr><td>Simulation locale</td><td>X</td><td>X</td><td></td></tr><tr><td>Simulation à distance</td><td></td><td>X</td><td>X</td></tr><tr><td rowspan="5">Generic functions</td><td>Manipulation collaborative des paramètres et résultats</td><td></td><td></td><td></td></tr><tr><td>Simulation management</td><td></td><td></td><td></td></tr><tr><td>Visio-conférence</td><td></td><td>X</td><td></td></tr><tr><td>Messagerie instantanée</td><td></td><td>X</td><td>X</td></tr><tr><td>Tableau blanc</td><td></td><td>X</td><td></td></tr><tr><td></td><td>Ecran partagé</td><td></td><td>X</td><td></td></tr><tr><td></td><td>Fonctionnalités asynchrones</td><td></td><td>X</td><td></td></tr><tr><td></td><td>Indépendance du système</td><td>X</td><td>X</td><td>X</td></tr></tbody></table>

– Capacité de gestion de simulation, tel que joindre la simulation, replay de la simulation ...

Concernant des fonctionnalités collaboratives, nous identifions six caractéristiques importantes concernant les fonctionnalités collaboratives synchrones (Visio-conférence, Messagerie instantanée, Tableau blanc, Ecran partagé) et asynchrones (Wiki, Forum etc).

Par le tableau 2.2, nous identifions que, dans trois moyens présentés, BSCW permet plus de capacité dans le support de simulations collaboratives. Car, c'est un moyen ouvert dans lequel on peut facilement combiner les outils nécessaires pour soutenir des fonctionnalités absentes.

## f) L'outil utilisé dans un projet de modélisation et simulation

Pour les étapes du processus de modélisation-simulation (voir le processus de modélisation et simulation à la section 1.3 page 17), on applique des techniques de collaborations différentes qui sont adaptées aux besoins spécifiques de chaque étape.

Pour l'étape du modèle du **Domaine**, la collaboration se résume souvent à des réunions entre les membres. Donc, les techniques de communication synchrones comme la messagerie instantanée, la vidéo conférence, audio conférence, par exemple : NetMeeting [Taylor 2001],
<figure><img src="image_12.png" /><figcaption>FIGURE 2.2 – Collaw [Hanisch 2001]</figcaption></figure>

Agora [Allan 2007] ou Skype [Perényi 2007].

L'établissement du modèle conceptuel constitue l'étape où il est particulièrement important de collaborer. Pourtant, il n'y a pas beaucoup d'outils et de techniques qui permettent à plusieurs modélisateurs de créer ensemble des modèles conceptuels. La plupart du temps, les concepteurs construisent individuellement les modèles et les communiquent ensuite aux autres membres d'un projet.

Dans [Hanisch 2001], A.Hanisch présente un outil appelée Collaw (voir la figure 2.2) qui permet d'écrire collaborativement des modèles conceptuels. D'autres outils comme Net-Meeting [Taylor 2001] et VNC proposent des solutions intéressantes pour construire des modèles conceptuels de manière collaborative, comme la figure 2.3. Les outils de partage de bureau virtuel permettent à deux concepteurs de construire ensemble un modèle conceptuel. Les modélisateurs doivent cependant accéder à un même bureau virtuel et partagé : aucune gestion d'un espace privé n'est possible.

Comme nous l'avons déjà vu, l'étape de création du modèle **Computationnel** exige une activité de collaboration moins importante : les développeurs programment des modèles informatiques tout seul selon les spécifications du modèle conceptuel précédemment établi. Les techniques collaboratives utilisées lors de cette étape peuvent être asynchrones comme le courriel ou les forums.

Lors de l'expérimentation d'un modèle, les scientifiques effectuent trois tâches principales :
(i) la saisie des paramètres, (ii) l'exécution de la simulation et (iii) l'analyse des résultats. Pour la saisie des paramètres de simulation, quelques techniques de collaboration existent comme :
la saisie directe via une interface collaborative, ou bien l'écriture collaborative et le partage de fichiers de paramètres qui vont être lus par les simulateurs.
<figure><img src="image_13.png" /><figcaption>FIGURE 2.3 – NetMeeting et SIMUL8 [Taylor 2001]</figcaption></figure>

Dans la plate-forme WBSC [Hanisch 2001], la deuxième solution est adoptée. Les paramètres sont formatés dans un fichier spécifique (le plus souvent texte ou XML) que le simulateur peut interpréter. Ce fichier est chargé sur la plate-forme collaborative et le simulateur est exécuté. L'inconvénient de cette technique est que l'on doit connaître la spécification du fichier d'entrée. De plus il faut éditer de manière individuelle le fichier avant de le communiquer à l'ensemble des membres du projet.

Les sorties d'un simulateur sont souvent présentées sous forme textuelle. Donc une plate-forme doit fournir une fonction pour convertir des fichiers textes en images ou en graphiques. Cette fonctionnalité peut être réalisée sur un serveur qui convertit les résultats de simulation et les diffuse à tous les participants. L'avantage de cette approche est de permettre une gestion simple du partage des résultats de simulation. Cependant, s'il y a beaucoup de demandes de conversion au serveur, le serveur peut-être surchargé. Il est possible de surmonter cet inconvénient en envoyant directement le fichier texte à la machine de chaque chercheur. Par contre, chaque utilisateur doit installer le logiciel pour le convertir sous la forme souhaitée.

### 2.3.3 Synthèse

Plusieurs modèles de simulation collaborative et outils/plateformes collaboratives ont été examinés. Mais, aucune approche ne peut complètement répondre aux difficultés présentées dans la section 2.2 page 33. On concentre souvent des solutions ad-hoc qui sont conçus pour un problème ou tâche spécifique. Ainsi, nous devons développer une solution dédiée repondant à ces difficultés.

Néanmoins, ces travaux possèdent des avantages que nous pouvons exploiter. Comme l'application de la technologie de WEB dans la collaboration. Grâce à son caractère facile et prêt à utiliser, cette technologie sera essentielle pour le développement des environnements collaboratifs, dans le futur. De plus, la notion BSCW (Basic support collaborative work) est une bonne piste pour établir l'environnement de la simulation collaborative. Cet environnement sera donc
<figure><img src="image_14.png" /><figcaption>FIGURE 2.4 – Entrée directe des paramètres [Nguyen 2008a]</figcaption></figure>

un BSCW à base de WEB. Pour supporter des fonctionnalités collaboratives spécifiques autour du simulateur, l'idée d'Ahmed Korichi [Korichi 2008] est une bonne solution : utiliser à la fois un BSCW et des outils spécifiques supportant la collaboration autour du simulateur.

## 2.4 Conclusion

Au cour de ce chapitre, nous avons donner un aperçu de la collaboration autour d'un simulateur du système complexe concrète : GAMAVI. Ce projet vise à étudier le phénomène et les mécanismes de propagation locale et de persistance du virus H5N1 dans le contexte des secteurs semi-industrialisés et traditionnels du Vietnam du Nord. La collaboration autour du simulateur ne s'est pas bien réalisée. La plupart du temps, il y a seulement l'informaticien (assurant souvant le rôle de modélisateur) qui réalise la simulation même s'il n'a pas de compétence sur le problème. Les thématiciens définissent ensemble des scénarios, et les envoient au modélisateur. Ce dernier manipule le simulateur, l'exécute, recueille les résultats et les renvoie aux thématiciens pour analyse. Ceci cause des simulations inefficaces et la perte de temps. Il vaut mieux que les thématiciens participent en collaborant avec le modélisateur et l'informaticien dans la simulation.

Nous trouvons que ce problème n'est pas spécifique pour GAMAVI, mais peut être généralisé à la majorité des simulateurs de systèmes complexes actuels. Une meilleure collaboration est nécessaire entre le thématicien, le modélisateur et l'informaticien. Mais, le thématicien est souvent absent, tandis que le modélisateur et l'informaticien sont une même personne. Deux raisons principales sont identifiées qui explique pourquoi les thématiciens ne collaborent pas avec les autres.

La première difficulté concerne l'asynchronisme entre les intervenants qui est causé par la pluridisciplinarité (ou l'interdisciplinarité) entre eux. La deuxième concerne les difficultés dans la collaboration à distance qui est origine de l'inappropriée des outils collaboratifs actuels. Plusieurs solutions dans la littérature sont examinées. Mais, on doit combiner souvent de nom-
<figure><img src="image_15.png" /><figcaption>FIGURE 2.5 – Représentation du résultat par le converteur Proof2SVG [Henriksen 2002]</figcaption></figure>

breux outils différents pour répondre à ces deux difficultés. Aucune approche ne peut résoudre complètement les deux difficultés et ainsi qu'aucun outil permet d'effectuer à la fois la simulation et la collaboration.

Par conséquent, nous devons proposer une nouvelle approche qui permet de produire un outil spécifique supportant simultanément la simulation et la collaboration et qui répond totalement aux difficultés ci-dessus. Deux questions concrète sont identifiées à partir de ces besoins :

Questions

Q1 : Quels seraient les contours d'une plate-forme générique assurant la collaboration autour d'un simulateur ?

Q2 : Comment concevoir un simulateur collaboratif à partir d'une problématique et d'un modèle existants, qui favorise la collaboration ?

Pour la première question, le simulateur collaboratif semble une bonne piste. Nous allons l'analyser en détail dans les parties suivantes. Pour répondre à la seconde, il est important d'étudier en amont des méthodes de modélisation aussi bien en génie logiciel qui est dans les domaines des systèmes complexes et de la simulation.
# Méthode pour la conception d'un
outil de simulation et de la
collaboration

## Sommaire

<table><tr><td>3.1</td><td>Méthode d'ingénierie logicielle</td><td>50</td></tr><tr><td>3.1.1</td><td>Modèle en cascade [Foster 2009]</td><td>50</td></tr><tr><td>3.1.2</td><td>Approche itérative et incrémentale</td><td>50</td></tr><tr><td>3.1.3</td><td>Modèle Spiral</td><td>51</td></tr><tr><td>3.1.4</td><td>Approche Agile</td><td>52</td></tr><tr><td>3.1.5</td><td>Synthèse</td><td>53</td></tr><tr><td>3.2</td><td>Méthode de modélisation-simulation des systèmes complexes</td><td>53</td></tr><tr><td>3.2.1</td><td>Fishwick et Gilbert & Troitzsch</td><td>53</td></tr><tr><td>3.2.2</td><td>Drogoul et al [Drogoul 2003, Drogoul 2004]</td><td>54</td></tr><tr><td>3.2.3</td><td>ComMod - Modélisation d'accompagnement</td><td>56</td></tr><tr><td>3.2.4</td><td>ARDI</td><td>57</td></tr><tr><td>3.2.5</td><td>KIMONO</td><td>59</td></tr><tr><td>3.2.6</td><td>Synthèse</td><td>61</td></tr><tr><td>3.3</td><td>Méthodes pour la conception des collecticiels</td><td>62</td></tr><tr><td>3.3.1</td><td>Modèle en trèfle</td><td>62</td></tr><tr><td>3.3.2</td><td>RCOM</td><td>63</td></tr><tr><td>3.3.3</td><td>Méthode CoCSys</td><td>65</td></tr><tr><td>3.4</td><td>Synthèse</td><td>66</td></tr></table>

Un des objectifs de cette thèse est de proposer une méthode pour concevoir un outil spécifique permettant à la fois la simulation et la collaboration. Une telle démarche est complexe car elle doit être suffisamment :

- générique pour s'appliquer aux plusieurs projets de la simulation des systèmes complexes existants.

- intelligible pour être utilisable, dans un cadre pluridisciplinaire, par des acteurs provenant de diverses disciplines ayant des compétences hétérogènes.

- complète c'est à dire, intégrer tous les concepts de base permettant la modélisation de la collaboration.

Au cours de ce chapitre, nous présentons trois grands courants de la conception. Nous présentons dans un premier temps le génie logiciel. Ensuite, nous nous focalisons sur les méthodes de
modélisation et simulation. Finalement, nous abordons les méthodes pour concevoir des collecticiels.

## 3.1 Méthode d'ingénierie logicielle

### 3.1.1 Modèle en cascade [Foster 2009]

Le modèle en cascade a été proposé dans les années cinquante du siècle dernier. Il est aujourd'hui toujours utilisé. Il repose sur une succession de phases : (1) Analyse des besoins, (2) Conception, (3) Développement, (4) Test, (5) Maintenance. Le processus prévoit une étape de vérification entre chaque phase.

Un grand inconvénient de ce modèle est qu'il exclut l'utilisateur dès la phase de conception car trop technique. D'autre part, il est difficile d'effectuer des modifications en cours de route. De plus, avec ce modèle, on rencontre souvent des risques liés à l'identification tardive des problèmes et la validation tardive de bon fonctionnement. Cette approche s'avère approprié lorsque les exigences logicielles sont explicitement identifiées.

Néanmoins, cette approche propose une structure de conception claire et complète et une documentation détaillée.

### 3.1.2 Approche itérative et incrémentale

<figure><img src="image_16.png" /><figcaption>FIGURE 3.1 – Modèle itératif</figcaption></figure>

Cette approche itérative et incrémentale a été créée en 1930 par le travail de Walter Shewhart, expert au laboratoire Bell Telephone Laboratories<fnref n="1" />. Jusqu'aux années 1960 cette ap-

<footnote n="1">1. http://www.bell-labs.com/</footnote>
proche a été officiellement appliquée pour le génie logiciel, dans le projet Mercury de NASA [Larman 2003].

C'est une combinaison entre la méthode itérative et la construction incrémentale du modèle. Elle permet de surmonter les risques tardifs du modèle en cascade en proposant un processus de développement itératif entre des étape du processus et raffinements successifs de l'information manipulée. Le caractère incrémental nous donne la possibilité d'améliorer le processus de développement, ainsi que d'ajuster les exigences à l'évolution de l'environnement. Tandis que l'approche itérative nous permet de rétroagir à la phase d'analyse. Cela nous aide à améliorer la qualité du logiciel.

De plus l'approche itérative et incrémentale repose sur un travail d'équipe pour résoudre des problèmes et favoriser le développement de solutions. Elle exige que toutes les parties concernées y compris l'équipe de développement, ou les utilisateurs adoptent des techniques de collaboration [Bittner 2006].

### 3.1.3 Modèle Spiral

Présenté en 1985 par Barry Boehm, Spiral est une spécification de l'approche itérative et incrémentale dans laquelle le processus de conception se traduit par une spirale plutôt qu'une séquence d'activités avec "retour arrière".

<figure><img src="image_17.png" /><figcaption>FIGURE 3.2 – Modèle Spiral [Larman 2003]</figcaption></figure>

Le modèle s'appuie sur une succession d'itérations dont chacune se déroule en quatre phrases : (1) analyse initiale (ou à partir du cycle précédent) des besoins, des objectifs du cycle (solutions et contraintes); (2) étude des risques, évaluation des solutions de remplacement et éventuellement conception; (3) développement et vérification de la solution résultant
de l'étape précédente ; (4) examen du produit et projection vers le cycle suivant.

Il s'agit d'une des premières approches qui formalise et met en évidence le concept d'itération à la base du risque et la nécessité d'utiliser une étape discrète d'évaluation des risques à chaque itération [Larman 2003]. Par conséquent, l'utilisateur s'implique d'avantage dans cette démarche qu'avec l'approche en cascade.

### 3.1.4 Approche Agile

En Février 2001, un groupe de 17 experts - représentant DSDM, XP, Scrum, FDD, Extreme Programming, l'inventeur du Wiki, JUnit, Crystal clear, ASD - intéressés à promouvoir des méthodes itératives et incrémentales modernes, simples se sont rencontrés afin d'identifier les points communs dans le génie logiciel. Cette rencontre a abouti aux prémisses d'Agile qui applique à la fois aux techniques itératives et incrémentales [Larman 2003].

Les méthodes Agile tentent de minimiser les risques par des développements dans des périodes courtes, appelés itérations qui se situent généralement entre 1 et 4 semaines. Chaque itération est elle-même vue comme un projet de logiciel, constitué de toutes des tâches nécessaires pour le développement des nouvelles fonctionnalités : planification, analyse des besoins, conception, rédaction code, test, et la documentation.

<figure><img src="image_18.png" /><figcaption>FIGURE 3.3 – Méthode Agile</figcaption></figure>

Selon le Manifeste pour le développement Agile de logiciels [Fowler 2001], cette méthode prône quatre valeurs fondamentales :
- L'équipe : *Les individus et leurs interactions plus que les processus et les outils* - Il s'agit que l'équipe est bien plus importante que les outils (structurants ou de contrôle) ou les procédures de fonctionnement. Il est mieux d'avoir une équipe soudée qui communique régulièrement plutôt qu'une équipe composée d'experts fonctionnant chacun de manière isolée. La communication est une notion fondamentale de l'approche.

- L'application : *Des logiciels opérationnels plus qu'une documentation exhaustive* - il est vital que l'application développée fonctionne. La documentation est considérée seulement comme un moyen de communication et de transfert des compétences au sein de l'équipe.

- La collaboration : *La collaboration avec les clients plus que la négociation contractuelle* - Il faut impliquer les utilisateurs dans le développement.

- L'acceptation du changement : *L'adaptation au changement plus que le suivi d'un plan*

### 3.1.5 Synthèse

Dans cette section, nous avons présenté trois méthodes du génie logiciel. Bien qu'aucune approche puisse répondre à notre objectif dans la conception de l'outil spécifique supportant simultanément la simulation et la collaboration, elles proposent quelques idées intéressantes comme :

- pour le modèle cascade, c'est une démarche complète facile à utiliser, à comprendre et à réduire des risques.

- la rétroaction vers les étapes précédentes et la construction incrémentale de l'approche itérative et incrémentale.

- l'implication forte de l'utilisateur du modèle Spiral.

- les quatre valeurs fondamentales du méthode d'Agile. Surtout, la valeur de *l'équipe* et de *la collaboration*.

## 3.2 Méthode de modélisation-simulation des systèmes complexes

### 3.2.1 Fishwick et Gilbert & Troitzsch

Le travail de Fishwick [Fishwick 1995, Fishwick 1997] est un des travaux qui s'inspire de plusieurs méthodes de la modélisation informatique. Selon lui, la conception d'un simulateur est un processus incrémental avec trois étapes itératives :

- Conception du modèle : Le système créé est représenté avec des sémantiques formelles ou des logiques mathématiques.

- Exécution du modèle : Le modèle est transformé ensuite en un algorithme qui peut s'exécuter sur un ordinateur.

- Analyse des résultats : Les résultats de l'exécution sont collectés, analysés et comparés avec des données observées.

Selon Drogoul [Drogoul 2003], *le problème de cette proposition est que la traduction du modèle initial en un modèle computable apparaît comme «naturelle»*. Il manque une étape intermédiaire entre la conception et l'implémentation du modèle.
Gilbert et Troitzsch [Gilbert 1999] ont essayé de surmonter ce problème en ajoutant cette étape intermédiaire : construction du modèle. Cependant, la conversion du modèle en un algorithme n'est pas triviale.

<figure><img src="image_19.png" /><figcaption>FIGURE 3.4 – Méthode de Gilbert et Troitzsch, conçu par [Drogoul 2003]</figcaption></figure>

### 3.2.2 Drogoul et al. [Drogoul 2003, Drogoul 2004]

A partir des inconvénients de la méthode de Fishwick et Gilbert & Troitzsch qui : (i) n'est pas spécifique à la simulation orientée agent et s'applique pour la simulation informatique de façon général ; (ii) qui est orientée tâche au lieu du modèle, Drogoul et al ont proposé un processus itératif et incrémental en se basant sur l'affichage des rôles différents avec des missions, capacités, des points de vue propres à chaque étape.

Selon l'auteur, dans un processus de modélisation et simulation, il y trois rôles différents : le thématicien, le modélisateur et l'informaticien.

Le thématicien est l'expert d'un ou plusieurs domaines ou thèmes. Il définit le but du projet, c'est à dire qu'il définit la question initiale, et fournit des connaissances et des données sur le système. En particulier, il possède deux types de connaissances : les macro-connaissances, l'ensemble de connaissances «globales» sur le système cible, souvent tirées d'observations, et des micro-connaissances, des observations et hypothèses sur les individus du système cible. Les motivations des thématiciens sont souvent nécessaire pour comprendre le lien entre le micro et le macro-niveau. Ils utilisent des micro-K pour construire le modèle du domaine souvent informel qui décrit des agents réels (agents observables dans le système cible), leurs paramètres et leurs comportements.

La deuxième rôle est celui de modélisateur. Ce dernier transforme le modèle du domaine en modèle conceptuel, un modèle plus formalisé où il n'existe pas d'ambiguïtés potentielles. L'implémentation d'une solution opérationnelle ne peut pas se réaliser directement à partir du modèle du domaine. Ce dernier est souvent informel, ambigu. Il manque beaucoup de détails
<figure><img src="image_20.png" /><figcaption>FIGURE 3.5 – Méthode de Drogoul et al [Drogoul 2003]</figcaption></figure>

nécessaires et contient beaucoup de détails superflus pour la mise en œuvre.

Après le modèle conceptuel, le troisième rôle, l'informaticien, va proposer un modèle opérationnel pour faire le lien avec celui du modélisateur et pour faciliter la construction de l'environnement de simulation. Ce modèle intermédiaire permet aux deux autres rôles de comprendre, et éventuellement de modifier, ce qui va être implémenté [Drogoul 2003].

Bien que cette méthode soit appliquée pour la modélisation et simulation des systèmes complexes, mais nous ne pouvons exploiter tous leurs innovations pour nôtre problématique. Parce que elle permet produire seulement des simulateurs stand-alone. Cependant, elle a proposé un processus intéressant qui est découpé par des étapes concrètes. Chaque étape est caractérisée par un modèle et des rôles spécifiques. Ainsi, la création d'un modèle est le résultat d'un processus itératif et incrémental.

Le simulateur conçu par ce processus est également vérifié et validé. Le feedback à travers les étapes assure que la conception est toujours à bon chemin. Des tests réalisés vont vérifier le simulateur avec le modèle opérationnel. La validation avec le modèle conceptuel est effectuée par les thématiciens dans l'étape simulation.

La grande innovation de ce travail est la spécification des rôles des contributeurs. Dans cette méthode, les missions, la position ainsi que les connaissances nécessaires de chaque rôle sont bien présentes et guidés. Cependant, elles ne sont pas vraiment détaillées, et manquent de guides pour des outils (conceptuel et logiciel) utilisées.

Comme présenté dans la section 2.2 page 33, une des difficultés que nous rencontrons a pour origine la pluridisciplinarité (ou l'interdisciplinarité) des stakeholders/des thématiciens qui utilisent le simulateur. Ainsi, un des objectifs de notre démarche est d'intégrer tous les points de vue des thématiciens dans la conception. C'est juste pour gagner la légitimation du produit final. Cependant, les deux travaux ci-dessus n'ont abordé aucune solution pour cela. Ils ont concentré seulement au contexte individuel (Bien que, l'approche de Drogoul et al ait présenté des différents rôles, mais ces rôles effectuent leur travail individuellement
à chaque étape). D'autre part, ces méthodes ont tacitement accepté que toutes les données nécessaires soient prêtes, ils concentrent seulement à concevoir les modèles. Néanmoins, dans un contexte de groupe interdisciplinaire, la tâche de collection et d'intégration des données des domaines différentes n'est pas facile. Par conséquent, dans la section suivante, nous allons présenter trois approches dans un contexte de groupes qui implique les différents points de vue des thématiciens : Commod - Modélisation d'accompagnement, ARDI et KIMONO.

### 3.2.3 ComMod - Modélisation d'accompagnement

La modélisation d'accompagnement - Commod - a été proposé en 1996 par un groupe interdisciplinaire de chercheurs qui s'intéressent aux problématiques de la gestion des ressources renouvelables et de l'environnement. L'objectif de Commod est de développer la simulation en intégrant le point de vue des experts et stakeholders durant le processus de modélisation et d'utiliser ces points de vue avec un objectif d'apprentissage collectif. Dans cette approche, les intervenants participent à la construction des modèles pour améliorer leur pertinence et augmenter leur utilisation pour l'évaluation collective des scénarios.

<figure><img src="image_21.png" /><figcaption>FIGURE 3.6 - Cycle de la modélisation d'accompagnement [Bousquet 2005]</figcaption></figure>

Commod propose un cycle itératif composé de trois phases dans laquelle les chercheurs, les stakeholders collaborent pour concevoir le modèle en utilisant le paradigme agent et les jeux de rôles [Barnaud 2008] :

- Analyse des données secondaires et études de terrain complémentaires pour analyser une situation et un problème donnés.

- Conception d'un modèle à partir de la représentation de la situation issue de ce travail d'analyse.

- Simulations à l'aide du modèle avec les acteurs locaux afin de confronter la représentation initiale des chercheurs à celle des acteurs locaux et de faciliter un processus de concertation entre eux. Cette dernière phase peut mener les chercheurs à la mise en œuvre d'un nouveau
cycle ComMod pour adapter le modèle aux représentations et aux préoccupations des acteurs locaux, lesquelles peuvent évoluer au cours du processus d'apprentissage collectif suscité.

Commod est utilisé dans deux contextes spécifiques et consécutifs : la production de connaissance sur des systèmes complexes et l'accompagnement de processus collectifs de décision. Dans le premier contexte, Commod propose de construire une représentation du système étudié qui est réalisé participativement par les acteurs. Cela permet de prendre en compte les différents points de vue existants. Ensuite, elle est commentée, récusée ou modifiée par d'autres groupes d'acteurs.

L'objectif du deuxième contexte peut être d'aller au-delà du partage des points de vue, et de s'engager dans un processus dont la finalité est de modifier le fonctionnement du système. Cet objectif peut être émis directement ou à la suite du travail précédent de partage des connaissances, par l'ensemble des acteurs. La modélisation d'accompagnement propose un processus d'enrichissement progressif. A chaque itération, le but est mieux compris et mieux partagé. *Il ne s'agit pas de trouver la meilleure solution, mais de se donner les moyens de prendre en charge au mieux les incertitudes de la situation examinée en commun<fnref n="2" />.*

Cette méthode a l'avantage d'impliquer tous les stakeholders du système étudié dans le processus de co-construction et d'utilisation du modèle. Fondée sur le principe de la démocratie technique, la méthode de co-construction permet de canaliser les différents savoirs convoqués autour de la table vers une communauté d'intérêts : la résolution commune d'un problème ou la réflexion sur un avenir commun.

Ce processus peut engendrer des problèmes d'organisation (quand la disponibilité des participants est limitée), de lassitude (quand la démarche n'aboutit pas rapidement à des éléments concrets) ou d'intégration du processus (quand de nouveaux participants sont incorporés en cours de route) [Barreteau 2010].

D'autre part, les séances de modélisation participative, dans Commod, sont réalisées dans un même lieu physique. Les intervenants se regroupent donc en un même endroit pour échanger directement. Néanmoins, pour organiser de tels réunions, beaucoup de temps et d'argent vont être dépensés. Les modélisations à distance sont une solution, mais il faut ajouter des guides ainsi que des infrastructure pour assurer cet échange.

### 3.2.4 ARDI

ARDI est une partie de la modélisation d'accompagnement appliqué pour la conception et développement des plans de gestion des terres et l'eau [Etienne 2011]. A l'image de l'approche Commod, cette méthode est basée sur une compréhension mutuelle des éléments clefs entre différents acteurs pour co-construire un modèle.

L'acronyme ARDI signifie ACTEURS, RESSOURCES, DYNAMIQUE et INTERACTIONS. Il identifie les quatre étapes de cette méthode. Cependant, avant de réaliser ces étapes, les intervenants doivent co-effectuer une étape préambule. Le problème doit être formulé de façon simple, en contenant suffisant d'information (comme des questions, des scientifiques, des territoires concernés) formulé sous la forme de questions clés ou de tableaux. Ces questions sont divisées ensuite en trois questions concernant l'information des acteurs, des ressources et

<footnote n="2">2. La charte Commod : http://cormas.cirad.fr/ComMod/fr/charter/</footnote>
des processus dynamiques. Elles sont simplement formées par une combinaison entre le pronom d'interrogation *que* (*what* en anglais) avec les mots *acteurs* ou *ressources* ou *processus*.

Par exemple, dans le travail effectué en Africain du Sud concernant le processus de la Rivière Crocodile, le problème a été formulé par les questions : *What do you think about water resources use and management in the Crocodile Catchment? What is driving change in the flow of the Crocodile River?* Elles sont ensuite divisées en trois : (1) *What are the main stakeholders that interact with the river and its flow?* (2) *What are the main resources of the catchment in relation to water flow?* (3) *What are the main processes that drive changes in the Crocodile Catchment that affect the river flow?* Puis, le collectif répond successivement selon cet ordre

<figure><img src="image_22.png" /><figcaption>FIGURE 3.7 – Modèle généré par ARDI dans la gestion de l'eau à Rivière Corcodie [Etienne 2011]</figcaption></figure>

dans un interval de 1 à 3 heures pour chaque question. Les réponses sont formulées par une liste de mots clés pour les représenter ensuite par un diagramme comme montré dans la figure 3.7. Premièrement, les ACTEURS sont listés, ils doivent direct ou indirect (acteurs dont les actions vont encourager les acteurs directs à changer de pratique). Ensuite, les ressources sont listées et caractérisées. Troisièmement, la dynamique des acteurs est définie. Enfin, on synthétise les réponses pour formuler les interactions entre les acteurs et les ressources.

Chaque atelier est une collaboration entre des stackholders et deux personnes spécifiques : un animateur et un observateur/enregistreur. L'animateur assure la clarté et l'accord général sur les termes ou concepts utilisés. Tandis que, l'observateur/enregistreur suit l'échange entre les membres du groupe ou entre un participant et l'animateur. Par le travail de ces rôles, on peut obtenir des réseaux sociaux, une meilleure compréhension des différents modèles mentaux et la trajectoire pour atteindre un accord entre les intervenants.

A l'image de l'approche Commod, ARDI a l'avantage de clairement définir des rôles, un cycle de modélisation cohérent, des guides, et des outils de supports (le tableau interactif ou les
documents). Cependant, ces outils de supports sont utiles pour des ateliers où on se groupe au un même lieu. Cette méthode ne supporte pas le travail à distance. De plus, cette méthode se focalise sur le modèle conceptuel. Il manque des guides pour les étapes suivantes (l'implémentation et la simulation).

### 3.2.5 KIMONO

KIMONO (Keep It Modular, Open-ended, and Neatly Organised) est une méthode pour la conception de modèle World [Amouroux 2011]. Il s'agit d'une séquence de modèles permettant aux experts du domaine de répondre à une question exploratoire ou explicative. Les modèles mondes sont utilisés pour aider les experts du domaine à évaluer leurs hypothèses et orienter leur recherche. Précisément, un modèle monde représente explicitement les constituants du système de référence, y compris l'individu et l'environnement.

Cette méthode est constitué de 4 éléments principaux : (1) Une définition des rôles des contributeurs ; (2) Un cycle de modélisation ; (3) Des guides de modélisation ; et (4) Des outils informatiques. Comme présenté dans la figure 3.8, la colonne à droite identifie des rôles différents à chaque étape du cycle de modélisation qui est au centre.

Pour les rôles des contributeurs, l'auteur a re-utilisé le résultat de [Drogoul 2003], avec trois rôles : le thématicien, le modélisateur et l'informaticien et ajouter le rôle initiateur. Le premier qui est responsable pour le modèle conceptuel fournit la connaissance concernant le système de référence et conduit le processus de modélisation. Tandis que, le modélisateur et l'informaticien sont considérés comme des rôles de supports qui s'occupent du développement. Le rôle d'initiateur est la personne qui met en évidence les questions scientifiques, et les problèmes à étudier. Cette personne demande la conception d'un modèle monde pour résoudre leur problème. Ainsi, il est impliqué dès le début de la modélisation, comme illustré dans la figure 3.8.

Un des objectifs de cette méthode est de répondre au manque de données ainsi qu'à l'utilisation de multiples sources de données. Par conséquent, l'auteur associe le cycle de [Drogoul 2003] et la façon d'élicitatier des connaissances collectives de l'approche ARDI [Etienne 2011] afin de former le cycle de modélisation de KIMONO. Ce cycle contient deux parties principales : l'étape initiale et la modélisation itérative. La première partie qui est correspondant avec les quatre premières étapes dans la figure 3.8 vise à éliciter le modèle du domaine. Cette élicitation est réalisée collaborativement par les thématiciens avec l'aide du modélisateur. Ce modèle du domaine est représenté par des ontologies et des textes qui constituent la partie *Overview* du protocole ODD [Grimm 2010]. Après cela, une étape de l'évaluation va examiner la compléture des données. Si elles sont incomplètes, une recherche de nouvelles données va être réalisée parallèlement au processus de modélisation.

Ensuite, une étape pour former l'objectif et évaluer les données de l'itération est proposée. Il s'agit de concevoir consécutivement trois modèles : le modèle conceptuel, le modèle opérationnel et le modèle implémenté qui adaptent le travail de [Drogoul 2003]. Puis, c'est l'étape d'exécution et d'évaluation du modèle qui est basé sur la macro-connaissance des thématiciens. Cette étape permet à l'initiateur de décider si le problème est résolu ou si on doit répèter la boucle de modélisation (dans le cas où le manque de connaissances bloque l'avancement).

Lors de chaque séquence de modélisation itérative, un document ODD est créé. Il re-exploites produits lors des étapes précédentes. Ce travail est similaire avec celui de l'observer.
<figure><img src="image_23.png" /><figcaption>FIGURE 3.8 – KIMONO [Amouroux 2011]</figcaption></figure>

vateur/enregistreur dans la méthode ARDI. Il permet de créer une représentation commune entre des intervenants pour partager les connaissances.

L'avantage de cette méthode est de fortement impliquer les thématiciens dans la modélisation : ils sont le centre du processus. D'autre part, cette méthode permet de surmonter le manque de données par une étape initiale d'élicitation des données requises. De plus, elle a