Premi` ere approche : sur les structures informatiques

La premi`ere direction que nous prendrons concerne une approche m´ethodologique de la mani`ere dont il nous faut conduire nos exp´eriences de simulations multi-agents, notamment lorsqu’une approche formelle du mod`ele fait d´efaut. L’approche propos´ee dans ce cadre re- pose sur la proposition d’outils g´en´eriques permettant de concevoir des simulateurs dont le fonctionnement soit explicite et flexible. Notre motivation est double :

– rendre explicites les structures informatiques utilis´ees dans un simulateur. L’id´ee est que si les sp´ecifications des mod`eles doivent correspondre `a des structures informatiques, il

4.4 Choix de recherche 89

est n´ecessaire de les rendre explicites. Ce qui permettra aussi de faciliter l’´elaboration de r´eplications ind´ependantes.

– permettre l’exploration d’un mod`ele en facilitant les possibilit´es de variations sur son impl´ementation. Il s’agit ici de faire un effort sur la r´eutilisabilit´e des outils qui sont con¸cus

R´eplications ind´ependantes

Si l’on part du constat que la dynamique de tout mod`ele multi-agents peut potentiellement ˆetre biais´ee par son impl´ementation, ce qui est vrai dans la majorit´e des cas, et que de surcroˆıt la plupart des mod´elisations sont propos´es de fa¸con informelle, une r´eplication ind´ependante de l’exp´erience originale est sans doute l’un des meilleurs moyens de contrecarrer le ph´enom`ene de la divergence impl´ementatoire. Dans le vocabulaire de la simulation classique, on qualifie ce type d’approche de v´erification et validation ind´ependante (independent verification and validation IV&V) [Arthur & Nance, 1996, Sargent, 2001]. Sargent distingue deux fa¸cons de proc´eder suivant que la r´eplication est effectu´ee en parall`ele de l’exp´erience originale ou a posteriori. A ce propos, il est int´eressant de noter que la premi`ere est jug´ee beaucoup plus rentable que la seconde. Sargent explique que l’une des conclusions de l’´etude men´ee par [Wood, 1986] sur de nombreux projets est que, pour un coˆut prohibitif, le seul b´en´efice d’une r´eplication a posteriori est de permettre une ´evaluation qualitative des moyens de v´erification et de validation qui ont d´ej`a ´et´e mis en œuvre dans l’exp´erience originale. Finalement, qu’elles soient appliqu´ees a priori ou a posteriori, les m´ethodes de IV&V n’ont jamais ´et´e vraiment tr`es populaires et leur int´erˆet n’a que rarement ´et´e mis en avant.

Arthur et Nance pensent que c’est un tort et que la plus-value de cette approche est largement sous-estim´ee dans le domaine de la simulation [Arthur & Nance, 2000]. Leur id´ee est qu’il s’agit d’une m´ethode qui doit ˆetre mise en parall`ele avec ce qui se fait aujourd’hui dans l’ing´enierie logicielle classique o`u ce type de m´ethodes est largement int´egr´e dans le processus de d´eveloppement. L’importance des bˆeta testeurs dans le cycle de vie d’un logiciel complexe en est la parfaite l’illustration.

Dans le cadre de notre probl´ematique, l’exp´erience de Edmonds et Hales nous a clairement montr´e l’utilit´e de la r´eplication5 et nous avons vu que cette approche comporte de nombreux avantages. Dans un premier temps elle est ´evidemment le moyen de rendre explicite un ph´e- nom`ene de divergence impl´ementatoire lorsque les diff´erentes r´eplications ne donnent pas les mˆemes r´esultats. Mais surtout, elle peut potentiellement r´ev´eler les diff´erents points o`u le mo- d`ele souffre d’un manque de sp´ecification engendrant une ambigu¨ıt´e sur son impl´ementation. Par ailleurs, en fournissant une nouvelle batterie de r´esultats, elle donne aussi un point de comparaison suppl´ementaire (parfois le premier) qui est le bienvenu.

