Résolution de problèmes et simulations : différences et similitudes

Lorsqu’on présente un système multi-agents réactifs pour la résolution de problèmes, et particulièrement quand on laisse apparaître le processus de convergence, un observateur naïf s’extasie souvent devant “cette intéressante simulation”, et ne détecte pas les capacités de calcul du système. En effet, si l’on compare l’apparence des travaux relatifs à la simulation comportementale, et celle de la résolution de problème, on a globalement les mêmes phénomènes : initialisation à partir de situations peu structurées, ou très localisées, puis développement, exploration, agrégation, et stabilisation éventuelle en formes structurées, liées à l’environnement. Et il n’y a réellement pas de différence dynamique. Le processus parallèle est le même que l’on fasse une simulation de fourmilière ou une segmentation d’image.

Les différences sont ailleurs, et relèvent de trois points principaux : la finalité et l’orientation de la conception, l’exploitation de la dynamique, et la traduction d’éventuels états de convergence. Une de nos contributions est d’expliciter les différences et l’orientation que l’on peut prendre dans chacune des phases.

En premier lieu, la finalité et les données de la simulation et de la résolution sont très différentes. Simuler, c’est produire une représentation informatique dynamique d’un phénomène, à partir de descripteurs essentiellement locaux, et afin d’observer les implications globales que ceux-ci peuvent avoir lors de l’activation parallèle des fonctionnalités, de les comparer à des formes connues dans le monde réel, et d’en inférer la validité des hypothèses initiales. Une simulation validée peut alors devenir un outil de prévision. Résoudre un problème, c’est le transcrire dans un système dynamique dont l’état doit pouvoir être interprété comme une solution en cours d’élaboration. Dans le cas de la simulation, soit on connaît les comportements locaux, et on veut observer leurs conséquences globales (objectif de prévision et de conception de systèmes complexes), soit on connaît des formes globales, et on souhaite valider des hypothèses sur les comportements locaux les ayant produites (exploration descendante), mais dans les deux situations on conçoit à partir d’une situation initiale donnée. On notera que l’élaboration des hypothèses locales productrices de formes globales n’est pas du ressort du concepteur informaticien, mais d’un modélisateur disciplinaire spécialiste du domaine simulé.

Modèles Multi-Agents pour l’Aide à la Décision et la Négociation en Aménagement du Territoire

124 Pour la résolution de problème, on souhaite trouver la façon d’organiser spatialement (localisation) ou temporellement (ordonnancement) un système pour satisfaire des contraintes, à partir d’une situation initiale connue ou non (différence entre la recherche des transitions ou simplement des positions). On conçoit donc ici à partir de la situation finale. Plus précisément, on doit découvrir le bon système qui respectera dans ses différents états les contraintes du problème, et pourra, en évoluant, les réduire. La problématique conceptuelle est donc très différente puisqu’il faut imaginer a priori une structure de système apte à produire différentes formes. Et ceci en s’abstrayant de la sémantique et du contenu, puisque l’interprétation est du ressort de l’utilisateur (approche réactive). Il n’y a pas, pour ce faire, de méthode stricte ; et on peut noter que la confusion entre simulation et résolution peut être entretenue par l’usage répétée de “simulation de résolution de problèmes” : ignorant souvent toute méthode de spécification locale à partir de formes globales, on est amené à faire des essais, et donc à tester des choix de structures d’agents en les activant, et en observant quelles formes sont obtenues. On a donc alors transité par une simulation pour établir des règles de construction, utilisables a posteriori directement à partir des spécifications d’un problème. En réalité il s’agit là de la phase classique de “mise au point” ou de réglage du système de résolution, avant son utilisation effective sur des cas réels. Par ailleurs, lorsqu’on dispose de bonnes solutions obtenues par d’autres méthodes, on peut souhaiter ajuster le fonctionnement jusqu’à atteindre les mêmes résultats. En résumé, dans le cas d’une simulation, la démarche conceptuelle de l’informaticien est très faible, puisqu’il a juste à proposer la bonne architecture permettant la mise en oeuvre des descripteurs proposés par le modélisateur du domaine source ; alors que pour la résolution de problème, l’informaticien doit, après avoir recueilli les données et contraintes auprès du client, concevoir la structure et les interactions produisant les formes souhaitées. L’idéal conceptuel serait de disposer d’une catégorisation des problèmes, assorties d’une analyse préalable, et telle que l’informaticien n’aurait qu’à identifier la bonne classe, puis appliquer la structure recommandée.

En deuxième lieu, il faut s’interroger sur le statut de la dynamique (l’évolution des états au cours du processus). Est-elle l’objet ou l’outil du processus ?

En simulation, qu’elle soit ascendante ou descendante, on construit un système pour en observer l’évolution et conclure sur les hypothèses locales initiales ou sur les formes atteignables. La dynamique est donc un produit de la conception, que l’utilisateur va, au besoin, analyser et exploiter si le déroulement l’intéresse (dans le cas par exemple des

simulations de processus temps-réel où le temps n’est pas une variable explicite). A l’extrême, lorsque le but d’une simulation ascendante est de reproduire un processus temporel connu par observation du processus réel, le concepteur / utilisateur va ajuster le système afin de produire une dynamique donnée ; mais il n’y a pas de critère général a

priori quant à sa forme ou ses caractéristiques.

