Dans ce cas d’une approche procédurale, on peut par ailleurs remarquer que la structure du programme conduit à un arbre : « La structure sous-jacente au niveau de ces nœuds est un arbre au sens informatique du terme. » 1852 Aussi le deuxième doctorant, Frédéric Blaise, écrira-t-il encore en 1993 : « ces notions [topologie, géométrie, dynamique de croissance] se traduisent concrètement par une structuration des données et des programmes qui tend à suivre l’organisation de l’arbre lui-même. » 1853 Ainsi, un programme de simulation tendrait-il, par sa forme, à représenter en l’imitant l’architecture réelle de l’arbre simulé. Il n’y aurait de simulation que s’il y a imitation de l’organisation interne.
Il reste qu’un des apports majeurs de la thèse de Jaeger consiste en la séparation nette et explicite entre la topologie de la plante, gérée par le moteur de croissance, et sa géométrie, gérée par un module autonome compatible avec une chaîne de visualisation infographique standard :
‘« L’indépendance des tâches ‘Simulation ‘ et ‘Graphisme’ sous-entend des structures de données adéquates pouvant d’une part recevoir des résultats de simulation et, d’autre part, s’intégrer dans une chaîne de visualisation à vocation générale. » 1854 ’Plus loin :
‘« De plus, la simulation numérique a obligé à penser clairement les concepts de modélisation. » 1855 ’Cette précision de Jaeger est fondamentale. Sans le dire, il reprend en fait cette distinction explicite entre le topologique et le géométrique à Alvy Ray Smith et à sa façon de résoudre informatiquement le vieux problème d’interprétation géométrique des L-systèmes 1856 . Elle permet de comprendre que c’est le langage évolué et structuré, le FORTRAN puis le C, qui, petit à petit, commence à prendre en charge la communication jusque là houleuse ou impossible entre les différents formalismes (topologique stricte, probabiliste et géométrique). Jaeger fait ici la même expérience que Hogeweg en 1978 : il découvre que la traduction d’un algorithme en un langage différemment structuré oblige à penser et à faire construire autrement le modèle par l’esprit comme par l’ordinateur. Les structures informatiques servent alors de lieux formels de médiation, de schèmes médiateurs entre des axiomatiques hétérogènes. Le langage C va même plus loin encore puisqu’il n’oblige pas seulement à distinguer différentes procédures agissant sur des données, comme le HPL, le FORTRAN ou le PASCAL, mais plutôt différentes structures d’objets que l’on définit formellement mais réalistiquement à partir de la liste de leurs propriétés. Dans cette problématique de simulation, Jaeger et de Reffye éprouvent donc à nouveau ce que nombre de concepteurs de systèmes experts avaient déjà vécu dès les années 1960 : une sorte de reflux critique de l’informatisation sur les connaissances et les conceptualisations. Le modèle n’est pas seulement traduit en un langage informatique. Il est clarifié, complexifié et, même ici, rendu possible dans la mixité de sa conception même, par la programmation. Ce que montre d’ailleurs très vite l’informatisation structurée dans le cas de l’AMAP, c’est que la classification très qualitative de Hallé et Oldeman serait peut-être même à réorganiser, comme le suggère déjà Claude Edelin à l’époque 1857 .
| SIMULA est un langage de simulation discrète issu d’ALGOL 60 et créé en 1964 par deux informaticiens du Centre de Calcul Norvégien d’Oslo (Ole-Johan Dahl et Krysten Nygaard). Ses concepteurs ont notamment cherché à systématiser la forme qu’avait prise une série de simulations sur ordinateurs effectuées lors de la conception du missile Minuteman, aux Etats-Unis, en 1957 1858 . Ces simulations avaient consisté à séparer le problème très complexe de la simulation du missile en vol en « composants » hétérogènes : « composant structure », « composant frottement dans l’air », « composant trajectoire », etc. Le système informatique consistait à faire communiquer ses composants autonomes au cours de la simulation. L’intérêt était que chaque composant incorporait une expertise particulière très poussée qui ne communiquait que le strict nécessaire aux autres : le programme général avait pour simple fonction d’encadrer ce qui s’apparentait à « un groupe de spécialistes travaillant ensemble pour résoudre un problème » 1859 . Mais plus que la notion anthropomorphe de « spécialiste », c’est la notion d’« objet » qui va remplacer celle de « composant » dans SIMULA. Ce langage est en effet conçu pour faciliter la description formelle des règles opératoires affectant les systèmes à événements discrets 1860 . Ses concepteurs avaient auparavant travaillé dans un contexte militaire de recherche opérationnelle où la simulation de type Monte-Carlo, effectuée d’abord « à la main », avait dès 1949-1950 remplacé les techniques traditionnelles d’analyse numérique 1861 . À l’époque, il y a donc une demande forte pour un « ensemble cohérent de concepts » et pour un langage de description informatique susceptible de servir directement à une approche de modélisation de type simulation Monte-Carlo 1862 . Or, SIMULA introduit la possibilité d’un fonctionnement « quasi-parallèle » de différents « processus » à événements discrets. Ces processus ont la possibilité d’intégrer étroitement des « procédures algorithmiques » à côté des traitements mathématiques de manière à faciliter la représentation intuitive et donc la programmation des éléments du système total 1863 . Le premier compilateur SIMULA a été en fonction sur un UNIVAC 1107 dès janvier 1965. |
| Le langage C a, pour sa part, été conçu par Dennis M. Ritchie et Brian W. Kernighan des laboratoires Bell, entre 1971 et 1972, pour être portable et servir autant à des tâches simples et de bas niveau (proches du langage machine) 1864 que de haut niveau. En 1980, Bjarne Stroutstroup, toujours des Bell Labs, crée le C++ de manière à ce que le C permette la programmation orientée objet en prenant modèle sur SIMULA qui, entre-temps, s’est développé en SIMULA 67. Le but est alors d’exprimer le problème réel dans un langage peu abstrait et proche de celui qui est employé par ceux qui se le posent 1865 . Au lieu d’une approche par lois générales qui fait l’hypothèse d’une impossible connaissance intégrale et de surplomb des processus (comme dans la première intelligence artificielle), une approche taxonomique et compartimentée est employée. Les objets sont définis comme des instances particulières de certaines classes. Les classes sont des structures de données formelles où figurent des listes d’attributs (caractéristiques) et de méthodes (comportements) qui peuvent affecter les objets de ces classes. Les objets communiquent entre eux par des messages sous forme de services aux autres objets (décrits dans les méthodes). Les classes peuvent être emboîtées : elles héritent alors certains de leurs attributs ou de leurs méthodes. Les objets regroupent et protègent leurs données et leurs méthodes avec une grande autonomie : ils sont dits encapsulés. |
| La programmation orientée objet a donc son origine dans la simulation de problèmes complexes mettant en relation des éléments divers et hétérogènes. Elle s’oppose d’une certaine manière à l’approche par modèles mathématiques qui reposait tout entière sur une technique de programmation procédurale, fonctionnelle (procédure de calcul, d’analyse numérique, d’approximations 1866 , etc.) où des langages généraux et orientés vers les formulations mathématiques (comme FORTRAN) faisaient encore l’affaire. La modélisation orientée objet ouvre donc à une possible pluriformalisation des simulations et tend à compléter ou remplacer une conception mathématiste monoformalisée 1867 . Elle réifie 1868 ses concepts de manière à mieux répliquer le phénomène qu’elle simule. |
Toujours est-il que dans cette première version commerciale du logiciel, on n’a pas encore affaire à une véritable simulation dans le sens défini précédemment, car il faudrait pour cela traiter tous les nœuds en parallèle comme c’est le cas dans la réalité. Les méristèmes d’une plante réelle évoluent de manière corrélée et non séquentielle. Le temps passe pour eux, « en même temps », si l’on peut dire. Autrement dit, il faudrait disposer d’une machine parallèle de type MIMD (Multi Instructions Multi Datas) 1869 . Or, selon Jaeger, il n’est techniquement pas réalisable d’interconnecter plusieurs millions de processeurs jouant chacun le rôle d’un nœud de l’arbre simulé. Il reste donc deux solutions techniquement envisagées 1870 . La première consisterait à simuler le parallélisme en utilisant des outils logiciels comme des échéanciers. Cette solution est en cours d’implémentation en 1987 et ne sera véritablement mise en œuvre qu’avec les travaux de Frédéric Blaise, en 1991. La solution qui est d’abord retenue par Jaeger consiste à générer le végétal nœud par nœud à un âge préfixé (fixé à l’avance). Elle est simple à manipuler et requiert peu de ressources en mémoire. L’inconvénient est double 1871 : premièrement on n’obtient pas véritablement la simulation de la croissance de façon dynamique mais seulement des représentations d’étapes de croissance, deuxièmement la réalisation d’animations nécessite la reprise intégrale de la simulation pour chaque âge différent. Pendant le calcul, la forme transitoire obtenue ne doit pas être affichée car elle ne ressemble pas à un arbre réel. Cette simulation n’est donc pas encore botaniquement réaliste dans son processus dynamique même, bien que dans ses résultats figés, elle le soit assez rigoureusement. Il demeure néanmoins impossible de simuler la gêne entre axes puisque chaque axe est « calculé » jusqu’au bout avant que le suivant ne le soit. Et donc tout méristème « ignore » tout de son environnement.
Quelles sont finalement les hypothèses botaniques qui sous-tendent un traitement de la croissance en mode préfixé et quelle est leur conséquence sur le moteur de croissance ? La première hypothèse est que les caractères morphologiques et géométriques d’un nœud ne dépendent que des nœuds précédents 1872 , et la seconde est que la plante pousse dans un environnement parfaitement homogène. Moyennant ces hypothèses, assez lourdes, il n’est pas irréaliste de ne traiter que la suite des nœuds ayant ramifié. C’est donc ce que fait le premier « moteur de croissance » de l’AMAP. Cette expression est proposée dès le départ par Françon, sur le modèle des « moteurs d’inférences » des logiciels d’intelligence artificielle.
[Jaeger, M., 1987], p. 60.
[Bouchon, J., Reffye (de), Ph., Barthélémy, D., 1997], p. 317. [Reffye (de), Ph., Blaise, F., Guédon, Y., 1993] préciseront également : « les concepts botaniques utilisés et la modélisation mathématique qui en découle font que la simulation tend à reproduire le fonctionnement de la plante plutôt que sa seule forme » (p. 40.) ; et la phrase de Blaise est reprise dans les mêmes termes p. 41. Ainsi le logiciel semble réaliser un « modèle vrai » de l’arbre, au sens de J. Sauvan, (in [Sauvan, J., 1966] cité par [Legay, J.-M., 1997], p. 25). C’est-à-dire qu’il coïncide avec la réalité modélisée aussi bien du point de vue phénoménologique que du point de vue de la logique interne.
[Jaeger, M., 1987], p. 95.
[Jaeger, M., 1987], p. 133.
Voir [Smith, A. R., 1984], p. 2.
Pour Edelin, certains modèles architecturaux de Hallé seraient plus proches que d’autres et seraient ainsi à regrouper sous quelques « super-modèles ». Le modèle informatique nous permettrait de les spécifier plus pertinemment du point de vue botanique. Voir [Jaeger, M., 1987], p. 133.
Voir [Ten Dyke, R. P. et Kunz, J. C., 1989], p. 466.
“Object-oriented programming is like having a group of specialists working together to solve a problem”, [Ten Dyke, R. P. et Kunz, J. C., 1989], p. 466.
[Dahl, O. J. et Nygaard, K., 1966], p. 671.
[Nyggard, K. et Dahl, O. J., 1978], p. 245.
“a consistent set of concepts”, [Nyggard, K. et Dahl, O. J., 1978], p. 246.
[Dahl, O. J. et Nygaard, K., 1966], p. 671.
Il se caractérise par l’introduction des structures de contrôles, des pointeurs et de la récursivité. Voir [Bac, C., 1985-2003], p. 1.
[Coquillard, P. et Hill, D. R. C., 1997], p. 154.
En regard, il est instructif de lire les actes de la RCP du CNRS de 1966 (Recherche Coopérative sur Programme n°30), donc exactement contemporaine du travail de Dahl et Nygaard, sur les procédures ALGOL : elles ne sont dédiées qu’à l’analyse numérique. Voir [Kuntzman, J., 1967] et [Gastinel, N., 1970].
Le concept et le terme même de « pluriformalisation » apparaîtront cependant plus tard et dans un autre contexte. Nous y reviendrons plus bas, en temps utile.
Sur cette notion, voir [Drogoul, A., 2002a].
Précision donnée par [Blaise, F., 1991], p. 56.
[Jaeger, M., 1987], p. 61.
[Jaeger, M., 1987], p. 61.
[Jaeger, M., 1987], p. 61.