Pour que ce type de m´ethodes puisse ˆetre g´en´eralis´e, il est important que la communaut´e ´elabore de plus en plus d’outils de conception logicielle qui facilite le d´eveloppement de simu- lateurs multi-agents quel que soit le contexte de leur utilisation (cf. section4.3.3). Autrement dit, l’un des principaux d´efis est aujourd’hui celui de la r´eutilisabilit´e des logiciels que nous concevons. Les outils de conception de simulateurs que nous pr´esenterons dans le chapitre suivant ont ´et´e ´elabor´es autour de cette id´ee.

5

Il est tr`es int´eressant de noter que les auteurs n’ont pas seulement r´ealis´e une r´eplication a posteriori, mais qu’ils ont aussi ´elabor´e un nouveau mod`ele ind´ependamment l’un de l’autre. D´emarche qui leur a ´et´e d’une grande utilit´e pour mettre au jour les insuffisances des sp´ecifications du mod`ele original.

Variations sur l’impl´ementation

R´ealiser une r´eplication dont l’impl´ementation est effectu´ee par une tierce personne n’est cependant pas toujours possible pour des raisons ´evidentes de disponibilit´e en moyens hu- mains. Dans le cas o`u une seconde impl´ementation r´ealis´ee ind´ependamment par un autre programmeur n’est pas possible, r´epliquer une seconde fois l’exp´erience suivant de nouvelles orientations peut sembler inutile. Il y a effectivement de fortes chances pour que la nouvelle impl´ementation ne soit fondamentalement pas diff´erente de la premi`ere ´etant donn´e qu’on ne change pas de programmeur. De plus, il s’agit l`a d’une tˆache tr`es contraignante dans la me- sure o`u le d´eveloppement d’un seul simulateur demande d´ej`a de nombreuses heures de travail. R´eimpl´ementer un nouveau simulateur peut alors paraˆıtre bien trop coˆuteux pour un r´esultat dont on fait l’hypoth`ese qu’il sera similaire. Ce qui peut bien sˆur ˆetre un mauvais calcul.

Faut-il pour autant se limiter `a une seule version de l’impl´ementation ? Nous pensons bien sˆur que non. S’il n’est effectivement pas tr`es productif de red´evelopper soi-mˆeme enti`erement un simulateur, il est par contre tout `a fait pertinent d’impl´ementer des variations sur les diff´erents modules qui le constituent. Mˆeme si, du point de vue de la validation, cela n’a pas la mˆeme valeur qu’une r´eplication ind´ependante, modifier les points cl´es du fonctionnement interne du simulateur pr´esente les mˆemes int´erˆets : d’une part cela permet d’identifier une potentielle influence de celui-ci sur les r´esultats et d’autre part cela donne des points de comparaison concrets. Certains des travaux que nous avons pr´ec´edemment cit´es, notamment [Axtell, 2000a,Lawson & Park, 2000,Edmonds & Hales, 2003,Meurisse & Vanbergue, 2001,

Michel, 2000], sont bas´es sur cette id´ee : `a partir du constat du ph´enom`ene de divergence impl´ementatoire, ils montrent la n´ecessit´e d’explorer plusieurs impl´ementations diff´erentes.

Finalement, de la mˆeme mani`ere qu’il est souhaitable d’effectuer une analyse de sensibilit´e du mod`ele `a ses diff´erents param`etres, on voit ici toute la n´ecessit´e de concevoir des outils de simulation permettant d’explorer les diff´erentes fa¸cons dont un syst`eme multi-agents peut ˆetre impl´ement´e afin de mesurer leurs impacts sur les r´esultats produits par le simulateur. Dans le cadre de l’analyse de sensibilit´e, le logiciel SimExplorer propose par exemple une approche qui permet d’explorer les diff´erents param`etres d’un mod`ele ind´ependamment de sa nature grˆace `

a l’identification de fonctionnalit´es logicielles g´en´eriques [Amblard et al. , 2003]. Nous verrons dans le chapitre suivant que les outils de conception de simulateur que nous d´ecrirons ont ´et´e ´elabor´es dans le mˆeme esprit en ce qui concerne l’impl´ementation du mod`ele lui-mˆeme. Par ailleurs, ces outils nous ont permis de conduire nos recherches suivant la deuxi`eme direction que nous souhaitons aborder dans ce document.

4.4.3 Deuxi`eme approche : sur les principes de mod´elisation multi-agents