Simuler les morphogenèses des systèmes de villes

 Simuler les morphogenèses des systèmes de villes

Aspects informatiques de Simpop2

Nous pouvons voir sur la chronologie (figure 4.1 page 103) que le projet Simpop2 était très largement avancé au démarrage de cette thèse. Nous n’avons participé ni `a la conception du modèle, ni `a la réalisation de la partie générique commune `a toutes les applications, ni `a celle de l’application Europe dont nous présentons pourtant les résultats dans la suite. Il existe au jourd’hui une documentation abondante sur Simpop2 et ses résultats :

• Des articles présentant les ambitions du modèle et de ses applications, et les règles du modèle dans le détail [SFM+05, SM08, PSB+09, BP10a]; • Des articles exposant les résultats de campagnes d’expérimentation sur les applications Eurosim [SM08], Europe et Etats-Unis [PSB+09, BP10b, BP10a];

• Uneanalyse des propriétés du méta-modèle multi-agents, et une comparaison `a neuf autres modèles dans un ouvrage de référence sur la simulation `a base d’agents [TDZ08]; • Un rapport de stage de master centré sur une étude de sensibilité des mécanismes d’inter action [Sch08]; • Un site web dédié4, sur lequel nous reviendrons dans la section 7. En nous inscrivant dans la distinction (clairement présentée dans [Meu04] et [DVM02], et reprise dans [TDZ08]),

entre le modèle de conception, le modèle opérationnel et le programme, notre objectif dans cette section n’est pas de décrire les deux premiers des trois, et nous invi tons le lecteur `a se reporter aux sources mentionnées ci-dessus pour étudier comment ceux-ci traduisent la théorie évolutionnaire urbaine dont nous avons tracé les grandes lignes dans le chapitre précédent. En revanche, bien que nous n’ayons pas participé `a sa réalisation, il nous a semblé important de dédier quelques paragraphes `a la présentation du programme Simpop2, et cela pour au moins deux raisons :

1. Le programme développé n’est que superficiellement présenté dans [Gli07], et n’a jamais fait l’objet d’une documentation écrite de plus haut niveau que les commentaires par cellaires intégrés au code5. L’implémentation d’un mod` ele est parfois considérée comme peu valorisante, notamment en comparaison de la conception, de l’expérimentation et des résultats. En 2002, forts de dix ans d’expérience en tant qu’informaticiens dans des projets de simulation orientée agents, A.

Drogoul et ses collègues notaient que « dans la plupart des projets existants, [un mod` ele opérationnel `a base d’agents computationnels] est souvent négligé au profit d’une implémentation directe, ce qui est en partie dˆu au fait que l’informa ticien, dans beaucoup d’institutions, est toujours considéré comme un simple « exécutant » (citant [Dav02]) » [DVM02]. Or le programme Simpop2 se distingue en réifiant le mod` ele opérationnel dans un programme `a base d’agents computationnels. 2. Une retombée attendue d’une collaboration avec des informaticiens est un logiciel fonc tionnel pour étudier une question qui n’aurait pu l’ˆetre sans.

Mais au vu des contraintes associées aux projets interdisciplinaires, parmi lesquelles leur durée, un petit nombre de développeurs, et de la volatilité de ces derniers, la maintenabilité du code est un critère tout aussi critique que ses fonctionnalités. Un code exprime des idées, c’est une pièce de sa voir constructif. En faisant le point sur l’état actuel du code, nous discutons de l’incidence de certains choix techniques effectués sur sa maintenabilité et son devenir potentiel.

Le programme multi-agent

L’implémentation du modèle générique Simpop2 et de ses applications s’appuye sur l’API Swarm, et donc sur Objective-C6. La présentation de morceaux choisis de ce programme nous permet d’en illustrer trois aspects intéressants. Avec le premier nous examinons la réponse apportée par les programmeurs de Simpop2 `a la question « Comment programmer des agents computationnels avec un langage `a objets? ».

Nous essayons de démarquer l’agent de l’objet, nous déconstruisons l’ontologie urbaine réalisée, et nous regardons les constructions Objective-C mises `a profit pour permettre de « dépasser » les limitations des objets du langage et constituer des agents villes. Le second point concerne la gestion du temps dans le modèle, sujet central en simulation. Le troisième concerne la représentation de l’espace et quelques optimisations pour accélérer les calculs spatiaux. 

Comment programmer des agents-villes ` a partir d’un langage ` a objets?

Agents et objets. Nous l’avons dit dans le chapitre précédent, en simulation ces vingt dernières années, l’agent est un concept dont l’expressivité a prouvé son utilité `a médier l’échange entre informaticiens et géographes en phases d’analyse et de conception, mais qui souvent s’évapore `a la réalisation. Pour [DVM02], « les agents computationnels décrits en IAD ou en SMA(faisant référence `a [Jen00]) ne sont tout simplement pas utilisés par la simulation orientée agents ».

Pour le courant geosimulation par exemple, le terme « agent » est souvent assimilé `a « un objet mobile qui représente un acteur humain » [BT04, BAN05]. L’implémentation est donc souvent une traduction objet « immédiate » et appauvrie, qui ne fait pas le lien avec les architectures d’agents computationnels. J. Ferber résumait cet antagonisme en disant que « les agents sont définis `a un niveau conceptuel et les objets (…) aux niveaux d’implémentation et d’éxecution » [Fer95], chap. 1).