Publier constitue depuis toujours une des activités des chercheurs. Partager ses résultats revient à soumettre ses travaux à ses pairs. Il s’agit non seulement d’assurer la
reproductibilité, mais aussi de faciliter la diffusion de l’innovation scientifique (théorique et pratique) au sein de la communauté.
Avec l’importance grandissante de l’informatique dans la recherche, les outils logiciels deviennent essentiels pour les scientifiques (simulateurs, solveurs, algorithmes d’optimisation, etc.). Pour autant, ces logiciels ne jouissent pas d’un statut comparable à d’autres produits de la recherche.
On les perçoit souvent comme de simples commodités à l’instar des appareils de mesure ou de laboratoire. On estime que ces logiciels ne sont pas réellement des contributions scientifiques et ce, même si les algorithmes qu’ils implantent relèvent clairement de la recherche en informatique.
Cette perception erronée des logiciels de recherche débouche sur des problèmes de reproductibilité. De plus, l’absence (quasi) totale de valorisation du développement d’algorithmes freine considérablement la recherche académique en informatique.
Je pense qu’une réflexion doit impérativement avoir lieu au sein de la communauté scientifique. Des politiques contribuant à l’émergence de plates-formes logicielles de recherche
open source sont en effet indispensables.
La diversité des algorithmes et de leur mise en œuvre
Les appareils de mesure et de laboratoire sont, par nature, interchangeables. Lorsqu’on remplace un thermomètre par un autre de précision équivalente, on mesure la même température (s’ils ne sont pas défectueux). Ce n’est pas forcément le cas pour les logiciels.
Les algorithmes proposent souvent des résultats variables pour un même problème. Même différentes mises en œuvre d’un algorithme donné se comportent parfois diversement. Sans parler des autres choix d’implantation (méthodes de calcul, paramétrage, fonctions de coûts, etc.).
Comme je l’ai expliqué dans
mon billet de juillet-août, la qualité du développement d’un algorithme se révèle un élément crucial de l’efficience du logiciel final. Un «
hack» particulièrement bien pensé peut conduire à un gain final significatif (y compris dans celui de la solution produite).
Le contexte d’utilisation importe aussi. Prenons le prétraitement de données. Parfois, pour utiliser un logiciel, on transforme les données brutes en «données utilisables». Or quelques petits changements (pas toujours explicités) dans un prétraitement suffisent à altérer le résultat final.
La reproductibilité scientifique à l’heure des logiciels
Les chercheurs se trouvent donc devant une abondance de choix. Quels algorithmes utiliser ? Quelles implantations choisir ? Quels prétraitements appliquer aux données brutes ? Autant d’informations indispensables, mais rarement toutes disponibles, pour assurer la reproductibilité scientifique impliquant un traitement informatique.
Depuis plusieurs années, des chercheurs en appellent à l’utilisation de
logiciels open source pour rencontrer ces enjeux de reproductibilité
[1, 2]. En rendant le
code source accessible à tous, n’importe qui peut télécharger les logiciels, ausculter leur fonctionnement et les exécuter.
Si, à la disponibilité du
code source, on ajoute également celle des données et du paramétrage des programmes, la reproduction de résultats publiés devient envisageable (pour autant que l’on dispose des ressources computationnelles nécessaires à l’exécution de ces programmes sur ces données).
Pour favoriser les
logiciels open source, certains demandent que les journaux scientifiques exigent des auteurs la disponibilité des programmes utilisés
[2]. Ils proposent différents niveaux d’ouverture suivant que tout le
code source est partagé, ou seule une partie de celui-ci (par exemple pour des raisons de propriété intellectuelle).
Utiliser des logiciels open source ne suffit pas
Les
logiciels propriétaires ne sont disponibles que sous forme binaire, ce qui empêche toute vérification de leur fonctionnement. Il paraît évident qu’ils sont donc un frein à la reproductibilité et à la diffusion des idées.
Promouvoir l’utilisation de
logiciels open source apparaît dès lors comme la solution au problème de reproductibilité de la partie informatique des recherches. Malheureusement, ça ne suffit pas.
La complexité de certaines recherches mobilisant l’informatique (climat, biomédical, physique quantique, etc.) implique la mobilisation de centaines de composants logiciels, parfois écrits dans différents
langages de programmation, gérant plusieurs formats de fichiers et manipulant des milliers de paramètres.
Il devient alors très difficile de comprendre réellement les contributions des différents composants et la manière dont ils s’articulent. Et accéder à des millions de lignes de
code source n’apporte pas forcément une solution pour y voir plus clair.
Pire, comme les chercheurs utilisent régulièrement des logiciels différents pour exécuter les mêmes tâches, le processus de vérification revient à réévaluer en permanence les mêmes algorithmes implantés dans différents logiciels pour assurer la reproductibilité de tous les résultats de recherche.
Le diable se cache dans les détails
Le lecteur pourrait se dire que je cherche à couper les cheveux en quatre. Des articles scientifiques décrivent généralement précisément les algorithmes mobilisés. Les détails pratico-pratiques ne présentent donc pas de réelle importance pour évaluer une recherche les utilisant.
Mais, comme expliqué ci-dessus, l’implantation particulière d’un algorithme joue un rôle dans les résultats produits. En outre, la motivation des développeurs est rarement explicitée. Ils poursuivent leur propre stratégie qui diffère généralement de celles des utilisateurs.
En particulier, le manque de temps et/ou de motivation fait que tous les
logiciels open source n’intègrent pas les derniers perfectionnements. Un chercheur en informatique peut, par exemple, développer un
logiciel open source pendant sa thèse et ne plus travailler dessus par la suite. Ce logiciel, quoique accessible, devient alors vite obsolète.
Dès lors qu’internet donne accès à des millions de
logiciels open source, représentant parfois des centaines d’implantations différentes d’un même algorithme, on se demande comment choisir la meilleure implantation pour ses recherches.
Cela suppose des compétences adéquates pour évaluer la qualité d’un logiciel, ce qui est rarement le cas. De plus, une telle analyse prendrait un temps considérable. La tentation est alors de se précipiter sur le premier logiciel venu sans réellement en examiner l’excellence.
La majorité des chercheurs se retrouvent donc complètement dépendants des concepteurs des logiciels qu’ils utilisent.
Le rôle de ceux qui développent les logiciels
On peut distinguer deux catégories de personnes qui contribuent à des logiciels mobilisés par la recherche. D’une part, des ingénieurs informaticiens, parfois chercheurs en informatique. D’autre part, des chercheurs d’autres domaines (tels la physique) qui apprennent la programmation «sur le tas».
Si certains ingénieurs informaticiens publient leur
code source, la majorité d’entre-eux ne le font cependant pas. De plus, le développement de «
programmes élégants» et réutilisables n’étant pas valorisé dans la carrière académique, rares sont les chercheurs qui adoptent les meilleures pratiques de développement.
Du coup, même lorsque l’on peut accéder au
code source d’un logiciel, sa réutilisation se révèle souvent ardue. On assiste dès lors au réflexe de redévelopper les mêmes algorithmes (en particulier de base) et ce, même lorsque des implantations
open source existent.
Une perte d’énergie considérable des chercheurs
Imaginons que 25% de ces articles utilisent réellement l’algorithme, et que 10% des auteurs l’ont redéveloppé pour l’occasion. Cela représente 740 implantations pour 2016. Supposons de plus qu’une implémentation demande 0,08 année/homme de développement. Au total, nous arrivons, pour la seule année 2016, à 59 années/hommes de développement – pour rien !
Le problème de la qualité des logiciels de recherche
Quant aux autres chercheurs qui s’improvisent ingénieurs informaticiens, ils atteignent rarement les standards de qualité qui garantissent la réutilisation du logiciel sur le long terme (conception claire, interface de programmation cohérente, documentation détaillée, processus de révisions, etc.).
Leurs modules logiciels mal conçus, lorsqu’ils sont assemblés pour produire une solution logicielle complexe répondant à une problématique de recherche actuelle, représentent autant de risques concernant leur maintenance, les
bogues et autres
effets de bord et donc,
in fine, la reproductibilité.
À cela s’ajoute la
rotation de l'emploi très élevée dans la recherche académique. Moins de 5% des doctorants seront stabilisés à terme
[3]. La conséquence est que les modules logiciels deviennent très vite inutilisables, et que les chercheurs suivants consacrent du temps à les redévelopper.
Les enjeux des logiciels utilisés dans la recherche
Les quelques éléments que je viens d’évoquer permettent d’identifier quatre règles à respecter en matière de logiciels utilisés dans la recherche :
-
Promouvoir des logiciels open source qui garantissent l’accessibilité au code source.
-
Assurer le traçage précis du contexte d’expérimentation impliquant des logiciels (données brutes, prétraitements et paramétrage des différents modules).
-
Éviter le redéveloppement inutile des mêmes logiciels pour se focaliser uniquement sur l’optimisation de ceux existants.
-
Créer un environnement de développement bien conçu qui permette à des chercheurs non ingénieurs informaticiens d’ajouter «proprement» leurs modules logiciels personnels.
Pour rencontrer ces différents enjeux, je défends le développement de plates-formes logicielles de recherche ouvertes et la création de véritables collaborations entre les ingénieurs informaticiens et les autres chercheurs.
Les plates-formes logicielles de recherche
Une plate-forme logicielle de recherche propose un
framework cohérent pour développer des applications dédiées à un domaine particulier (tel la modélisation climatique). Une telle plate-forme est développée et maintenue par la communauté scientifique correspondante.
Les parties prenantes partagent les coûts de développement (par une participation directe au développement et/ou par une contribution financière). Elles concourent ainsi à la diffusion des connaissances, notamment en assurant une réutilisation aisée des modules logiciels développés.
L’élaboration de plates-formes logicielles suppose tout d’abord l’adoption d’un ensemble cohérent de concepts. Ensuite, il faut identifier les processus globaux et les décomposer en groupes de tâches et de sous-tâches, chaque tâche ou sous-tâche pouvant être exécutée par un ou plusieurs algorithmes.
On peut, par exemple, décomposer le
partitionnement de données en trois tâches : (i) identifier les caractéristiques des objets à partitionner, (ii) établir une similarité entre objets sur base de ces caractéristiques et (iii) détecter les objets similaires. Plusieurs solutions existent pour ces trois tâches.
La nécessité d’une architecture en couches
Schématiquement, une «bonne» plate-forme logicielle adopte une
architecture en couches (Figure
1↓). Chaque couche se base sur les couches inférieures (plus génériques) et propose des fonctionnalités aux couches supérieures (plus spécifiques).
Les couches basses implantent les briques génériques et forment l’ossature de la plate-forme. Ces couches impactant transversalement l’ensemble de la plate-forme, les choix qui y sont effectués exigent l’implication d’ingénieurs informaticiens.
Au contraire, les couches les plus élevées ne demandent pas forcément de compétences informatiques avancées. Plusieurs
plugins, exécutant la même tâche mais avec une approche différente, sont interchangeables.
Une telle architecture isole les couches les plus hautes,
a priori moins stables, du reste de la plate-forme. Non seulement cela réduit les risques d’
effets de bord, mais cela favorise l’introduction d’approches innovantes qu’il suffira le plus souvent d’implanter comme un nouvel
plugin.
Notons qu’il existe déjà des plates-formes pour certains domaines, comme
Protégé pour la modélisation d’ontologies numériques
[4], ou encore le projet
Clear Climate Code dans le domaine de la climatologie
[5]. Avec la
plate-forme GALILEI, j’ai moi-même tenté d’en créer une pour l’analyse de données textuelles et la détection de communautés d’utilisateurs
[6].
La nécessité d’une collaboration pluridisciplinaire
Le développement d’une plate-forme logicielle de recherche ne se limite pas à un challenge informatique. Certains choix sur lesquels reposera l’architecture dépendent directement de l’état de la recherche dans un domaine particulier (tel les enjeux épistémologiques).
La décomposition des processus globaux en tâches et sous-tâches suppose en effet un consensus au sein de la communauté scientifique. Si un désaccord existe entre les chercheurs (par exemple sur les éléments constitutifs d’un modèle climatique), impossible de concevoir une plate-forme fédératrice.
Une fois un accord sur cette décomposition trouvé, les ingénieurs informaticiens apparaissent les mieux placés pour élaborer cette plate-forme. Bien entendu, des échanges continus avec les autres chercheurs restent indispensables pour modéliser les différents éléments.
À la lisière de la biologie et de la médecine, la
bio-informatique, qui émerge comme un domaine de recherche à part entière, illustre mon propos. Des informaticiens appliquent leurs techniques aux données médicales (
séquençage de l'ADN,
imagerie médicale, etc.).
Des collaborations pluridisciplinaires existent donc déjà. Mais elles sont encore peu nombreuses et se limitent à des domaines très spécifiques. Il faut absolument multiplier ces collaborations.
J’ai ainsi la chance de participer au
projet FAMe, une collaboration avec des médiévistes visant à numériser les données sur les famines durant l’
Antiquité et le
Moyen Âge. L’objectif est de mieux comprendre les variations de la production agricole. Un enjeu d’une grande actualité.
L’indispensable effort de développement logiciel dans la recherche
Au regard du modèle d’architecture logicielle, la conception et le développement des couches les plus basses sont déterminants. De mauvais choix impliquent en effet quasi mécaniquement l’échec du projet complet. L’implication d’ingénieurs informaticiens reste donc cruciale.
Loin de se limiter à l’architecture générale, l’approche en couches s’applique également aux approches logicielles de résolution. Prenons les
algorithmes génétiques. Pour faire simple, cette approche s’inspire de l’évolution pour résoudre des
problèmes d'optimisation [8].
Sans rentrer dans les détails, les
algorithmes génétiques proposent un cadre général basé sur différents «opérateurs» (croisement, mutation, etc.) qui varient au gré des problèmes. Chaque catégorie de problèmes implique des opérateurs spécifiques, des adaptations particulières étant également nécessaires au sein d’une même catégorie.
On retombe en fait sur une
structuration en couches. On retrouve «en bas» l’
algorithme génétique générique. Puis, au fur et à mesure qu’on s’approche d’un problème concret («en haut»), on spécialise les différents opérateurs en réutilisant les fonctionnalités des couches précédentes.
Le plus efficace revient à laisser les ingénieurs informaticiens implanter différents opérateurs génériques (mais adaptables) dans les couches basses. Les autres chercheurs se chargent ensuite de la seule spécialisation de l’
algorithme génétique nécessaire pour résoudre leur problème concret.
Et ce que je viens d’esquisser pour les
algorithmes génétiques pourrait être généralisée à quasi toutes les approches logicielles utilisées en recherche. En d’autres termes, tous les domaines de recherche profiteraient du développement de
bibliothèques logicielles transversales et ouvertes !
Favorisons des plates-formes logicielles de recherche ouvertes
Pour faire avancer la recherche moderne, il devient indispensable de promouvoir des plates-formes logicielles de recherche ouvertes. Il importe d’améliorer le financement de leur développement, et d’inciter de bons ingénieurs informaticiens à s’y atteler. On en cependant est loin.
Les bailleurs de fonds refusent bien souvent de financer explicitement ce type de projets. Ils affectionnent plutôt des recherches «plus sexy» aux objectifs aussi ambitieux qu’irréalistes
[9]. À cela s’ajoute le déficit chronique dans le financement de recherches pluridisciplinaires
[10].
Les diplômés en informatique se retrouvent souvent mal armés pour participer à de «gros» projets informatiques. Les études pourraient les encourager à contribuer à des plates-formes ouvertes plutôt que limiter leurs travaux pratiques à de «petits programmes». Cela permettrait aussi de sensibiliser les futurs chercheurs en informatique.
Avec une évaluation académique basée avant tout sur les articles scientifiques, le développement n’est plus considéré aujourd’hui comme une activité scientifique réelle valorisable mais «comme un simple exercice périphérique».
Les «bonnes» revues scientifiques ont un rôle à jouer. La publication d’un plus grand nombre d’articles considérés comme de véritables contributions scientifiques et dédiés à des plates-formes logicielles de recherche ouvertes constituerait un incitant fort pour les chercheurs en informatique.
Il apparaît urgent que les universités et les bailleurs de fonds changent de paradigme d’évaluation académique. Un élargissement des critères semble indispensable. Une prise en compte des contributions concrètes en matière de logiciels de recherche serait notamment la bienvenue, même lorsqu’elles ne se matérialisent pas dans des articles scientifiques. Mais ceci est une autre histoire…
Références
[1] Matthias Schwab, Martin Karrenbach & Jon Claerbout, «Making scientific computations reproductible», Computing in Science Engineering, 2(6), pp. 61–67, 2000.
[2] Darrel C. Ince, Leslie Hatton & John Graham-Cumming, « The Case for Open Computer Programs », Nature, 482(7386), pp. 485–488, 2012.
[3] Kendall Powell, « The future of the postdoc », Nature, 520(7546), pp. 144–147, 2015.
[4] Mark A. Musen, «Protégé: community is everything», International Journal of Human-Computer Studies, 62(5), pp. 545–552, 2005.
[5] Nick Barnes & Darnes Jones, «Clear climate code: Rewriting legacy science software for clarity», IEEE Software, 28(6), pp. 36–42, 2011.
[6] Pascal Francq, «The GALILEI Platform: Social Browsing to Build Communities of Interests and Share Relevant Information and Expertise», Dans Open source for knowledge and learning management : strategies beyond tools, Miltiadis D. Lytras & Ambjörn Naeve (éd.), Idea Group Publishing, pp. 319–342, 2007.
[7] Bjarne Stroustrup, Software development for infrastructure, IEEE Computer, 45(1), pp. 47–58, 2012.
[8] John H. Holland, Adaptation in Natural and Artificial Systems, University of Michigan Press, 1975.
[9] Marc Audétat (dir.), Sciences et technologies émergentes: pourquoi tant de promesses ?, Hermann, 2015.
[10] Lindell Bromham, Russell Dinnage & Xia Hua, « Interdisciplinary Research Has Consistently Lower Funding Success », Nature, 534(7609), pp. 684‑687, 2016.