4.3.1 La tentation du programmeur
Loin d’ˆetre un cas marginal, il arrive que l’impl´ementation constitue le seul mod`ele de l’exp´erimentation. Autrement dit, il n’est pas rare que le mod`ele ne soit pas explicit´e, sous une autre forme que le langage naturel, en dehors du programme informatique utilis´e pour r´ealiser la simulation. Quel programmeur de simulations multi-agents n’a jamais impl´ement´e un simulateur sans ´elaborer au pr´ealable un mod`ele papier de la dynamique du syst`eme ? Ce qui s’explique en partie par le manque de formalismes adapt´es aux syst`emes multi-agents trouve aussi ses raisons dans le fait qu’il arrive parfois qu’on ne sache pas exactement ce que l’on veut simuler. En cons´equence, le programme informatique r´esultant est souvent la seule manifestation du mod`ele que le designer ait `a l’esprit.
Prenons un exemple. Lorsque la d´emarche consiste `a inf´erer un syst`eme par exemple, l’ob- jectif est d’obtenir un mod`ele ayant un comportement macroscopique `a partir d’interactions microscopiques qu’on ne connaˆıt pas encore et qu’on cherche `a d´ecouvrir. Dans ce cas, un premier mod`ele informel est utilis´e pour r´ealiser une premi`ere impl´ementation. La suite lo- gique d’une telle exp´erimentation consiste bien sˆur `a r´eviser le mod`ele en fonction des r´esultats
4.3 Aux origines du probl`eme 85
obtenus par la simulation. Cependant, il n’est pas rare que la r´evision de ce mod`ele soit di- rectement concr´etis´ee par la modification de l’impl´ementation. A cela plusieurs raisons, d’une part le caract`ere informel du mod`ele laisse une grande libert´e au programmeur et d’autre part la complexit´e du programme obtenu pousse rapidement son concepteur `a consid´erer que cer- taines parties de son code peuvent ˆetre bugg´ees, ce qui l’am`ene `a r´eviser son impl´ementation sans avoir l’impression de toucher au mod`ele.
Il est bien sˆur important de programmer un simulateur en ´etant conscient qu’il ne faut pas faire de faute de programmation, cependant il y a ici un ´enorme pi`ege : un programmeur est capable d’ing´eniosit´e. Par cons´equent, tant que le comportement du syst`eme obtenu ne correspond pas aux attentes ou qu’il lui paraˆıt incoh´erent, le programmeur est fortement tent´e de modifier l’impl´ementation jusqu’`a l’obtention de r´esultats qui le satisfassent. Autrement dit, celui-ci va passer son temps `a modifier le simulateur, en changeant les m´ecanismes li´es aux diff´erents modules (scheduling, comportements des agents, gestion des actions et interactions, repr´esentation de l’environnement, etc.), pour que ce dernier r´eponde `a ses attentes. Etant donn´e la multitude des param`etres qui peuvent engendrer des biais de simulation, il est ici important de comprendre que le simulateur est, `a ce stade de l’exp´erimentation, un syst`eme pour lequel il n’existe pas encore de mod`ele papier ´equivalent.
A partir de l`a, il faut se demander dans quelle mesure le simulateur obtenu correspond encore `a l’id´ee du mod`ele originel : en est-il encore le reflet ? Si l’on prend le contre-pied de cette question et que l’on consid`ere maintenant que l’impl´ementation constitue elle-mˆeme le mod`ele, une autre question fondamentale doit ˆetre pos´ee : peut-on, `a partir du code informatique, ´etablir des sp´ecifications qui permettent de le comprendre, de l’exposer et de le r´epliquer ? Sans la possibilit´e de r´eplication, nous avons vu que l’interpr´etation des r´esultats n’a pas beaucoup d’int´erˆet pour ses utilisateurs potentiels. De plus, cet exercice de traduction, du fonctionnement du simulateur vers un mod`ele papier, est par ailleurs une ´etape indispensable si l’on souhaite communiquer les r´esultats de l’exp´erimentation. Cette d´emarche pose cependant le probl`eme de sa faisabilit´e. En effet, les changements apport´es au code source qui modifient la dynamique du syst`eme sont souvent assez subtils, ce qui ne facilite pas leur tra¸cabilit´e surtout lorsque les modifications ne sont pas ajout´ees de fa¸con atomique. Par cons´equent, leurs implications dans le r´esultat global en deviennent difficilement identifiables [David et al. , 2002]. La premi`ere question de ce paragraphe doit alors ˆetre pos´ee dans le sens inverse : le mod`ele ´elabor´e `a partir du code informatique repr´esente-t-il effectivement le fonctionnement du simulateur ? On peut l´egitimement en douter pour toutes les raisons que nous avons d´ej`a expos´ees. Nous pouvons r´esumer notre point de vue de la mani`ere suivante : simuler ne veut pas dire programmer.
4.3.2 Le probl`eme de l’interdisciplinarit´e
Nous avons vu que la simulation multi-agents est aujourd’hui utilis´ee dans de nombreux domaines de recherche. Ceci n’est bien sˆur pas sans poser quelques probl`emes qui contribuent au ph´enom`ene de divergence impl´ementatoire. Au-del`a des questions li´ees aux variations s´e- mantiques des diff´erentes terminologies employ´ees, l’interdisciplinarit´e pose encore une fois le probl`eme de la traduction des mod`eles envisag´es dans des structures informatiques qui leur correspondent [Vanbergue, 2003,Meurisse, 2004]. Autrement dit, nous nous int´eressons ici aux probl`emes pos´es par le passage d’un mod`ele multi-agents ´elabor´e par l’expert d’un domaine particulier, et donc non informaticien, `a son impl´ementation sur ordinateur par un expert en informatique. Comme nous allons le voir, ce processus est bien sˆur affect´e par les diff´erents points que nous avons d´ej`a expos´es auparavant. En fait, il les catalyse.
Comme nous l’avons dit dans le chapitre pr´ec´edent, l’approche multi-agents constitue un outil de mod´elisation dont les d´efinitions des principes fondamentaux (autonomie, proacti- vit´e, etc.) restent encore aujourd’hui assez floues quant `a la mani`ere dont ils doivent ˆetre impl´ement´es. En partie li´ee `a la volont´e de ne pas restreindre le champ d’application des syst`emes multi-agents en contraignant leurs impl´ementations (d’o`u l’utilisation syst´ematique de la d´efinition faible d’agent, cf. section 3.1.1 page 45), cette absence de correspondance entre le paradigme et des structures informatiques concr`etes ne facilite en rien la mod´elisation et la simulation de ces syst`emes. Comme le souligne tr`es justement l’analyse propos´ee dans [Drogoul et al. , 2002], la difficult´e que nous avons `a sp´ecifier ce qu’est r´eellement un agent d’un point de vue computationnel se retrouve `a tous les niveaux de la conception d’une simu- lation multi-agents. Notamment, les auteurs expliquent que l’expert d’un domaine particulier ne peut avoir qu’une id´ee approximative de ce qu’il est v´eritablement possible de mod´eliser ou non grˆace `a ce paradigme. En effet, dans le cas g´en´eral, celui-ci ne poss`ede pas la connaissance qui lui permettrait d’appr´ehender la mani`ere dont son savoir peut ˆetre concr`etement traduit en langage informatique.
Par cons´equent, lors de l’´elaboration de son mod`ele, l’expert se concentre principalement sur la sp´ecification de deux aspects de celui-ci : la d´efinition du comportement des entit´es in- dividuelles et la nature de l’environnement dans lequel celles-ci vont ´evoluer. Cette approche a bien sˆur l’inconv´enient majeur d’´evacuer en partie les probl`emes qui sont li´es `a l’impl´emen- tation. La tentation dont l’expert en informatique charg´e d’impl´ementer le mod`ele fait d´ej`a l’objet est alors largement amplifi´ee : malgr´e les impr´ecisions du mod`ele, il lui faut cependant l’impl´ementer d’une mani`ere ou d’une autre. En cons´equence, la dynamique du mod`ele est ici aussi fortement modifi´ee par l’interpr´etation que celui-ci en fait lorsqu’il l’impl´emente. Il est alors, encore une fois, impossible de garantir que le programme informatique obtenu est bien l’expression de ce que l’expert du domaine a en fait `a l’esprit.
On ne peut pas ici ne pas mettre en cause l’expert en informatique. En effet, il est de sa responsabilit´e d’informer l’expert du domaine qui lui a command´e l’exp´erimentation des limitations et des probl`emes qui sont li´es `a l’utilisation du paradigme agent. Ceci est d’autant plus important que cela doit permettre d’´eclaircir les points o`u le mod`ele propos´e pose des probl`emes quant `a son impl´ementation. A ce propos, on peut dire que la simulation multi- agents est en quelque sorte victime de son succ`es : de part son aspect novateur, elle a s´eduit des personnes d’horizons divers qui ne sont pas toujours au fait des probl`emes que nous avons soulev´es. Par ailleurs, la mont´ee en puissance r´eguli`ere des processeurs et l’ergonomie croissante des plates-formes ont facilit´e l’acc`es `a cette technologie en r´eduisant les investissements humain et financier n´ecessaires `a de telles exp´erimentations.
4.3.3 L’embarras du choix
Nous avons vu que la mani`ere dont sont publi´es les r´esultats d’une simulation est un facteur qui ne facilite pas leur r´eplication et leur r´eutilisation dans un autre contexte que celui de l’exp´erience originelle. A propos de r´eutilisation, le tr`es grand nombre de plates-formes existantes rend bien sˆur encore un peu plus difficile le partage des travaux de recherche. Il faut alors se demander pourquoi il existe autant de plates-formes.
Lorsqu’on en vient `a attaquer l’´etape d’impl´ementation du mod`ele, deux solutions sont envisageables : impl´ementer le mod`ele sur une plate-forme pr´eexistante ou d´evelopper son propre simulateur. Vu le nombre important de plates-formes aujourd’hui disponibles, on pour- rait s’imaginer qu’il n’y a que l’embarras du choix et qu’il existe forc´ement une plate-forme qui
4.3 Aux origines du probl`eme 87
r´epond aux besoins de l’exp´erience. En fait, il s’agit bien d’un embarras. A vrai dire, la majo- rit´e des projets de simulation multi-agents choisissent la deuxi`eme solution et d´eveloppent leur propre plate-forme. Ce qui peut sembler paradoxal vu les efforts suppl´ementaires qui doivent ˆetre d´eploy´es pour aboutir `a un r´esultat. En fait, il existe principalement deux raisons `a cela. La premi`ere est li´ee au manque de souplesse des plates-formes de simulation. En effet, suivant la plate-forme cible, le mod`ele est plus ou moins contraint par les mod`eles environ- nementaux et les architectures agent qui sont support´es par celle-ci. Autrement dit, il est n´ecessaire de formater le mod`ele de mani`ere `a ce qu’il puisse ˆetre impl´ement´e en utilisant le ”langage” du simulateur. Dans certains cas cela peut ˆetre impossible, dans d’autres le mod`ele s’en trouvera consid´erablement affaibli. Etant donn´ee l’h´et´erog´en´eit´e des domaines abord´es, il n’est alors pas surprenant qu’il soit parfois n´ecessaire d’´elaborer une plate-forme sp´ecialement con¸cue pour r´epondre aux besoins particuliers de l’exp´erience consid´er´ee.
La deuxi`eme raison vient de ce que les techniques d’impl´ementation utilis´ees pour les diff´erents modules qui composent une plate-forme de simulation sont souvent encapsul´es et/ou tr`es mal document´es. Finalement, ´etant donn´ee la complexit´e des programmes utilis´es pour coder un simulateur multi-agents, chaque plate-forme constitue une instance singuli`ere qui apporte ses propres r´eponses aux probl`emes pos´es par la mod´elisation et l’impl´ementation des mod`eles multi-agents. Ce qui a pour cons´equence de rendre le fonctionnement interne d’un simulateur quelque peu ´esot´erique pour toute personne n’ayant pas particip´e `a son ´elaboration. En tant qu’utilisateur, il est ainsi souvent tr`es difficile, voire impossible, de maˆıtriser l’ensemble des rouages du processus de simulation et donc de contrˆoler que le simulateur n’engendre pas des biais dus `a sa propre impl´ementation. C’est pourquoi, il est sans aucun doute beaucoup plus rassurant de d´evelopper son propre simulateur car on peut alors en connaˆıtre tous les aspects. L’op´eration de d´eveloppement peut dans un premier temps paraˆıtre contraignante mais c’est bien la cl´e qui permet de v´eritablement contrˆoler son exp´erimentation.
Il faut donc consid´erer que, dans la majorit´e des cas, un projet de simulation n´ecessite l’im- pl´ementation d’une plate-forme qui lui convienne. Bien sˆur, une telle plate-forme peut dans une certaine mesure ˆetre utilis´ee pour d’autres probl`emes li´es au domaine concern´e mais il faut garder `a l’esprit qu’il est tr`es difficile d’obtenir une plate-forme ”cl´e en main” ayant un fort pouvoir de g´en´ericit´e. Les d´eveloppeurs de la plate-forme Swarm l’ont tr`es bien compris. En effet, cette plate-forme ne propose pas un syst`eme de simulation ”tout en un” o`u seul le com- portement des agents reste `a coder. Au contraire elle constitue un ensemble de biblioth`eques et de facilit´es logicielles destin´ees `a fournir les moyens de d´evelopper sa propre application. Le tr`es grand nombre d’applications ´elabor´ees sur le principe de Swarm (Repast, Echo, etc.) d´emontre l’utilit´e d’une telle d´emarche. D’ailleurs, `a propos de Swarm, il est plus juste d’utiliser les termes outils logiciels de conception de simulation plutˆot que plate-forme. Les outils de simulation que nous pr´esenterons dans le chapitre suivant ont ´et´e con¸cus dans le mˆeme esprit.
4.3.4 Le manque de formalisme ad´equat
Dans le chapitre pr´ec´edent, nous avons vu que la question de la mod´elisation de l’in- teraction soul`eve de nombreuses difficult´es. Nous avons notamment abord´e ce sujet lorsque nous avons pr´esent´e les probl`emes li´es `a la repr´esentation des actions simultan´ees. En fait, la difficult´e que nous avons `a mod´eliser de telles situations est sans aucun doute en partie res- ponsable du caract`ere informel de l’approche multi-agents. En effet, alors que ce paradigme de mod´elisation se fonde sur la d´efinition d’un ensemble d’entit´es autonomes agissant de concert
sur un environnement commun, tr`es peu d’approches proposent des solutions qui prennent en compte la simultan´eit´e des actions sous une autre forme que la r´esolution de conflits ou la mise en ordre s´equentielle des actions. Et comme nous l’avons vu, ce point pr´ecis est extrˆemement d´elicat et peut contribuer `a rendre le simulateur g´en´erateur de biais et les solutions couram- ment envisag´ees ne sont pas forc´ement satisfaisantes du point de vue de la mod´elisation du syst`eme. En fait, la mani`ere dont ce probl`eme est finalement mod´elis´e fait souvent partie des points flous du mod`ele. Points pour lesquels l’impl´ementation finale est donc largement laiss´ee `
a l’appr´eciation du programmeur en charge du simulateur.
D’une mani`ere plus g´en´erale, le manque de formalisme g´en´eralement associ´e aux mod´e- lisations multi-agents se refl`ete dans l’absence de correspondance entre les mod`eles qui sont utilis´es pour d´efinir un mod`ele de simulation multi-agents et des structures informatiques concr`etes.