Exposé du 6 juin 2014
Céline ROUSSEAU, Tristan BOUREAU et Gilles HUNAULT
Titre court
Valorisation
Titre long
Valorisation de l'analyse d'images de fluorescence de chlorophylle sur le plateau PHENOTIC : comment passer d'un script R interactif à un service Web d'analyse d'images automatique
Table des matières cliquable
1.
2.
3.
4.
5.
1. Une petite pièce de théâtre
scène précédente scène suivante
2. Les étapes de la valorisation
Comme vous avez du le comprendre au travers de la petite pièce de théâtre, Il y a avait au départ un script d'analyse d'images, écrit dans le cadre d'une thèse. Ce script (ou programme) utilise le logiciel R. Ce script, testé, fiable, mais artisanal, fonctionnait très bien nos ordinateurs, avec des images en local. Mais pour l'utiliser ailleurs, en routine et sur d'autres ordinateurs, il a fallu effectuer quelques modifications. C'est ce que nous détaillons dans la partie 3.
La valorisation de ce script consiste à fournir un service Web payant qui (durant la nuit) :
décompresse les images de l'archive fournie,
les analyse,
produit un PDF de l'analyse,
fournit des courbes d'évolution au cours du temps,
envoie un mail pour prévenir que les résultats sont disponibles.
La modification du script n'est pas la seule étape. C'est la partie amont la plus immédiate à envisager. Après réflexion, il est facile de se rendre compte qu'il y a des questions qui ne posaient pas en local :
où stocker les fichiers (quelle machine, quel coût, quelle gestion...) ?
quel volume de fichiers cela va-t-il représenter au fil des années ?
comment facturer le service (à l'acte, au volume de fichiers, à la durée d'analyse...) ?
puisqu'il s'agit s'un service payant, comment garantir sa qualité, son exécution ?
y a-t-il des problèmes de propriété intellectuelle (pour le script, les données...) ?
faut-il stocker ou détruire les images après analyse ?
si on stocke les images après analyse, quelle base de données faut-il construire et avec quelle interface ?
quelle pérennité pour le service ?
quelle maintenance, quelle évolution pour le script ?
quels acteurs (secrétariat, assistant, contact...) sont impliqués ?
quelle charge cela va-t-il représenter pour le service informatique qui gèrera les analyses et les images ?
La [longue] liste de ces questions montre qu'on est bien loin de juste modifier un script. Les questions qui se posent sont plutôt définies en termes de gestion, de stockage, de service et de qualité de service, de facturation...
Avec encore plus de recul, il y aussi des possibilités de prolongement scientifique, de recherche fondamentale qui peuvent émerger :
Peut-on modéliser puis simuler l'évolution des symptomes et en faire un film animé ?
Pourrait-on envisager de photographier ou filmer avec une caméra les feuilles et les envoyer sur le serveur d'images en temps réel ?
Si on comprend les mécanismes biologiques et physiologiques sous-jacents, peut-on automatiser les choix de seuils ?
Pourrait-on fournir un service de surveillance automatique de serres, de jardins... ?
Pourrait-on prévoir un envoi en temps réel des images et un envoi systématique, par exemple en fin de semaine des résultats ?
«Remote sensing» : serait-il possible avec de nombreux capteurs bon marché de dédier un capteur à une feuille et de récupérer massivement des images par wifi ?
Si on revient, stricto sensu aux étapes de la valorisation, on peut les résumer ainsi :
La première étape consiste à passer d'un produit artisanal à un produit fiable, fonctionnel.
La deuxième étape vient définir et réunir les divers acteurs du service pour qu'ils se répartissent les tâches et qu'ils collaborent [efficacement].
La troisième étape est celle qui vient mettre en place la facturation et la gestion du service.
Enfin, la quatrième et dernière étape avant la mise en production est la phase de test pour s'assurer que le service est opérationnel.
Ensuite, ce n'est plus de la valorisation au sens strict du terme, mais de l'exploitation, de de la production, de la maintenance, du suivi...
3. Détails techniques du script
Notre script initial était interactif : il posait quelques questions et venait confirmer les réponses fournies.
Nous avons du séparer la partie saisie des paramètres dans une page Web de la partie exécution différée via un processus automatique paramétré sans aucune interaction ni intervention humaine de façon à pouvoir réaliser les analyses d'image de nuit :
Notre script fonctionnait sous Windows, nous avons du l'adapter pour Linux.
Notre script demandait un répertoire puis un nom de controle, comme H2O ou h2o.
Nous avons modifié la question associée pour que le terme Controle puisse se comprendre comme Référence ou Témoin.
Le script ne doit pas s'interrompre ou "planter", il a donc fallu fiabiliser le code, prévoir l'impossible (comme l'absence de données, la division par zéro, le manque d'un fichier-image dans l'archive)...
Vous pouvez voir ici une simulation du service en exécution et là la page de présentation du service Web.
4. On n'y pense pas au début mais...
Quand on programme pour soi, on a vite fait d'écrire du code «relativement propre» mais qui n'est relisible que par soi. Voici donc quelques "trucs" auxquels il faut penser, en programmation scientifique de production :
il faut en général réfléchir et écrire les commentaires puis le code entre les commentaires afin de toujours disposer de commentaires et d'être capable de se relire ;
il faut toujours prévoir une démonstration facile à reproduire ;
quand on sait que son script va être exécuté par d'autres utilisateurs que soi, il ne faut jamais faire confiance à l'intelligence ou aux compétences informatiques de l'utilisateur mais au contraire prévoir toutes les erreurs possibles. Ainsi :
- il faut toujours convertir les virgules en points dans les saisies de valeurs décimales
- il faut toujours penser au typage des paramètres
- il faut toujours afficher des informations au fur et à mesure quand l'exécution est longue...
il faut préparer et disposer d'une description des calculs, de la méthode, du choix des options, des paramètres, parce qu'il y aura toujours quelqu'un(e) qui viendra demander :« au fait, en détail, qu'est-ce qu'il fait, votre script ? » ou encore : « il sert à quoi, ce paramètre ?».
si la durée d'exécution dépasse la minute, en plus d'affichages partiels et d'attente (comme une barre de progression ou un message comme fichier 15 / 50), il faut se poser la question de l'optimisation du code, en particulier en R, qui est vectoriel.
Ainsi, en programmation classique, on dispose de tableaux et le principal moyen d'action sur les tableaux est la boucle de parcours, comme par exemple pour calculer la somme des éléments du tableau :
##################################################################################### # # # algorithme général du calcul de la somme des éléments du tableau nommé tdata # # # ##################################################################################### # initialisation de la somme somTab <- 0 # itération sur les éléments du tableau pour chaque élément telt du tableau tdata ajouter telt à somTab fin pour telt ##################################################################################### # # implémentations classiques de la boucle de parcours : # ##################################################################################### /* for (telt in tdata) { somTab = somTab + telt } # fin de pour telt for (ind=0,ind<size(tdata),ind=ind+1) { telt = tdata[ind] somTab += telt } # fin de pour telt for (ind=1,length(tdata)) { telt = tdata[ind] inc(somTab,telt) } # fin de pour telt # implémentation en R obligatoire somTab <- sum( tdat) # implémentations quasiment interdites en R for (telt in tdata) { ... for (ind in 1:length(tdata)) { telt <- tdata[ind] ... */En R, il faut toujours commencer par se demander comment se passer des boucles ? Par exemple, pour la somme des éléments d'un vecteur, R fournit une fonction nommée sum() qui dispense d'écrire explicitement la boucle de parcours. Pour plusieurs lignes ou colonnes dans une matrice, R fournit des fonctions nommées rowSums() et colSums() en plus de apply(FUN=sum,...). Pour calculer les sommes des composantes d'une liste, R fournit des fonctions nommées lapply() et sapply(). Pour calculer des sommes correspondants à des sous-groupes, R fournit des fonctions comme mapply(), tapply(), by... et cela, toujours avec des itérations implicites, sans aucune boucle à écrire soi-même...
5. Comment conclure sans conclure (!)
On dit souvent qu'en recherche, rien n'est jamais fini, qu'une réponse à une question amène une autre question. En valorisation, c'est souvent pareil : un service en fonctionnement oblige toujours à de la maintenance, de la mise à jour, de la refonte, de l'évolution. Un bon service stimule l'imagination et invite à en créer un autre, ou à en développer un en parallèle.
Avant de se lancer dans une démarche de valorisation, il faut savoir que c'est une démarche souvent longue, de temps en temps complexe, avec de nombreux acteurs, bref parfois une aventure et des fois, une galère...
Retour à la page principale de (gH)