A l’inverse, en résolution de problèmes, la dynamique du système est une “machine à produire des solutions”, puisque on introduit des contraintes, des descripteurs, et on “laisse faire la machine” en espérant qu’on l’a bien conçue, et qu’elle nous donnera une ou des solutions. La dynamique est donc un outil qu’il va s’agir de construire au mieux. La qualité de la conception, et donc du résultat, réside dans différentes caractéristiques souhaitées : la convergence tout d’abord, sans qui « la machine à résoudre » ne s’arrête jamais ; puis la pertinence, qui assure que l’état produit est une solution au problème ; la rapidité, qui précise que la convergence ne doit pas seulement avoir lieu, mais que de plus elle doit se faire en un temps raisonnable pour les ressources disponibles ; l’économie, qui précise que les ressources utilisées doivent être minimales pour un produit donné ; la contrôlabilité, qui garantit que l’on peut d’une part évaluer l’état d’avancement du processus, et d’autre part éventuellement le réorienter ; la simplicité enfin, parfois corollaire de l’économie, qui permet que des utilisateurs non experts puissent produire des solutions, et éventuellement comprendre le processus source. Une caractéristique complémentaire peut s’ajouter aux précédentes, bien qu’elle ne soit pas intrinsèquement exigée : la flexibilité, c’est-à-dire la capacité de la machine à produire des solutions à d’autres problèmes avec des ajustements mineurs. En résumé, la conception d’un système pour la résolution de problèmes fait de la dynamique un outil très élaboré qu’il va s’agir d’optimiser. Une de nos propositions porte donc sur la façon de construire un système multi-agents pour la résolution de problèmes, dont la dynamique réponde aux caractéristiques précitées.

Enfin, en troisième lieu, la traduction que l’on donne des états de convergence est très dépendante de la finalité du processus mis en oeuvre. Dans une simulation, l’état du système, quel qu’il soit, est signifiant, car il peut être interprété comme une possible situation atteinte dans le temps ou l’espace ; en revanche, pour la résolution d’un problème, seuls les états stables sont intéressants, car ils caractérisent l’atteinte d’un attracteur, et donc d’un “satisfecum” au sens de Simon [1977]. Toute situation intermédiaire non stable, par un principe dynamique très simple, est nécessairement améliorable, pour peu que le “paysage dynamique” ne soit pas simplement tout plat (entropie nulle) et que les états

Modèles Multi-Agents pour l’Aide à la Décision et la Négociation en Aménagement du Territoire

126 soient bornés (hypothèse admissible pour des problèmes réels : contrainte pragmatique). Les cas d’oscillation, si on oublie qu’ils sont souvent peu identifiables (surtout pour des excursions importantes), peuvent refléter formellement l’existence de solutions étendues, et non plus seulement ponctuelles ; ce qui se traduit par l’équivalence de ces différents états par rapport au problème. Cependant, les oscillations dans la résolution de problème manifestent plus généralement que le système est “trop chaud”, et que les variations d’état devraient être davantage limitées pour amener une stabilisation sur un point fixe. Donc, en résolution de problèmes, on recherche la convergence vers des états ponctuels stables, alors qu’en simulation elle est indifférente, hormis si l’émergence de structures stables est un phénomène observé. A l’extrême, il n’est jamais nécessaire de présenter à l’utilisateur final les états intermédiaires d’une résolution de problème.

Ceci doit cependant être tempéré dans le cas où on utilise une simulation pour résoudre un problème de type spatio-temporel (ordonnancement). Dans un premier temps on valide un modèle descriptif de l’environnement par simulation, en n’introduisant pas les objets commandable. Puis on ajoute ces objets, et on teste des dynamiques locales, éventuellement interdépendantes, jusqu’à ce que les formes spatio-temporelles émergentes satisfassent différentes contraintes. Enfin on applique ces dynamiques au système réel, en espérant que la clôture du modèle n’a pas induit de divergences trop marquées avec la réalité. Dans ce cas, et bien que pratiquement on résolve un problème, les états intermédiaires semblent utiles car descriptifs des trajectoires à respecter. Mais il faut ici bien distinguer ce que l’on pourrait appeler des solutions “en extension” de solutions “en intention” : si on enregistre la totalité des trajectoires (en extension) pour les faire suivre a

posteriori par les objets réels, comme une consigne stricte, on a effectivement résolu un

problème, puis appliqué la solution ; si en revanche, on porte du modèle au réel les comportements réactifs mis en oeuvre (fonctions d’entrées et d’activation), alors on ne fait qu’utiliser les résultats d’une simulation que l’on espère valide. Dans le cas en extension, l’espace d’état lui-même inclut la dimension temporelle (ou celle du processus réel), et donc la solution décrite dans cet espace n’est valable qu’après convergence au sens de l’évolution de la solution (temps de calcul, et non temps du processus). De nouveau seuls les états stables sont signifiants.

Par ailleurs, la représentation de l’état se suffit à elle-même en résolution, alors qu’en simulation on doit généralement introduire des indicateurs permettant d’observer le processus et de la comparer à des données. En effet l’intérêt même des approches

multi-agents est de permettre la simulation de grands systèmes complexes (nombreuses entités) spécifiés localement ; or ils sont plus signifiants en regard des formes globales émergentes que des comportements locaux. Seuls des indicateurs globaux (variables "moyennantes") peuvent éventuellement nous renseigner sur la ressemblance éventuelle avec un système réel. Ceci est très classique pour les systèmes complexes où des propriétés émergent sous certaines conditions (cf. l’exemple du magnétisme), et n’ont de sens que globalement. L’état exact du système obtenu n’a alors pas d’importance, mais c’est plutôt sa structure qui est déterminante (connectivité, extension, fractalité). En résolution l’état exact constitue la solution. La répartition précise est signifiante.