Sans préjuger des décisions de la cellule "développements logiciel", on peut déjà avancer quelques spécifications sur lesquelles il conviendra de réfléchir :
Type de logiciel
C'est une question cruciale : du logiciel presse-bouton à "débrouille toi pour re-bidouiller des bouts de code" il y en a pour tous les goûts. Mais l'expérience montre qu'un logiciel intégré avec interfaces évoluées, donc en principe plus agréable pour l'utilisateur, est non seulement coûteux à développer, mais aussi très difficile à co-développer par une pluralité de programmeurs. Inconvénient supplémentaire, il est rigide, et l'utilisateur ne peut en général pas l'adapter à ses besoins au cas où la "bonne" option soit absente. Il paraît donc plus réaliste, au moins dans un premier temps, de s'orienter vers une bibliothèque de modules indépendants, avec une interface basique de type "carte de paramètres" (ou mieux si le développeur du module le souhaite), mais qui partageraient une même charte graphique et sémantique, et si possible un même format de données.
Communauté de développeurs - charte de développement
Toute personne qui souhaite développer un module doit pouvoir le faire. Mais l'expérience montre qu'il est très difficile de mettre en place une communauté et qu'il faut minimiser les contraintes sous peine de faire fuir les développeurs. Les modules doivent donc être aussi autonomes et indépendants que possible, mais doivent suivre une "charte" claire concernant les structures d'échanges de données, les choix graphiques, la langue, la documentation… Cette dernière devrait inclure le descriptif de l'objectif du module, son mode d'emploi (en particulier nombre et type des entrées et des sorties du modèle compatibles avec le module), le plan d'expérience à faire exécuter par le modèle, l'interprétation des traitement statistique et graphique des résultats obtenus, ainsi qu'un exemple traité.
Langage de programmation
Il est souhaitable de laisser le statisticien libre de choisir son langage de programmation, dans la mesure où il peut avoir des contraintes spécifiques. Un très bon candidat est cependant le logiciel 'R', déjà évoqué. Il s'agit d'un clone gratuit du logiciel Splus que de nombreux biologistes et statisticiens de l'INRA utilisent déjà. Ses principaux défauts sont sa lenteur relative et la pauvreté de son environnement de programmation, mal adaptée à de gros projets de développement. Dans tous les cas, il semble indispensable que le module puisse fonctionner sur toute plateforme (Unix/Linux, Windows, Macintosh…).
Format d'échange des données
Une des clefs du succès tiendra à la définition d'un format d'échange de données entre modules et modèles qui soit à la fois simple, performant et évolutif. Ceci pour ne pas alourdir le travail du modélisateur qui souhaiterait utiliser la bibliothèques de modules, ni celle du statisticien qui souhaiterait programmer un nouveau module. Un bon candidat semble le langage de balise XML (extended markup langage) qui tend à devenir le standard d'échange entre applications informatiques, et qui est supporté par un nombre grandissant d'environnement, et en particulier par le logiciel R. MIA-Avignon teste la faisabilité de son usage dans ce contexte.
Glossaire
Il semble indispensable de bien définir les termes employés. On peut proposer qu'un glossaire soit mis en place dès le début du projet, avec traduction en anglais. Ceci afin que tous les modules partagent la même sémantique.
Langue
C'est un choix délicat qui doit être fixé dès l'origine du projet, car il est ensuite très difficile de faire machine arrière. Une solution consiste à développer systématiquement en anglais. Une alternative plus ambitieuse est de travailler avec des dictionnaires de traduction. Il ne paraît pas indiqué de développer uniquement en français, car on souhaite donner une audience internationale à ce projet. De même pour la documentation.
Mise à disposition des modules
Quoi de plus pratique q'un site web ? Une difficulté qui risque d'émerger rapidement est d'organiser la documentation des modules. Comment repérer si un module permettant tel traitement sur telle structure de données existe déjà ? On peut imaginer modulariser un peu plus, et concevoir des modules de plans d’expériences ou d’échantillonnage, des modules d’analyse des données simulées, des modules d’interprétation graphique, et peut-être pour simplifier l’usage, des modules qui intègrent ces différentes étapes.