¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
Valorisation, partage et transfert des résultats de la
modélisation
Garder le modèle
interne, livrer le modèle
Processus de développement du
modèle
Nature du travail
informatique impliqué
Modèles livrables et
valorisation/transfert
Caractère itératif du
développement dans le domaine de la modélisation
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
Introduction ( Ù )
Dans ce dossier, il est question des modèles développés dans le cadre de travaux de recherche, et des évolutions qu’ils sont susceptibles de connaître ensuite.
Il est proposé la description d’un processus de développement du modèle et de différents états que le modèle est susceptible de prendre, entre son état d’origine en tant qu’outil de recherche du chercheur qui l’a conçu, et toutes les formes qu’il prendrait ensuite en tant que vecteur de valorisation/partage/transfert des résultats de la recherche.
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
Garder le modèle interne, livrer le
modèle ( Ù )
A l’origine, le chercheur crée, met au point et utilise son modèle pour ses recherches. Puis vient le moment où le modèle atteint un état permettant d’envisager de le communiquer et de le mettre à disposition d’un tiers.
Il peut être question de livrer le modèle à quelqu’un d’autre pour diverses raisons, par exemple afin de l’intégrer dans un plus gros modèle, dans un outil de simulation, dans un outil d’aide à décision, dans une application logicielle répondant au besoin d’utilisateurs particuliers (acteurs de la profession…), pour le coupler à un autre modèle, etc.
Livrer le modèle requiert d’avoir au préalable effectué sur le modèle un certain travail d’ingénierie :
- La part indispensable de ce travail d’ingénierie consiste à qualifier le modèle. Cette qualification est à la fois scientifique et informatique, elle couvre des aspects fonctionnel/système et logiciel. Il s’agit d’accompagner le modèle du nécessaire pour qu’un tiers sache quoi en attendre et comment l’utiliser, l’exploiter. La qualification implique un travail de formalisation : caractérisation, définition de procédures de test et de livraison, conditions d’exploitation, aspects opératoires…
- D’autre part la forme informatique du modèle sera peut-être retravaillée à ce stade, et ce de façon plus ou moins poussée en fonction des contraintes de livraison ainsi que des moyens alloués : le contexte dans lequel il est visé de livrer le modèle à un tiers (livraison à un collègue de laboratoire, diffusion externe…), le budget, les ressources humaines informatiques disponibles, les délais de livraison...
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
Livrer le modèle ( Ù )
Qualification,
diffusion
On peut relever deux aspects dans le fait de livrer un modèle : la qualification et la diffusion. Il y a derrière la qualification du modèle le souci de le caractériser et de l’utiliser à bon escient. La diffusion consiste à le mettre à la disposition des autres, d’une manière plus ou moins élaborée/pratique en fonction des moyens attribués à cette tâche.
Les échanges avec les
utilisateurs
A partir du moment où le modèle est communiqué et mis à la disposition des autres, les utilisateurs - ceux qui prennent connaissance du modèle, ceux qui envisagent de l’utiliser, ceux qui l’utilisent - vont demander à celui qui l’a conçu des explications, des clarifications. Ils vont exprimer des besoins, demander des modifications par rapport à ce qu’eux-mêmes voudraient faire du modèle, ils vont donner des idées d’évolution. Ils vont aussi signaler des anomalies qu’ils auront détectées à l’usage ou à la compréhension.
Enrichissement par confrontation aux utilisations
Les échanges avec les utilisateurs vont jouer sur ce que va devenir le modèle. Avant tout, ils permettront de corriger le modèle et d’en améliorer ainsi la qualité et la robustesse. De plus ils sont susceptibles d’influer sur les évolutions en terme de spécification (nouvelles fonctionnalités…).
Travail induit
Livrer un modèle s’envisage rarement dans un contexte figé (ce qui pourrait toutefois se concevoir, par exemple dans le cas d’un modèle dont plus personne ne s’occupe, qui serait livré sous forme de code source dans le but de trouver quelqu’un qui le reprenne). Généralement la livraison s’inscrit dans la durée et l’idée est de continuer à livrer le modèle – voué à évoluer - au fur et à mesure qu’il est modifié. Aussi s’engager dans une logique de livraisons nécessite de pouvoir compter sur des personnes s’en chargeant tout au long de l’existence du modèle.
D’une part, livrer le modèle ne
peut se faire que si le modèle a été rendu livrable grâce à un travail
d’ingénierie préalable (voir le paragraphe
« garder le modèle interne, livrer le modèle »). D’autre part le fait
de livrer le modèle induit lui-même une charge de travail : par les opérations
et la mise en œuvre de la diffusion (voir « modèle en diffusion » au paragraphe « nature du travail informatique
impliqué »), par les échanges avec les utilisateurs (voir ci-dessus le
sous-paragraphe « les échanges avec les utilisateurs »). Dans tous
les cas, il est besoin de quelqu’un qui prenne en charge les aspects
d’ingénierie tout au long de l’existence et des évolutions du modèle. La personne
responsable sera entre autre garante/interlocutrice des livraisons. De plus les
retours des utilisateurs peuvent entraîner du travail en terme de maintenance et
évolution du logiciel (voir ci-dessus le sous-paragraphe
« enrichissement par confrontation aux utilisations »). La charge de
ce travail sera plus ou moins importante en fonction de la conduite qu’il est
choisi de tenir. Peut-être, si l’on en a les moyens, choisira-t-on de prendre
en compte tous les retours/demandes des utilisateurs. Mais peut-être, pour
limiter la charge de travail, préfèrera-t-on toujours corriger les anomalies
signalées par les utilisateurs mais se contenter de répertorier les demandes
d’évolution sans les prendre en compte dans le logiciel.
Aspects juridiques
Le fait de livrer le modèle soulève des questions d’ordre juridique/contractuel (droits de propriété intellectuelle, droits d’accès informatiques).
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
Processus de développement du modèle ( Ù )
Le schéma pointé ci-dessous découpe en différents stades le processus de développement d’un modèle s’inscrivant dans une perspective de transfert et de valorisation. Toutefois, il existe une telle disparité dans les modèles (taille, nature, forme …) et dans les contextes de développement (composition et taille des équipes, délais de développement …) que cette description n’est probablement pas adaptée à tous les cas.
|
Schéma « processus de
développement du modèle » |
Il est à noter que le processus de développement du modèle n’est pas un processus linéaire. Pour plus de détails à ce sujet, voir le paragraphe « caractère itératif du développement dans le domaine de la modélisation».
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
Etats du modèle ( Ù )
Aux différentes étapes du développement correspondent des états du modèle : voir l’illustration par le schéma « processus de développement du modèle » .
La liste des différents états du
modèle qui ont été identifiés est donnée ci-dessous dans un ordre croissant en
terme d’aptitude à la livraison et à la réutilisation :
- « modèle interne »,
- « modèle communicable »,
- « modèle sous forme appropriée »,
- « modèle en diffusion ».
Le schéma pointé ci-dessous donne quelques caractéristiques des états du modèle, relativement à la livraison et au développement logiciel :
|
|
Voir aussi le paragraphe « nature du travail informatique
impliqué » et le paragraphe
« modèles livrables et valorisation/transfert ».
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
Nature du travail informatique impliqué ( Ù )
Il est repris ici un à un les états du modèle (voir le paragraphe « états du modèle »), tout en donnant quelques caractéristiques du travail qu’il est nécessaire de fournir pour parvenir – et se maintenir – à chacun des états :
· « modèle interne » :
Initialement, le modèle est un outil interne de recherche. Avant de l’exposer à autrui, il sera nécessaire d’effectuer sur le modèle un travail d’ingénierie (voir le paragraphe « garder le modèle interne, livrer le modèle »). Si l’idée est de continuer à exposer le modèle au fur et à mesure de ses changements, il sera nécessaire que quelqu’un prenne en charge ces aspects d’ingénierie tout au long de l’existence et des évolutions du modèle, faute de quoi le modèle ne pourrait que rester réservé à son concepteur.
· « modèle communicable » :
La condition nécessaire et suffisante pour exposer le modèle à autrui est d’en avoir établi les qualifications scientifique et informatique (voir le paragraphe « garder le modèle interne, livrer le modèle »). En fait, le travail de qualification fait partie intégrante de tout développement logiciel au même titre par exemple que le travail de codage, et ce indépendamment du fait que l’on ait l’intention de garder le logiciel pour soi ou de le diffuser à des tiers. L’effort à fournir dans le travail de qualification est grandement de nature méthodologique, aboutissant à un résultat de forte valeur ajoutée scientifique/recherche : le modèle (porteur de la matière scientifique) muni de sa qualification (faisant partie intégrante de tout logiciel).
Pour prendre la question sous un autre angle, s’il était question de
passer à quelqu’un le modèle avant même qu’il n’existe sous forme informatique,
cela pourrait se faire au moyen d’informations textuelles. La personne qui
aurait l’intention de produire sa propre implémentation du modèle pourrait le faire
à partir de la définition/spécification du modèle et de données de
qualification.
· « modèle sous forme appropriée » :
Au-delà de la qualification, il peut être engagé sur le modèle un travail informatique plus ou moins poussé en fonction du besoin, des ambitions caressées en terme de partage/réutilisabilité/interopérabilité et des forces informatiques mobilisables. Dans ce travail, la personne qui assume le rôle d’informaticien traite des questions informatiques en partie liées à la thématique scientifique concernée : les formes de livraison appropriées et autres problématiques spécifiques (voir aussi le paragraphe « modèles livrables et valorisation/transfert »). Faire ce travail informatique tôt dans la chaîne de développement constitue une capitalisation des efforts, qui facilitera tous les développements logiciels futurs qui se serviraient de ce modèle (ie les développements représentés par la boîte « transferts/utilisations multiples du modèle sur divers projets logiciels » sur le schéma « processus de développement du modèle »). Ce travail améliore la viabilité du logiciel, on peut le voir en grande partie comme une préparation de l’avenir. A partir du moment où le modèle est voué à durer, ce travail lui sera bénéfique, indépendamment du fait que l’on ait l’intention de le garder pour soi ou de le diffuser à des tiers.
· « modèle en diffusion » :
Une fois le modèle prêt à être livré, il peut être choisi de le diffuser, la manière de le faire dépendant des besoins et des moyens attribués. La diffusion peut être artisanale (livraison manuelle) ou plus sophistiquée (par exemple sous forme de services Web). Diffuser engendre des activités telles que mettre en place et gérer des infrastructures informatiques d’hébergement et diffusion de logiciels : système de gestion de version, serveur de diffusion, technologies Web… Ces activités, qui ne sont en rien particulièrement liées à la modélisation, ont une valeur ajoutée informatique de nature généraliste, de fort potentiel de mutualisation a priori inter-discipline. Toutefois, l’espace de diffusion pourrait en plus offrir aux livreurs de modèles des services génériques spécifiques du contexte de la modélisation.
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
Modèles livrables et valorisation/transfert
( Ù )
Rendre les modèles livrables est une manière de préparer le terrain pour les développements futurs de logiciels appelant ces modèles. En cela, les modèles livrables constituent un tremplin pour la réutilisation.
Plus précisément, il a été identifié (voir le paragraphe « états du modèle ») plusieurs degrés dans la forme sous laquelle le modèle peut être livré.
Le « modèle communicable » est le minimum requis pour remettre le modèle à un tiers (tandis que le « modèle interne », lui, reste réservé à son concepteur).
Le « modèle communicable » peut, après avoir subi améliorations et transformations, devenir un « modèle sous forme appropriée », plus attractif pour quelqu’un qui serait intéressé de le récupérer. A ce stade, le modèle livrable n’est pas à considérer comme une entité directement opérationnelle, il faut plutôt le voir comme un service qui calcule et fournit des données de sortie en fonction des données injectées en entrée (les entrées/sorties, définies dans un esprit de généricité, ne sont pas adaptées à une utilisation spécifique). Les transformations/améliorations sont effectuées dans l’idée de parvenir à afficher une offre claire de modélisation sous une forme informatique telle que réutiliser revienne à appeler un traitement existant/prêt et non pas à le développer (les modules et briques de modélisation peuvent être préparées par exemple sous forme de bibliothèques de calcul, de services Web...). En effet, c’est très souvent cette forme, à fort caractère générique et de forte valeur ajoutée scientifique, qui intéresse ceux qui souhaitent exploiter le modèle : que ce soit un chercheur qui veut l’incorporer dans son propre modèle d’intégration, ou bien une société privée intéressée de l’appeler dans ses propres produits logiciels ou projetant de réaliser un outil logiciel s’appuyant sur le modèle. Ainsi, rendre le modèle prêt à être appelé par d’autres logiciels serait une porte ouverte à de potentielles utilisations futures de toutes sortes.
Dans le cas où il est choisi de diffuser les modèles, certains modes de diffusion donnent accès aux modèles avec souplesse, avec rapidité, rendent faciles les changements de versions logicielles… Dans la mesure où grâce à certains modes de diffusion, l’accès aux modèles est facilité et le fait que les modèles existent est mieux connu, proposer les « modèles en diffusion » peut d’autant plus favoriser leur réutilisation.
En conclusion, rendre les modèles livrables constitue une clé de la valorisation et du transfert des modèles de la recherche, sachant par ailleurs que le fait de rendre un modèle prêt à être livré, ainsi que le fait de le diffuser a un coût et s’inscrit dans la durée.
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
Caractère itératif du développement dans le domaine de
la modélisation ( Ù )
( Retour au paragraphe « processus de développement du modèle » )
Le processus de développement du modèle (voir le schéma « processus de développement du modèle ») n’est pas un processus linéaire.
Ceci est lié à certaines spécificités du cadre dans lequel les modèles sont généralement développés :
- Contexte de la recherche : le modèle est défini de manière itérative, il est construit rétroactivement. Le fait d’en faire tourner une version inspire des modifications qui vont conduire à la version suivante, génère des idées d’évolutions. Voir : la boîte « modèle outil de recherche » sur le schéma « processus de développement du modèle ».
- Objectifs multiples, déclinaisons futures du logiciel : le modèle, outil de recherche en soi, est susceptible d’évoluer par rapport à divers objectifs, il peut être à l’origine de multiples utilisations/outils/applications logicielles dérivées du modèle. Voir : la boîte « transferts/utilisations multiples du modèle sur divers projets logiciels » sur le schéma « processus de développement du modèle ».
C’est pourquoi des approches de développement itératif/incrémental sont souvent bien adaptées au développement des modèles.
Pour plus de détails/informations, voir le support « Informatique et modèles : les choix informatiques à faire pour développer un modèle » relatif à la formation « Formation INRA-ACTA-ICTA ; Introduction à la modélisation ; les modèles mathématiques pour l’agronomie et l’élevage ; 2nde session, du 28 novembre au 1er décembre 2005 » ; en particulier à la page 12 intitulée « Fort caractère itératif du domaine de la modélisation » dont il est pointé ici une reproduction du schéma.
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
Fiche produite par Nathalie Rousse (INRA/UMR ARCHE AgRosystèmes Cultivés & HErbagers)
de
La page au format pdf (02/11/06)
-
mise en ligne
le 02/11/06 –
Plate-forme
INRA-ACTA-ICTA, Modelia http://www.modelia.org
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